KM pilot projects

---

We need to draw a distinction between testing individual components of knowledge management, and piloting a knowledge management system. Both may be needed, and proof-of-concept tests of individual KM components can be valuable exercises, but we would highly recommend piloting the complete system on a small part of the business, even if you don’t do tests of individual components.

There are four reasons for doing pilot projects, and four things that the pilot projects will deliver.

• The first few pilot projects will be “proof of value” projects, and the organisation will be watching them closely to see if they work, and in particular, to see whether knowledge management work in your individual context. You may need to many people within your organisation who say “yes, knowledge management sounds fine, and I can understand how it worked in Ford, or Shell, or BP, but our business is different”. A successful pilot project will demonstrate that knowledge management also delivers value in your own business.
• Secondly, the pilot project will deliver a lot of learning about how knowledge management works in your business, and how knowledge management can be implemented in your culture.
• Thirdly, if the pilot is successful, it will deliver monetary value to the organisation, and so should be worth doing in its own right
• Finally, you should be able to get some good marketing material from the pilot project, in terms of stories, endorsements, quotes and video. This will be incredibly valuable for the roll-out phase.

Below are some of the areas where you might consider suggesting a knowledge management pilot.

• If there is the business critical activity which is new to the organisation, then rapid learning will deliver business benefits. If it is new to only one part of the organisation, then transferring learning from where it has been done before, will give huge benefits.
• If there is repetitive activity, where continuous improvement is needed, then knowledge management can help drive down the learning curve.
• If there is activity which is carried out in several locations, where performance level varies, then knowledge management can help exchange knowledge from the good performers, to improve the poor performers.
• Finally if there is an area of the business which is stuck due to lack of knowledge, then knowledge management can help develop the knowledge needed to get unstuck.

 
Each of these areas carries the potential for a successful pilot.

3 steps to KM implementation

---

In terms of implementation approaches for Knowledge Management, you ultimately want the organisation to be in the box where all of the knowledge management framework is used by all of the business (and by system, we mean the framework of roles, processes, technologies and governance which will underpin KM). This is the yellow box shown in the diagram, and this is your ultimate implementation destination.

However there are three routes you can take to the yellow box.

Firstly you can go straight into the box, design a system in isolation and roll it out across the business, with no testing. This is the top red arrow that takes you straight into the yellow box. We don’t recommend this route - it's too easy to get it wrong, and there's no opportunity to tweak the system en route.
Secondly you can roll out components of the system across the business, building and testing the system piece by piece (point A) until it is complete (point B). This is the second red arrow, and we don’t recommend this route either. Firstly the individual components are unlikely to add much value on their own. Secondly, you have no opportunity to test how all the components work together.

What we do recommend, is two stages of testing in small parts of the business. Firstly proof of concept testing of specific interventions (point 1, bottom left box, some of the system in some of the business), and then piloting the whole system (point 2, top left box) prior to rolling out across the whole organisation (Point 3). This takes longer, but is far more robust.

I will post more about the piloting process tomorrow.

When KM is NOT a change program

---

This year, we have the pleasure of developing KM for a major start-up company. For the first time ever, we start with a blank slate. The business processes are not in place, the accountabilities are not in place, the structures and technologies are still being firmed up. We can build KM into the work processes from day 1.

This requires a rethink in terms of KM strategy. Our normal change-management approach is not needed, as there is nothing in place to change. Instead we need to make sure that KM is fully embedded in, and linked with, the business processes and management systems so that it becoms part of "business as usual" from the outset.

Our issue will be embedding and sustaining, not changing.

Knowledge without integrity (quote)

---

Integrity without knowledge is weak and useless, and knowledge without integrity is dangerous and dreadful.
- Samuel Johnson

Changing KM strategies as knowledge evolves

---

Here's another look at the issues of knowledge maturity, and how your KM strategies evolve as knowledge matures (previously dealt with in this post).

Here we combine the ideas from that post, with the concept of a learning curve.

At point A on the learning curve, there is little knowledge, and the knowledge management strategy at this point must be on lessons identification and re-use - on retrospects and after action reviews - on learning very quickly through a deliberate focus on the knowledge that is being gained. There is no point in looking for any best practice at this stage, as the knowledge is still exploratory (see for example the story about learning in the battlefields of Normandy).

