Say what you like about the ISO KM standard; at least it encourages you to address KM in the correct order!

There are many approaches adopted for introducing KM, and not all of them work well. For example the historically common approach of “Technology Push” – where an organisation seeks to buy a KM technology as their first step into KM – is usually a recipe for failure. It is still common today – I have many enquiries from organisations who say “we are starting up in KM – help us choose a technology”.

Starting like this, from the KM tool, is starting KM the wrong way around.  There is no point in choosing a tool until you are clear what you are doing KM, for who, and with what objective; until you understand the stakeholders and objectives, and also the other elements of the KM Framework which need to be in place.

This is where the beginners in KM will find the new ISO standard – ISO 30401:2018 – particularly useful (contact us for a free white-paper introduction to the standard). In common with all other ISO management system standards, IOS 30401:2018 follows a defined structure (described here) which doubles as a logical sequence for building your KM Framework. ISO have standards for many management systems, they know how they work and how to introduce them, and the logical sequence is based on this experience.

This sequence is described in sections 4 through 10 of the standard as follows;

• First you become clear on the organisational context for KM. Why do you need KM? What will it do for the organisation? What are the external and internal issues which make KM important to you?  This answers the WHY question – why do you need KM? It ties KM to the strategy of the organisation right at the start of the KM thought process; well before you  think about tools.
• Secondly you become clear on the stakeholders for KM, and what they need from the KM framework. This is another way of looking at KM objectives. In the previous section you decided what KM would do for the organisation, in this section you think through, and document, what it will do for the stakeholders. 
• Thirdly you look at the scope of KM. What is in scope, what is out of scope, what will KM focus in and what it will ignore, what part of the organisation will be involved and what parts will not. 
• Only then do you define the Framework – the elements of roles, processes, technology and governance, and how these will affect the culture of the organisation. You look at an integrated framework that covers the lifecycle of knowledge, and covers knowledge in all its forms and transitions. 
• Once this is in place, the standard requires you to look in more detail at the leadership elements that support the KM framework, including the assignment of accountability.
• Then you look at planning and objective setting for KM.
• Then you look at support resources for KM.
• Then you look at how KM operation, KM monitoring and performance management, and finally continuous improvement of the KM Framework.

Now THAT is KM “the right way round”

There are a number of strategic approaches that you can apply when implementing Knowledge Management. All have their failings – we recommend a combination of two of them. 

There are many and varied ways to introduce KM to a company, and a lot of these fail. The main 6 strategies are listed below, with their arguments for and against; probably the worst approach (and one of the most commonly applied) is number 5.

Our recommendation, for almost all clients, is a two-pronged strategy of piloting and trials, plus opportunistic quick wins (a combination of numbers 3 and 6).

This is a reprise and rewrite of a post from 5 years ago about KM change models vs KM maturity models. AKA “why KM change is more like spread of a forest fire than the growth of a tree”.

Photo from the US National Parks Service

The use of a maturity model allows an organization to have its methods and processes assessed according to management best practice, against a clear set of external benchmarks. Maturity is indicated by the award of a particular “Maturity Level”. The majority of KM maturity models (and ours is no exception) have a series of descriptors of various levels of KM maturity, and the implication is than an organisation can progress from one level to the next in a smooth maturation process.

The analogy, if you like, is that of a tree. As a tree matures, it passes from a seedling to a sapling to a mature tree, but this is a continuous progression. You can describe, using metrics such as the number of branches, size of trunk, number of fruit, where the tree is on its maturation journey. If you won an orchard, you can describe the average maturation level of the trees as (for example) 2.5 on the maturation scale.

Knowledge Management is more like a forest fire than a tree.

