KM supporters - don't just preach to the choir

---

Happy Devils Fans
Originally uploaded by C.P.Storm

Here's an observation from eighteen years of working KM

Only about one in five people instinctively "get" KM.

Only about 20% of staff are supporters of the idea from the beginning. When you talk to a room full of people about KM, the "KM Light Bulb" will switch on over the heads of about a fifth of your audience.

Now this is a good thing, as that 20% will become your allies, your supporters and the early adopters.

However, about 3 in 5 people don't care about KM

They don't get it instinctively, the light bulb doesn't switch on. They will do it if they have to, if it's part of the job, but if they don't have to do it, they won't. If KM is voluntary, or "encouraged", they won't bother. They have better things to do. They just want to get on with their job. Now in a way, this is also a good thing, because if we make KM part of "doing a good job", they will do it.

The remaining 1 in 5 really don't like KM at all

They think it a waste of time, or a personal threat, or a way of "stealing their ideas". These people will resist KM, unless it is made unavoidable and fully embedded into performance management so that their job prospects suffer if they refuse to share.

There are a few implications of these demographics.

Firstly, if you introduce KM from the bottom up, you only reach 20% of the people.

There is still a strong movement in KM who beleive that what you need to do is allow people the time and space, provide them with the tools, and KM behaviours will emerge. Well yes, they will emerge, but only among the 20% of supporters. You will get a lot of Buzz, you will find some exciting projects, but you are preaching to the choir. The KM fans will create a KM bubble, but you won't penetrate the rest of the organisation, so 80% of the knowledge remains untapped and unmanaged. This is a pattern we have seen many times. If you go back to the initial KM launch in BP in 1997, the mood of the meeting was "Management just need to allow us the time and space to do KM". This was because the meeting was attended by enthusiasts, who just wanted to be allowed to share knowledge. Ten years later we realise that to reach the other 80%, management need to move beyond Allowing, and move beyond Encouraging, in order to get to Expecting or Requiring. Management Expectation will reach the next 60%, Management Requirement will reach the remaining 20%.

Secondly, you can use the 20% of enthusiasts to make the case to management

Management are not going to set the expectation or the requirement, unless they believe KM really adds value. So use the 20% who are your supporters and early adopters to conduct the pilots, deliver the benefits and write the case studies that will convince management to set KM as a corporate expectation. Use this resource as a stepping stone to the next step. This is the thinking behind our staged implementation model which we will cover in the next newsletter. To continue the ecclesiastical metaphor, its OK to preach to the choir, if you then use the choir to produce the required miracles that will convince management.

Finally, you won't complete the journey until KM becomes inescapable

If the company is committed to KM, then the last 20%, who really don't like it, need to know that their future is at risk if they continue to avoid or sabotage the KM efforts. As Bob Buckman said, "we incentivise KM. If you share your knowledge, we incentivise you by letting you keep your job". OK, this is hard-nosed stuff, but if you let KM remain optional - if you let people avoid it with no sanction and no follow-up, then the word gets round, the 60% stop doing it (as they have other things to get on with), and soon there's nobody in the church except the choir see blog post about "the tipping back point")

Now the figures may vary from company to company, and from culture to culture, and may not always be 20%, 60%, 20%. In a truly progressive company, it may be 40%, 55%, 5%. In a cynical old-style firm, or a public sector department riddled with politics, it might be 5%, 50%, 45%

However the demographic groupings will be there, and your KM implementation program needs to recognise this. Its fun to preach to the choir - you get lots of positive feedback - but it won't get you very far in the long run.

"The first fully functioning KM war" - another glimpse of KM in the military

---

8th Provisional Security Company Marines Board Zodiac
Originally uploaded by DVIDSHUB

An excellent blog here from Randy Garsee on KM in the US Marines.

Here's a quote he includes

“This is the first war where we had a fully functioning system of knowledge management, where information can be gathered, accumulated, studied, and analyzed.”
Col. Michael Crites

also

“Marines are famous, I think, in strength and physical courage and intellectual ability,” Crites says. “But now I think we’re showing more intellectual prowess overall because of the effort of Marine Corps Center for Lessons Learned.”

You will also note the extensive use of After Action Review, described in the post.

A slideset of KM in BP

---

I see that Chris and Geoff have made this old slideset public. It's material that we created as part of the BP KM team back in the 1990s, plus some material from 2000

If the slideset doesn't appear below, then click here

BP Knowledge Management

View more presentations from whatidiscover.

It's worth bearing in mind that this is all pretty old stuff, that everything from slide 25 onwards has been superceded, and that all the recent developments in terms of governance, metrics, and embedding KM in the operational and performance frameworks (such as the use of KM plans), are not here.

However the first 16 slides are a good summary of KM in the oil sector, and contain elements that are still in use at BP and elsewhere

KM failure stories number 5 - choosing the wrong tool

---

felt tools
Originally uploaded by CREEPETZ

This is the story of a medium sized company that wanted to start KM.

They looked around at what others were doing, read the books, bought the magazines, and decided that Shell were one of the leaders to emulate. One of the core components of Shell's KM model is it's communities of practice, which use online question and answer forums to share knowledge around the globe.

The company decided to copy this, and to introduce online question and answer forums. Now already you can see a few warning signs - you cannot assume that communities of practice alone will deliver KM (Shell has many more tools in its KM toolbox*), and secondly you cannot assume that the technology will deliver the communities. So perhaps it was unsurprising that the community forums remained almost completely unused.

