Knowledge management is a large and complex field, covering many elements, and applied in many different ways (see my blog post on 50 shades of KM for example). However there are a small number of Knowledge Management sub-components or modules which come up time and time again, and probably represent the main building blocks for KM.

Lego #5 by Antonio on Flickr

These modules are applied in different ways in different organisations, and use different processes, technologies and roles. Each of them delivers a certain amount of value; combined, they can create a complete Knowledge Management framework. Any one of them might be favoured in any particular industry.

The seven main KM modules are listed below.

1. Connecting people, through Communities and Networks.

Connecting people through Communities of Practice and Networks is the most popular module within Knowledge Management, applied (according to our global KM surveys) in three quarters of KM programs; Legal KM programs being the main exception. This module requires an effective set of Community software, but more that this, it requires governance, leadership roles, and community processes (see the ten success factors for Communities of Practice).  Through connecting people in this way, knowledge can flow from person to person, across silos and organisational boundaries.  Questions can be asked and answered, and individuals can collaborate on solutions.

2. Learning from Experience.

About two-thirds of KM approaches include some form of learning from experience, or lesson-learning (again, Legal KM programs often proving an exception).  Learning from experience can be applied at many levels; to teams, to projects, to products or to programs. It may involve After Action Reviews, Design improvements, Toyota A3s, Retrospects, and other techniques. But however it is applied, and however it is supported by technology and roles, the same principles of systematic gathering and re-use of new knowledge are needed if learning from experience is to be successful.

3. Creation of “Best Practices”.

The third most common KM module is the creation of some form of compiled and documented knowledge base. Whether you call it “Best Practices” or not, 60% of KM approaches address this issue of “gathering and synthesising what we know”. The home for this synthesised knowledge may be a Wiki, a Knowledge Asset, a Checklist, or even an Expert System. I am not talking about libraries here – the key to a Best Practice approach is developing and making available the Current Best Way to do something, and then continuously improving that “Best way” to make it even better.

4. Provision of Knowledge to external Customers

5. Better access to knowledge documents.

“Better access to knowledge documents” is a very common area of focus of Knowledge Management programs, although this verges into the adjacent fields of ECM and information management. Portals and Enterprise Search (even Semantic Search) are the key tools here for ensuring findability of documented knowledge.

6. Knowledge Retention.

Knowledge retention is a strategic approach to protecting against knowledge loss as experienced staff leave an organisation, and a whole variety of KM interventions can be applied to both retain and transfer the knowledge.

7. Innovation.

Innovation as a separate KM module deals with Knowledge Creation, often through development of innovation teams, creation of breakthrough innovation projects, and use of structured innovation processes.

Business sectors and the seven building blocks

As already hinted above, different business sectors tend to have a focus on different KM modules. Some of the main differences are as follows (and please bear in mind that most organisations address the first 4 modules, and many address all seven to varying extents).

• Connecting People is a core focus for multinational organisations, where knowledge is spread over many sites and many countries. Aid and Development organisations, for example, focus on Connecting People, as do the multinational oil companies.
• Learning from Experience is a core focus for Project organizations, such as Construction, Engineering and Aerospace.
• Best Practice is a core focus for service organisations, and for Manufacturing.
• Provision of knowledge to customers is a focus for Finance, Insurance, Retail and Educational organisations, as well as the development banks.
• Better access to knowledge documents is the core focus in the Legal sector, but is part of the KM Framework for almost every organisation.
• Knowledge Retention is a core area of focus for many organisations; typically Western Engineering and manufacturing companies concerned about reliability (Nuclear, Aerospace, Utilities etc) or growing organisations relying on the knowledge of a few experts. 
• Innovation is a focus for any competitive organisation, be it product innovation or process innovation, but is seldom the core focus for a KM program. 

However whichever building blocks you choose, the key is to link them up into your final framework, as no block stands alone.

Projects and the wider organisation are linked in a Knowledge-handling cycle

Please note, in this article you can replace the word “project” with “department” or “division” or “team” or “office” throughout.

