Why Communities of Practice die young

---

I have just been reading a very interesting article entitled The Rise and Fall of a Community of practice: A Descriptive Case Study, by Alton Chua. I can't find an online version for you, I'm afraid, but the article describes the experience of developing a community of e-learning instructional designers at Holden College, and why the initiative, which seemed to enjoy a promising start, fizzled out completely in less than one and- a-half years.

Unfortunately this seems to happen all too often. I have spoken with many companies, with experience of attempting to use Communities of Practice, only to see them fizzle out and die.

The Holden College example shows typical reasons for failure, which can be summarised as follows.

1. The Community of Practice was too small. It covered a very narrow element of practice - the creation of e-learning content - and so only had 25 potential members. There is such a thing as Critical Mass for CoPs, which varies depending on the urgency of the topic and whether the CoP can meet face to face, but generally the Bigger the Better for CoPs. Shell, for example, started with 300 small CoPs, but when these struggled, amalgamated them into a handful of giant CoPs. The Holder college CoP was too small to live. 

2. The domain was not really a practice domain, more a task domain. The members were primarily lecturers and teachers - creation of e-learning was a task (and for some an unwelcome task), and not a practice area that the members identified with. The CoP would not pass the "I am a ..." test. There was therefore little identification with the subject matter for the CoP. 

3. The CoP had the opportunity to meet face to face, but found it difficult to organise meetings (partly because of reason 2 above - people did not identify with the topic, so did not prioritise it), and therefore fell back on electronic communication. Critical mass is far greater for CoPs that interact online, and the fate of the Holden College CoP was sealed at this point. 

4. The leader and core group of the CoP decided to focus on "creating deliverables". The interviewed members said that they had joined the CoP to learn from each other, and yet here they were being asked to do additional work. Given that the CoP was voluntary, then people who were already busy, and who would get limited value from the deliverable, voluntarily resigned.

Contrast this with a CoP which I continue to monitor, which started on 1997 and is still going strong 16 years later. It contains nearly 2000 members, covers an area they identify with, has occasional face-to-face conferences, and is focused on solving the problems of the members.

That's how you give a Community longevity.

10 corridor conversations that say "KM needs a tune-up"

---

If you hear any of these statements in the corridors around your organisation, then your Knowledge Management is not working, and needs a thorough investigation!

1. Why do we keep having to re-learn this lesson?
2. I’m sure I heard someone mention that to me the other day, now who was it?
3. I am sure someone must have done this before somewhere - if only we knew who.
4. You know what - I have just found out the Australia office is doing exactly the same piece of work I am! What a waste.
5. Nobody ever asks me what I think.
6. It's been a total mess since Susie left - she was the only one who knew what to do.
7. It was pure luck that I met Freddy – he had just the answer I was looking for.
8. That project was just deja vu all over again - same old mistakes every time.
9. I could have told you that wouldn't work!
10. I just found this in the archives - if only we had had this when we started the job.

Four Roles within the simple KM model

---

Yesterday I blogged about the simplest and best Knowledge Management model - if you missed it, follow the link.

This model is a process-based model, and is based on the flow of knowledge in and out of projects, and in and out of the tacit and explicit repositories (the Community of Practice, and the Knowledge Base respectively).

One thing we can overlay on that, is the accountable roles for each component, and that is what I have done in the diagram shown here.

We have four main roles, but as described below, two of them may be combined. There may be a number of other subordinate roles, but these four are the minimum. None of these roles need be full-time, especially in small companies, and can be part of someone's role portfolio. Here are the four roles -

1. The Owners (/custodians/Stewards) of the Knowledge Assets, represented in the picture by the woman in brown holding a pencil. We describe this role in our page on the Knowledge Owner role, and in my blog post on Process Ownership. There will be one Knowledge Owner for each important topic.

2. The Leaders (/facilitators/moderators) of the Communities of Practice,  represented in the picture by the man in blue holding a pencil. We describe this role in our page on Communities of Practice. There will be one Leader  for each Community of Practice.

Note that in some organisations, the CoP leader also acts as the Knowledge Owner for that area of practice, in which case roles 1 and 2 are held by the same person.

3. The Knowledge Managers (/KM champion/Lesson Integrator) working in the teams and projects, represented in the picture by the man in a cap holding a spanner. We describe this role in our page on the Knowledge Manager role, and there are several example descriptions of this role in my blog posts tagged "Role". There will be one Knowledge Manager for each major department or major project.

4. The Knowledge management team, represented in the picture by the woman with the necklace. We describe this role in our page on the Knowledge Management team roles, and there are several discussions of this role in my blog posts tagged "Role". There will be generally one Knowledge Management team, although in major multinationals there may be one per business stream.

So together with the simple process flow model, we can map on the organisational design of roles and accountabilities which are needed to ensure KM happens.

The best and simplest Knowledge Management Model

There are many Knowledge Management models available, and you can find a selection of them on the Knoco KM Models page.

The one I present to you today is perhaps the simplest and the best, as well as one of the earliest to be created, and one of the most robust. You can almost certainly use this model as the basis for your KM approach.

Let me talk you through it.

At the base of, and as the basis for, the model, we have the teams and projects in the organisation learning Before, During and After. I won't expand on this part of the model; if you need to know more, see my blog post on learning before, during and after.

However the knowledge that the team or project has gained, if it is of value to others, needs to be "pushed" somewhere (the blue arrow on the right of the diagram) (see more details on Push and Pull in KM).

The knowledge can be pushed to one of two destinations - it can be shared, through discussion or presentation, with other teams and/or members of the relevant community of practice. Or it can be placed in some form of Knowledge Base (a lessons management system, for example).

The communities of practice represented the networks of practitioners around the organisation, where much of the knowledge may be held tacitly, and is shared through discussion.