As learning slows, then you can begin to take stock of all the lessons and all of the experiences, and can begin to bring them all together in crafting a collective view of successful strategies, which we can call best practice. This best practice is continuously evolving and continuously improving. It is not static and its not a required standard; its the current version of the best approach, which people are free to improve on. The knowledge management strategy at point B is one of harnessing the power of the community to drive continuous improvement around a common practice concept.

As learning slows to a standstill, at Point C, then any further search for improvement becomes a waste of energy, and any attempts at further incremental innovation turn into tinkering. Here the knowledge management strategy becomes one of standardisation, and embedding of knowledge into organisational design and standardised process.  At the bottom of the learning curve, knowledge is as mature as it can get; until there is a change in context, such as a change in technology, a change in the market, or a change in the industry. So even though further incremental innovation is pointless, there may be step-out innovation as soon as the context changes. This is Point D, so the knowledge management strategy of standardisation at point C must be matched by a watchfulness, and the constant question of "has anything changed that means we could do this in a radically different way ?" If something has changed, then you kick off down a new learning curve.

Failures or inefficiencies in KM come from using the wrong strategies in the wrong parts of the curve - applying best praxctice at point A, applying standardisation at point B, trying to innovate at point C, or blindly ignoring point D and applying a stadard approach where step-out innovation is needed.

Get your KM strategy aligned with the correct state of knowledge maturity, and you will succeed.

(Also, an organisation working in many different knowledge areas of different maturity levels may need different strategies for different areas).

Top 7 reasons why KM implementations fail

---

It is a commonly stated observation that 80% of knowledge management programs fail.

I don’t know whether this is a true observation, but it is commonly stated. Whether it is true or not probably all depends on what you mean by “knowledge management program” and what you mean by “fail”. However certainly there has been a large number of failures, as well as a (probably smaller) number of successes. As a consultant with 17 years experience in the field I have been involved in both successes and failures, so here’s my observations on some of the most common reasons for failure.

1. KM is not introduced as a change program

KM is a program of organisational change. It’s not about buying and rolling out technology, it’s not about giving people new toys, and it’s not about adding another task into the project framework – it’s about changing the way people think. It’s about changing personal and organisational priorities, and it’s about changing the way people think about knowledge. As I say in this post, it is a profound shift from the individual to the collective

• From “I know” to “We know”

• From “Knowledge is mine” to “Knowledge is ours”

• From “Knowledge is owned” to “Knowledge is shared”

• From “Knowledge is personal property” to “Knowledge is collective/community property”

• From “Knowledge is personal advantage” to “Knowledge is company advantage”

• From “Knowledge is personal” to “Knowledge is inter-personal”

• From “I defend what I know” to “I am open to better knowledge”

• From “not invented here (i.e. by me)” to “invented in my community”

• From “New knowledge competes with my personal knowledge” to “new knowledge improves my personal knowledge”

• From "other people's knowledge is a threat to me" to "our shared knowledge helps me"

• From “Admitting I don’t know is weakness” to “Admitting I don’t know is the first step to learning”

So KM needs to be introduced as an organisational change program, with high level sponsorship, with a communication strategy, with a desired end-state, and with step-wise implementation rather than “everyone change at once”. Change follows the S-curve, change needs to reach a tipping point, and hearts and minds need to be changed one at a time. Organisational change is a well-established field, and KM needs to learn from this field.

2. The KM team does not have the right people to deliver change

If KM is a program of organisational change, then the KM team need to be change agents and change leaders. The team leader, first and foremost, needs to be a change agent, a visionary leader, capable of working at the highest levels in the organisation as well as the lowest. They need to be an insider; this is a role that cannot be outsourced, as they need to "speak the language", know the politics, and have the credibility. They need to know enough about KM to translate it into business and customer terminology, but able to back it up with sound KM theory. They need to be comfortable in the board room as well as on the factory floor, and in both locations they need to inspire, and they need a team that can inspire as well.

All too often, the KM teams we come across in organisations are not like this at all. They are the wrong people. They are back-room boys and girls, more at home managing databases than inspiring change. They prefer working with computers to working with people. They do not inspire, and they are not visionary. They are uncomfortable in the board room.

Finding the right people is not easy, but changing the culture of an organisation is not easy either. With the wrong people on the team, you don't get the right result, even with the best consultants in the world to support you.

3. The KM team preach only to the choir.