A forest fire does not mature slowly. It catches in one small place, then sweeps across the landscape.  In a forest fire, change is not top-down nor bottom-up, but side to side (see my blog post http://www.nickmilton.com/2019/07/km-change-is-not-top-down-or-bottom-up.html for more detyails. A forest fire is not a maturation process, it is a phase-change, from unlit to lit. There are various measures of readiness for forest fires – they can be enabled by hot weather, strong winds and a build-up of combustible material, or disables by fire-breaks and rain – but it still is not a process of maturation.

I am aware as I write this that a forest fire is also a highly dangerous life- and property-threatening phenomenon and a lethal consequence of global warming. If you find this metaphor too negative, please use another, such as kindling a bonfire, or adoption of a virally-marketed product.

Knowledge Management is a forest fire rather than a tree, because implementing KM is a culture change process. It involves changing hearts and minds, and hearts and minds are changed one at a time. We have all seen the moment when a heart/mind changes and someone “gets lit”. It’s that lightbulb moment, like “catching fire”. There is no maturation for a process, only the question “has it caught fire”. Once it has, the question becomes “how much is burning”.

I describe here a change model for hearts and minds which you can apply to your key stakeholders, that takes them up to a commitment threshold, beyond which KM can be adopted. Below this threshold they are unlit kindling. Above this threshold they are alight.

KM then works only if all the conditions are sufficiently right to change the hearts and minds. Once the conditions are right, you light the KM fire in a small part of the organisation (a KM pilot), and once this is burning, adjacent areas will also catch fire, until finally the whole area has caught the KM habit.

That’s the change model – what’s the problem with maturity models?

Maturity models are popular, and give the organisation a chance to compare themselves against a standard, and to identify room for improvement. This can be a useful check, but maturity models have a number of drawbacks (for a deeper discussion, see chapter 27 in the new edition of the Knowledge Manager’s Handbook).

• The first is that the model may have gaps or be based on inaccurate assumptions. There are many maturity models, for example, which ignore the issue of governance, and others that include content as a key component (thereby assuming that Knowledge Management is basically Content Management). Choose your model wisely, or (better) use more than one.

• Most maturity models make assumptions about the sequence in which things have to happen, and these assumptions do not hold true universally. 

• I large and complex organizations, where the organizational landscape is heterogeneous, a maturity model tends to gloss over or average out significant differences in portions of the landscape, removing them from visibility and opportunity for action. The maturity model may say “the forest is cool” when in fact the fire is already blazing somewhere local.

• Finally, as discussed above, KM implementation is not one of gradual maturation across the organization at large, but of spreading the adoption of a new paradigm, and thus the idea that the organisation matures in a stepwise process is inappropriate.

Take Leadership, for example.

Senior management support is the biggest enabler (and lack of senior management support is the biggest barrier) to KM. Leadership is vital. Imagine a leadership scale from 0 to 4. Imagine you have moved leadership from level 1 to level 2. Is this progress?  If level 4 is “whole–hearted support from senior management”, what is level 2? Half-hearted support? That’s as bad as no support at all. Until you get to level 4, you don’t have what you need for sustained KM.

Rather then trying to move the whole organisation to level 2, why not find the one leader who you can help reach level 4? Leave  the rest at level 1 for the moment, and find the early adopter. Gain their whole-hearted support to pilot Knowledge Management in their part of the business, deliver success, and use this to change the next Heart and the next Mind.

The indicator of progress is therefore not the average level of KM leadership maturity, but the presence or absence of the “first sponsor” in the organisation.

What is the conclusion regarding maturity models?

For all these reasons, maturity models are much better used:

(a) not for assessment and objective benchmarking, but as part of an internally driven diagnostic and planning mechanism along with a lot of independently gathered data, where the question is not “how mature are we against external assumptions?” but “what can this external model suggest to us about our strengths and weaknesses, and which of these areas should we prioritise based on known needs?”; or  

(b) in homogeneous, well defined contexts such as communities of practice, knowledge-base development, or expertise transfer, where there are specific, well-known good practices and reliable precursors that hold true in most cases.

In Knoco, we actually do offer a maturity model, which we offer as a free online survey (choose Maturity Survey in the box at the top of the page). It is of some use, but treat it with caution for all the reasons mentioned above.

In addition we suggest you measure a number of other things;

• The state of your Organisational Learning culture, to identify the major cultural barriers and enablers, and to enable you to target your change campaign (this is like the readiness conditions for a forest to catch fire).
• The completeness of your Knowledge Management Framework, in order to identify those parts of the business where it is most complete, and also to identify where you need to fill gaps
• The degree of management of specific knowledge topics, in order to identify areas for priority attention
• The level of buy-in of key stakeholders
• Once change has started, the progress of change across your organisation
• Once implementation is completed, then
  • Compliance with KM expectations
  • Compliance with the ISO KM standard
  • KM activity levels

The real message behind all of this is that KM is a change program, and needs to be measured using change models.

KM does not mature like a tree; it catches hold like a flame, and that is how it should be measured.

In a post from 2009 (no longer available) Lucas McDonnell provided 6 signs that your Knowledge Management strategy could be in trouble. I have added 4 more.

Image from wikimedia commons

Lucas’ 6 signs are as follows, with my comments in brackets, and then I add a few more trouble signs of my own.

1. People outside your group don’t understand what you’re doing (a failure in communication);

2. You keep changing vendors/technologies/products (often a symptom that technology alone is not working, which also means that changing technology won’t help);

3. You keep layering vendors/technologies/products on top of each other (this seems like a “sweetshop” approach to KM, rather than a strategic view of what technology is needed, as modelled by Schlumberger);

4. You find it difficult to explain what you’re trying to accomplish (because you do not have a business-led strategy);

5. You’re prescribing organizational change (by which Lucas means that change is prescribed, rather than delivered through solving a series of business problems);

6. You’re making big promises (I struggle with this one a bit – but Lucas means “don’t overpromise”).

I think we can add a few more signs to this

7. All you are focusing on is vendors/technologies/products, rather than on a balanced framework of roles, processes, technologies and governance;

8. You are  selling KM on its own merits, not on value to the business; 

9. You still haven’t an case studies of KM adding value; 

10. Nobody outside your group has started doing KM yet.

Some of these warning signs (2, 3 and 7) show that you are operating a model where vendors, technologies and products take centre stage. Others that you are not communicating, and in particular not communicating value) (1,4, 8). Than there is a third group, which suggests you are going for a top-down prescribed approach, rather than an agile approach (5, 8, 10).