The knowledge base is the managed repository for explicit knowledge (ie not a repository for all forms of information, but for knowledge) where knowledge gained from the individuals, teams and projects is synthesised into knowledge assets.

The knowledge from both of these stores - tacit and explicit - can be accessed through Knowledge Pull (the left hand blue arrow) to allow teams and projects to Learn Before their next activity (by searching the Knowledge Base, and asking the Community of Practice).

There you are - a very simple model of 6 components

• Learn Before
• Learn During
• Learn After
• Push and Pull
• Communities of Practice
• Knowledge Base

You can complicate the model further if you need to, but it's a very good starting point for building your Knowledge Management Framework. I have an additional blog post on the four roles within this model.

I remember drawing a version of this model in Shepperton in 1997 (pre-PowerPoint - it was drawn on an acetate slide) and it has proved robust and valuable ever since. 

If an organization isn't constantly learning and improving, it's dying

---

"If an organization isn't constantly learning and improving, it's dying, and someone else is taking over its markets and customers. " 
Ken Blanchard, co-author of the One Minute Manager

Do you know what you know?

---

“Does an organization know what it knows? That is the first step. Only then can it effectively create new knowledge".

 Eduard van Gelderen, chief investment officer at APG Asset Management, Amsterdam.

KM must have "local value"

---

How can we help people see that Knowledge Management is a "good thing"?

People need to see not only that Knowledge Management delivers value to the organisation, but also that it delivers value to them as individuals. So talk to them, and find out

• What are their local business challenges?
• What are their local "hot issues"?
• What knowledge would help them with these issues and challenges?
• How could Knowledge Management give them access to this knowledge?

Then find some stories or case studies, where other people in similar situations have been able to use Knowledge Management not only to deliver business results, but also to make their own lives easer.

Go by the "Principle of Local Value".

People will adopt a new idea, provided they see it as having tangible value in the local setting. Help them see the local value.

Knowledge communities, or learner communities?

---

Not every organisational context is the same, therefore not every Knowledge Management solution is the same. That's a fact of life, and it even applies to such tried-and-tested KM components as the Community of Practice.

The standard view of the Community of Practice is that of a network of people who collectively act as a mutual knowledge resource. Within the Community is a wide range of experience - from highly-experienced old-timers, to relative newcomers - experts and newbies sharing the same community. Through asking and answering questions, they provide each other with useful knowledge that helps each practitioner to perform their work better. Often the answers to questions come from the more experienced staff, but this is not always the case, as I explain in my blog post about the Long Tail of Knowledge.

This is the model of Community of Practice that we see in the standard case studies, from the likes of Shell, IBM, Fluor and ConocoPhillips.

The role of the leader or facilitator in a Community of Practice such as this is to provide the conditions (culture, technology, behaviours) that allow conversation to happen, and then sit back and watch it happening, intervening only if necessary.

This is a knowledge community. Everyone is a knowledge user, everyone is potentially a knowledge supplier. The knowledge flow is multi-way, and the knowledge primarily comes from within, and circulates within, the community.

But this is not the only sort of Community of Practice.

Takes for example another famous case study, the US Army "Company Command" CoP. The Army creates 2000 company commanders a year - it is the soldiers first command assignment - and they stay in post for 2 years. There is therefore a CoP of about 4000 Company Commanders, with an average of 1 year experience in the role.

This is not a CoP that holds the knowledge itself. The CoP is not the primary source of experience, because they are all learning together. The Community, in this case, exists to support the individuals on their learning journey, rather than to be a closed system of knowledge exchange. This is a community of learners - almost everyone is a knowledge user and only a few are knowledge suppliers. Plenty of newbies, no experts.

The role of the leader or facilitator in a Community of Practice such as this is to promote and facilitate the learning journeys of the members. So for example, in Company Command, they provide the following learning tasks.

• Quizzes
• Discussions initiated and coordinated by the leaders
• "Book clubs"
• Interviews with leaders
• Video interviews
• "Challenges" - discussions on typical scenarios a Company Commander will face
• Community blogs
• Community email newsletters

(Please note that the Community leader is not Teaching, but is still actively facilitating and directing the learning activities). You will see few if any of these activities in the Flour/ConocoPhillips style of CoP, because their communities contain experienced people rather than being a community of the inexperienced.

Company Command is not the only example of this type of Community of Practice, and it will be a useful Knowledge Management tool in any organisation which regularly has to provide knowledge to a large population of inexperienced staff (see my blog post on the influence of demographics on KM - this type of situation is likely to be more common in the Far East than in Europe or the US).

So, as always, choose "Horses for Courses" as we say in English. Choose the KM approach that suits your organizational context.

"The Best Knowledge Management Strategy Award"

---

The award being presented,  photo from the
Lawyer Management Conference website
(follow links in article)

Yes, there actually has been a "Best Knowledge Management Strategy Award."

It was awarded at the Lawyer Management Awards 2013 four weeks ago, and was awarded to A&L Goodbody for what the judges called: “A really attractive client-facing integrated service with step-through inclusive project management sponsored at the highest level.”

I believe, translated out of business speak, that means an extranet portal that provides A&L Goodbody's clients with access to practice notes, FAQs,checklists and e-learning talks.

This is less of a Knowledge Management strategy to enhance the effectiveness of the firm, and more of a strategy of information provision to clients, but I do have to say, I am delighted to see a "Best Knowledge Management" award at a prestigious event like this, and many congratulations to the A&L Goodbody team for their award (and congratulations also to the teams from Taylor Wessing in second place, and Hogan Lovells and Wragge & Co in joint third).

KM has arrived in the world of Tuxedos, LBDs, celebrity hosts, champagne and awards.

And people say Knowledge Management is dead!

Finding the Unknown Knowns

---