But there were other issues as well. Shell's communities are spread around the globe; this company had all its staff in a single office. Shell's community staff could only interact virtually; in this company they could talk, they could visit each others offices, and they could talk to their colleagues if they had a problem. Shell is a multilingual organisation, and an English Language forum made sense; in this company, although their forum was in English, the staff all spoke their native language, making it far easier to talk in their native language, than communicate through the forum in English.

I am pleased to say that this company very quickly realised that they had made a false start, and rethought their strategy, deciding instead to implement a full set of KM processes, tailored to their own context. But it's a lesson worth learning - there is no one-size KM solution. Although there are a set of universal principles, the solution you create and the toolset you adopt must be designed around your own needs.

Learning without liberty - the importance of empowerment

---

Handcuffed , Tokyo
Originally uploaded by mskogly

"Liberty without learning is always in peril; learning without liberty is always in vain".
- John F. Kennedy

This is a great quote! But how does it apply to KM?

I was having a conversation recently on a discussion forum about what Communities of Practice needed in order to succeed, and my "number one need" was Empowerment. There is little point in having communities, unless they are empowered to act on the knowledge they share.

By Empowerment, I am referring to the ability of the community members to take action, based on the knowledge they receive.

Here's one scenario

"Jo has a problem. Jo asks the community for help and advice, and receives some excellent practice. She applies the knowledge she receives, and solves the problem"

Here's another.

"Joe has a problem. Joe asks the community for help and advice, and receives some excellent practice. He presents the solution to his boss. His boss doesn't like it, and suggests another course of action"

In scenario 1, communities deliver value, and thrive and grow.
In scenario 2, communities can actually be counterproductive, in that they create tension between what people know is right, and what they are allowed to do.

These are extreme scenarios, but I hope illustrate what I mean by empowerment.

In a disempowered organisation, people can receive the knowledge they need to act, but lack the freedom to take the action, which leads to frustration and bitterness. Learning without liberty is always in vain.

Wikis in the Army

---

Nancy Dixon has just published a really interesting post about the use of Wikis by the US Army, as a way of developing doctrine.

As you read this article, notice not just the technology that is being used, but the structure around it, for example

The roles and accountabilities (TRADOC, with overall ownership)
The processes (initially Kaizen workshops, then AARs)
The governance (top-down direction from the general)

The technology is working (or looks like it will work) because its part of a complete system.

More reasons for failure - let's learn from BPR

---

Truck accident
Originally uploaded by Larsenio

Hey - I hope I'm not being unduly negative here, with all these posts about failure!

If we understand reasons for failure, we can avoid them in our own KM campaigns, and successful KM implementations are based on a thorough understanding of what not to do, as well as what to do.

Here's a list of 19 reasons why BPR exercises failed, from Hammer & Champy (1993, Chap. 14). I have put (KM) in the list instead of Re-engineering - see how many of these reasons make sense to you in a KM context.

1. Trying to fix a process instead of changing it


2. Not focusing on business processes


3. Ignoring everything except (KM) [e.g. reorganisation, reward system, labour relationships, redefinition of responsibility and authority]


4. Neglecting people's values and beliefs [need to reward behaviour that exhibits new values and behaviour]


5. Be willing to settle for minor results


6. Quitting too early


7. Placing prior constraints on the definition of the problem and the scope for (KM) effort.


8. Allowing existing corporate cultures and management attitudes to prevent (KM) from getting started. [e.g. consensus, short termism, bias against conflict]


9. Trying to make (KM) happen from the bottom up


10. Assigning someone who doesn't understand (KM) to lead the effort.


11. Skimping on the resources to (introduce KM)


12. Burying (KM) in the middle of the corporate agenda.


13. Dissipating energy across a great many (KM) projects.


14. Attempting to (introduce KM) when the CEO is 2 years from retirement


15. Failing to distinguish (KM) from other business improvement programs [e.g. quality improvement, strategic alignment, right-sizing, customer-supplier partnerships, innovation, empowerment, etc.]


16. Concentrating exclusively on design [forgetting implementation]


17. Trying to make (KM) happen without making anyone unhappy.


18. Pulling back when people resist making (KM) changes


19. Dragging the effort out [1 year is long enough]

So, what do you think? Do any of those not apply? Maybe number 1 is more a BPR concern than a KM concern, but other than that the only comment I have is that number 6 and number 19 are in conflict, and I have yet to see a successful KM implementation that took less than a year.

Otherwise this view of a focused, managed, well-resourced, visionary, committed program, supported from the top down and not afraid to make waves, fits most of the really successful KM programs that I know.

Now KM is prone to ADDITIONAL reasons for failure, which you will find in older posts on this blog.

KM failure stories number 4 - right tool, wrong situation

---

Capitol Hill Bus Accident in the Snow
Originally uploaded by legalmindedpunk

A good story here about someone using specific KM tools for the wrong reasons, and going wildly off course as a result.

