Why "85% of KM initiatives have no stated objectives" is a scary observation

If it is true that 85% of KM initiatives have no stated objective, then its no surprise they so often fail.

Image from wikimedia commons

In an unpublished 2011 presentation, now unfortunately no longer on the web, Bob Armacost quoted the results of a survey run by KPMG as follows:

• "80% of companies in a recent survey said that they had KM initiatives under way
• Of those companies, 85% had no stated objectives for their KM initiative".

 I suppose it depends what you mean by "stated objectives", but even so, that's a scary statistic.

Given that so many KM initiatives fail, then to start an initiative with no clear business objective is surely a rash thing to so.  Clarity of purpose is one of our 7 top success factors for successful KM implementation.

So what sort of objective might the KM initiative have?

ISO 30401, the ISO management systems standard for Knowledge Management, in its very first "requirements" clause, talks about having defined "Outcomes" for your KM initiative. The outcomes are the business results you want to achieve, set by the business drivers for attempting KM in the first place.

Our KM surveys in 2014, 2017 and 2020 tested 7 business drivers, and found they were ranked as follows, with high numbers equating to high ranking:

• KM to improve operational effectiveness - rank 5.2
• KM to increase internal efficiency (time and cost) - rank 5.1
• KM to provide a better service to clients and customers - rank 4.7
• KM to retain knowledge at risk of loss - rank 4.4
• KM to improve internal innovation - rank 3.9
• KM to enable company growth - rank 3.5
• KM to improve health, safety or environmental record - rank 2.4.

Each of these is a potential outcome. Depending on which business driver is relevant to your organisations (and different industries have different drivers for KM), then impacting this business driver must surely be a stated objective for KM.  If your organisation wishes to become more efficient through the use of KM, then one stated objective of your KM program must be to improve efficiency, measured through reductions in cost and time.

You can map your KM initiatives onto this objective using a strategy map, you can put metrics in place to measure KM activity, and you can seek anecdotal or even measured evidence that KM activity is linked to delivery of this business objective. 

You can then declare an objective such as "Improved knowledge management will deliver efficiency improvements in our capital projects resulting in an average 5% cost reduction against the 2016 baseline", or "Improved knowledge management in our contact centres and online customer support will result in a 5% improvement on Net Promoter Score against the 2016 baseline."

The value of a clear objective and outcome

It may initially seem scary to link KM to a measurable business outcome, but let me tell you three things:

• Lots of people have done it, and this blog contains over 100 examples of metricated business impact from KM
• Your senior management will really appreciate it, and your KM program will be all the safer from having a clear link to business deliverables. No manager will support the development of KM for its own sake, but will support it if there is stated value to the organisation;
• You will find this business objective clarifies your KM program considerably, and allows you to focus only on those things that add real value. It will make your life simpler and clearer.
• You will find it easier to map, measure and report progress.

Don't be part of the 85% with no defined objective. Get smart, and define clear goals.

The 12 steps for implementing KM in a problem-focused way

One of the more effective ways to introduce Knowledge Management is through solving a series of business problems. Here is a 12 step approach to doing just that.

Image from wikimedia commons

I came across this paper by Ray Dawson, professor of KM at Loughborough University, proposing a 12-step approach to KM implementation based on the successive solution of a series of business problems. Ray illustrates his 12 steps with case studies of implementation of KM technologies.

A similar approach was implemented at Mars to great effect, and is one component of our favoured KM implementation strategy alongside a longer-term framework-based approach.

Here are Ray's 12 steps in bold, with my commentary.

1. Undertake a problem audit to identify a recognised problem. Start by targeting a problem in the company that is manageable in size, knowledge-related, and also widely recognised by all staff concerned. 
2. Find out how bad the problem is.  If there is a problem then there will be a cost as a result, and these cost figures give a baseline upon which a return on investment for KM can be measured. 
3. Find a knowledge management solution in the context of the problem. 
4. Check the cost of the proposed solution so you can calculate a business case.
5. Check the value for each individual. A new knowledge management initiative has two stakeholder groups - it must have financial benefits to a company, but it must also give value to each individual employee that must make it work. 
6. Get buy-in from management and individuals based on the business case for the identified problem alone. The knowledge management initiative must be “sold” to both management and users. 
7. Involve the users in the solution. Users should be involved in the requirements process and design of the new KM approach. 
8. Plan for systems operation as well as the implementation. Neglecting to plan for the operation of a system is likely to mean any initial success cannot be sustained. 
9. Implement the solution 
10. Evaluate the actual savings made. You can find many examples of such savings on this blog.
11. Use the evidence of success to achieve a wider KM rollout and to get buy-in for new initiatives. This is the social proof aspect we discuss here. The solved problems act as proofs of concept and pilot projects for the wider initiative.
12.  Use smaller knowledge management projects to build bigger projects.  Large projects can be broken down into smaller projects that can each be implemented with the first 11 steps of this knowledge management implementation methodology. In this way the company can work towards the larger integrated system to which it aspires. 

This is a very practical approach to KM implementation which we entirely endorse here at Knoco. The smaller problem-led pilots help build the KM structure brick by brick, and lead you towards implementation of a complete Knowledge Management Framework

The 5 key skill areas for a KM implementation team

Here are 5 key skill areas you must not ignore when putting together your Knowledge Management implementation team. You need to have all of them on the team.

Image from wikimedia commons

You know the four enablers of People, Process, Technology and Governance? What we call the four legs on the KM table?

These four areas should be reflected in the people and skills you choose to drive Knowledge Management implementation.

KM covers the area of overlap between IT, HR (or Learning and Development), Organizational Process and Management, and so the KM implementation team needs a blend of people who can cover these areas. So we need the following skills on the KM implementation team, plus one more skill as described below.

People Skills
If the aim of the KM team is to introduce new behaviours and practices to the organisation, they will need people skilled in training, coaching, mentoring and facilitation. It may be useful to have someone on the team with an HR, training or business coaching background. Get some facilitation training for whole team as well.