There is a lot of knowledge out there in the organisation that we Don't Know That We Know, and one of the truths of Knowledge Management is that we don't know what we know until we need it, or until someone asks us really deep and probing questions.

That's why an effective Knowledge Management program cannot be based in individual volunteering, or Push, as this only find the Known Knowns.

Sometimes you find organisations who have set up a system whereby people are required to identify lessons themselves and to add them into a lessons management system, or to identify "knowledge objects" and add them to a database, or to identify new ideas and improvement suggestions and add them to a Suggestions Scheme.

I am not as huge fan of volunteer systems like this.

I think you capture only a small proportion of the knowledge or ideas this way, because you miss the Unknown Knowns.  People are not aware that they have knowledge and ideas, and if they are aware, they often discount the knowledge as "not important".

Instead, don't wait for knowledge, ideas or lessons to be volunteered - go seek them out. Go and do some proactive knowledge identification.

There are two main approaches for doing this; reactive, and scheduled.

The reactive approach requires someone to identify particular successes and failures from which to learn. The failures can be obvious, such as safety incidents or significant project overruns, and many companies have mandatory processes for reviewing these failures. But how do you spot the successes? Maybe you can use your company benchmark metrics, and seek to learn from those departments with the best results that year. Perhaps you could work with the knowledge from the manufacturing plant that never had an accident, as well as from the one with frequent accidents. Maybe you can look for the best sales team, and look to learn the secrets of their success.

Or maybe you can do both successes and failures - I did a very interesting study not long ago for an organisation that measures staff engagement using the Gallup survey. We picked the ten top scoring sales teams, the ten bottom scoring teams and the ten teams which had shown the most improvement over the previous year, and interviewed the team leader and a team member of each one, to pick out the secrets of successful staff engagement.

An alternative approach, common within project-based organisations, is to schedule learning reviews and knowledge exchange within the activity framework. These could be

• After Action Reviews on a daily basis during high-intensity learning, or after each significant task 
• Peer Assists early in each project stage, or during project set-up
• Retrospects (or some other form of Post Project review) at the end of each project stage, or at each project review gate
• A Knowledge Handover meeting at the end of a project, to discuss new knowledge with other projects
• A Retrospect (or some other form of review) at the end of a bid process, when the company knows if the bid has been successful or unsuccessful.

There are many advantages to the scheduled approach. Firstly, success and failure are components of every project, and if every project is reviewed, lessons may be identified which can avoid the big mistakes later on.

Secondly, if lessons identification is scheduled, it becomes a clear expectation, and the company can monitor if the expectation is being met. This expectation is common in many organisations, thought the rigour with which the expectation is met seems to vary.

Finally, by scheduling and facilitating the learning dialogue, you can uncover the knowledge that nobody knows they know, until they start to discuss it. You find the Unknown Knowns.

Knowledge - the asset you already own

---

This is an argument you can use with your senior management, when trying to sell Knowledge Management.

Knowledge is like treasure buried in your own back yard - it's a resource you already own; you just haven't uncovered it yet. 

Any organisation is rich with knowledge, any organisation pays a lot for knowledge already (60% of the non-capital spend according to Larry Prusak). That knowledge is a very powerful resource, but it's mostly locked away in silos, and in the heads of individuals. 

All you need to to, to release the value of that knowledge, is start to link up the people.  

You don't need to buy the knowledge - you own it already. All you need to do it free it up to move to where it is needed.

Turning learning on its head (quote)

---

"Since the industrial revolution, our organizations and society at large have held three biases regarding learning.

First, the transmission of knowledge from an outside expert, whether a teacher, consultant or "best practice", is seen as the essence of learning. 

Second, by institutionalizing "off-line" classroom learning, the building of capacity becomes separate from the use of that capacity.

Third, learning is seen primarily as a matter for individuals, not groups.

Emergent learning practices turn these three biases on their head"

Parry and Darling, "Emergent learning in action, the After Action Review"

The risk of knowledge loss at the end of a project

---

"The risk of a knowledge loss at a project’s end is a serious problem for organisations, especially in knowledge- intensive industries, such as pharmaceuticals, financial engineering, or high-tech. 

Companies could save considerable costs, which result from redundant work and the repetition of mistakes, if they master the project learning cycle".

From Schindler and Eppler; Harvesting project knowledge: a review of project learning methods and success factors

5 success factors for project-based learning

---

This list below of success factors for project-based learning was proposed by Schindler and Eppler, two researchers working out of University of St. Gallen (Switzerland), in their paper "Harvesting Project Knowledge: A Review of Project Learning Methods and Success Factors".

It's a pretty good list! Their text is in bold, my commentary on each of these is in parenthesis.

1. From single review to continuous project learning - we stress the necessity for continuous project learning through regular reviews.  (In Knoco, we recommend any project define the methods and frequency up front through the use of a Knowledge Management Plan, and that suitable processes are the After Action review and the Retrospect, or Lessons Capture meeting, or even a Learning History in the case of mega-projects. This is the Process component of  project-based learning).

2. New project roles and tasks - the need for new roles for project knowledge management should have become obvious.(This is the Roles and Accountabilities component of project-based learning - we recommend that someone in the project team itself - a project Knowledge Manager -  takes accountability for ensuring learning processes are applied, making use of facilitation skills as appropriate).

3. Integration of learning and knowledge goals into project phase models -  project learning is too important to be left to chance or to the initiative of motivated individuals. (This is what we include as part of the Governance component of project-based learning. By embedding knowledge management processes into the project phase models or project management framework, we set a very clear expectation that project learning is important and part of normal project activity).

Integration of learning and knowledge goals into project phase models (This we also include as part of the Governance component of project-based learning. This is the performance management element of Governance. If learning is in the project goals, then the project team will be judged and rewarded by whether they learn, as part of judging and rewarding whether they met their goals).

