The Future of KM Will Require Some Effort

In my latest whitepaper, “Building the Knowledge Management Hypergraph” published through InfoGovCon, I decided to explore an idea I’ve had for a while about the nature of the Big Data problem for most enterprises. Not in the traditional sense of Big Data with massive amounts of structured, semi=-structured, and unstructured data compiled through transactional devices, machine learning, and the rapidly-growing Internet of Things (IoT), waiting to be sorted, mined, and analyzed. No, part of my thinking was that the Big Data within most organizations has more to do with the rapidly expanding size of our email systems, cloud-based file storage, and collaboration platforms, such as SharePoint. If the average SharePoint farm is over a terabyte of data and growing at 50 to 75% per year, and as the reach and capability of social and cloud-based technologies like the Office Graph exponentially increase the rate at which data grows, and the complexity of our data models, it seems to me that even the traditional document management platform is quickly dipping its toes into the Big Data waters.

Within my whitepaper, I set up the problem space this way:

The category of knowledge management has changed dramatically over the last decade, and even now — with the rise of cloud-based content management and collaboration platforms merged with machine learning and social networking capabilities — the rate of change is somewhat outpacing organizational ability to keep up. In a world where features are developed and released within days, rather than in multi-year cycles, organizations are trying to adjust to this new reality.

The basic needs of knowledge management have not changed: the ability to capture and store knowledge assets and intellectual property, and providing simple yet powerful search capabilities to allow employees to easily discover and retrieve them. However, the sheer volume of content is making both the storage of these assets, and the ability to retrieve it quickly and easily, a difficult proposition. And the more difficult it is to locate and retrieve your content and business-critical data, the less likely end users are to embrace the platform. Adoption and engagement have become key measurements of the success of knowledge management initiatives, and yet most organizations struggle to achieve their goals because they do not truly understand the failures of their platforms.

What is needed is a “knowledge management hypergraph.” A hypergraph is defined in mathematics as a generalization of a graph that can model the relationships between models, but with unlimited edges and nodes. When put in context of the social graph efforts led by companies such as Microsoft, Google, Facebook and others, the relationships between document artifacts and business processes are joined by and expanded upon by the relationships of readers, authors, team members, administrators, and anyone else who may interact with any single node, amplifying the relationships between nodes exponentially.

The premise of the paper is that our data is growing more complex, and therefore we need to approach knowledge management and content collaboration in a more strategic manner. We are good at collecting data, less effective at managing our data, and, in my opinion, failing at taking advantage of the knowledge and wisdom buried within our data. Which is a fundamental tenant of Big Data: we don’t know what is there, we don’t understand its potential value, therefore let’s keep everything, because we may eventually find out. Some of the latest technologies in search, social, and machine learning will help us improve the ways in which we capture, organize, and orchestrate our data – but not everything can be automated. In the paper, I outline four areas around which enterprises need to refine (or, more likely, build out from scratch) their strategies:

• Information and collaboration management – We need to take a more serious look at the primary platforms through which we create and consume content, such as SharePoint. The most recent AIIM.org survey investigating the success of SharePoint deployments (“Connecting and Optimizing SharePoint – important strategy choices”) reveals that only 11% of respondents feel that their SharePoint projects have been a success, just over half (52%) say they have aligned SharePoint with their corporate governance efforts, and yet 75% still have a strong commitment to making the platform work. While most respondents claim that a lack of executive support is one of the primary causes of these failures, in my experience it is a chicken-and-the-egg argument. If you fail to go into the project (a SharePoint deployment) without a clear idea of the end state, the business value you will achieve, and the measurements necessary to show that business value, most executives will find it difficult to give their support, viewing it as yet another IT boondoggle. On the flipside, I have also seen projects with strong executive buy in (call it “intuitive leadership”) work their way through these deployment and measurement issues, because their management agrees that the platform is “directionally correct” and provides both qualitative and quantitative benefits. Ok, I made this bullet a lot longer than I had intended. Onto the next one…
• Capture and correlation – Part of our operational excellence efforts is to continually improve the quality of our inputs and outputs. In this case, constantly refining, revising, improving our methodologies, our content, and our metrics. One major aspect of this activity is building a strong information architecture, ensuring that as content goes into the system, it is correctly “mapped” to related content. Context is everything. I spent the good part of a decade writing about and speaking to audiences about pattern development, identification, and reuse as a way of improving the product development process. One of the reasons I am such a strong advocate for Glyma is that it is a SharePoint-based toolset that focuses on correlating content. Having a map of your key business processes, for example, allows you to locate and use individual artifacts on their own, as well as better identify related material. The Glyma website has a number of case studies and use cases that help illustrate this point.
• Social interaction – Yes, I talk about and write about social a lot. That’s because I’ve been working with social tools for two decades. My college roommate was at AOL in the early 90’s, and added me into an AOL Instant Messenger beta group way back when. Groove was released while I was working on my MBA  in the late 90’s and replaced our FTP server for sharing content and collaborating on team projects. My startup Qoses Inc. created social-based project management tools in 99/00, and my team at E2open integrated WebEx into our hosted collaboration platform back in 2001. So yes, I am quite serious about social. But aside from my background, its just the way in which people work these days. We are social creatures. We share, we
  rate, we Like, we comment, we link to it – all of which adds context, adds metadata, and adds to the complexity of the content we store.
• Search and dissemination – and finally, at the center of it all, is search. No way around it: if we fail on the search experience, the rest of our planning was all for naught.

Rather than summarize the remainder of the whitepaper, I encourage you to download a copy (hey, its free) and join the discussion over on Yammer.com/SPYam