Understanding Context within Knowledge Management

I’m in Copenhagen this week participating in the IntraTeam Event Copenhagen, which is run by IntraTeam.dk under the leadership of Kurt Kragh Sørensen (@KurtKragh), with a workshop on Microsoft Teams and information architecture, as well as a change management keynote. During my workshop yesterday, we had a quick sidebar discussion on the importance of context in collaboration — and in how you capture, search for, and extend (add to) your information assets.

I think it goes without saying that the category of knowledge management has changed dramatically over the last decade. When I got into the space back in the mid-1990’s, most of the solutions we deployed within our environment were hard-coded and inflexible, even for something as simple as a centralized team blog (a term which didn’t yet exist) or a contact/feedback form. Many of the tools and solutions we used even 5-7 years ago have become obsolete due to the rise of cloud-based content management systems (CMS) and collaboration platforms, which have been merged with artificial intelligence (AI) and machine learning based capabilities that make it a much more fluid, dynamic system. Of course, the rate of change can sometimes outpace our organizational ability to keep up. In a world where features are developed and released within days rather than multi-year cycles, companies are struggling to adjust to this new reality.

The tools we use to capture, store, and receive information assets may have evolved, but the basic needs of knowledge management have not changed. We still want/need:

• the ability to capture and store all of our knowledge assets and intellectual property, whether documents, images, files, audio, or video
• simple yet powerful search capabilities to allow employees to easily discover, retrieve, and share these assets
• the ability to automate the ways in which we classify, correlate, and add context to these assets

One of the primary mistakes made by organizations is to overly focus on the front-end user experience (UX) — an understandable over-emphasis on adoption and engagement — while neglecting many of the core business and IT requirements. The UX is important, for sure, but the long-term viability of any knowledge management or collaboration platform is tied to your ability to locate and retrieve your business-critical data. If end users cannot find the content they need in a timely manner, the less likely they’ll embrace the platform — regardless of the front-end features provided.

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. In other words, the failures of many knowledge management systems has shifted from the front-end to the back-end.

With the combination of standard information assets (instant messaging, email, documents, presentations, etc.), data from business systems (CRM and ERP platforms), social feeds, and the various machine learning data points that are increasingly being connected to all of our geographic, biographic, and psychographic profiles, we are generating massive amounts of data, year in and year out. With this increase, our data is growing more complex, and therefore we need to approach knowledge management and content collaboration in a more strategic manner.

Any organization’s operational excellence efforts should include efforts to continually review and improve upon the quality of inputs and outputs. Having spent a portion of my career in project and operational management roles, I am very familiar with the constant review, refining, revising, and improvement to methodologies, content, and metrics. Arguably, this is the core of most management roles, et al, with operations luminaries such as W. Edwards Deming providing best practices for management and quality improvement, as outlined in his 14 points.

One important lesson that I learned in building out collaboration environments was the importance of building and continually improving a strong information architecture, ensuring that as artifacts are added into the system, they are correctly “mapped” to related content and activities in the system, creating a vast web of connections between artifacts, people, and activities that add context to each. Because 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. 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. Of course, at the center of it all, is a strong search strategy. No way around it: if we fail on the search experience, the rest of our planning was all for naught.

Generally speaking, we are good at collecting data — but we are far less effective at managing our data. In my opinion, most organizations fail to take advantage of the knowledge and wisdom buried within their data, which skews their understanding of the benefits achieved from those systems.

This is a fundamental problem with knowledge management: we don’t know what we have, we don’t understand the value of what we have, and we don’t know how to get more value out of what we have. As a result, we keep everything, hoping to eventually find more value. 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. Information architecture is the key to adding relevance to this data, helping us to index and contextualize our information assets.