The KM team are enthusiasts. They see the value in KM, they “catch the vision”, and they assume everyone else will catch the vision. As they go out into the organisation they begin to meet other enthusiasts, they will get a lot of Buzz, they will find some exciting projects, but unless they move beyond the enthusiasts they are just preaching to the choir. The KM fans will create a KM bubble, but if you don’t move beyond the enthusiasts, you won't penetrate the rest of the organisation. Experience shows that maybe 20% of people are enthusiasts, maybe 60% don’t care about KM one way or another (they will do it if their job requires it, but it’s not a big deal either way), and 20% hate the idea, and find it threatening. Very soon you have to leave the 20% of enthusiasts (even though it’s much more fun to work with them), and start the hard work of working with the other 80%; the tough nuts, the cynics and the don’t-cares.

And that’s where your change-agency skills will come in. Without them, and without preaching beyond the choir, you won’t get anywhere near your tipping point. You will get stuck with a happy choir, and a totally disinterested congregation.

4. Only parts of the KM solution are implemented

There are many elements to KM. There is connect, and collect. There is push, and pull. There is people (roles and accountabilities), processes, technologies and governance.

All too often, KM implementations take only one element, and assume that will work in isolation. A common assumption is that knowledge has to be captured and published, so people go down a route of collect and no connect, push and no pull, and a focus on technology without process, accountability and governance. Another common assumption is that all you have to do is “let people talk” and knowledge will share itself. So people go down a route of connect, people, and technology, And of course knowledge doesn’t “share itself”.

Taking a small element of KM and assuming it will work in isolation is like taking one ingredient and assuming it will create the whole recipe, or like taking one small element of a central heating system and assuming it will heat the house.

One common reason why we get invited into organisations is because they have part-implemented KM, and it got them nowhere. “We had a KM program last year, we bought a new search engine, but people aren’t using it”. “We introduced SharePoint and set up 40 communities of practice, but they are all inactive”. “We put in place a lessons learned process, but we are just learning the same lessons over and over”. They introduced a tool or a process or a technology, when what they needed was a system.

5. KM is never embedded into the business

Lots of KM programs do not take root, because they have never been embedded in normal business. They are delivered by a strong team and a charismatic leader delivered as something separate - not fully rooted in the work structure and management framework of the company. They are like a tree in a pot - well tended, well watered, but separate - and when the tender care is removed, the organisation tips back. KM needs to be like a tree in a forest - rooted in the fabric of the business.

The goal is to embed a self-sustaining approach to KM in all elements of the business, with clear governance and good support, and clear evidence of sustainable culture change and sustainable business value. Don’t stop your implementation until you have got to this point. And even then, plan for a handover period, until embedded operational KM is up and running. Stopping a KM program before this point is a common reason for failure. And given that it may take years to reach this point, you need to ensure that your high level sponsor (see point 6) is “in it for the long run”.

6. There is no effective high-level sponsorship

In order to embed KM in the business, then changes to the business need to be made. You may have to change the incentives policy, perhaps removing the "factory of the year" award that drives so much internal competition. You may need to change the accountabilities of the Heads of Function, to include accountability for the maintenance of certain knowledge areas (that accountability usually being devolved to subject matter experts and communities of practice). You may have to introduce high level groups of responding to the output of knowledge capture sessions, whenever these uncover organisational weaknesses that need to be addressed, or organisation improvements that can be made. You may need to introduce a new technology across the entire organisation. For all of these, you need support at the highest level, so you need a sponsor with the ear of the CEO.

In addition, you need the heads of function onside, so you also need a high level steering team, including the CIO, the head of HR, the head of projects, the head of operations etc. These guys need to steer the KM project, and in return for that ability to steer, need to support the result.

Now not every KM implementation starts at a  high enough level to have a C-grade sponsor. Sometimes KM starts in one division, or one country, or one function; however for KM to be applied across the whole company, or for the company-wide blockers to be removed, then the scale of KM implementation needs to be escalated, To do this, you will need to use the results of your divisional or national or functional KM program to make a case to senior management. You need to be able to say to them "Here is what KM can deliver. we have proved this at national, divisional or functional level. We can make these same improvements, and deliver the same scale of improvements across the entire business.  However we need active sponsorship from you". You make a deal with senior management. In return for their support, you promise real business benefits (see point 7). Of course you have to deliver against these promises, but without senior support, there is no way you can deliver.