Process skills
The team need experience and skills in the operational processes of the business.  The KM team should contain people with good and credible backgrounds and skills in each major organisational subdivision. This is really to establish as much credibility as possible. When members of the task force are working with business projects, they want to be seen as "part of the business", not "specialists from head office who know nothing about this sector of the business". They have to be able to "talk the language" of the business - they need to be able to communicate in technical language and business language. They act as Best Practice champions within their area of business, and when the working task force is over, may take a leading Knowledge Management role in their subsidiary.

Technology skills.
The KM team needs at least one person who has strengths in the details of the current in-house technology, understands the potential of new technology as an enabler for knowledge management, and can help define the most appropriate technologies to introduce to the organisation.

Governance skills.
Finally the Km team needs a person who can look at KM from a high level - who can understand how it fits into the governance systems of the organisation, and who can work at a high level to introduce the policy changes and the governance systems that are vital to the long term survival of KM. This person can be the KM team leader, or even the executive sponsor.

Change Management skills

Even if you have the 4 skills areas that map to the legs on the table, there is still one more skill area you need - Change Management. The knowledge management implementation task force has a hard job ahead of them, changing the culture of the organisation. They will be working very closely with people, often sceptical people, and they will need very good influencing skills. Look for people with skills as change agents and influencers. Also the early stages of implementing knowledge management are all about raising awareness, and "selling" the idea. The KM team needs at least one person who is skilled at presenting, communicating and marketing/selling KM. This person will also be kept busy raising the profile of the company's KM activities at external conferences. 

If the KM Table has 4 legs, then make sure there are people on the team with enough skills to look after each leg, to  make sure your final framework is sturdy and sound, and then add one or more people who are skilled in fostering Culture Change. 

Focus your KM first steps.

To start with, you don't need Knowledge Management to be applied everywhere - only in the few places where it makes a difference.

FOCUSR by Libertarian Girl on Flickr

There is always a balance to be struck between burden and value. KM involves extra work - it involves attention to an asset (knowledge) that previously people could ignore. If you focus your KM efforts in those places where the value most outweighs the burden, then your KM program will be welcomed far more than if you apply the KM burden everywhere.

I was reminded of this in a conversation with a client. He was concerned that KM would founder due to lack of resource and prioritisation in the projects.

"Everyone is really busy" he said. "If you put requirements for knowledge work onto the projects without giving them extra resources, nobody will change the way they work".

"What if" I replied "we only asked the most important projects to deliver lessons and knowledge products? The high profile, high risk, flagship projects?"

Immediately his tone brightened.

"That would work" he said. "Those projects already have extra attention and extra resource. They really want to tell their story, and management really want to hear the results. I could see that working, and the other projects, the cookie cutter projects, we could just leave them alone for a while."

By focusing Knowledge Management on 20% of the projects, this client can probably get 80% of the value with 20% of the effort. Later, when KM becomes second nature to the flagship projects and the value has been proven, maybe they can bring in the second level of projects, then later the third.

If you take a strategic approach and focus your initial KM efforts, you are far more likely to get buy-in.

How long does Knowledge Management take to implement?

Introducing Knowledge Management is likely to take a decade before it is fully embedded. Here are some benchmark statistics 

Over the past few decades we have helped many organisations to benchmark their current status of Knowledge Management. 

They ask for this service for a number of reasons. Sometimes they want to see where they need to improve. Sometimes they need to see IF they need to improve. Sometimes they need to set a benchmark so they have something they can measure future improvement against.

There are a couple of trends in these benchmark figures. 

The first trend appears when you look at how the overall benchmark score varies with the length of time KM has been addressed by the organisation. The graph above shows the overall KM score (from 1 to 5) for about 50 organisations, plotted against how long they have been deliberately working with KM, in years. Bear in mind when you look at this that not all organisations want to score 5 out of 5, and that 4 out of 5 is a pretty fine score. However to reach a level 4 seems to take 10 years.  

Also note on the plot the two red points, which represent the same organisation measured at an interval of 2 years, showing good progress. Similarly the two green points represent a different organisation, measured twice, at a 3.5 year interval, showing a similar rate of progress.  Both of these organizations had an intensive KM program in place with support from the very top. These two companies improved at a much faster rate than the average. 

The second piece of evidence is from our three global KM surveys. The graph to the right is a combination of answers to three questions:

• How big is your organisation?
• How many years have you been doing KM?
• How mature is KM at your organisation?

The three coloured bars therefore represent the average number of years organisations have been doing KM when they are at the three levels of maturity:

• Early stage
• Well in progress
• Fully embedded.

So you can see that small companies at the "fully embedded" stage have been doing KM for 10 years or more, and large companies for significantly longer. Even companies that see themselves as "well in progress" with KM have been doing it for 6 to 10 years depending on size.

The sample size for this plot is 1039 responses. 

Conclusions from these two plots are as follows;

Firstly, changing the culture to become a knowledge-focused organisation is a long term process. You should be able to see significant progress within a few years, but it may take 10 years for KM to really become embedded in the culture as "the way we work".  

That doesn't mean you can't deliver value in the short term - in fact that should be your intent in the early years; delivering demonstrable value through short term pilots.  However you can't embed KM quickly.

Secondly, companies start from different places. There is a big range of scores in the top plot for organisations which are just starting KM implementation. If you already have a collaborative, open and supportive culture, you start at a higher point, and get good pretty quickly. If your culture is hierarchical, blaming and closed, it's going to be a much longer journey.

Thirdly it seems to vary considerably based on company size, As you might expect, smaller companies can change faster, and the lower plot suggests that the KM culture change in an organisation of more than 100,000 staff will take much longer than in organisations with hundreds of staff.

Fourthly you can transform much faster if you have the right conditions. The red points and green points on the upper plot transformed at more than twice the normal rate, thanks to a concerted KM push driven from the top of the organisation.

Please feel free to use these figures to benchmark your own organisational transformation, and help your management realise that a) KM is a long term culture change, and b) they can help you accelerate it if they give it strong backing. 