The Boston Square here is one that I have used with projects as part of their Knowledge Management planning, and is a useful framework to allow projects to reflect about the knowledge sharing they need to do.

The thinking is as follows.

• The project knows some things
• The wider organisation (the centre, the functional departments and other projects) knows some things as well.
• At the start of the project, they need to learn as much from the wider organisation as they can. If there are important things the organisation knows but the project doesn’t, the project needs to learn these things.
• At the end of the project, if the project has learned things the rest of the organisation does not know, then the project needs to share this knowledge.
• At all other times, the project and the organisation should be in synch – in the green boxes in the diagram.
• If there is any knowledge held in the red boxes, meaning that the organisation doesn’t learn what the project knows, or the project doesn’t learn what the organisation knows, then this is evidence of organisational silos, and of the lack of knowledge sharing. 

The projects and the organisations are like two chambers of a beating heart, responsible for the circulatory flow of Knowledge

There are four key enablers for Knowledge Management – the 4 legs on the KM table.

• Roles and Accountabilities
• Processes
• Technology
• Governance

The first 3 are generally recognised as the “People, Process. Technology” trio, while experience over a number of years (and documented in the paper referenced above) has shown that without governance, the other three cannot be sustained.

It’s informative to look at what happens if any of these four are missing.

• If there are no roles and accountabilities, then Knowledge Management is nobody’s job (or else, it’s “everyone’s job” which soon becomes “no-one’s job”)
• If there are no processes for KM, then nobody knows what to do, or how to do it.
• If there is no Technology for KM, then nobody has the tools, and KM can never extend beyond the immediate and local
• If there is no Governance, then nobody sees the point. KM remains an optional activity, and nobody has time for optional activity.

There is a very close link between knowledge and performance, which is at the heart of any KM framework.

Knowledge results in performance. The more knowledge we have, the better we can perform. The more we learn from performance, the more knowledge we have. This puts us in a reinforcement cycle – a continuous improvement loop – continuously improving knowledge, continuously improving performance.

We are all well aware of this link as it applies to us as individuals. The more we learn about something, the better we get, whether this is learning to speak Mandarin, or learning to ride a bicycle. The knowledge builds up in our heads and in our legs and fingertips, and forms an asset we can draw on.

It’s much harder to make this link for a team, or for an organization. How do we make sure the organization learns from performance and from experience? How do we collect or store that knowledge for future access, especially when the learning takes place in many teams, many sites or many countries? How do we access the store of knowledge when it is needed, given that much of it may still be in peoples’ heads?

This link, between knowledge and performance, is fundamental to the concept of knowledge management.  Knowledge management, at its simplest, is ensuring this loop is closed, and applied in a systematic and managed way, so that the organisation can continuously learn and continually improve performance.  The  knowledge manager should

1. Know what sort of organisational performance needs to be improved or sustained (and in some organisations this may not be easy – the performance requirements of public sector organisations, for example, may not always be easy to define);
2. Know what knowledge is critical to that performance;
3. Develop a system whereby that knowledge is managed, developed and made available;
4. Develop a culture where people will seek for that knowledge, and re-use and apply it;
5. Develop work habits and skills that ensure performance is analysed, and that new knowledge is gained from that performance (using processes such as lesson learning or After Action reviews);
6. Set up a workflow to ensure that the body of knowledge is updated with this new knowledge; and
7. Be able to measure both the flow of knowledge through this loop, and also the impact this has on performance.

That’s KM at its simplest; a closed cycle of continuous learning and continuous performance improvement.

The complexities come in getting this loop up and running, in a sustainable way, in the crazy complex pressurised world of organisational activity.

But that’s what they pay us Knowledge Managers for, right?  Dealing with those complexities. Designing the framework that closes the loop. Delivering the value.

Ensuring that knowledge drives performance, and that performance results in new knowledge.

How much of  a Knowledge Management framework needs to be consistent around the globe, and how much can you vary on a local basis?

The answer is that you select certain global commonalities, but allow local expression of these. And the local expressions could be localised by geography or by corporate division.

There are several elements which need to be common, and applied globally.