Schindler and Epper therefore cover three out of the four enablers for Knowledge management - Roles and Accountabilities, Processes, and Governance. 

The one they do not cover is technology, perhaps because there were few effective Lessons-Management technologies around in 2003. Therefore I would like to propose a 5th enabler, as follows;

5. Application of an effective lessons management system, including workflow to ensure the lessons reach those who must take action as a result, and a tracking system to track the effectiveness and application of learning.

The Danger Radar - an outcome of Lessons Analysis

---

Rupert Lescott wrote a great blog post yesterday about Lessons Analysis - how by looking at the products of an effective lesson learning system we can recognise common themes across a number of lessons.

In the 90s, I was in charge of a lesson-learning system in Norway. At one point we had lessons from over 300 projects in the system, and we grouped them (as Rupert describes) into a series of "things that commonly go wrong in our projects".

Rupert provides a similar list in his blog post today, based on experience in very many projects around the world.

In Norway, we treated our list as our "Danger Radar" - the more of these problem areas that a project faced, the greater the risk to effective project delivery. The top 7 problem areas were as follows (remember these were small office-based projects)

1. The project team is new, or contains a significant number of new members
2. There is no clear full-time customer for the project 
3. Satisfactory completion of the project relies on an external supplier. 
4. The project is a low priority 'back-burner' project. 
5. The project scope is poorly defined. 
6. The project relies on an unusual degree of IT support. 
7. The project involves consultation with large numbers of staff.

Any project where more than one of these was true had "Danger on it's Radar".

Such a project therefore needed to pay considerably more attention than usual to project management, and was advised to scan back through the relevant lessons and guidance, and speak to the people involved, in order to find out how the danger can be averted.

A few years later, the organisation applied the same concept to big engineering projects, and came up with what they called the "Train Wreck Indicator" - a similar indicator based on common reasons for failure, determined through lessons analysis. Any project that scored a Red Light on the train wreck indicator was given additional help and oversight in order to help it steer a path through the problem areas, and avoid becoming a train wreck.

If you have an effective lessons learned system, and are building up a library of project lessons, then consider a similar analysis, to build your own "Danger Radar".

 Contact us if you want to know more about our lessons analysis service.

Choosing conversations that work for knowledge sharing

---

Conversation is widely recognised as the best Knowledge Management tool there is, but the wrong conversation can build barriers to effective knowledge sharing.

Knowledge and true understanding can be shared through conversation, but not through every type of conversation.

The problem is that conversations do many things, and knowledge sharing is only one of them. Understanding how conversations work, and being able to influence conversations styles through facilitation, are vital tools for the knowledge manager.

Here are some types of conversation. This is not an exhaustive list!

• Small talk. Small talk is the social communication where the fact of communicating is more important than the words. "Hi, how are you? What a nice day!" all really mean "I see you, I recognise you, I have, or want to create, a social bond with you".  Banter is one type of small talk. Gossip is another (though gossip is also a form of reporting and debriefing). Much of the interaction we see on Facebook, for example, is small talk (lol). Small talk has a vital social role, but does not share knowledge.

• Social cohesion. Social cohesion conversation is like small talk, but the purpose is to gain social cohesion through agreement. Reminiscence is a social cohesion tool - "Hey, do you remember when .... Did you see that moment in the second half of the game where he ....". The "Like" button is a social cohesion tool - "I am on your side". The problem with social cohesion conversation is that it can completely mask the truth. The Solomon Asch experiment showed how social pressure means that individuals will often agree to something they know to be incorrect, in order not to disagree with the rest of the group - not to be "off-side". Facilitators in knowledge management sessions such as Knowledge Exchange and Peer Assist need to be very much aware of the social cohesion aspect, and actively search for the dissenting voices. The only "side" to be on, in knowledge sharing, is the side of the truth.

• Reporting and debriefing. These are conversations (or more often, serial monologues) where people state facts and occasional opinions. Most project meetings are like this. These meetings are vital to have, but are only very superficially "knowledge sharing" meetings. Facts are shared, deep understanding generally is not shared. People go away "better informed, but none the wiser". If reporting and debriefing is the only type of conversation which happens in your projects, you need to introduce some  different processes, such as After Action Review, and Retrospect.

• Argument and debate. These are the "win/lose" conversations. Someone has an opinion, and defends it against alternative opinions. Very often this is tied into the issue of status - "I am the expert - my opinion must be defended as it gives me my status; if I lose the argument my status will be weakened". Debate is a milder form of argument, but both debate and argument carry the concept of winning. In debate and argument, people listen to and question their opponents statements in order to find weaknesses and loopholes. Many of the discussions on Linked-In are arguments, debates, or serial monologues. Argument and debate are hopeless for knowledge-sharing. As Thomas Jefferson said - ""I never saw an instance of one of two disputants convincing the other by argument." The body language in the picture above suggests that this is a debate or argument.

• Dialogue. As described in this HBR article, dialogue is the primary tool for knowledge sharing in organisations. The goal of dialogue is not winning, nor convincing, nor agreeing, but reaching a deeper level of collective understanding. In dialogue, people listen to and question the statements of others in order to understand why they hold these views. Dialogue requires listening skills as well as debating skills. In dialogue, people allow their opinions to be challenged (and indeed, welcome that challenge). In dialogue, everyone leans in to the conversation. Dialogue requires trust and openness. Dialogue is a very difficult conversational style to achieve, and until it becomes second nature in an organisation, the role of the facilitator may be vital. The facilitator watches the conversation, defuses argument, challenges group-think, ensures assumptions are questioned, seeks out the dissenting voices and the unshared opinions, and keeps the process of the conversation on track to it's stated goal - that of building shared understanding. 

Without good facilitation, dialogue can easily degenerate into debate and argument, or even further into opinion-stating, social cohesion and small-talk, and the opportunity for effective knowledge sharing is lost. Contact us for KM process facilitation, or for facilitator training.