Why "Top down vs bottom up" is a false dichotomy for knowledge management implementation

There is a bit of a philosophical divide in KM circles - those who take a top-down approach to implementation, and those who prefer bottom-up.  The truth is that neither are right.

Image from wikimedia commons

The bottom-up view is that if you provide people with the KM tools, then Knowledge Sharing will naturally emerge. They point to Wikipedia as a prime example of this - the wisdom of the crowds spontaneously emerging as documented knowledge. They point to Twitter, to Linked-In, to many of the global social networking tools. They believe that Knowledge is organic, and that too much management will kill it. This was certainly a very prevalent view a decade ago, particularly where communities of practice were concerned.

The top-down view is that knowledge is an asset to an organisation, and that assets cannot safely be left to manage themselves. They believe that if there is an area of knowledge which is important to the organisation, then there should be a community of practice that looks after that knowledge. They delegate a chain of accountabilities for KM, starting from the very top.

ConocoPhillips is a prime example of the structured knowledge company - they divide their business into areas of competence, and for each one they make sure there is a community of practice and a network leader, who is also the editor of the relevant wiki page. The network leaders are given training, and the communities are nurtured through a growth process until they become very effective knowledge-sharing mechanisms. Each network leader reports upwards through functional excellence teams into the functional leadership of the organisation.

However, maybe there is no dichotomy here: 

• Nonaka and Takeuchi list "top down/bottom up" as one of the 7 Western polarisations which you should not get hung up about;
• The top (management) and the bottom (knowledge workers) are both stakeholders for knowledge management, and to focus only on one is a common implementation trap;
• Knowledge is an asset both for the organisation, and for the knowledge workers.

Knowledge Management therefore has to work both for the top and for the bottom. You can neither implement it from the top or from the bottom - nor, for that matter, as a middle-up-down approach.

Knowledge Management needs to be implemented holistically - including top, bottom and middle. All three layers have to be involved, and all three have to see value being delivered for them.

Because you cannot implement KM holistically for the whole organisation all at once, you need to take a piloting approach to Knowledge Management implementation, introducing it holistically for one practice area to solve one business problem. Once it is working here, delivering value to top, middle and bottom, then move to the next practice area, then the next, until the job is done and implementation is complete.

This is implementation not from the top, nor from the bottom, but from side to side; from wall to wall.

Awareness, willingness, ability: the 3 main challenges to KM

There are three main classes of challenge to introducing KM. We can call them Awareness, Willingness, and Ability

Mountain challenge
Cresta route, Ben Nevis

The awareness challenge can be summed up as follows

The people who have the crucial knowledge, are often unaware that they have it, unaware how valuable it is, unaware who needs to know it, and  unaware that sharing knowledge is something they should do.

The people who need the knowledge are often unaware that they lack it, unaware that they need it, unaware that it exists already, unaware of who holds that knowledge, and unaware that seeking knowledge is something they should do.

The willingness challenge can be summed up as follows

The people who have the crucial knowledge, are unwilling to share it. They fear that sharing knowledge will cost them time and effort, and may in some way disempower them. If the knowledge is gained through trouble or failure, they may be unwilling to admit to this, or discuss it. If the knowledge is gained through success, they may be unwilling to appear as if they are "showing off".

The people who need the knowledge are unwilling to look for it.  They fear that admitting a need for knowledge makes them look incompetent, or they prefer the fun of creating the knowledge for themselves. They are unwilling to say "I don't know - please help me".

The ability challenge can be summed up as follows

The people who have the crucial knowledge, are unable to share it. They don't know who to share it with, where to put it, or how to share it. They don't know, or don't have, the tools, processes and roles to help them. 

The people who need the knowledge are unable to find it.  They don't know where to look, who to talk to, or how to search. They don't know, or don't have, the tools, processes and roles to help them. 

To address these challenges, you need to 

• make the case for KM and raise the awareness, for example through a communication program;
• analyse and address the cultural aspects behind any unwillingness, through culture based initiatives or just good governance; and 
• introduce a framework of roles, processes and technology which provides the ability to seek and share.

Once you have addressed these three challenges, KM will be an easy journey

Should we treat KM implementation as a project?

Does KM have to be a project? We argue that it does.

Image from wikimedia commons

Implementing KM means building something new within your organisation. A new management framework, a new way of working, a new set of behaviours and attitudes. The work is not done when implementation is over - KM needs to be sustained, maintained and continually improved - but there will be a primary implementation phase.

To the extent that the implementation phase of Knowledge Management

• needs a strategy and a plan
• needs a team and budget
• has a start and an end, and  
• has objectives and deliverables

then it needs to be managed as a project.

Implementing KM is a special type of project - a change management project, planning to develop and implement a new management framework - but its still a project.  The Head of KM, or the CKO, or the Knowledge Manager for the organisation acts as the project leader, in order to

• Develop, together with the leadership of the organization, the vision, objectives, metrics and deliverables of the knowledge management implementation project. The delvierables should include a definition of the end state - for example an embedded KM framework with rolesm, processes, technology and governance all in place and applied.
• Deliver these objectives; accountable for delivery, for the budget, for managing the members of the knowledge management implementation team, for managing progress and activity; all of the standard accountabilities of a project manager. 
• Define and test the knowledge management framework through the testing and piloting phase, and ensure that the KM framework operates effectively and efficiently.
• Ensure that the KM framework delivers business value. 
• Embed the KM framework within the structures, habits and rhythms of the organisation. 
• Hand KM over to an operational KM team, to manage, maintain and continuously improve it. 

Whatever process you use internally for managing projects; apply it to your KM implementation.  

Stage gates, project plans, steering committees, Prince 2 - whatever your internal project management processes is; apply it, so that KM implementation is seen as, and treated with the same rigour as, a "proper project".

Whatever tools you use for project management, apply them to your KM project. 

SMART objectives, work breakdown, risk mapping, knowledge gap mapping, gantt  and pert charts, and project KM tools such as After Action Review and Retrospect.