The Los Angeles Times decided that it would be good to have an editorial composed and edited by the masses. The LA Times started by posting their editorial, and then provided a wiki for the public to respond. As Wikipedia has learned, there is no alignment of goals among political types and the partisans reigned supreme during the very brief life of the wikitorial. In the organic, evolving world of wikis, consider the wikitorial an evolutionary dead-end. At first, the users made a good faith effort to collaborate on an editorial, but they soon concluded that producing a single editorial that was acceptable to everyone was not going to happen and there had already been attempts to delete the entire editorial, so by the second day, they forked the editorial so that it would be possible to represent different points of view. Once news of the wikitorial experiment showed up on Slashdot, a technology-related news website (http://slashdot.org), it attracted a lot of attention and it was soon followed by pornographic posts and so on. On the third day, the wikitorial was shut down.

The reason the Los Angeles Times wikitorial failed is that an editorial is a point of view about a controversial subject. The goals of the individuals on either side of the debate are to discredit those who disagree with them and establish their world view as pre-eminent. In other words, the goals of the left and the right are not aligned. Therefore, I suggest no bi-partisan wikis. Ever. There is no such thing.

Angry Mob or wise crowd?

Angry Mob
Originally uploaded by dpsullivan

---

What makes the difference between the wisdom of crowds, and the madness of the mob?

How do you know that something is correct, just because many people believe it?

Where do you draw the line between crowd-sourced wisdom, and popular delusion?

I don't know the answers here, I am just intrigued by the questions, and I was struck by this quote from

this blog

"The key to such widespread phenomena (as financial bubbles) lies in the nature of the crowd: the way in which a collection of usually calm, rational individuals can be overwhelmed by such emotion when it appears their peers are behaving in a certain universal manner. ... At its fundamental level, this fear of being left out or failing when your friends, relatives and neighbors seem to be making a killing, drives the overwhelming power of the crowd.

"Another motivating force behind crowd behavior is our tendency to look for leadership, in the form of the balance of the crowd's opinion (as we think that the majority must be right) or in the form of a few key individuals who seem to be driving the crowd's behavior by virtue of their uncanny ability to predict the future. In times of uncertainty we look to strong leaders to guide our behavior and provide examples to follow. The seemingly omniscient market guru is but one example of the type of individual who purports to stand as all-knowing leader of the crowd, but whose façade is the first to crumble when the tides of mania eventually turn".

Signs that your KM strategy is about to crash

---

Accident is going to happen
Originally uploaded by Gravestone

In a great post, Lucas McDonnell provides 6 signs that your KM strategy is in trouble. These are

1. People outside your group don’t understand what you’re doing.

2. You keep changing vendors/technologies/products.

3. You keep layering vendors/technologies/products on top of each other.

4. You find it difficult to explain what you’re trying to accomplish.

5. You’re prescribing organizational change.

6. You’re making big promises.

Now numbers 2 and 3 make me think there is a missing "sign 7", namely

7. All you are focusing on is vendors/technologies/products

It still amazes me how often you hear "KM is all about people" from teams who are concentrating solely on technology. we have known for Years that KM is about technology AND people AND process.

So however much time and money you spend on technology, spend the same on People - coaching people, training people, listening to people, setting people's roles and people's accountabilities, and looking at people structures.

Then spend the same amount of time on Process - work process, knowledge seeking process, knowledge sharing process, community process, team process and project process. Finally there is the issue of governance, which is often neglected completely.

Driving a KM strategy on technology alone and neglecting the other three aspects of people, process and governance, is like driving a truck with only one tyre inflated.

Sooner or later, something is going to crash.

Getting the seniors to buy in

---

A recent discussion on the KIN blog on Community Sponsors has raised the issue (again) of how to gain senior management buy-in to KM.

My knoco South Africa colleague Ian Corbett uses this matrix to identify areas where sponsorhip is likely to be forthcoming. This is controlled by two factors

1. The corporate need (need for growth, need to close performance gap)
2. The character of the senior manager (open to help, closed to help)

We can extend this (and often do extend this when screening pilot projects) to address

3. The ability to scale up the results, and
4. the ability of the KM team to deliver

However when it comes to getting senior management buy-in, then the number one piece of advice is -

"Don't even bother to approach them, unless KM will answer a real business need"

And even then, they may not be open to your help.

Sites don't build communities - communities build sites

---

We ran a KM Assessment last year with the KM lead for an organisation. At one point we were talking with one of their KM team, who proudly announced "we have lots of communities of practice". When we pressed her a little more to find out what she meant by this term, we found that for her, a Community of Practice is a SharePoint site with a list of contributors, a blog, and a wiki. Then when we went online to look at these "communities", the vast majority were entirely empty. Quite silent. No activity at all.

It takes far more than technology to build a Community. The key is in the word Community. Community is a feeling - it is a feeling of having something in common. It is a feeling of trust and of loyalty. Communities of practice deliver value in organisations because they set up structures of dual loyalty. A community member is loyal to their work team, but also loyal to their community, and this loyalty and trust is what enables the communities to be a conduit of knowledge between one work team and another.

Providing a set of community tools and expecting community behaviours to emerge is a variant of the "Build it and they will come" argument, which is pretty well discredited (see here for example). It's like building a village hall in sectarian Northern Ireland, and expecting a multi-sect community to develop.

They key is to build the community first, and let them build the hall. Or the website/blog/wiki/whatever. You can provide the tools, and the bricks and mortar, but the community builds their own site.

That's why we always recommend face-to-face community launch, to build the sense of community, the trust and the loyalty, before we build the toolkit. And sometimes the toolkit is not needed - the six communities we helped launch in Kuwait* are delivering value without the aid of SharePoint, blogs and wikis (all of which are coming, but not there yet)

*Unfortunately the link to the community case studies on the KPC site is no longer active

Computers cannot know

---

In her blog on Legal KM, Mary Abraham asks "What exactly does knowledge management accomplish? Does KM add anything? Is it a distinct discipline or just information management with a fancy title"?

She bases this question on a post entitled The Promise of Information Management, and says "the post begins by asking what information management tools and technology are really designed for and answers the question with the Maslow-like diagram that shows the hierarchy of IM needs. (these include) risk mitigation, compliance and security; cost savings and efficiency; improved knowledge and innovation. Those sound like worthy — and rather familiar — goals. But isn’t that what Knowledge Management (or at least KM 1.0) claims for itself as well. If the information managers have all of this well in hand, what exactly does knowledge management accomplish?"?

Well, yes it is what Knowledge Management claims, to an extent. So is KM just information management with a fancy title?

I think to answer this question, we need to get clear on what's different about knowledge, and therefore what's different about knowledge management.

• Information is something that can be held in books and computers, but Knowledge can only be held in people. Books and files can inform, books and files cannot know.
  
  
• Information is based on data, knowledge is based on experience. Only people can have experience.
  
  
• Information can be taken out of context, knowledge cannot be divorced from context.
  
  
• Information is the basis on which action can be taken and decisions made, knowledge is the ability to choose the correct action and make the best decision.
  
  
• Although some knowledge can be made explicit, and passed to others to be internalised, much knowledge can never be made explicit. Information can always be made explicit.
  
  
• Accessing information is not the same as acquiring knowledge, as the acquisition of knowledge also requires the acquisition of understanding



• Finally, if I were going into the operating theathre for major surgery, I would rather have a surgeon with knowledge of what to do, than a surgeon who just had information

The differences between knowledge and information are human differences, to do with context, experience, and sense making. Although good IM is vital to help with explicit knowledge, it is not enough in itself even then, as the issues of externalisation and internalisation also need to be addressed. IM will never help with tacit knowledge exchange.

So IM can help "improved knowledge and innovation" but without KM, it won't deliver it fully. Also the goal of KM is not "improved knowledge and innovation" - it's improved decision making and performance.

So on top of IM, we need to add the personal, social, behavioural and cultural aspects of KM, we need to introduce the processes, strautures and accountabilities for expternalising, sharing and intneralisaing knowledge, as well as those for the management of information and content. We need to bring in teh human dimemsion.

See our video page for my video on the difference between data, information and knowledge

Dialogue in KM

---

Conversations at State of the Net
Originally uploaded by antony_mayfield

I am a firm believer in the power of Dialogue in Knowledge Management (see previous blog post here). We can assume that connecting people together can lead to better knowledge exchange, but connecting wires doesn't make a circuit. You need a way of ensuring conductivity as well as connectivity, and dialogue provides that conductivity.

What's different about Dialogue? Dialogue is a form of conversation, in which the participants are trying to reach mutual understanding. It is a process of exchange of views and of knowledge, of asking questions and of listening to the answers. It is a combination of listening, advocacy, reasoning and consensus-seeking. Dialogue is a question-and-answer process by which people exchange knowledge. It is hard to imagine effective knowledge exchange without some form of dialogue.

It differs from argument, which is all about presentation and advocacy of views. There are no winners or losers in dialogue; you can't say "I lost the dialogue with Peter”.

It differs from debate, which is all about testing the validity of a proposition rather than testing whether it is understood.

It differs from interrogation, where all the questions are one-way, and only one person stands to profit from the exchange.

It differs from discussion, which is often about analysis of detail rather than searching for common understanding.

I blogged previously about the unknown knowns. This is the unconscious knowledge, the deep knowledge of which people are unaware. Under these circumstances, the transfer of knowledge from one person to another is not an easy thing to achieve! The person who has the knowledge (the "knowledge supplier") may only be partially conscious of how much they do know. The person who needs the knowledge (the "knowledge customer") may only be partially conscious of what they need to learn. The knowledge supplier has both conscious and unconscious competence, and the knowledge customer has both conscious and unconscious incompetence. Also the knowledge supplier doesn't know what the customer needs, and the knowledge customer doesn't know what the supplier has.

Without effective dialogue, a lot of this knowledge will not be transferred at all.

Dialogue is needed, in order to

• Help the knowledge supplier understand and express what they know (moving from superficial knowledge to deep knowledge)
• Help the knowledge customer understand what they need to learn
• Transfer the knowledge from supplier to customer, and
• Check for understanding

The knowledge customer can ask the knowledge supplier for details, and this questioning will often lead them to analyse what they know and make it conscious. The knowledge supplier can tell the customer all the things they need to know, so helping them to become conscious of their lack of knowledge. As pieces of knowledge are identified, the customer and supplier question each other until they are sure that transfer has taken place.

Almost all of the effective KM processes are based on dialogue. AARs, Peer Assists, Knowledge Handovers, retrospects, Harvesting interviews, Learning Histories, Knowledge exchange - all are dialogue based.

Some of the elements of dialogue can be done remotely through Web 2.0 tools, though this is often a poor second. Blogs are 95% monologue, and although some dialogue can be sparked through blog comments, it's more often debate than dialogue. Community discussion forums can occasionally engender dialogue, but again, debate and argument are often found in there as well. Wikis allow co-creation, but not through a dialogue format, which makes them difficult for really contentious or emergent topics. In most cases, if transfer of important knowledge needs to be done well, there is nothing like the power of dialogue in conversation.

2009 MAKE awards announced

---

...and the winner is
Originally uploaded by notsogoodphotography

The 2009 global MAKE awards finalists have been announced here

And the winners are

Accenture (Global)
- Apple (USA)
- APQC (USA)
- Bechtel (USA)
- BP (United Kingdom)
- British Broadcasting Corporation (United Kingdom)
- ConocoPhillips (USA)
- Deloitte Touche Tohmatsu (Global)
- Environmental Resources Management (Global)
- Ernst & Young (Global)
- Fluor (USA)
- General Electric (USA)
- Google (USA)
- Hewlett-Packard (USA)
- Honda (Japan)
- Honeywell (USA)
- IBM (USA)
- IKEA (Sweden)
- Infosys Technologies (India)
- KPMG (Global)
- LG Group (S. Korea)
- Mars (USA)
- McKinsey & Company (Global)
- Microsoft (USA)
- MindTree (India)
- Nissan Motor (Japan)
- Nokia (Finland)
- Oracle (USA)
- Petrobras (Brazil)
- POSCO (S. Korea)
- PricewaterhouseCoopers (Global)
- Royal Dutch Shell (Netherlands/United Kingdom)
- Samsung Group (S. Korea)
- SAP (Germany)
- Schlumberger (France/USA)
- Siemens (Germany)
- SK Group (S. Korea)
- SKF (Sweden)
- Sony (Japan)
- Steelcase (USA)
- Tata Group (India)
- Toyota Motor Corporation (Japan)
- Unilever (Netherlands/United Kingdom)
- Wipro Technologies (India)

What makes me proud, is the presence here of three of our major clients (as well as one or two others we have worked with over the years in a more minor capacity).

BP - Tom and I were part of the BP KM team in the late 90s, have provided BP with KM training and KM services ever since, and helped with the major KM refresh in 2004. BP demonstrates perhaps the most embedded KM system I have seen outside the military.

BBC - Tom and I consulted to the BBC Live and Learn Team from 2002 through 2004, and helped to introduce many of the core processes of KM. Much credit is also due to Euan Semple and his pioneering introduction of web 2.0 tools. The BBC is an organisation of knowledge sharers, by remit and by nature.

Mars - we held the first KM course in Mars in 2002 (EuroDisney - I remember it well), were at the KM launch in Lisbon, helped draft the KM strategy, and provided training and KM services for many years. Their successes have been enormous - well done Linda, Kirsty and the team.

A cherished KM moment

---

I came across this the other day - it's an extract from my book Performance Through Learning (available here), telling of a key moment in the history of the BP KM journey

The room was too small for the number of tables, and the pillars made it difficult to see the stage. People needed to crane their heads to get a clear view, and the air was stifling from the heat of the video lights (the whole event was being captured on video, and web-cast live onto the BP Intranet). And yet there was a tremendous buzz in the room. The three days had been an intense experience, as KM enthusiasts from around the BP group had stood up on stage and described the approaches they were applying to managing knowledge. Ray King had told us of his online community of computer modelers, Tony Kuhel told us about the Olympus system in BP Oil, John Minge beamed in by videoconference to talk about knowledge sharing on Texas drilling rigs, and many others shared their successes and plans. Then there were the outside experts - Colonel Ed with his ‘war stories’ from the Army, Larry Prusak talking animatedly and powerfully for an hour without notes, John Henderson with his view of the future Knowledge Economies. Finally there was the input from the rest of the company, as people used the Knowledge Management website to raise issues and ask questions, which Chris Collison read out loud to the assembled delegates in Milan every morning

It was now the afternoon on the third day. The buzz was still high. We had spent the late morning in breakout groups, working some of the critical issues which needed to be overcome if KM was ever to be a way of life for BP. Jim Shannon, a video producer from the Alaska office, was standing on stage reporting the results from his group’s discussion.

Jim explained how the top levels of BP need to articulate the scale of the challenge and the potential benefits, and then cascade the KM ideals down to the production floor. People need to be involved, and the Knowledge Management community, exemplified by the attendees at this meeting, needs to identify and understand those people they will depend on for success. “How many of you people attending the meeting” Jim asked “are willing to go back and become champions within your businesses, to evangelize and lead Knowledge Management? Stand up if you are willing to be an evangelist for KM”. There was a moments pause, and then chairs began scraping back all around the room as every delegate rose to their feet in a silent movement of commitment to the cause.

After the meeting was over, the KM team traveled out to a restaurant on the shores of Lake Como where I led the group in our own retrospect of the conference. Each of us could identify our personal success factor. For Nigel Gibbs, it was “'the sense, level and quality of community that we developed. Transforming 80 individual learners to a community of learners was the biggest shift I've encountered in such a session. The challenge now, for me, is to shift the community of learners to be a learning community.” Barry Smale noted that we avoided the event being a 'Show and Tell' of KM Team presentations. “This was an objective in the organization of the event and worked extremely well since the delegates got ownership.” Georgie Dicker recalled the continual buzz of enthusiasm in the room and how she ended up in a nightclub with a bunch of the delegates where they were still talking about Knowledge Management at 3 a.m. in the morning.

All of us agreed that Milan had been the right event at the right time and had sparked an excitement and commitment that would form the foundation of BP’s move towards a fully knowledge-enabled company.

Right focus, wrong team

---

One of the most frustrating situations you can face as a consultant, is working with an internal KM team that does not have the capacity to deliver. You want to help them, you want them to succeed, they are focused on the right things, but they are just the wrong people.

So who are the right people? I am talking here primarily about the team that implements Knowledge Management - that introduces the roles, technologies, processes and governance, and that leads the change to a new way of working.

The team leader, first and foremost, needs to be a change agent. They need to be 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.

The skills of the KM team need to be varied. KM covers the area of overlap between IT, HR (or Learning and Development) and Organizational Practice, and so the team needs a blend of people who can cover these areas. Some of the following skills should be on the team.

Facilitation/influencing skills. The knowledge management implementation team has a hard job ahead of them, changing the culture of the organisation, and the soft skills are absolutely core. They will be working very closely with people, often sceptical people, and they need very good influencing and facilitation skills. Secure facilitation training for the team members as soon as you can.

Coaching and training skills. If the aim of the team is to introduce new behaviours and practices to the organisation, they will need people skilled in training, coaching and mentoring. Look for people with skills as change agents and business coaches. One or more people with a training background should be on the team.

Writing skills. The processes of knowledge capture and packaging are in some ways very akin to journalism. Interviewing, group interviewing (e.g. Retrospects), analysis, summary, write-up, presentation, are all part of the stock-in-trade of journalists. Make sure there is at least one person on the team with journalistic or writing skills, and preferably more than one.

Marketing and communication skills. The early stages of implementing knowledge management are all about raising awareness, and "selling" the idea. The team needs at least one person who is skilled at presenting and marketing. This person will also be kept busy raising the profile of the company's KM and Best Practice activities at external conferences.

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

This is what John Keeble, the CKO of Enterprise Oil, said

"If you look at the team more widely, rather than just the person leading it, far and away the most important things are the interpersonal skills, and we have said whoever we are recruiting anyone for the team, that's the most important thing. We can teach them the knowledge management skills, they bring their own network with them, but they have got to have the interpersonal skills, because so much of this is about persuasion. You cannot coerce people into sharing their knowledge, you have to be able to entice and cajole and persuade them to do it"

The organizational backgrounds of the core team need to be varied. The team will be attempting to change behaviour, and embed knowledge management into the business process, across a large part of the organisation (or indeed the whole organisation). Ideally the team should contain people with good and credible backgrounds in each major organisational subdivision. This is really to establish as much credibility as possible. When members of the team 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 team is over, may take a leading Knowledge Management role in their subsidiary.

The members of the team will also need to be passionate about the topic. The team members must be seen to be personally committed to best practice and knowledge management if they are to retain credibility. They need training in the skills and theories of KM and Best Practice transfer, and need access to books, conferences and forums on the topic They must be enthusiastic about applying knowledge management tools and techniques in their own business, and to their own work, in service of improving their own performance.

Finding such 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. However with the right team, the right leader, and the right approach, absolutely anything can be done, and KM implementation will be easy.

Knowledge management is

Knowledge management is
Originally uploaded by Ed Bilodeau

Excellent screenshot, showing Google Lookahead function's idea of the Knowledge Management definition - click on the picture to see full size


According to Google, KM is

A business process, not a technology
About people
Not anything new
A donut shaping your KM strategy with communities of practice (duh??)
The challenge for the leaders to development
About technology

Pithy believe, or taciturn knowledge

---

Another great bit of machine translation, taken from KNOWLEDGE MANAGEMENT IN AN ORGANISATION

"The concept, believe government is mostly used today’s world. And in the believe formed society, egghead collateral is deliberate as the budding apparatus for any organisation.

The presentation of brand new difficult incident done each classification to have believe government initiatives to accumulate, safety as well as implement the believe in one after another ways. Every universe renewed organisations have been right away perplexing to grasp believe government beliefs for their operations.

It is endangered with the make use of as well as developments of believe item of an organisation. The believe is possibly pithy believe or taciturn knowledge. The pithy believe is called as documentary believe as well as the taciturn believe or biased believe is resides in the minds of employees/scientists as well as so on".

I like the concept of taciturn knowledge - that's a great piece of egghead collateral

Changing hearts and minds - one at a time

---

The road of life twists and turns and
no two directions are ever the same.
Yet our lessons come from the journey,
not the destination......365/365
Originally uploaded by AndYaDontStop

It's an old saying; Q- how do you change hearts and minds? A - one at a time.

Implementing Knowledge Management is a change process - we all recognise this. we are changing attitudes as well as workflows and toolkits. We are changing attitudes towards knowledge; from seeing it as a personal attribute to seeing it as collective, from seeing it as a source of personal power to seeing it as a source of company power, and from seeing it as something acquired in the classrooom to seeing it as something acquired every day through work (see more details on the KM culture shift). If people can understand this with their heads and grasp in in their hearts, then we have made this shift.

KM professionals, helping the organisation make the culture shift, need to recognise that these hearts-and-minds shifts cannot be made wholesale. You need to plan a campaign of culture change. There are three weapons in our arsenal here - stakeholder mapping, communications planning, and a compelling case.

Taking these in reverse order, the compelling case needs to be a case for the individual as well as a case for the company, and ideally should be presented in such a way that the individual can "feel" the benefit, or "experience" the value of shared knowledge. We like to do this through exercises, such as our millionaire game, or (the King of all KM experiences) Bird island.

Communications is key to a change campaign, and we believe that communications planning needs to be one core component of a KM strategy. To help folks with this, we have produced a Template Communications Plan, which is available free of charge from our Downloads page. This template is one we use ourselves, and will allow you to

* define which message needs to be given to which audience
* define the medium for delivery of the message, the frequency of delivery, the owner and the sign-off for each message
* change the communication style and message as KM implementation proceeds through it's four stages.

The final weapon in the KM managers (or CKOs) arsenal is Stakeholder Mapping. There are many methods of Stakeholder mapping, most of which rely on defining relationships of power and influence (or power and impact). That's not what you need. You need to map stakeholders in terms of buy-in and influence, and then you need to map, for the most influential stakeholders, how their level of buy-in is needed to change over time. No one person buys into KM in a single step - there are several levels of buy-in maturity. We use an old Amoco model which recognises a ladder of 8 levels of buy-in to an idea, where people seldom move more than 1 or 2 steps at a time. So once you have listed your stakeholders, look at your KM implementation plan, identify the critical decisions, define the level of engagement needed from the critical stakeholders, and map out carefully how you will help them climb the ladder, step by step, reach that level.

That way, when the critical implementation decisions are reached, the hearts and the minds will be in the right place to make the right decision.

more detail from the lessons survey

---

Here are some more details from the lessons learned survey results I mentioned yesterday. You can find the full results from the survey on the Knoco downloads page

74 responses were received. The organisations represented fell into the following categories, with 11 respondents not identifying their organisation.

• Academic (1)
• Automotive (1)
• aviation (2)
• consulting and services (9)
• engineering and construction (7)
• insurance and banking (2)
• IT (4)
• Legal (2)
• manufacturing and sales (5)
• military (4)
• mining (1)
• oil and gas (10)
• pharmaceutical (4)
• public sector (7)

76% of respondents said that their organisation has a lessons learned system in place in at least one major part of their activity. A further 7% were in the process of introducing one. 6% had previously has a lessons learned system, but had stopped, while 11% had no system. Lessons learned systems seem to be most common in oil and gas, military and engineering and construction, but numbers are too small to be sure.

The respondents were asked which part of their business applied lessons learned. Answers are listed below. At least half of the respondents apply lessons learned within the project context.

• Project management (24 responses)
• All activity (7 responses)
• Software deployment and release (4 responses)
• Bidding and pitching (3 responses)
• industrial safety occurrences (3 responses)
• research and development (2 responses)
• Operations (2 responses)
• Other (11 responses)

The survey asked those respondents who had, or were introducing, a lessons learned system, to rate the effectiveness of the system, using a rating between 0 (not at all effective) and 5 (Excellent). The responses are shown in the graph.

• 6% rated the system as 0 (not at all effective)
• 6% rated the system as 1 (slightly effective)
• 48% rated the system as 2 (moderately effective)
• 15% rated the system as 3 (good)
• 18% rated the system as 4 (very good)
• 6% rated the system as 5 (excellent)

Participants who scored highly (3, 4 or 5), were asked to identify success factors which resulted in a high score. Responses were very varied, with no real consistency, suggesting that many factors are needed.

Participants who scored low (0, 1 or 2), were asked to identify the barriers which resulted in a low score. Reponses are shown below, and several common factors can be identified.

• Senior management (11 responses)
• Culture (10 responses)
• Lack of follow through and application (15 responses)
• Time issues (4 responses)
• Other barriers (13 responses)

The respondents were given a list of components of a lessons learned system, and asked to identify whether they applied these components (see graph to the right). The most common is the use of a defined process for identifying lessons from activity, and 46 of the respondents (80% of those with a lessons learned system) had such an identified process. The least common was the use of rewards to incentivise lessons submission.

The figure to the right shows how each of these components correlates with the effectiveness score for the KM system. For each component, the blue bar represents the average effectiveness of those systems with that component. The red bar represents the average effectiveness of those systems without that component. For example, those Lessons Learning systems which include the definition of Actions arising from the lessons (the top component in figure 6) score nearly 3 on average, while those which do not include definition of actions, score less than 2. We can therefore assume that, on average, the definition of actions helps make lessons-learning more effective.

Therefore all components where the blue bar is longer than the red bar are likely, from the data provided by the respondents, to make a positive contribution to lessons learning. The greater the difference in length, the more positive the contribution.

In general terms, all except 2 components seem to make a positive contribution to lessons learning. However we can (relatively arbitrarily) group them as follows

Strong positive contribution
• Actions defined arising from the lessons
• Clear high level expectations from senior management that the lessons learned process will be applied
• A method to measure whether actions have been completed and lessons closed out
• A process for validating/agreeing the actions
• Accountable person/people assigned to complete the actions
• A defined process for identifying lessons from activity

Moderate positive contribution
• A person or people to track the metrics
• An escalation method if the lesson or action needs to be addressed at a higher level
• A clear accountability for identifying lessons from activity
• A high level sponsor of the lessons learned process
• Quality assurance of this process (eg trained facilitation)
• A method for disseminating the lessons
• A lessons learned database which can hold lessons from multiple projects or units

Fairly neutral
• Quality control of the lessons to ensure they are well written
• A method to measure whether lessons have been captured
• A search function within the lesson database

Strong negative contribution.
• Rewards to incentivise submission of lessons

Respondents were asked which components were missing from this list. There were a variety of answers but no common factors.

Respondents were asked to list the methods they use to identify lessons. These are grouped below. Many respondents indentified more than one method.

• After action reviews (17 responses)
• Other project-related review (28 responses)
• Learning from incidents and events (5 responses)
• Individual (ad hoc) submission (7 responses)
• Other (9 responses)

You can find the full results from the survey on the Knoco downloads page and conclusions in yesterday's blog post

.

Lessons Learned Survey results

---

You can find the full results from my recent Lessons Learned survey on the Knoco downloads page

They are pretty interesting. My main conclusions are as follows

It seems evident from the responses to this survey that a large proportion of companies and organisations are attempting to operate, or are intending to operate, a lessons learned system in some part of their organisation. However less than half are actually satisfied with the effectiveness of this system.
No one industry segment can be shown to have “got lesson-learning right”. Certainly lesson learning seems more prevalent in the oil sector and the military, but even there, satisfaction ratings are not uniformly high, and survey responses are too few to be certain.

In most cases, lessons learned is being applied to project activity, and project-related team dialogue processes such as After Action review and Retrospect are commonly used to identify lessons, together with incident investigations, external evaluations, and individual submissions. However there are many barriers to operating these processes, and even more barriers to actually following through with the learning and making a difference to the work of the organisation. The issue of re-use and re-application of lessons is a constant theme in the responses quoted here.

It seems that effective lesson-learning contains many elements, each of which has a positive impact on the success of the system, and that a successful system needs to incorporate as many of the elements as possible. These elements are cultural as well as procedural. The most important things to get right seem to be

• Ensuring that lessons lead to action, and that these actions are followed through to application in future projects. It is probably the lack of follow through that causes the greatest frustration.

• Clear involvement by senior management, with clear expectations that the lessons learned system will be applied. Without senior management attention, time for lesson-learning is not prioritised, or lesson learning is treated as a tick-box activity.

• Formalising, defining, embedding and consistently applying the system (and there are sub-issues here, for example accountabilities, and avoiding the “tick box” mentality).

• A supportive culture (and this will be driven largely through the behaviours of leadership, and by the importance they place on lesson learning).

Learning lessons seems to be something that the majority of companies seek to do, but it seems to be easy to do badly. If a company wishes to learn effectively, they need to address lesson-learning as a complete system, they need to make sure that all elements of the system are in place from identification through to reapplication, and they need to ensure that they have the full backing and attention of senior management. From this foundation, success should be possible.

KM failure stories number 3 - all push and no pull

---

Ready!
Originally uploaded by jasonippolito

Another organisation started implementing Knowledge Management, and found that there were very many excellent stories to share in the organisation. As well as introducing a range to tools, they began to provide a service of capturing and sharing knowledge and stories from around the organisation, and did an excellent job of this.

They did so well, that their services became very popular, and soon they had little time for anything else. They put their KM strategy work on hold, and became almost a full-time capture service. Eventually the organisation "declared success" for KM, and wound down the team, whereupon KM activity rapidly tailed off.

There were two issues here. One was that the team became diverted from the strategic issues of KM implementation and became a service team rather than a change leadership team. Consequently when the team disbanded, there was no change to sustain. There will always be a demand for capture services - a greater demand than you can service - and you need to find a way to deal with this. You train others in capture and storytelling, you develop the skills internally or you outsource the capture work to give yourself space to delivery the strategy. A KM implementation team needs to work at a strategic level, not a tactical or service work level.

Secondly, the focus was all on knowledge Push, and not on knowledge Pull. They were great at pushing out stories, but not so great about creating the demand for learning and the demand for knowledge. With no Pull, there was little re-use, and little delivery of benefit. Like the waterskier in the picture above - with no Pull, you can't get going.

KM failure stories number 2 - a KM tool in isolation is like a pump without pipes

---

Manifold and pump
Originally uploaded by Bryn Pinzgauer

We were working with a KM team, who had asked us to come into their organisation and run some Retrospects from major successful bids. They wanted to develop and deploy knowledge of how to bid successfully.

We held a series of Retrospects, and they worked very well. We had some fantastic dialogue within the bid team, and with the internal client, and identified a series of learning points. We found some really good success factors whch should be repeated in future, and whole set of opportunities for improving the bid process, including some things that were really frustrating the bid teams (mostly related to inappropriate company policies). We documented the lessons and the opportunities for improvement, trained the client in the Retrospect process, and moved on.

A few months later the client called, and said "That Retrospect process is rubbish". That took me aback, as I know from experience that it is a very powerful and robust process, so I asked him why he said this. He replied - "those issues that were frustrating the team when we started, are still there. They have come up again in the latest Retrospects. Nothing has been changed".

Well - nothing would be changed, if all they did was hold Retrospects. Retrospects are great for identifying team learning, but there needs to be a follow on process to take action on the issue, and for this particular company, those actions needed to be taken at a high level in the company. They had not implemented a process or workflow for addressing the actions, and no engagement from senior managers in the learning process. Retrospects, like so many KM tools, need to be part of a system, and no tool in isolation will stand in for the system as a whole.

I blogged a while back about "KM and central heating", making the point that a KM system is like a central heating system in that it requires many components that work together in order for knowledge to flow (For those of you in hot countries - think of air conditioning systems in big buildings).

Introducing Retrospects without a system to act on the learning is like installing a hot water pump with no pipes and boilers and radiators, and then expecting your house to get warm.

This is a surprisingly common KM failure mode - introducing one or two tools, and expecting them to do the work of a complete system of technologies, processes, accountabilities and governance.

Knowledge management failure stories - #1

---

Failure ' Day 63
Originally uploaded by worak

We worked with a company, which used to be a state utility, and now was facing commercial competition. They decided that they had a lot of in house knowledge, which could be a real asset if brought to bear on commercial bids, and the subsequent work.

We worked with them to build a KM strategy, but were worried from the start by the organisational level at which KM was set, and the calibre of the leader of the KM team. He was a very competent engineer, but not a change leader, and not confident with senior management, and this was something that we were unable to influence. As a result the value and vision of KM was not really communicated well enough up the organisation to gain sponsorship.

The KM project subsequently focused on delivering a KM portal, fed by lessons from Retrospects (therefore focusing on push rather than pull). KM roles were assigned in the projects, training courses were delivered, and a couple of pilots were initiated. However the technology was delivered 6 months late, and by then the impetus had already began to wane. There were no quick wins to demonstrate value, and the long gap between training and delivery of the technology meant that KM activity was not sustained. When a major reorganisation followed, KM was effectively abandoned. It now remains only at a very low level, and the deliver of value has been well below what could have been acheived.

So what was missing?

. A strong leader, prepared to lead change
. High level buy-in and sponsorship
. A phased implementation approach, with a roll-out phase when the entire KM system was ready
. A change management strategy, with early wins used to drive later adoption
. Any form of Knowledge Pull (see here)