7. KM is not introduced with a business focus.

I see this one all the time, and it's a crucial point. KM should not be introduced for its own sake; it should be introduced because it solves business problems. The primary value of knowledge is helping people make better decisions, and so perform work better, faster and/or cheaper. You won't sell KM to anyone, let alone the doubters, the cynics or the high-level sponsors, by assuming that KM has self-evident benefit. You won't get anywhere by saying "we need to improve knowledge sharing", unless you can clearly demonstrate how better knowledge sharing will help the business. If you want support of a high level sponsor, you need to show how KM will help solve the issues that worry that sponsor. And if you aren't clear yourself, then sometimes the sponsor can help you clarify.

One of our clients took a KM strategy to the executive team of their organisation, It was a good strategy, but a little short on focus. Luckily rather than kicking it out, they said "yes, you can go ahead with KM, so long as you focus it entirely on the growth agenda. If it can help us grow, then go ahead". That's what they did, and now, many years later, then have a wealth of stories showing massive growth and many hundreds of millions of dollars value created, through the help of KM. It worked for them, and it would work even better for you if you think through the business priorities and the business benefit right at the start, before you even go to the sponsors in the first place. You need to know how KM will support the business strategy, you need to know where the value will come from, and you need to know, in general terms, the size of the prize.


Getting it right.

So if these are the 7 common reasons for failure, then the secrets of success are as follows

• Plan KM implementation as an organisational change program
• Recruit an excellent in-house change agent to run the program, supported by a powerful team
• Map out your stakeholders and your audience segments, and ensure you address all of them
• Implement KM as a holistic system, containing all necessary elements
• Don’t stop KM implementation until KM is fully embedded into company processes, accountabilities and governance.
• Make sure you have sponsorship at a high enough level that you can make and embed the required organisational change, and that you have a steering committee to ensure support for this
• Make sure your KM implementation is focused on solving real, pressing business issues.

 Good luck! If you need any help and advice on how to do this, give us a call

Knowledge, and root cause

---

I spent Monday and Tuesday this week facilitating a knowledge capture session for a major project - a project that met many hurdles and stumbling blocks, a project that was a first-of-a-kind, that finally proved too ambitious to succeed (for now), and had to be put on ice until the business climate was right.

 It was a fascinating meeting, and we spent hours trying to unravel the root causes behind what happened. Many things went wrong on the project, there were many symptoms of challenge or delay or failure, but there turned out to be only 4 or 5 root causes behind all the symptoms. These root causes were complex and interrelated, but we managed to tease them out in the end.

Reflecting about the experience afterwards, I came to a couple of key conclusions.

• Firstly, if you don't understand the root cause, you don't have the necessary knowledge to proceed.
• Secondly, when you present the knowledge, it should be structured by root cause and not by symptom.

Let me explain.

Firstly, the root cause analysis is vital to understand what happened, and without that understanding, you don't know what to do in future to avoid the symptoms recurring. It's like medicine - there are many things that can cause a rash, and if you understand the cause, you can treat it. If you misunderstand the cause - if the rash is caused by an allergy and you are treating it as if it were measles - then you won't clear the rash, because you lack knowledge. Similarly, if you don't understand the causes behind your project delay - if you think it was caused by a lack of rigour in progress-chasing, but in fact it was caused by poor stakeholder alignment - then you wont know how to fix it. You may improve your progress chasing, but the stakeholders remain misaligned. If you don't have knowledge of the root cause, you don't have knowledge of how to improve the situation.  You are just guessing.

When you pass on that knowledge, you are aiming to give subsequent projects knowledge of how to improve their own situation by avoiding the same challenges, delays and failures. You need to give them the ability to take action to improve their own chances of success. You could present the knowledge by symptom ("this is how you avoid project delay") or by root cause ("this is how you improve stakeholder alignment"). My preference is to present it by root cause, really because here you are speaking most directly to the individual who takes the action. Project delay could be caused by many factors and influenced by many people - the people who chase progress, the people who seek to align the stakeholders - and its best to speak to those people directly, so they know what they can do to improve the project chances of success. Knowledge needs to lead to action, and action must address the cause and not the symptom.

So as I have been packing the lessons from this weeks event, I have tried wherever possible to start from the root causes, identify how those can be addressed, and turn those learning points into actionable recommendations for individuals in future projects.