Once the implementation is over, KM stops being a project, and starts being an operational management discipline, just like safety management, financial management, risk management or talent management. KM still needs to be a main focus of attention, and there needs to be an oversight and support team in place with a clear role to play, as well as KM roles throughout the business.

Until then, though, its a project.

Contact Knoco for help with your Knowledge Management Project

Why incrementalism doesn't work for KM change

Incrementalism will not work as a way to introduce Knowledge Management. KM is a mindshift - a giant leap - not a series of small steps.

One giant leap by Vivobarefoot on Flickr

Incrementalism is a method of working or changing by using many small incremental changes instead of one giant leap. Logical incrementalism implies that the steps in the process are sensible, and together each small step makes progress towards large change.  It is a preferred approach in many organisations, because it doesn't upset the status quo too much.

But Knowledge Management has to upset the status quo!

The status quo in most organisations is that the value of knowledge is unrecognised, people treat knowledge as personal asset not a valuable corporate asset, and knowledge work is not seen as "real work".

This status quo generally results in knowledge mismanagement.

I have already talked about the culture leap for Knowledge Management - the 8-inch shift from "Knowledge is MINE" to "Knowledge is Ours". This is a jump across a chasm, a polar switch in attitude, not a series of shuffles from one state to another.  Knowledge Management cannot effect this culture change in incremental steps, it requires a paradigm shift.

We see the same effect in our Bird Island exercise. People build a tower, and then start to think how they might improve the tower. They think, they discuss, they conduct after action reviews, and decide that next time, their tower could be 20% higher. They think they can improve incrementally.

Then we show them a picture of the World Record tower, which is often 3 or 4 times the height they have managed. They realise that a big leap is needed, not a series of little steps. As one of our participants said:

"That's the difference between the top learners and the rest: it will take the incrementalists all eternity to catch up with the best learning organisations. A shift from an incrementalist standpoint is quite a fundamental shift"

The "top learner" takes learning from everywhere any anywhere - from other people, other companies, and from records from the past. They challenge their thinking, they throw away their design if its unsatisfactory, they have open minds and they welcome challenge. That's where we see the giant leaps in performance in Bird Island - with performance increases of 300% or 400%. This is true also in KM implementation.  we need a giant leap, not baby steps.

So if we can't use incrementalism, how then do we effect the KM change?

We effect change through standard change management techniques.

• Make the case that the Status Quo is unacceptable. In the Bird Island game, this is done by showing how pathetic the current performance seems against World Class performance. In the organisation, this is done by showing the unacceptable costs or risks of lost knowledge.
• Show what the future will be like. Present case studies of embedded Knowledge Management where true value is being delivered. Show how people treat knowledge as a really valuable asset, and how they work differently as a result.
• Find someone who "gets it" (your first follower) and work with them to pilot KM in one small part of your own organisation.  Capture your own case study.  
• This pilot is a big leap in a small area, as opposed to incrementalism, which is a small change over the whole company. 
• Communicate the success from the pilot. Use this as social proof to find the second follower, and the third.
• Communicate, communicate, communicate.
• When you have a big enough body of proof, use this to gain senior management support for roll-out.
• Communicate, communicate, communicate.  Recognise the good performers. Publicise their successes. Continue to show the others what the future will look like. Coach, support, cajole, encourage.  Roll out KM area by area, business problem by business problem, department by department.
• Embed KM, so the culture does not change back.

Big changes don’t happen incrementally, they happen dramatically through choice or by circumstances.  Knowledge Management is a big change in culture, and you cannot get there through small incremental steps.

Implementing KM as if you were a business start-up (video)

As my last blog post this year, please find below a presentation I gave last month to CIEDO in Barcelona.
 

Many thanks to CIEDO for inviting me to the conference, which was extremely interesting. I was honoured to be invited.

In the video I am talking on the topic of KM Implementation, and suggesting that you approach it as if you were a start-up launching a new product into a market (which in many ways you are). I then pick five of the common ways in which start-ups fail, and suggest how KM can avoid the same failures.

Be aware, this is video lasts over an hour. The introduction is in Spanish as are the questions at the end, but my part is spoken in English. 

Other videos from the event can be found here, also the conclusions of the conference.

Loss Aversion, and the dis-incentives for KM-based change

The risk of loss of the status quo can be a powerful disincentive for change, and can be a powerful factor working against knowledge management implementation.

There is a very apt quote from Machiavelli (The Prince, 1532), which applies to Knowledge Management as it does to any change initiative:

“There is nothing more difficult to take in hand, more perilous to conduct, or more uncertain in its success, than to take the lead in the introduction of a new order of things, because the innovator has for enemies all those who have done well under the old conditions, and lukewarm defenders in those who may do well under the new.” 

As Machiavelli points out, the status quo is a powerful factor. Introducing something new, such as KM, disturbs the status quo without yet providing anything tangible to replace it. Sometime in the future Knowledge Management will deliver rewards, but people are always more unwilling to lose tangible benefits in the here and now, in return for potentially bigger but intangible benefits in the future.

This is known as "loss aversion".

Wikipedia tells us that in economics and decision theory, loss aversion refers to people's tendency to strongly prefer avoiding losses to acquiring gains. Most studies suggest that losses are twice as powerful, psychologically, as gains.  This is reflected strongly in Machiavelli's quote.

Implementing KM involves change, all change involves loss, and all loss leads to aversion. Therefore you will make enemies of anyone who sees that they will lose something - power, prestige, profile - as knowledge management is introduced.

Elon Musk, as reported on the Farnham Street blog met a similar loss aversion from the regulators when proposing a re-usuable space rocket.

"There is a fundamental problem with regulators. If a regulator agrees to change a rule and something bad happens, they can easily lose their career. Whereas if they change a rule and something good happens, they don’t even get a reward. So, it’s very asymmetric. It’s then very easy to understand why regulators resist changing the rules. It’s because there’s a big punishment on one side and no reward on the other. How would any rational person behave in such a scenario?"

So how do we tackle loss aversion when implementing Knowledge Management?