• Knowledge Management needs a common vision and a common definition (see blog post on example visions). That means that KM, across the whole global organisation, is trying to do the same thing.

• Knowledge Management should employ common principles. Principles such as Shell’s “Ask, Learn, Share“, or the common “Learn Before, During and After” principle, need to be seen across the entire KM deployment.

• Knowledge Management should employ a consistent approach to Communities of Practice. CoPs are  likely to be one of the elements that cross the corporate geographical and divisional boundaries, so a common and integrated CoP approach is important.

• Knowledge Management should use a common global set of technologies wherever possible. One set of Community software, one Yellow Pages, one search engine, one Portal, one Lessons Management System, one email system, and so on. There may be technologies that apply to only one part of the business – CRM being used only by sales, and not by manufacturing, for example – but it should be applied globally to sales.

• Knowledge Management should be approached in the same way by Leadership. This will be expressed in a common KM Policy, and reflected in leadership expectations.

The elements which need to differ from division to division, are as follows.

• Embedding KM processes into business process. Each division will work with a different process. (Ideally processes should be harmonised globally within each division – if not, then this can be one of the early tasks that KM helps with). Therefore KM will need to be embedded differently, in different steps in the process, and sometimes using different processes. The Sales process and the Project Management process may be sufficiently different that each uses a partially different set of KM processes, embedding these processes in different places, but the principles of “Learn before, during and after” should still apply. Projects may “Learn before” by doing KM planning at the project start, while Production may do KM planning on an annual basis. Projects may “Learn After” through holding Retrospects, Sales through using Knowledge Exchange. The principles are the same, the local expressions of those principles are tailored to the business process.

• Embedding roles into the organigram. Each division will have a different organigram, so KM roles (which will be needed in all divisions – roles for knowledge creation and use, roles for knowledge ownership, roles for KM support) will be placed in different spots on the organigram. If the Projects division has a Project Management Office, for example, this could be the ideal home for the KM support roles for projects – the facilitators, the trainers, the lessons management team. If the Marketing division has regional hubs, this could be the ideal place for the KM support roles for marketing. And so on. 

So the implementation of Knowledge Management is set on global principles, adapted to local settings – all part of the work of defining the Knowledge Management Framework and the Knowledge Management organisation

When we review client Knowledge Management frameworks, it is often the same two elements that are missiong, or poorly developed.

One of the services we offer at Knoco is an assessment and benchmarking of client Knowledge Management Frameworks, to assess for completeness and maturity.

We do this in two ways, through a high level online self-assessment, and through a detailed diagnostic study where we conduct in-depth interviews and bring an expert eye to bear on your KM approach.

And you know what? There are some interesting patterns emerging from the results.

Let’s look at the average results from the online survey results first (top right; components are scored from 1 to 5) and look at the factors that, on average, receive the lowest score. These are:

• Roles and accountabilities (a lack of clear KM roles and accountabilities in the organisation)
• Business alignment (KM not aligned with business goals and objectives)
• Governance (no governance, for example no clear expectations, no performance management, no support)

If we look at the results from our detailed diagnostic analysis, we see a similar pattern. The diagnosis includes a more detailed analysis and different scoring levels, but if we extract the scores for the elements of People, Processes, Technologies and Governance, thenTechnology scores highest, Governance scores lowest, and People (roles and accountabilities) scores second lowest.

“Learning before, during and after” is one of the oldest models in KM, and still one of the most useful.

Learning before, during and after was one of the early bywords for Knowledge Management at BP in the 90s – a simple and memorable mantra that project staff can grasp easily and quickly. It forms the basis for an operating philosophy for KM, and describes how Knowledge Management activities can be embedded  within the cycle of business activity.

The management of knowledge, like any management discipline, needs to be systematic rather than ad hoc, and needs to be tied into the business cycle. In any project-focused business, where business activities (projects) have a beginning and an end, knowledge can be addressed at three points.