If I can do this well, if I can do this effectively, then I have a chance of making a real difference to future projects, and helping them to avoid being put on ice themselves, and helping them to succeed where others have failed.

Free Brain

---

With every pair of hands you hire, you get a free brain

Why is knowledge sharing so often a waste of time?

---

Thanks to David Gurteen for pointing out this Dilbert strip which is in many ways a valid viewpoint about knowledge sharing. Too often, companies set up "knowledge sharing" activities with little purpose and little focus, other than "lets get together and share knowledge across disciplines". It's a bit like John Cleese's "Monday morning meeting" ("Why are we at this meeting?" "Because its Monday and this is our Monday meeting. We always have a Monday meeting"). People with real work to do, don't bother to attend.

 

"Let's share knowledge" is not a business purpose, and I can empathise with Dillbert's reaction.

 

Far better is to focus your "knowledge sharing" on a business need.

 

• "Let's get together and pool what we know about new market entry, and see if we can help accelerate the China market"
• "Let's get together and see if we can understand why our success rate on new products is so low, and see what needs to be done"
• "Let's get together and compare our experience to determine the best way to track our containers once they leave the warehouse"

 

These are all valid focused reasons, and represent knowledge-sharing for the purposes of problem-solving.

This is knowledge-sharing as real work.

If this were the case, Dillbert would have far less justification for dropping out.

The fallacy of incrementalism

---

Robert Thomas has made an interesting comment on my blog, where he mentions "the fallacy of incrementalism".  Robert says

"It's the fallacy of incrementalism - thinking you might do maybe 10% better next time. Yet at that rate it would take a huge number of repetitions to get from (our - when I did Bird Island) first 75cm tower to (our) second 3m+ tower. 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 teams, and from records from the past. They challenge their thinking, they throw away their design if its unsatisfactory, they have open minds and welcome challenge. That's where we see the giant leaps in performance in Bird Island - with performance increases of 300% or 400%

The fallacy of incrementalism is that this is an effective way to learn. It's slow and steady, sure, but can be overtaken easily by the top learners.
The incrementalist approach represents learning only from your own performance. And we see in the Bird Island exercise that learning from your own performance gives estimated improvements in the order of 10% to 30%. They take their own design, and tweak it and stretch it. A team that learns incrementally, learns slowly.

KM as a culture change agent

---

There is always a lot of energy around the topic of KM and culture change (in fact there is a lively conversation going on in Linked-in at the moment, on the same topic).

Everyone accepts that culture will help or hinder KM implementation, and that there are supportive cultures and hindering cultures.

What we also need to remember, is that Knowledge Management practices are themselves agents of culture change.

• The After Action review was first introduced by the US Army after Vietnam as a culture change process, and they found that learning was a major by product. I also have an excellent video from the Process Manager at Jwaneng diamond mine, where he describes the business value, then lights up completely as he talks about the culture change that came with the business prize.

• Peer Assist is an excellent culture change process, making commections across the organisation, promoting learning from others, and breaking down cultural silos. Introducing Peer Assist is like planting the seed of a collaborative culture.

• Communities of practice also are a new cultural phenomenon. I am sure you have seen the Rio Tinto video, where the manager describes communities as "a significant shift in the culture of the organisation" (at about 4m 10s)

• Retrospects (provided action is taken based on the lessons) are also a harbinger of a new culture - a culture of reflection and self analysis. (If no action is taken, this reinfirces the feelings of "this is a waste of time" and "nobody ever listens to us").

So even if your culture is anti-KM, dont wait for the culture to change before you start KM.

Start KM, and the culture will change!

The emotional shock that destroys “not invented here”

---

During the last 2 weeks I have run 3 “Bird Island” exercises, and after the last one, I received some interesting feedback.

“The big learning for me” this guy said “was the shock when I saw what others had done, and how poor our performance was compared to theirs”.

In this exercise, we ask teams to perform a task in isolation – to build a tower as high as they can, to pass certain constraints (so trading off height versus stability). We then allow the teams to share knowledge with each other, and we then show them the best practice from all the (nearly 300) teams who have done the exercise before.

There are three moments when team members get an emotional shock.