• Wherever possible, we make a case for change by maintaining that the status quo is undesirable. Maybe not sharing knowledge, or not learning from others, can be shown to put the profitability of the organisation at risk. Maybe failing to retain knowledge means that in 5 years time the organisation cannot compete.
• Secondly we paint a picture of the KM-enabled future. We do this through proof of concept activity and piloting, so people can see for themselves how KM works, and can hear from their colleagues about the benefits it brings.

These two approaches allow people to re-set the loss aversion equation, by reducing the value of the status quo and increasing the tangibility of the KM future. This makes it safer for people to make the change.

KM implementation - knowing when to stop

Knowing when to stop KM implementation - to "declare victory" and stand down the implementation team - is as big a decision as starting KM in the first place. 

Image from wikimedia commons

I am a proponent of viewing KM implementation as a project, and projects have start dates and end dates. When you start you don't know exactly how long implementation will take, and there is a huge risk of stopping your KM Implementation activity too early, before KM has become fully embedded. 

By "stopping KM implementation" I don't mean stopping KM, I mean stopping treating it as a change program, and starting treating it as "Business as Usual" or "The Way We Work". 

Stopping implementation is like taking the training wheels off a bicycle so the rider continues independently. It's like when your child no longer needs arm bands to swim, and they can swim independently. This happens only when KM has become embedded, with KM roles in the organisation, KM processes in regular use, KM technology which has become a "standard tool", and KM governance which services to reinforce and guide. It may take a decade before this point is reached. 

So if for example you agree with your management a "5 year KM program" then the risk is that you stop after 5 years, no matter how far you have come, and if KM is not embedded at that point, it slides back or tips back to the previous state, despite the best efforts of the KM operational team. 

You can think of a KM implementation project as best approached as a series of 6 decisions, with each decision moving you on to the next stage

1. The decision to investigate what Knowledge Management would mean for us in our organisation
2. The decision that the organization needs improved Knowledge Management, and to find out how much investment is required.
3. The decision to set up a KM implementation program, with a full-time team and budget.
4. The decision to pilot KM in high profile areas
5. The decision to roll out KM as a required discipline to the whole organisation.
6. Once KM is embedded, the decision to stand down the implementation team and hand over to management within the business (with the support of a central KM team to operate and maintain the KM framework).

We are talking here about decision 6. You don't stop the implementation project until you have good evidence to support decision 6.

To do so would be like stopping a bridge-building project until the bridge crosses the river, and has a roadway across it. Ending KM implementation is like commissioning that bridge, testing it, completing and de-snagging it, and then declaring it open.

So if you are to set up KM implementation as a project, then you need very clear deliverables which you agree in advance with management. If you have not yet achieved these deliverables, then implementation needs to continue. Deliverables might be, for example, 

• a self-sustaining approach to KM in all elements the business,
• KM processes into the high level process suite,
• clear governance, including a policy, minimum conditions of satisfaction, and KM metrics linked to the performance management framework,
• clear chains of accountability for KM within the organisation,
• a complete, supported and well-understood technology suite,
• providing a support system, including local support from KM champions, central support and training from a central KM operational team, and self-help support resources,
• clear evidence of sustainable culture change and sustainable business value.

This is what you are aiming for, and don't stop until you have got there. And even then, plan for a handover and commissioning period, until operational KM is up and running.

That is when you can safely stop your KM implementation project.

KM - simple but not easy

My assertion is that Knowledge Management is actually really quite simple, but simple does not equate to easy.

For all the tools and all the strategies and all the nuances and all the things that we to do complicate knowledge management, at it's heart it is a very simple concept.

It is about making sure that the decision makers in the organisation have access to the crucial knowledge they need to make decisions. Then its about making sure that the right things happen to transfer that knowledge, either through conversation or through content. Then it's about change management - changing to a world where knowledge is considered important.

It's the change management aspect that's the hard aspect. 

There is enough technology out there, there are well-defined processes that work extremely well, there is an understanding of the roles and skillsets needed, and nowadays there's a pretty good understanding of the governance elements as well. All of that is easy enough. It's the change itself that's hard.

I think that's where people often go wrong with their KM programs. They do the easy stuff, not the hard stuff. They buy the technologies. They print the booklets. They work with the enthusiasts and sing with the choir.

What they don't do so often, is have the really hard discussion with the CEO and the senior management team about the value KM can deliver to the organisation, and the few focus areas they need to address. They don't gain those high level sponsors. They don't go and tussle with the hard-pressed team leaders and work out what you can do to help them, and what they can do to help you. They don't get out and work in detail with the pilot projects, to deliver the spectacular successes that act as a beacon to the rest of the organisation.

Knowledge Management is not complicated. It really isn't, despite the complicated models people sometimes build. But it needs courage and it needs dedication and it  needs perseverance and a thick skin, and it needs you to work at some very difficult conversations.

Do the hard work, and the simple becomes possible.

How to recognise a KM opportunity

Implementing Knowledge Management involves identifying opportunities where KM can help the business. But how do you spot these opportunities?

My Name is Opportunity, by One Way Stock, on Flickr

Implementing KM is not just a case of top-down roll-out of a Knowledge Management framework, but should involve looking for opportunities where KM can help the business. 

You can recognise these opportunities at two scales. The first scale is the "proof of concept" trials -  small interventions with a KM tool or process, so people can see it in action, and realize that "KM is not all smoke and mirrors – it can work here".

Suitable opportunities might include the following:

• A lessons capture meeting such as a retrospect for 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 KM”. We did gather learning - some very powerful learning - and this opened the door to management support. 

• 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 project teams, and can make a positive impact to project plans.

• A facilitated exchange of knowledge on a key topic. In another organization we worked with, the proof of concept was getting experts together from all over the world to build a company best practice on bidding and winning large government contracts. 

• Creating a knowledge asset on a key topic. Another client we worked with was going through a series of mergers, and compiled knowledge in the form of a set of guidance summarizing "what we have learned about delivering effective mergers." 