The solution to this is simple.

1. Introduce KM as a holistic framework
2. Communicate, and sell KM on the value it will bring to the business and the individual
3. Use an agile approach, deploying proofs of concept and pilots.

Watch out for these warning signs, and avoid the crash

Implementing Knowledge Management requires two parallel strategies, like the two prongs of a fork.

There was a very interesting article by Ron Bascue in the 2011 Fall edition of the US Army KM newsletter (now no longer available online), about a twin-strategy approach to delivering a Knowledge Management strategy.

Ron makes the point that Knowledge Management needs to be a strategic long term program of change, based on thorough assessment and analysis,  while at the same time people need to be able to see short term progress, see KM in action, and understand the value it brings. As Ron says;

“Getting to a fully developed KM strategy takes significant time. And while the assessment and strategy development process is going on, the parent organization is moving forward while the clock is ticking on the KM organisation to show its value.”

So Ron recommends a two-pronged strategy to address this issue.

“Our approach incorporates two lines of effort; one a strategic development effort and the other focused on providing immediate tangible results – a series of quick wins”.

Ron recommends Kaizen events as a way to deliver the quick wins, each of which should solve a business problem or improve an internal process. However a number of Knowledge Management processes could be used, depending on the nature of the problem to be solved;

• After Action Reviews for improving team delivering, 
• Retrospects for capturing team lessons, 
• Communities of Practice for improved knowledge sharing, Peer Assists for bringing knowledge into projects, 
• Knowledge Assets for creating knowledge resources, and so on.

Ron’s two-pronged approach is also what Knoco recommends.

We refer to the Quick Wins as “Proof of concept” events; small interventions with a Knowledge Management tool or process during the Strategy Creation phase, just so that people can see KM in action, and realise that “Yes, it can work here. No, it’s not all smoke and mirrors. Now I understand”.

However even after the strategy is complete, the KM team needs to continue to solve business problems. However rather than small proof of concept exercises, you move on to larger scale Pilot Projects as part of the Implementation program.

By solving business problems, the KM team continue to show the value, and engage people in the process without requiring them to buy in at strategic level.

Follow Ron’s advice (and ours) – make pilots and “proofs of concept” part of your twin-strategy Knowledge Management implementation.

In a great blog post, Seth Kahan shares 7 lessons on KM change programs 

In the post from 2009, Seth talks about leading KM change at World Bank, and contrasts his first KM initiative (which failed) with his second (which succeeded).

The first initiative was “was comprised of a few select, world-class thought leaders who drew on a dedicated budget to design and implement a powerful new tool they hoped would revolutionize the way business was done. We met in closed meetings, witnessed remarkable demonstrations, and marveled at the power of the Internet to spread knowledge.”

In other words, KM was being pushed by a closed group, who were “preaching only to the choir“. Unsurprisingly, nothing came of it.

The second initiative, with no budget and no resources, “told everybody what we were up to. In fact, we spent a good deal of time in the beginning figuring out how to tell as many people as we could, as fast as possible. We even met regularly with our detractors, as their input was sometimes needed the most”.

The second initiative was being run as a change program, with communication extending beyond the closed group of supporters, and engaging with everyone.  And within 2 years, it had changed the organisation.

Seth’s seven lessons for Change

Seth identifies seven lessons for KM change based on his experience

1. Communicate so people get it and spread it. As he says though, this is not one-way communication, but a conversation that spreads