Firstly when a team, who is proud of their 80cm tower which they think they could stretch to 95cm with luck, are visited by someone from a team who have already reached 125cm and think they could get to 150. You can see the jaws drop as they realise how constrained their thinking has been.

Secondly when we show the teams the benchmark statistics (current record height, well over 3m, current modal height, 290cm). There is always an audible gasp in the room, as teams who think they might just about get to 150cm, realise how far off the mark they really are.

Then the third moment is when we show a picture of a >3m tower. You would think that the benchmark data themselves would have given enough of a shock, but somehow the picture is even more impressive – a smiling team standing behind a tower which brushes the ceiling. The usual response from the room is “Whoah!”

I think it’s that shock, that destroys the Not Invented Here.

Never do we hear a team say “well they may have got to 3m using that design, but we aren’t going to use it. We will invent our own”. Always they take the design, and maybe tweak it a bit to add some more innovation to push it a little higher.

So what’s going on psychologically?

I think there is something emotional happening, very akin to humility. People see evidence that they need to learn. They see evidence that their own knowledge is inadequate to deliver a reasonable performance. They become fully open to knowledge from others.

Without understanding the inadequacy of their own knowledge, people can be fully entrenched in “not invented here”, and it may need an emotional shock to dislodge them.

Bursting the knowledge bubbles

---

I have blogged a couple of times about the book  "Deadly Decisions - how false knowledge sank the titanic, blew up the shuttle and led America into war" by Christopher Burns; an excellent book, which I would recommend to the KM professional. He talks about what he calls the "Information bubble" - where a person making decisions inhabits a bubble, receiving information only from a few like-minded sources. The knowledge within that bubble is therefore groupthink - false knowledge, created only from local sources, and becoming a self-reinforcing and totally erroneous belief.

Burns gives the classic example of the second Bush administration, where Condoleeza Rice reorganised the various counter-terrorism groups to report only to her, acting as a filter and bottleneck, with the result (he suggests) that the senior administration "knew" that Iraq and Saddam Hussein were the only real threat to the USA. Concern about Bin Laden's plans to attack the US was therefore "effectively kept from senior members of the administration" until it was too late.

We see such knowledge bubbles at work in a number of contexts

• The team which thinks it has "the right solution" and listens to nobody else
• The individual with the "not invented here" mindset - immune to challenge
• The social media community which forms around like-minded people and perpetuates group-think
• The senior technical staff who defend "best practice" long past its sell by date
• The senior management team who are protected from, or immune to, "bad news"

In each case the information flow or knowledge flow reaches an impenetrable barrier.

Any organisation serious about KM has to burst these bubbles before disaster can strike. They can for example

• Require or mandate teams to hold peer assists, to get them to listen to others
• Outlaw "not invented here"
• Extend their communities to include all shades of opinion, and to promote dialogue, not monologue
• Recast Best Practice as a constantly changing concensus, not an immovable object
• Strengthen the knowledge supply chain to senior management, to become a conduit of what Burns calls "Dissonant facts (which need to) travel quickly up an organisation, in the same way that even the slightest pain shoots through the nervous system, and for the same reason".

Lets start bubble-bursting. Who's got the pin?

KM for senior management

---

Lots of managers assume that knowledge management is "something my staff need". They therefore set up KM initiatives to cover routine tasks at low levels in the organisation. They might set up a KM program to improve call centre response, or to improve shift handover, or to improve productivity on the assembly line.

This misses the point.

Knowledge Management is something that is of value at all levels. Knowledge supports decisions, and decisions are made at all levels. In fact the most valuable and risky decisions are made at senior level. The default approach to supporting these senior management decisions is to hire a big-5 consutant firm to supply the knowledge, but there is no reason why KM can't help as well.

So when you are proposing KM pilots, look for pilots at senior level, to support the big decisions. Here are some examples from the past.

Knowledge Management to support mergers and acquisitions. There's a massive, high level task, which requires big decisions. Learning from past mergers can materially improve future mergers.

Knowledge management to support new business. Companies may open new offices, or start up in new countries. With knowledge, this start-up may be quick and effective. Without KM, the start-up may hit snags, be delayed, or fail to deliver the required business results.

Knowledge of leadership. That's a massive issue! One company uses a detailed 6-monthly staff survey to measure morale, and gathers insights and learning from the managers of high-morale teams to help develop leaders in the organisation. Another has build an entire knowledge asset providing knowledge for plant managers.

 Delivering a high level KM pilot on these areas has three benefits.