1. The project team can learn at the start of the project, so that the project begins from a state of complete knowledge (‘learning before’). This is where processes such as Knowledge handover and Peer Assist can be applied. 
2. They can learn during the project, so that plans can be changed and adapted as new knowledge becomes available (‘learning during’), for example through the use of After Action Review.
3. Finally, they can learn at the end of the project, so that knowledge is captured for future use (‘learning after’) and entered into the Lesson-Learned workflow.

These activities of “Learning before,” “Learning during” and “Learning after” can become an expectation, or even a mandatory activity, for projects.  This model of ‘learn before, during and after’ was developed in BP during the 1990s, and was also developed independently in several other organizations. Shell refers to this as “Ask, Learn, Share”.

However, there is more to the model than the ‘learning before, during and after’ cycle. The knowledge generated from the project needs to be collated, synthesised, and stored as Knowledge Assets (guidance documents such as SoPs, or Wiki-based guidance) in order that knowledge deposited in the “knowledge bank” at the end of the project becomes more useful when accessed at the start of the next project. Communities of Practice need to be established to manage and share the tacit Knowledge Assets.

 This five component framework (learning before, learning during, learning after, synthesis of knowledge into Knowledge Assets, and building Communities of Practice) is a robust model which creates value wherever it is applied.

Complex organisations may be involved in more than one type of activity, and may need more than one KM strategy and framework.

Two of the early activities in any Knowledge Management implementation are to develop a Knowledge Management Strategy (as we discussed yesterday), and start to map out a potential Knowledge Management Framework.  However a large organisation, with many different divisions working in different ways, may need more than one strategy and more than one framework.

Let’s take, as an example, a utility company, providing water and gas to consumers.

This imaginary utility company has a Projects division, which installs new pipelines and new processing plants.  They have a maintenance and operations division which maintains the supply of water and gas to customers. And then they have a customer care division, which signs up new customers and manages the relationship and the interaction with the existing customers.

This organisation might need 3 strategies and 3 frameworks. 

The strategy for the projects division will be about cost reduction, and ensuring that projects are delivered on time, to budget and to specification. The KM framework will focus on learning from experience in order to improve project performance, and will involve processes such as Retrospects and Peer Assists.

The strategy for the Operations division will be about operational reliability and the continued provision of service. The KM framework will focus on maintenance methods and best practices, and on sharing tips and hints in communities of practice.  

The strategy for the customer care division will be about customer satisfaction and customer retention. The KM framework will focus on provision of knowledge to customers, either through online self-help or via a contact centre, and the division will almost certainly need some sort of knowledge base software.

Although the whole organisation can share a KM policy and KM principles, each division will need to interpret these in their own context, and will need their own KM framework embedded in their divisional ways of working.

The goal of Knowledge Management is to embed an effecting Knowledge Management Framework, that enables a thriving KM culture and impacts organisational outcomes. But sometimes one Framework is not enough.

I have blogged before about the different sorts of Knowledge which need to be managed, and suggested that Knowledge Management may look very different if it is Process-focused, Product-focused or Customer-focused.

A process-focused organisation will set up communities of practice who develop Best Practices, while a product-focused organisation will set up product-based communities focused on Best Designs.  The solutions will be similar in outline, but different in detail.

However there are many organisations which have more than one focus, as shown in the Ternary diagram here showing results from the Knoco 2014 Knowledge Management survey.  Manufacturing organisations, for example (the red square in the diagram) are equally focused on Process and Product. Info and Media companies (blue star) are equally focused on Product and Customer. Professional services (yellow circle) are concerned with all three.

These organisations may actually need to set up more than one Knowledge Management Framework.

An example

For example, we are working right now with a manufacturing company, looking at the way it manages knowledge.  We have found that they are not doing too badly in terms of product knowledge, but really need to sharpen their process knowledge. To this end, we are recommending two KM Frameworks, which we can summarise as follows:

A Product KM framework including

• Knowledge Gap Analysis
• Toyota A3 process
• A set of Subject-matter-responsible engineers
• Development of engineering checksheets
• Linkage between the issues list, the checksheets and the failure-mode analysis

We often hear there is no “one size fits all” for KM, and sometimes there is no one KM solution that fits all parts of the organisation either.