KM and urgent business need

---

"Whether it is an enterprise-wide initiative or a grass-roots effort, you must ensure that the Knowledge Management solution is developed to address an urgent business need". 

Michael Behounek, Director of Knowledge Management, and Mary Rose Martinez, Knowledge Management Specialist, Halliburton

Knowledge Management at Alaskan drill-sites

---

This paper here is an interesting (if somewhat technical) look at knowledge management in a remote and difficult business - drilling oil wells in the Alaskan Wilderness.

In the drilling business, time is money, and knowledge management is routinely applied to improve drilling performance through finding more efficient ways to operate, and through learning to eliminate wasted time.

The Alaskan drill crews use a Knowledge Management framework to help improve drilling performance, including the following elements;

• Clear management expectations and support
• A Technical Limits workshop, to drive "Learning Before"
• A Technical Limits coach, with accountability for driving the learning and improvement process on the rig site
• Rigsite meetings to identify and discuss lessons learned
• A supporting lessons management system
• Collection of metrics on key performance indicators such as the lessons closed/pending ration.

This metric is described as follows;

"Another important aspect is the gathering and processing of lessons. Closure of a lesson is generally defined as validation that a document, procedure, or rig-specific item has been changed. The Lessons Learned database maintains a good closed/pending ratio indicating a high level of activity and involvement moving lessons learned into rig operations."

The  pie chart to the right is a typical example of this metric, showing how 82%of the lessons identified at the rigsite have been "Closed" or "Completed" through embedding the learning into procedures.

The outcome, for the drilling teams, is continuously improved performance.

This is illustrated in the line-chart to the right, showing how the time for certain operations has been improved over a series of wells, through applying the learning framework described above.

The time to test the BOPE, for example, has been reduced from 17 to an average of 5 hours, and the time taken to mill a window has been reduced from 15 to 10 hours.

In a remote hostile environment, where time is money, a simple knowledge management framework is delivering step-out improvements in performance.

Your five first steps towards Knowledge Management success

At Knoco, we have seen enough Knowledge Management implementation programs by now (dozens, for sure) to know that there a few key steps every organisation needs to take in the beginning. These steps are as follows;

1. Assess the current state
2. Build a business-led strategy
3. Develop a draft KM framework
4. Create an implementation plan
5. Deliver some early pilots

Here is some more detail around each of these five steps.

Assess the current state. Before you can plan any future KM development, you need to know where you are right now. Knowledge Management is common sense, even it if is not common practice, and most organisations are already doing some elements of KM under different names. Those elements may not yet be effective, and they may not yet be joined up, but you need to know what's working, what's present but not working, and what's missing. We see three types of assessment;

• An assessment of the current KM system (and by system we mean processes, roles, governance, technology) to see what's missing. A gap analysis, if you will, and the KM implementation program will largely seek to fill the gaps, and connect the unconnected elements. 
• A scan of your current knowledge topics, to see which ones need the most urgent attnetion.
• An assessment of the supporting culture. Do you have the correct culture to become a learning organisation, or is some culture change also needed?

Build a business-led strategy. Time and again, experience has shown that the most successful knowledge management initiatives are those which are business-led, and which solve business problems. Your KM strategy needs to be closely aligned to the business strategy, and to focus on the critical knowledge needed by the business. Elements of the strategy include

• Vision 
• Scope 
• Business drivers 
• Value proposition 
• Critical knowledge areas 
• Change and stakeholder management 
• Potential business-led Pilot areas

Sometimes the strategy can be driven by one overriding business need, such as the risk of Knowledge loss, and in this case a Knowledge Retention Strategy may be needed.

This blog contains plenty of guidance on getting your KM strategy correct.

Develop a draft Knowledge Management Framework. As Knowledge Management has evolved over the last two decades, the need for an integrated Knowledge Management framework has become apparent. With a Management Framework, KM can take on the aspects of other management systems, and be made part of normal business, rather than relying on a disparate set of tools.

A Knowledge Management Framework ensures that all necessary KM elements (Accountabilities, Processes, Technologies and Governance) are in place, and interconnected. This ensures that there are no gaps in the system, and that knowledge flows freely through the organisation.

Your Assessment (Step 1) should have been planned with a Framework in mind, and will have identified the gaps which need to be filled.  we are calling this a "draft framework" at the moment, as the framework will not be finalised until after piloting.

This blog contains plenty of guidance on building an effective Knowledge Management Framework.

Build an implementation plan. Implementing Knowledge Management is not easy. You really only have one attempt, and if this fails, you may find that the concept has become irrecoverably tarnished. An excellent Implementation Plan is needed, based on lessons from successful (and less successful) implementations in other companies, and tailored to your own context.

The plan will be based on

• the results of assessment and bechmarking 
• the Knowledge Management strategy 
• the draft Knowledge Management framework
• the potential pilot areas, and
• a staged, change management approach.

This blog contains plenty of guidance on Knowledge management implementation.

Start some business-led proof of concept pilots. A key component of your knowledge management strategy involves running some pilot projects. A pilot project is a project where knowledge management can be applied within the business, to solve a specific and important business problem, to deliver measurable results (and therefore prove the value), and also to act as a proving ground for Knowledge Management within the business.

Choosing the right pilots can be a massive springboard for your eventual KM implementation. A spectacular success early in the journey can give you some real momentum.

This blog contains plenty of guidance on Knowledge management pilots.

There are plenty of ways to get Knowledge Management wrong, and a few principles you need to follow to get Knowledge Management right.

Follow the five steps listed here and, with advice and guidance from a good experienced consultancy, your road to Knowledge Management success is clear.

Lesson-learning - a lesson is something you teach

---