• It delivers massive value to the business
• It engages senior managers in KM, and helps them understand the value KM can bring
• It gets senior managers on-side, by solving their problesm for them (see the thorn in the lions paw).

 KM is something that is needed at all levels, and the sooner you involve the senior managers, the faster and smoother your implementation will become.

  

Warnings - the crucial content of the knowledge supply chain

---

Warning!
Originally uploaded by Håkan Dahlström

I blogged recently on the knowledge supply chain, as a metaphor for the transmission of knowledge and lessons in support of corporate decision making. The supply chain I described was a lateral one, peer to peer, designed for identifying learning from activity which can be used to improve future activity.

There is another knowledge supply chain, which is a vertical one. This is the supply of knowledge, and often the supply of warnings, from deep within the heirarchy, up to levels where major decisions need to be made.

It is the failure of this vertical knowledge supply chain that is behind some of the most spectacular disasters of the last century.

Nancy Dixon recently identified the 3rd age of KM being the integrated flow of knowledge up and down the heirarchy. This is still a very difficult thing to get right, as is profoundly illustrated by Christopher Burns in his book "Deadly Decisions - how false knowledge sank the titanic, blew up the shuttle, and led america into war". Burns mentions several cases where warnings have been ignored, or downplayed, or rationalised away completely. He cites many high profile examples

• Multiple warnings, often very detailed, that Al Qaeda was planning a major assault, using aircraft, within the USA
• Repeated warnings that the O-rings on the Challenger shuttle were at risk at low temperatures (the sam O-rings that failed at low temperature, with catastrophic loss of the shuttle and all crew)
• Warnings that the Titanic was steaming into an icefield
• Warnings that the cooling water system on the Three Mile Island plant was faulty, and might lead plant engineers to make decisions that could lead to melt-down

In his book, Burns talks about the psychology of information and knowledge processing, and reinforces how we form mental models which can be difficult to shift. A strong mental model can reject facts that don't fit, and companies and organisations can create structures that actually make this worse. The Bush Administration, he argues, was particularly bad at this, surrounding the president with like minded people, and producing a heirarchical knowledge supply chain which filtered out news that didn't fit the preferred model. The knowledge supply chain was fed at the base with warnings that might have averted 9/11, and might have avoided the Iraq war, but these warnings became weaker as they moved up the heirarchy, or were filtered out completely, he argues. The knowledge that was supplied to the top, was the knowledge that The Top wanted to hear.

However if an organisation is to avoid disaster, it must be very sensitive to warnings. Warnings cannot be filtered out or ignored, if we want to avoid our own versions of the Titanic, 9/11, the Enron collapse, the Challenger disaster, or Three Mile Island. The knowledge supply chain must carry these warnings faithfully and accurately, Burns says that

"Warnings are a special class of dissonant information and they are difficult to heed for three reasons. First warnings .... often come from people deep within the organisation who have few credentials and are often hard to understand. Secondly, they contain a prediction about the future based on facts, values and concepts which might be different fron those of the listener. It is important for the person giving the warning to remove as many of these obstacles as possible. And third, there's a pathology of giving and receiving warnings that needs to be overcome".

He describes this pathology as the warner, anxious to get the message across and worried that the "warnee" will not listen, having a tendency to overstate the danger. The warnee gets used to these overstatements, and discounts the significance of the message, which prompts the warner to even greater exaggeration. He says that the only way around this is to lay out the facts for the warnee, and let them connect the dots themselves. The end result is that warners find warning to be exhausting, confrontational and career-threatening. Many of the people Burns identifies as having tried to deliver warnings, either lost their jobs or retired soon afterwards.

So to allow warnings to reach the decision making layer, we need

• an openness at senior level to dissonant voices and to the "weak signals" of warnings (perhaps using an anlysis function specifically to look for these)
• a knowledge supply chain that is as short as possible, either through a flat information heirarchy, or the sort of cross-heirarchy knowledge sharing events that Nancy Dixon describes
• to reward warners rather than punish them, much as people are now encouraged and rewarded in safety-conscious cultures for identifying near misses or unsafe conditions. In a safety context, people are encouraged to warn, and a lack of warnings is seen as a sign that something has gone wrong with the system. We need a similar approach to warnings in all areas - not just safety warnings, but warnings of changes in the market, warnings of inefficient processes, warnings of complacency and of obsolete thinking.