2. Identify and energize your most valuable players. These are your supporters, your early adopters, who can be used to drive KM forward.

3. Understand the territory of change. Seth had a method for mapping stakeholder support, and a similar stakeholder mapping will be valuable for you (see here for a possible method).

4. Accelerate evolution through communities. This one, I think, may be specific to the World Bank. Communities of Practice worked well there, because of the large dispersed nature of the work. Smaller co-located organisations may find other ways to introduce and implement Knowledge Management; perhaps through After Action reviews, or focus groups. You need to work within your own Knowledge Management Strategy and Knowledge Management Framework.

5. Blow through bottlenecks and logjams. Seth suggests a “SWAT Team” mentality.  But please don’t bulldoze people!

6. Create dramatic surges in progress. Seth suggests special events to drive progress. Another way is to create energy around early successes; those Proof of Concept  exercises where Knowledge Management first adds real value to the business.

7. Keep your focus when change comes fast. When KM is successful, it can accelerate alarmingly. Stay cool – it’s all good!

Contact us for more details on leading change management as part of Knowledge Management implementation

Implementing Knowledge Management into an organisation will not happen accidentally. It happens by a deliberate decision. Or rather, it happens by a series of decisions.

Very few CEOs will wake up one morning and announce that the organisation will now be adopting Knowledge Management. Instead, like any other change, implementation is a series of investigations and decisions, and each decision rests on a basis of necessary evidence.

The chain of decisions is as follows.

1. The decision to investigate whether Knowledge Management would be something worth pursuing for your organisation. This is a decision to commission a task force, or some studies to gain some idea of whether KM is something the company needs to invest in. The task force will need to do some investigation, and see whether a business case can be made for KM.

2. The decision (based on evidence from the task force) that the organization needs improved Knowledge Management, and to proceed to find out how much investment is required. The task force will need to assess the current state of KM in the organisation. If the assessment shows that improvement in KM is needed, then further work is needed to scope out the scale of the implementation, to set the strategy, and to do a first-pass costing of what the implementation exercise might cost.

3. The decision (based on evidence from the assessment) to set up a KM implementation program, with a full-time team and budget. Once the organisation understands the scope of the KM implementation exercise, they fund a team and get going. At this stage they will have a KM strategy and implementation plan, and can conduct some proof of concept exercises as a trial of KM in the organisation.

4. The decision (based on the strategy) to pilot KM in high profile areas. If the small scale trials are successful, and KM has not fallen flat on it’s face or run into political road blocks, then the company may decide to scale up, and run some full scale pilots to fully road-test an integrated KM framework. By this time, KM is becoming quite high profile, and quite high cost.

5. The decision (based on evidence from the pilot) to roll out KM as a required discipline to the whole organisation. The pilots were successful, the value of KM to the business and to the employees is proven, and the integrated KM framework is robust. Now is the decision – not to be taken lightly! – whether to roll out a KM framework to the whole organisation, as a part of the company management framework. This is the point of no return.

6. Once KM is embedded, the decision to stand down the implementation team and hand over to management within the business. Once roll-out is over, the company has to decide when to stand down the implementation team, and hand responsibility for KM over to a steady state organisation

Treating KM as a series of incremental decisions has two main benefits.

• Firstly, it allows incremental investment rather than ‘trust me, it will work out OK’ management. This is sensible prudent decision-making. The investment in each stage will be a little larger than the previous stage – a task force costs less than a team, which costs less than a series of pilots, which costs less than a roll-out campaign. Each incremental increase in cost is built on a decision, which depends on the results of the previous stage, and on how well KM has proven itself. And at any point up until decision 5, the company can change its mind, because it is not fully committed. Beyond step 5 the company is committed to roll-out.

• And that’s the second advantage. If each decision is made by the right people, based on the right information and the right criteria, then you shouldn’t have to revisit the decisions later. Each decision should be documented, and should stand on its own merits; without assuming a benefit that hasn’t been delivered yet. You shouldn’t have to keep re-justifying, and remaking decisions.

So who are the right people to make the decisions? They need to be senior, and they need to have authority to spend the money. Decision number 5 – the decision to roll out KM – needs to be made at the highest level. You need the support of the CEO to make a company-wide change like this.

However by the time it comes to decision 5, you will have a series of successful trials and pilots that demonstrate that KM works in your organisation, and delivers real value.

In the early stages of Knowledge Management – even when you are still drafting the Strategy – you may need to deliver a “Proof of Concept” exercise.

Proof of?, a photo by katmeresin on Flickr.