• A launch event to kick off a community of practice. One of our clients was seeking to develop knowledge sharing behaviours, and a successful community launch gave them the evidence they needed to convince them this was worth supporting. 

• A retention interview from a departing expert. This has been the proof of concept for many retention-based KM strategies. Management want to see what is possible, and they want to be convinced that KM 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 or guidance. The second is stories, reaction or feedback from the people involved, saying "Hey, we tried KM, it was great, it was not difficult, and it created real value".

KM Pilot projects

Beyond the opportunities for small proof of concept tests, you can look for the big piloting opportunities.

KM Pilot projects are intended to test and refine the KM framework, and so involve more than just piloting one tool.  An effective pilot will deploy a complete (but potentially minimum viable) KM framework, and will  address a knowledge domain or practice area that could cover many business teams and divisions – rather than covering a single business project or team.

A pilot will therefore test the validity and value of the KM framework in a cross-organizational setting. Suitable business problems for KM pilots, where better access to knowledge can significantly help performance, are as follows:

• A business critical activity which is new to the organization, where rapid learning will deliver business benefits. If the activity is new to only one part of the organization, then transferring learning from where it has been done before may give huge benefits. 

• Repetitive activity business activity where continuous improvement is needed, where KM can help accelerate the learning curve. 

• Activity which is carried out in several locations, and where performance level varies, in which case KM can help exchange knowledge from the good performers to improve the poor performers.

• A business area which is subject to rapid change, where innovation and rapid learning are critical to survival, in which case KM can help by providing team sharing and learning processes, as well as access to relevant knowledge bases.

• An area of rapid business growth where deep experience and skills need to be scaled up to deliver on projects and services, in which case KM can help by facilitating knowledge capture and transfer and faster learning curves for mid-level staff.

• A business area where people are stuck due to lack of knowledge.

Pilots require a complete framework - a mix of roles, processes, technology and governance - and are a vital step in your KM programme.

Contact us for help in identifying and ranking KM pilot opportunities.

4 types of KM plan

Knowledge Management plans exist at many scales. Here are 4 of them.

KM planning session

Implementing KM is a project, and a project needs a plan. However KM can be implemented at many scales, and many variants of KM plan may be needed. In this post we describe 4 of them:

• The organisational KM strategy
• The organisational KM implementation plan
• A KM plan for a project
• A KM plan for an operational department

KM strategy 

A KM strategy is the framework document that sets the context, direction and principles for KM implementation. The strategy ensures that the Knowledge Management implementation proceeds in a way that is aligned with the current business approaches, is targeted on the right problems, and is coordinated with other existing change initiatives.

One of the key components in the strategy is an analysis of “What Knowledge do we most need to Manage? These strategic knowledge areas are identified through discussion at the highest level (CEO if possible).

One of our clients had an excellent discussion with their senior management, while preparing their KM strategy, on this topic of key knowledge, and were given a strong steer to “focus on driving growth in new consumer markets, through knowledge sharing networks”. That decision set their KM strategy, and formed a framework for the next 4 years of KM activity.

KM implementation plan 

Once you have your strategy in place, you can start on your implementation planning. This is where you plan your activities and resources, in order to develop and embed an effective KM “system”. The plan will be based on

• the Knowledge Management strategy 
• an assessment and benchmarking of your current state of KM 
• an outline “desired end state” (KM framework) 
• a staged, change management approach 
• a full analysis of the risks to Knowledge Management delivery 

The KM implementation plan maps out the steps from the current state to the end state, guided by the strategy and the assessment. It defines your timeline, and the resource needs.

Project KM plan 

The project-level Knowledge Management plan is a device that allows KM to be fully embedded into project controls, at the same level of rigour as risk management, or document management. It allows the assignment of accountabilities to individual project team members, and allows these accountabilities to be monitored and reviewed. Some organisations also address.

 A KM plan has three main components.

1. A Knowledge Register, which defines the key areas of knowledge needed by the project (“key knowledge inputs”), and the assigned actions to make sure this knowledge is accessed. It also defines the key areas of knowledge which the project will be learning about, and which they need to share with the rest of the organisation (“knowledge outputs”), and the actions to make sure this sharing happens. 
2. A KM Protocol, which defines the system by which knowledge will be managed in the project. It defines the roles and accountabilities, the technologies (such as lessons databases) which will be used, and the processes which will be applied and when they will be applied as part of the project timeline. 
3. An implementation plan for the project, to make sure the protocol is ready to use. This will require training of staff in the tools and technologies, induction of new staff, registration of staff onto the relevant communities of practice, installation of technology onto people’s desktops, and so on. 

The plan is created at a KM Planning work-shop, early in the project, held as part of the set-up activities; about the same time the team are developing their risk management plan, their document management plan, and other front-end planning activities.

Operational KM plans 

Just as a project KM plan is built into the planning and review framework of a project, an Operational KM plan needs to be built into the operational planning and review framework. This should be done as follows;

1. During the annual planning cycle, the operation will agree its annual objectives and budget. The next step will be to create the annual KM plan. 
2. The KM plan will contain the same components as a project KM, though the key topics in the knowledge register will be set by the new operational objectives. The operational management team will get together for a KM planning workshop, and start with the question – “What do we need to know (or to learn) in order to deliver our operational objectives”?
3.  The main deadline for the operation to capture new knowledge for other operations will be at the end of the year, when they review performance against objectives, and ask “What were the causes of any deviation from planned performance (either a positive or a negative deviation), and what have we learned from these to improve next year’s performance”? They will also review the application of the KM plan through the year.
4. The operational department may also assess the level of management of key operational topics or knowledge domains, for example through a KM audit or Scan. If any knowledge domain needs to be better managed (better documented for example, or updated, or a community of practice initiated), or is at risk of loss through potential departure of key experts, then the KM plan will define the remedial actions that need to be taken.

Contact Knoco for help with KM planning at all scales

Lean KM and the Minimum Viable Product

There is a concept in lean manufacturing known as the "minimum viable product". This is a very valuable concept to bear in mind when introducing Knowledge Management to an organisation