Making the vertical knowledge supply chain work efficiently and effectively may just be the biggest challenge that will face Knowledge Management going forward.

Lessons Learned - looking for common factors

---

Looking For Clues (188 / 365)
Originally uploaded by somegeekintn

One the the advantages of running a routine lessons learned system, is that it allows you to identify the persistent problems, and the common causes of failure. So although you can take action as a result of the learning from each individual lesson, then if you also look through the lessons for common themes, you can find the deeper problems and the systemic issues that need to be addressed.

I did something like this many years ago. After running a lesson system for several years, we had 300 lessons, and were able to draw out the common reasons for project failure. These are listed below for your information, and we used this information to rework our project initiation process, to remove as many of these problem areas as possible


The project team is not an established team with common working practices.

• The team contains staff new to the business and the project management system.
• There are changes of staff within the project team, during the running of the project.
• The project leader, or other key team members, is away at a critical time.
• The entire team is new.
• The team includes a mix of disciplines which do not usually work together.

The project involves new tools and techniques, which are unfamiliar to the project team.

• The team need to learn new techniques.
• The project involves the installation and use of new software.
• The project leader is unfamiliar with the topic.

There are customer issues.

• The customer changes during the project.
• It is not clear who the customer is.
• The customer is away at a critical stage in the project.
• The project has an external customer.
• The customer is unfamiliar with the topic of the project. 

 Satisfactory completion of the project relies on an external supplier.

• Influencing another company is key to success.
• Input or data is needed from another company.
• The project relies heavily on contractors.
• Input, resource or data are needed from another part of the business 
• The project relies on specialist support.

 The project is a low priority 'back-burner' project.

• The project has been given a long deadline and low priority.

The project is poorly defined.

• The objectives or deliverables are not clear.

There are IT issues.

• The project relies on an unusual degree of IT support.
• The project involves non-routine IT use.

Business strategy changes during the project.

• The project needs to be re-thought and redesigned.
• The customer needs to be re-interrogated.

 The project is running at a busy time.

The project requires lots of people to buy in to the results.

• The project may involve consultation with large numbers of staff.

 You might want to check your KM project against the list!

Community start-up - Johnny's story

---

Duck Start
Originally uploaded by photon ℽ

Found in the archives, an interesting view from my friend Johnny about how communities of practice can start from the bottom up.

"To start off a community, you really need to have a "Something" to go after; a common purpose, a common goal. You find out very very quickly what that is, there are a lot of them out there, you just start to see what people are struggling with. What are the issues in the company; what are the issues around you in your team? "Oh, it's this - OK, lets go and see what this other team over here are doing". So you speak to 10 people., and one of those people - you will know right away that you can build a relationship with that person. So you can do that either formally or informally, and its usually better to have an informal start-up. Just to see how it works, see if there is any "meat" here, and you get it running - up and trucking - and you get regular meetings going.

"The you start to say "We could look at this, and we could deliver this". Then once you have set that up, and you are happy that you know you could go and work something, then you have to approach your line manager, because you will need their support. There are no two ways about it; you will need their support to work outside your core role, so it's very important to try and get that support, so you have to do that.

" For me it's about like minded people getting together with a common purpose and trying to solve something quite small that may lead to something bigger. Deliver on it, and just show the difference it can make from just getting into a room together."

Thanks Johnny

Review/Preview

---

IMG_0646
Originally uploaded by Nick_Milton

Continuing the sport theme, I was watching a video of Guy Mercer, one of the up and coming young players at Bath Rugby, and he mentioned a term I have not heard of before in the context of performance and learning.

He referred to a Review/Preview - a meeting where the players review their performance at the previous weekend's match, watch the video from the game, identify the points where they made progress and the times when they were knocked back, identify their strengths and weaknesses, the effective tactics and ineffective tactics, and decide (with the help of the coaches) what they want to work on or change for the next weekend's match.

In many ways this is like an After Action Review, though with the added piece of process of tacking on a forward plan as well. I like this concept. For a team, it can be an effective tactic to drive continuous performance improvement. And for a rugby team, there is the added impetus that every other team in the tournament will be doing the same thing. The team that does not learn, heads for the bottom of the table.

Perhaps we should approach our business learning in the same spirit!