This is a small intervention with a Knowledge Management tool or process, just so that people can see it in action, and to show that “Yes, it can work here. No, it’s not all smoke and mirrors”.

This is not the same as a full-scale pilot, nor is it part of implementation – it’s a “Look at this” exercise.

Suitable proofs of concept might include the following;

A retrospect on a tricky (or successful) project. For one of the companies we have worked with this was a project that had gone disastrously wrong, and they effectively said to us “if you can get learning from this project, then we will believe what you say about Knowledge Management. We did, and they did.  

A Peer Assist for a high profile project. This  has been the proof of concept for many companies – a straightforward demonstration that valuable knowledge can be shared between projects teams, and can make a positive impact to project plans.  

A Knowledge Exchange on a key topic. For another organisation, the proof of concept was getting experts together from all over the world to build company Best Practice on bidding and winning PFI contracts. 

A Knowledge Asset on a key topic. For a third company, who was going through a series of mergers, this was a Knowledge Asset to summarise “what we have learned about mergers.” 

A Community of Practice launch. One organisation was seeking to develop knowledge sharing behaviours, and a successful community launch gave them the evidence they needed to move forward 

A retention interview from a departing expert. This has been the proof of concept for many a Retention strategy. Management want to see what is possible, and they want to see the output, in order to prove that retention can generate valuable output.

In each case, you should seek to create two things from the Proof of Concept.

The first is some valuable knowledge, either exchanged between people, or captured as lessons, guidance, tips and hints, or FAQs

The second is stories, or feedback from the people involved, saying “Hey, we tried this knowledge management thing, it was great, it was not difficult, and it created real value”.

It is through these stories that the concept is “proven”

Why is it that so many KM implementations never seem to learn the lessons of the past?

George Santayana quote by Mel_DJ on Flickr

We know by now what makes KM work. We know the 7 secrets of success for KM, and the 7 most common reasons for failure. We know the principles, we know which KM strategies succeed and which ones fail.

So why is it a sad fact that so many KM implementations continue to fail?

Here are some potential reasons why this happens

1. People who own KM initiatives are human beings, and as prone as other human beings to rush in without “learning before”. So they reinvent the wheel yet again. That’s why KM is needed in the first place – to influence people to value and to access and ro reuse knowledge, because this is not natural human behaviour; not even for the KM implementors.

2. People are prone to the common fallacy that “we are different – the lessons of the past do not apply to us” (the “we are different” fallacy is one of the 5 most common objections that you have to face as a KMer). Sometimes this is expressed as “people these days (Gen Y, Gen Z, whatever) are different – the lessons of the past will not apply to them”.  Still a fallacy I am afraid, though one that KMers are prone to as much as anyone else.

3. KM is simple, but difficult. It is very tempting to go for a mixture of an easy option and wishful thinking, though the easy option will fail.  The illusion of knowledge is one that applies to all humans.

4. People will offer you miracle solutions – usually technology solutions. “Buy our software, and knowledge will manage itself”. In 20 years of knowledge management, technology has never been the solution (though it has always been part of the solution – about 25% of the framework is technology).  Believing that it will save you this time, is wishful thinking again.

5. There is a lot of pressures from management to do KM on the cheap, quickly. and with minimal disruption. Unfortunately KM requires investment, it requires time, and (being a change process) causes disruption. You can fail quickly cheaply and non-disruptively, but you can’t succeed. It’s your job, as a KMer, to show management the investment of time and money that will be needed, and the value that KM will deliver in return. Be strong – make your case.

6. Maybe you don’t know which lessons to trust. There are many dissenting voices in KM, and many people who will tell you many different things. In the past KM has no “authoritative voice”. Now at least we have the ISO Standard 30401:2018; the Management System standard for KM, and part of the reason this standard was written was to help people avoid the pitfalls of the past. If you do nothing else in your new KM program, buy the standard and use it as a guide.

Those of us who have been working with KM for over a decade (since ’92 in my case, with BP for 7 years, then consulting) have a pretty good idea of how KM implementation can be done, and it is really frustrating seeing people jumping in and repeating the mistakes from the past. The collateral damage is that partial KM implementations, which deliver minor results then fizzle out, devalue KM, and spread a feeling that “KM doesn’t work”

KM does work, when the KMers learn and apply the lessons from the past. The successes and the failures of past KM programs have generated a wealth of knowledge about the effective application and implementation of Knowledge Management. This is knowledge of huge value to you.

Use that Knowledge, ladies and gentlemen. Others have striven to generate that knowledge, so that you, if you can avoid the temptations listed above, can guarantee success.