Something I often make plain at the start of Lessons learned meetings, is that when identifying and recording lessons, we should think of them, not as something we have learned, but as something we can teach others.

This is a subtle shift in emphasis form looking inwards, to looking outwards, and from looking backward, to looking forwards.

For much of the lessons workshop, the participants are looking back at what happened. "We had a difficult time with the client", they might decide, and then follow this Observation with a whole set of reminiscences about how difficult the client was, and what trouble it caused. With good facilitation, they can reach Insights about why the problems happened.

However the facilitator then has to turn the conversation outwards, and ask - "based on what you have learned from your reflection on the client difficulties, what can we teach the organisation about how to better deal with clients". The participants need to stop analysing history, and start looking at generic learning they can pass on to others.

That is a critical value-added step, and it is that step, and the subtle mindset shift from passive learners to active teachers, that allows the participants to turn an observation and the subsequence insights, into a Lesson.

KM and the Deming cycle - "Learn-Plan-Do-Measure"

---

The Deming cycle is at the heart of continuous improvement.

Variously described as "Plan-Do-Check-Act", or "Plan-Do-Measure-Learn" (the latter being a common oil-sector variant), it is a cycle of action, or a cycle of mindfulness, that drives learning and continuous improvement.

Knowledge Management is a key component of this cycle.

The picture here is taken from the 2006 publication, "Implementing a Framework for Knowledge Management", written by me, Peter Gibby, Walt Palen, and Sarah Hensley. It shows how Knowledge Management is an expansion of the "Learn" component of the Deming cycle. In fact, it is hard to see how you can operate the Deming cycle as an organisation, without KM.

Here we break out the KM element into "Learning Before, During and After" - that well-known basic model of activity focused KM. The link here between the Deming cycle and the "Learning Before, During and After" cycle emphasises three things.

1. Learning comes after doing. You need experience from which to learn, and that needs to be either your Doing, or someone else's.
2. Learning comes after measurement. It is through measurement (of whatever indicators you use to determine success) that you know whether the Doing was successful, and you know what needs to be improved or repeated in future.
3. Learning comes before planning. Although the Deming cycle is usually described as "Plan-Do-Measure-Learn", it can equally well be described as "Learn-Plan-Do-Measure"

In fact, "Learn-Plan-Do-Measure" is a great way to look at the cycle, because, to be honest, all planning should be based on learning.

Knowledge Management and Live Aid - how Sir Bob learned from George Harrison

---

This is not to claim that Live Aid had any big knowledge management program that I am aware of, merely to point out one piece of knowledge sharing which resulted in millions more going to the poor and needy in Ethiopia.

The first of the modern stadium mega-star charity concerts was the Concert for Bangladesh, held in Madison Square Gardens in 1971. The concert was the brainchild of George Harrison and Ravi Shankar, in response to the humanitarian crisis in Bangaldesh, and boasted performances by Shankar, Harrison, Ringo Starr, Eric Clapton, Billy Preston, Bob Dylan, and many others.

This concert (and the follow up record and film) was a pioneering concept in fund raising, and Harrison was pretty much making it up as he went along, The concert was a huge success, vast sums of money were raised for Bangladesh (as well as elevating the plight of the emergent nation in the Western media), but it was not without its headaches, particularly when it came to ensuring the money went where it was needed. For example, Harrison became embroiled in a row with the IRS, who held onto sums worth between $8m and $11m for many years, until long after the refugee crisis was over. Because no charity had been chosen before the concert to receive the money, the IRS argued that the concert itself (and the CD and film sales) were not tax-exempt.

So when Live Aid was conceived in 1985, as support for the Ethiopian Famine, one of the first things Bob Geldof did was call George Harrison for a spot of Knowledge Transfer, or Peer Assistance.

As reported by the BBC after Harrison's death, Geldof said Harrison had given him advice when he was organising the Live Aid concert, adding: "I remember him with a profound sense of gratitude."

The key lesson from the Concert for Balgladesh, which has been applied to all such ventures since, was to endure tax exempt charity status right from the start; a lesson which has resulted in massive savings for the charity sector.

Sources,
Guardian
GQ magazine

Knowledge Management in Mega-projects - what's different?

---

Knowledge Management as applied to projects is a pretty well-understood field (see for example my book on Knowledge Management for Teams and Projects). It consists of a rigorous structure of Learning Before, During and After, and drawing on the knowledge of others in the organisation in order to anticipate, avoid, and (if necessary) solve problems.

So what's the difference between KM in projects, and KM in mega-projects?

The answer is, Nothing much! Other than the scale, the principles and practices are identical.

The advice below is for the megaproject leadership team.

Learning Before. Because the costs, risks and unknowns are far greater in mega-projects, "Learning Before" is especially important. This includes learning from the project management structures of successful mega-projects (according to the book "Mega-projects and Risk", a lot depends on how the incentives are assigned and how the risks are allocated, for example), and learning from the typical reasons for cost and schedule over-run of megaprojects. One of the biggest causes of overrun is project wishful thinking - ignoring the unknown unknowns. These are things like

• discovering the soil conditions are far worse than expected
• finding unknown archaeological sites (Such as the unexpected discovery of 150-year-old revolutionary-era sites and Native American artefacts on the Boston "Big Dig")
• changes in government, leading to the need to renegotiate
• changes in commodity price

You can't know in advance what these are likely to be, but you can add in contingency, you can make a probabilistic risk, cost and duration estimate with some of these unknown unknowns included, and you can gather enough to knowledge to understand the major categories of risk, and have contingencies to deal with them. Knowledge management and risk management are closely allied in projects. Any megaproject should dedicate as much time as possible to Learning Before - forewarned is fore-armed.