Image from blog.fastmonkeys.com

The concept of the Minimum Viable Product (MVP) is generally taken as being the simplest and easiest version of the product you can build that delivers customer value.

The software manufacturer builds and releases (often to a customer subset such as the early adopters) a completely bare-bones version of a product in order to

• get customer feedback
• learn about the product in use, and 
• get some revenue.

We can use the same approach when it comes to implementing Knowledge Management within an organisation (as discussed in my blog series on "implementing KM as if it were a business start-up").

There are two key words in the definition

Firstly the product should be viable. In other words it should solve the customers problem, add core value, and provide a complete focused experience to the early adopters. The diagram at the head of this post illustrates the principle. If you were creating the first car by a lean and agile process you would not first release the wheels, then the axle, then the coachwork, as none of these elements on their own are viable. It would be better to develop a powered skateboard, then a powered scooter, then a motorbike, so that at each step you provide the complete experience of powered wheeled transport.

Secondly the product should be minimum. It should be the smallest subset of features that delivers value, because this is your starting point to lean about how the user interacts with the product, and which then allows you to take the next development step.  The Knowledge management version of the MVP is the Knowledge Management pilot - that first release of a knowledge management solution to a group of early adopters in the business, in order to test the concept and deliver business value.

In Knowledge Management terms we know that the viable unit is not the tool or the process, but the framework. 

No single item, be it a tool, a technology, a process or a role, will deliver KM value on its own. You need a framework of roles, processes, technologies and governance in order for Knowledge to flow from source to user, and to be applied for business benefit.  The minimum viable product is therefore the simplest possible framework you can release.

For example, if you want to pilot KM in an area of the business where knowledge needs to be shared between multiple business units you could take one of two approaches.

• The all-too-common approach is to introduce a technology (Yammer, for example, or Jive) and anticipate that people will start to use it. However this is neither minimum (both of these technologies are well-developed, with many features), not is it viable (technology alone will not work).

• Better to introduce a simple framework such as a community coordinator (role) who sets up monthly discussions (process) using dial-in conference calls (technology) to discuss an identified agenda of critical knowledge issues (governance). Once the community realises this minimum system adds value, then they can start to build upon this system until they have a KM Framework that fully meets their needs. This is exactly the approach taken by the community described in Johnny's story. 

Therefore lean and agile Knowledge Management focuses on delivering the minimum KM framework to the business as soon as possible, in order to deliver value, prove the concept, and most importantly to gain learning which allows the Knowledge Management product to take the next step of development.

As the web-page The Lean start-up says

Progress in manufacturing is measured by the production of high quality goods. The unit of progress for Lean Startups is validated learning - a rigorous method for demonstrating progress when one is embedded in the soil of extreme uncertainty

We see this principle in action in the way that IDEO introduced their KM system - through introducing a minimum viable product,learning from it, demonstrating progress, and iterating early and often.

Implementing KM is a place of extreme uncertainty. Apply a lean and agile approach; start with your MVP, introduce the KM skateboard, test it with the users, learn from it, iterate, and build the next improved version.  Pretty soon you will have your KM Porsche.

Is "viral introduction" the right way to implement KM?

We currently know very well the power of a virus, and the way that it infects and spreads. But is this "viral introduction" a good model for introducing KM?

Image by Kat Masback on Flickr

The world is in thrall to a virus at the moment. We are acutely aware of its power, as it sweeps across the globe in a series of waves, transmitted from person to person, seemingly unstoppable.

Often people will use viral infection as an analogue for the introduction of a new product or idea. Through "viral marketing" the idea or product or meme spreads from person to person across the market or the organisation in a series of waves. To introduce KM in such a way would be very appealing.

The problem with the viral introduction of knowledge management, is that most organisations have very good immune systems. They are remarkably successful at overcoming and rejecting new ideas, and generally fight them off after a while.

Just as a body overcomes and destroys an infection, so the habits, routines, dogmas, and "not invented here"s can overcome and destroy even the best innovation. This explains why so many KM initiatives start well, flare up like a fever, then 6 months later have disappeared completely, and the company is "back to normal".

As Victor Newman says - "All cultures are relatively “sticky” in the sense that they resist pressures to change".

We need a way of reducing the stickiness, and reducing the rejection rate. We need to make KM more like a transplant to be incorporated, than an infection to be fought.

That's where management need to be involved. They need to welcome the KM initiative, and to dampen down the resistance. Victor describes building relationship capital throughout the organisation until the management layer sees you as one of their own rather than a foreign body.  They can then help suppress the sticky organisational immune system long enough for KM to become embedded into the fabric of an organisation, like a transplant or a heart pacemaker is assimilated into the body.

Think Transplant, not Virus, if you are looking for long term change.

KM - who is in the driving seat?

A knowledge management strategy is not set in stone. It is not a fixed, immutable 5-year roadmap - it needs to change as the business landscape change. But who should steer these changes? Who is in the driving seat?

Image by Ivan Radic on Flickr

Does the KM team drive the strategy? Surely not - that would be a case of the horse leading the cart. Steerage needs to come from the business, not from KM.

Is is the KM sponsor? Potentially yes, but the sponsor is usually a single person with a single view point.

In order to get a representative steer from across the business, the best solution is to set up a steering team for your KM implementation.  This is a team of diverse senior leaders from within the main business units and functions, who help direct and drive the KM implementation effort by providing guidance, advice and challenge.

A successful steering team should powerful in terms of composition (senior managers with the titles, expertise, reputations, relationships, leadership skills and access to support and resources), their mutual level of trust, and their shared objectives. KM will usually need such a team to drive the change and steer the program, particularly in large and complex organizations.

The steering team will also ensure that the business is fully represented in the planning and decision making within the KM implementation. Committee members should represent the main functions (IT, HR, Quality etc) and the main lines of business (Marketing, Sales, Production, etc) in order to represent all the primary stakeholders. For example, in one Oil Company KM project the steering team consisted of:

• MD - Planning
• DMD - Marketing Operations
• Deputy Chairman & DMD – Planning & Gas
• Deputy Chairman & DMD – Refinery
• Vice President & Chief Operating Officer
• DMD – Joint Operations
• Manager – Information Technology

The steering team is not a decision making board, but an advisory board to the sponsor and so to the KM leader. They give decision making authority in the sense that decisions will be well informed, relevant to the business, and likely to garner support.

The steering team members do not have to be KM converts. In fact, it is probably useful if some of them have some level of scepticism; to add a level of real business challenge to the program, and to ensure that objections are met and resolved early on.

 The steering team can also act as ambassadors for the KM program in their own part of the business. The manager of IT, for example, can ensure that the needs of the KM program are honoured by the IT department, and the Chief Operating Officer can help identify and facilitate KM pilots in the operational departments.

The steering team should meet on a regular basis; for example quarterly. It should be chaired by the KM sponsor, in order to support the sponsor’s review of the progress and performance of the KM program, and to advise on next steps.

Through the use of such a mechanism, the KM program can use the wisdom of the business to navigate KM through any strategic changes, and ensure it delivers maximum value for the business. 

The 4 things you need to know at the start of KM implementation

If you are a new Knowledge Manager, implementing KM for the first time in an organisation, there are 4 things to learn about before you start, and some of that learning may be closer to home than you realise.

One of the tenets of Knowledge Management is that if you face a new piece of work, then you need to gain knowledge before you make a start. You make a KM plan, you identify your knowledge needs, you identify the sources of the knowledge, and you set out on your learning journey.

You "learn before doing", as this is the surest way to build on the successes of others, and to avoid their mistakes and pitfalls.

So what do you need to learn about?

For the knowledge manager, there are 4 main things you need to learn about:

1. How knowledge management works, and the possible elements of the knowledge management framework in an organisation like yours;
2. How your organisation works, and the role of knowledge within those workings;
3. How knowledge management can be introduced to an organisation, including the elements of KM strategy and KM implementation;
4. How Change Management works in your own organisation, and how a major change program should be run.

We see most Knowledge Managers focusing on number 1, and (to be honest) often getting very confused. KM is a complex field, with very many variants such as legal KM, practice-focused KM, product-focused KM, KM for customer service and R&D KM. There are also many variants that (in our experience) are suboptimal, such as KM only through social media push, or guerilla KM, or "KM as an IT system". The Knowledge Manager who Googles "knowledge management" will be overwhelmed by variety, and the risk is that they choose an answer that fits their prejudice, rather than an answer based on solid experience.

Most Knowledge Managers are internal appointments, and so take number 2 for granted. However if you are to make KM a success, you need to do your internal market research. You need a very good understanding of the internal stakeholders and their needs before you can start to build your plan.

Fewer Knowledge Managers focus on the third point. Implementing KM is a long term and risky business - many knowledge management programs fail and many knowledge managers lose their job. It is harder to find advice on KM implementation, as few organisations have implemented KM really successfully, and fewer people have been involved in more than one KM implementation. This is an area where it pays to find good experienced consultants to help you.

Even fewer learn about the 4th topic, which is strange because here the knowledge is close to home and accessible. Implementing KM is a change program, it is probably not the first change program your organisation has attempted, and there will be others in-house with valuable experience and knowledge to share. Find them, speak with them, and learn their lessons. Find out the secrets of their success and how they dealt with the pitfalls they encountered. Ask them "if you were starting a new program of change in this organisation, then based on your experience, how would you do it?"

You could, as an alternative approach, consider addressing these three areas in the reverse order.

• Firstly, learn about change in your organisation, and the secrets of successful change.
• Secondly, learn from experienced guides about the mechanics of KM implementation, in the context of your own change.
• Thirdly do your market research.
• Finally learn about the details of KM, and how it works in your own organisation. 

Contact us if you need any help with your pre-learning

Which comes first - Knowledge Management or culture change?

It's the ultimate chicken and egg situation. KM requires a supportive culture, yet how do you develop the culture without doing KM?

Should you wait for the culture to change, and then start your KM initiative, or should you start your KM initiative knowing you have to battle against the culture?

The Knoco global surveys of KM tell us that Culture is the second biggest barrier to KM implementation, and the second most common reason for abandoning KM.  There is no doubt that the existing culture can strongly infuence your KM efforts, and ISO 30401:2018, the ISO management systems standard for KM, says that

"A culture where connections and knowledge activities are encouraged, and knowledge is valued and actively used, will support the establishment and application of the knowledge management system within the organization".

However Knowledge Management is also a culture change agent. The graph below, also from the Knoco surveys shows how the number of cultural barriers decreases the more Knowledge Management becomes embedded.

So we have a "chicken and egg" situation. Culture is a barrier, culture can derail your KM initiative, but the more embedded KM becomes, the more the barriers come down. 

How then do we introduce KM? Do we start with the chicken, or wait for the egg?

The answer is that we introduce KM as a culture change exercise.

• First we perform a KM culture audit, so we understand the barriers.

• Then we look for small areas of the business where the cultural barriers are weakest and/or the need for knowledge and KM is strongest, so that the balance is tipped in our favour, and we make these our KM pilot areas. 

• We introduce KM in the pilot areas, deliver success, deliver value, than use these success examples in our communication and change program as "social proof". These pilots are our cultural "first followers" or "thin threads"; the equivalent of the first wave of penguins off the ice floe (see video here). 

• Then you repeat the last step as many times as it takes for the new culture to catch hold, recruiting your second followers, third followers and so on.   

• At the same time, you lobby your sponsor and steering team to begin to remove the institutional barriers to the new culture such as the recognition and reward scheme, the internal security barriers, and so on.

The answer to the "chicken and egg" is that you don't wait for the culture to change. You make a start, and change the culture as you go. Buy a pair of chickens, lay some eggs, make more chickens, and before long you have a whole chicken farm.

Use the power of KM to change the culture, and use the culture change to deliver KM.

Contact Knoco if you need help with your KM culture change