Learning During. Mega projects are incredibly complex, and if mega-projects are to be able to learn, they need a comprehensive and integrated system for "learning During". Learning events such as After Action Reviews need to be a requirement for all contractors, there need to be Lessons Learned Integrators in all teams and in all contractors, each contractor needs a lessons log, with cross-team lessons escalated to a lessons management system, there needs to be a learning team at project leadership level, and part of their role needs to be to pick up the weak signals and the first inklings that problems need to be fixed. This is a military learning model, and many mega-projects are military in scale. Learning During is not something a mega project can afford to ignore - rapid learning can save you millions - and the megaproject should develop and implement its own internal knowledge management framework, complete with governance.

Learning After. The megaproject needs to hold Retrospects after every major milestone, and the learning needs to be not just about engineering, but about the way the whole project is integrated, the reason for any delays and overruns, and also the softer aspects such as culture, behaviours and communication. It may be politically difficult for megaprojects to produce open, honest and public lessons after the completion of the project, given the implications of liquidated damages, and given the typical ties between megaprojects and politics. That should not stop them from trying, however, especially if the intent is to provide guidance for future megaprojects. Certainly every company involved needs to collect and document their own internal lessons for future use. The megaproject leadership team should even consider the appointment of learning historians, so that the Learning History of the project can be constructed.

Drawing on the knowledge of others. There is no online global community of practice for megaprojects that you can draw on, but you can at least convene an advisory group of past mega-project managers who can act as a sounding board and who can provide advice and experience during the course of the project.

Knowledge management, if correctly applied, can be a major factor in the success of projects, driving down costs, duration and risk.

Where megaprojects are concerned, with their complexities, unknowns, and political pressures, Knowledge Management becomes absolutely essential.

How to trigger innovation? Give people a problem that's outside their box.

---

If you want people to think outside the box, give them a problem that's outside the box.

There is a game I often play with a class, when we are on an innovation retreat such as a Business Driven Action Learning exercise.

We put people in a large circle, and give them a Koosh ball. The rules of the game are simple -

• All hold out your hands
• The person with the ball throws it to someone holding out their hands
• They remember who that someone is
• Once you have thrown the ball, put your hands down
• Continue until everyone has their hands down.

You, as facilitator, time how long this takes. Imagine it took 80 seconds.You say "Now do it again, passing the ball in the same order, but do it in 40 seconds".

You keep the exercise going, in several rounds, but you time each round, then cut this time in half to form the target for the next round. What happens, is instructional.

• Firstly, people take the same approach as before, but try to work faster.
• Then, they tighten up the circle, reducing waste time
• Then they reorganise - reforming the circle so they are standing in the correct order
• Then when challenged even further, they start to think outside the box. They start to come up with radically creative solutions. Maybe we don't need to be in a circle? Maybe we lay our hands on the ground, and roll the ball over them? Maybe we form a tube with our hands (in the correct order), and drop the ball down the tube?

While the target can be achieved by working in the known way (working inside the box), creativity is limited to incremental innovations such as reorganisation.

When the target is outside the box - outside the realm of the known solution - people need to be radically creative. When they roughly know what to do, they use known solutions. When they don't know what to do to meet the target, they become radically innovative.

Impossible targets drive innovation. "Put a man on the moon and return him safely, before the end of the decade".  "Fly 500 people nonstop across the USA and be able to land at La Guardia". "A h-fi system you can put in your pocket". These were the impossible targets that resulted in the space program, the modern airliner, and the Sony Walkman.

If you want people to be innovative, set outrageous goals. If you want them to think outside the box, set them out-of-the-box targets.

Etienne Wenger on the "M" in KM

---

"If by “manage” we mean to care for, grow, steward, make more useful, then the term knowledge management is rather apt".

Etienne Wenger, KM and CoP guru

Learning from Lessons Learned

---

Here's this morning's presentation from Singapore on Lessons Learned, courtesy of Bernie from Sketchpost


 

Why hasn't knowledge management caught on? Wrong question!

---

There is a discussion going on at the moment on the Australian ACTKM bulletin board, on the topic "Regarding KM's (Perceived) Failure to "Catch On""

Neil Olonoff is seeking feedback on this issue, based on a request he has received from a government contact, who asks "KM makes sense any way you look it at, so why hasn't it caught on after all these years?"

An interesting question, but the wrong question.

From the point of the writer of the request, and probably from the point of view of most people in government or the public sector, KM has not caught on.

However there are other industries where KM has caught on like wildfire, and has delivered over a decade of sustained value.

The International oil business, for example, where KM is embedded, institutionalised, and part of the unconscious fabric of working. Or the legal sector, who's own document-focused brand of KM is well established. Or the consulting sector. Or the development sector. Aerospace. The military. etc etc.

So the question is not "Why hasn't KM caught on" but "Why hasn't KM caught on HERE".

I think there are several reasons why KM has not yet caught on in government circles, and many of these can be related to the presence or lack of the components of organisational learning culture.

• KM catches on most easily where knowledge has the biggest and most immediate impact on performance. If you can see, and measure, the added value of knowledge (on cost, speed of delivery, bid win rate, whatever) then good KM, leading to an improvement of the delivery of knowledge to the decision makers, delivers immediate and visible value. In the public sector, performance is a very difficult concept to work with. What makes up "good performance" for a government department? How easy is that to measure, and how easy is it to tie back to knowledge?

• Where I have worked with public sector institutions, one of the things that struck me most forcefully was the way messages were managed. There seemed to be a lot of reworking documents, to make sure they said things in the correct way. Now there's nothing wrong with that per se, but it introduces barriers to empowerment, to transparency, and to other elements of the required organisational learning culture. 

• There is a distinct lack of "no blame" in the public sector, this time due to external pressures. All over the world (or almost all over), there is a hungry press waiting to pounce on anything that looks like a mistake or a failure from a government body. This makes "learning from failure" a very risky affair. Indeed, the default approach to learning from failure is the dreaded "public enquiry", after which someone will be sacked, someone will retire in disgrace, and the true reasons for failure will remain unfixed.

So there are some real structural and cultural reasons why KM is not so easy in the public sector. In addition, where I have seen it, it tends to be focused on the tactical issues, and seldom on the strategic issues.

However, whether you sit in the public or private sector and are pondering "Why does KM seem to be dead? Why hasn't it caught on?", then you are asking the wrong question, because in other places KM has caught on and is alive and well.

You need to learn from where it works, and see what's different about your own context.

The Tailboard AAR

---

The Tailboard AAR  is a term used by the Fire Service to describe a short Knowledge-sharing session (an After Action Review) that should happen immediately after activity, around the Tailboard of a fire truck, if necessary.

The great thing about this "reflective moment" is that it should happen immediately, while the team are still "present in the moment", before they get back to base, before memories start to shift, and while the shared experience they have just been through is still at it's most vivid.

Here's what the Fire Service says

"For (Goodyear Arizona Fire Department Chief) Russ Braden, AARs provide the first level of  learning for the organization and the best opportunity for constructing a safety-aware working culture. “Quite simply put, this is nothing more than a crew taking a few minutes to review the incident or a recent event. This is the time within the safety of their crew to review what went well, what can be improved, or what didn’t work at all. This type of learning environment will begin to spread lessons learned to each of the work groups, shifts, and to the rest of the department as it perpetuates..”  

District employees for the Northwest Fire District in Tucson, AZ, recently began carrying AAR pocket cards to facilitate the district wide use of “tailboards.” 

At a recent meeting of district Battalion Chiefs, personnel said the AARs were making impacts on the organization in several different ways. Captain Tim Graves said one of the best features of the four-question AAR that he’s found is its adaptability to the scale of the incident. ..... 

Battalion Chief Mike Duncan said “I think the AARs are a very critical trust piece: people learn that it’s OK to bring out actions that didn’t go as planned. ...   

Division Chief Kelly McCoy said he thought the AAR format was helping to promote the mindset of planning. ...  Other personnel said what they liked about the AAR process was that it was easy to use with a group.”

After Action Reviews have been around for a long time as a Knowledge Sharing tool, and the experience of the Fire Crews reminds us of some of the AAR ground rules.

1. Hold your AAR immediately after activity. For the fire crews, it's round the truck tailboard. For a sales team, it might be the a Back of the Taxi AAR. For a legal team, it might be a Courtroom Steps AAR. For a forestry team, it's still a Tailboard AAR, but the tailboard is a logging truck.
2. Hold your AAR routinely. By tagging it to the tailboard, the taxi or the courtroom steps, you introduce a trigger for review and reflection.
3. Give people support. Give them the Pocket Cards. Allow them to adapt them to the needed scale.
4. Carry the AARs through into planning. 

Three levels of Knowledge - Must, Should and Could

---

I am often asked "Does knowledge management have to be top-down, command and control? Should the company be telling people what to do and how to do it? Why can't knowledge just emerge, from the bottom up?

The answer, as usual, is that it is a question of Horses for Courses. There is some knowledge which can and should "bubble up from the bottom", and there is some knowledge that needs a top-down validation (but even in this case, this tends to be top-down validation of bottom-up contribution).

Let's look at the second case, as this is the one that people end to struggle with.

Here we are looking at knowledge that is mission critical, or related to safe operation. Knowledge like how to run a nuclear power plant, or an oil refinery, or how to fly a jumbo jet. we already know from incidents like the Longford Refinery disaster that in such situations the company is legally obliged to ensure that operators have access to the knowledge they need to do their jobs, and that "operator error" is no excuse if the knowledge is absent.

Any organisation will then put in place structures to make sure that people with mission-critical jobs have access to the best knowledge, compiled from the best sources, and will require validation that this is happening.

I recently presented about this, and mentioned the role of the "Practice Owner" - the person who acts as custodian or guardian of an area of knowledge. There were some immediate questions - "who gives this person the right to tell others what to do? What if they are wrong?". The answer is that the person speaks on behalf of the community of practice (and is often appointed by the community), and acts as a check and validator on the community process.

If the community members find a problem with company procedures then this is the person who checks that out, runs the management of change, and signs off (on behalf of the community and the company) on the new process.

People sometimes ask, why doesn't the community collectively sign off? The answer is, for company critical knowledge, you need checks and balances. Otherwise you can imagine the courtroom conversation

"What made you think that the procedure you provided Mr X, which resulted in the destruction of the laboratory, was safe?"
"Well your honour, it got 20 Likes in the company knowledge system"

When the company is responsible for providing correct knowledge, the company needs that validation process in place, which goes beyond star-ratings and Likes, and requires proper review and sign-off.

What you generally end up with, in high reliability organisations, is three levels of knowledge;

• There is the "Must Follow" knowledge, which is enshrined in the company standards, and which has been signed off by the Practice Owners (on behalf of the Community) as being the only safe or effective approach. Examples might be the operating procedures for the above-mentioned Nuclear plant, or the in-flight checklists for the Jumbo Jet (and which were missing, incomplete or inadequate at Longford Refinery). This is the top down knowledge.

• There is the "Should Follow" knowledge, which is represented by "Current Best Practice", and which the community collectively agrees that is the best way to do something, and which should be used as a default unless you have a good reason to do otherwise. These are the contents of the Community Wiki, or the community knowledge base, and there will be generally some form of validation procedure to determine that this really is the best knowledge available at the moment.

• Finally there is the "Could Follow" knowledge, that represents the good ideas, good examples, tips and hints, and templates. This is generally the content of the community forums and the community Yammer streams, and has the Likes and the star ratings. This is the bottom up knowledge, bubbling up from below and attracting rating and commentary as it goes, until it passes a validation step to become "Should Follow".