Knowledge Management in projects - a summary

---

The last chapter of my book "Knowledge Management for Teams and Projects" contains a bullet-point summary of how Knowledge Management should be applied in a project-based organisation, addressed to the three stakeholder groupings. This describes an ideal project-level Knowledge Management Framework

Project Management Plan by perhapstoopink on Flickr

The bullet-point summary is reproduced below (with a bit of clarification in parentheses in case you have not yet read the book).

Advice for the project manager and project knowledge manager

1. The project manager needs to ensure that the project staff are "Learning Before Doing" (this is part of the simple project-based Knowledge Management model of Learning Before, During and After). 
2. Right-Scoping meetings are a way of bringing in knowledge during the scoping phase of the project (this is a type of Peer Assist focused on getting the project scope to its correct minimum level). 
3. Customer interview maximises the team’s knowledge of the customers’ needs and context.
4. The earlier you can bring in contractors’ knowledge, the better. 
5. Peer Assist is one of the simplest and most effective ways of bringing in existing knowledge from past projects. 
6. Optioneering is one form of peer assist (looking at a series of options for the project, using the knowledge of others). 
7. If there is no existing knowledge, some level of business-driven action learning (or other innovation process) may be needed. 
8. Peer review is more of an assurance process than a knowledge management process. 
9. Technical limit is an excellent process for accessing the knowledge of the execution team prior to execution 
10. The project manager needs to ensure that the project staff are ‘Learning While Doing". 
11. The After Action Review is an excellent way of doing this (as part of a Project Learning System). 
12. AARs can be built into project review meetings. 
13. Communities of practice are a crucial resource for learning while doing. 
14. The project manager will need to appoint a knowledge manager for the project. 
15. Knowledge engineers and/or learning historians may also be needed in major projects (these are a specific type of knowledge manager dedicated to recording the details of the project, and the detailed lessons). 
16. A lessons and action log will be needed. 
17. The project manager needs to ensure that the project staff are "Learning After Doing". 
18. Retrospects need to be scheduled after each project stage (and perhaps more frequently). 
19. On a large, unique, pioneering or dispersed project, a Learning History may be needed. 
20. Knowledge management needs to be linked with performance management, risk management, and SSHE management 
21. (This one was not in the book, but we have learned, since its publication, that) All of the above project-level KM elements need to be documented in a Knowledge Management Plan, owned and monitored by the project Knowledge Manager. 

Advice for the Communities of Practice and Knowledge Owners

1. Ownership needs to be established for the management of knowledge between the projects, and for the derivation of best practices and standards (this is what we call the "Knowledge Owner" role, aka Practice Owner, SME, or technical Authority)
2. A Lesson Learning System will be needed for the projects (including Lessons Management software and an individual or team to manage this). 
3. Best practices, knowledge assets and corporate standards should be constructed for key areas of knowledge (potentially hosted on wikis). 
4. Subject matter experts (Knowledge Owners) are needed for these key knowledge areas. 
5. Transfer of tacit knowledge can be facilitated through staff transfer and through discussions within communities of practice.
6. A Yellow Pages (Expertise locator) system is also a useful tool. 

Advice for Management

1. The organisation needs a knowledge management framework. 
2. Knowledge management standards (for example a KM policy) need to be developed. 
3. Knowledge management plans should be introduced at project level. 
4. Some sort of audit or assessment of Knowledge management capability is needed. 
5. A small resource is needed for monitoring, support, and coordination of Knowledge Management (including performance measurement and the provision of training).

The challenge of Unknown Knowns

---

The unknown knowns are, in many ways, as tricky to deal with in Knowledge Management than the Unknown Unknowns. 

05.24.08 by Daniella on Flickr

We hear a lot (famously from Donald Rumsfeld) about the unknown unknowns, and how difficult they are to deal with, and in knowledge management terms, they can be a real challenge. However an equally challenging issue is the unknown knowns. These are the things that people know without realising – the unconscious competencies. These are very often the deep-lying technical knowledge that is of real value to other.

But how can someone share knowledge if they don’t know that they know it?

An example comes from when I was teaching my daughter to drive. To start with, she did not know what she did not know. The whole topic of driving was a closed book to her. However, once she was behind the wheel, she began to be aware of the things she needed to learn. Now I have been driving so long (36 years), that I drive automatically, without thinking. I know how to do it, but I am not conscious of what I am doing much of the time. I don't know what I know any more. So when she asked me complex questions such as “when changing gear going down a steep hill, do I put my foot on the clutch before I put it on the brake, or do I brake first?” I had to think for some time, and often I had to get into the driving seat, go through the manoeuvre, and analyse what I was doing in order to become conscious of it, before I could explain it to her.

The people who have the knowledge, are often unaware that they have it, like me and driving. The people who need the knowledge may often be unaware that they need it. Without an effective process to address the unknown knowns, the crucial knowledge may never get transferred. We need a process of helping people know what they know.

Questions are the route to the unknown knowns.

We have already seen the process from my driving example – the process is questioning.

There is a saying in the Middle East – “Knowledge is a treasure chest, and questions are the key”.  The person who needs the knowledge asks the difficult question, and starts the process of discovering the unknown knowledge.

The most effective means of knowledge transfer is through dialogue – via questions and answers. Through a question and answer process, the knowledge supplier becomes conscious of what he or she knows, and once they are conscious, they can explain or demonstrate to the learner. The explanation or demonstration can be recorded and codified and made explicit.

This works for teams as well. Teams have an unconscious competence in the way they work effectively together. Not only do the individual team members not know what they know as individuals, they doubly don’t know what the other team members know. So before you can start to capture or harvest any knowledge from a team, you need a team Q&A dialogue, carefully facilitated, such as After Action review or retrospect. Once you start the dialogue, and start discussing the reasons behind why things happened, the team will often piece together the learning as a group activity.

The "self-submission" trap.

Now imagine that you did not use dialogue or questions, and instead that you asked the team members to write down what they know. You would never get the unknown knowns, and you would never get at the double unknown secrets of team delivery.

And yet many organizations expect just that – individual submissions – as a feed into their knowledge base. And then they wonder why they don’t get the value.

Instead, you should aim to make use of the dialogue-based processes,

Interview
After Action review
Peer Assist
Retrospect

Use these as your primary means to help competence to become conscious, to help the knowns to become known, and to start to generate some content of real value.

---

The knower and the learner, and how to turn one into the other

---

"What's wrong with being a Knower?

"Being a Knower is about Knowing stuff, so in KM we should all aim to be Knowers, right"?

Wrong - we should all aim to be Learners.

Being Ignorant by Quoteseverlasting on Flickr

Knowers and Learners are two archetypes within Knowledge Management, representing two end-members of one of the ten cultural dimensions of Organisational Learning.

The difference between the two is fundamental to the Knowledge Management culture shift, and is well illustrated in an old issue of System Thinker magazine, in a piece entitled "Confessions of a recovering knower" by Brian Hinken. 

In this article, based on typical recovering-addict stories, Brian talks about the difference between knowers and learners.

The difference between a knower and a learner, very simply, is that a learner is willing to admit "I don't know", and be influenced. Knowers believe they know all they need to know to address the situations they are responsible for. But at an even deeper level, Knowing is so central to who they are that they sometimes act as if they do know something, even when they don't.

These two archetypes of Knower and Learner are the same two as Sir Clive Woodward, the great sports coach, describes as Rocks and Sponges.

We can see easily how an organisation of Learners/Sponges would rapidly develop habits and mechanisms for Knowledge Management, while an organisation of Knowers/Rocks would block any KM culture change efforts.

Moving from Knower to Learner

Brian goes further in his article and discusses both how he changed his own stance from Knower to Learner, and how others can do the same. He describes 5 areas which the Knower needs to "let go of" in order to become a learner. These are as follows (I have changed the wording slightly);

Question	Knower stance	Learner stance
1. Are you producing the desired results?	Yes, of course	Not necessarily
2. Can you take responsibility for changing things?	No	Yes
3. Could you try other ways of doing things?	No - I know the right way.	Yes, I am open to alternatives
4. Might there be approaches you currently don't know?	Of course not; I am the expert.	Of course.
5. Are you willing to be influenced?	No	Yes

This shift from knower to learner is one of the most fundamental transformations you may need to encourage and support in your organisation.

Through promoting the team-learning tools such as Retrospect and After Action review, you may begin to help people address the first two or three questions (indeed these processes are in themselves culture change agents).

Through introducing communities of practice and  Peer Assist you can help people address the fourth question.

 Finally with Knowledge Management pilots and proof-of-concept exercises we can demonstrate that a Learner mindset delivers step-changes in performance, and benefits both the individual and the organisation.

Don't be a knower - be a learner, and support others in being learners too.

The Chief Devil's Advocate role in KM

---

One of the biggest impediments to learning in an organisation is GroupThink.

 After all - if we all agree we are correct, we have nothing to learn, right?

Devil's Advocate by Sabihclicks on Flickr

In this blog post I explored the concept of a Knowledge Bubble - a group-think barrier which refuses to admit any knowledge contrary to that of the group (the classic example being the Bush Administration who, convinced that Saddam Hussein was the primary threat, refused to countenance warnings about Osama Bin laden). People inside the knowledge bubble are convinced they are correct, and immune to learning or to contradictory knowledge.

But if Group-think is such a potent threat to KM, whose job is it to prick the Knowledge Bubbles?

Thanks to Vince Polley for forwarding this interesting post from Tech Crunch called "The VP of Devil's Advocacy" - which might just have the answer.

The answer (and here the blog post quotes from the movie World War Z) is

"The tenth man. If nine of us look at the same information and arrive at the exact same conclusion, it’s the duty of the tenth man to disagree. No matter how improbable it may seem, the tenth man has to start thinking with the assumption that the other nine are wrong".

This is an illustration from Hollywood, but it is based on a real group - the Devils Advocates Office in Israeli intelligence, described here as follows

The devils advocates office ensures intelligence assessments are creative and do not fall prey to group think. The office regularly criticises products coming from the analysis and production divisions, and writes opinion papers that counter these department's assessments. The staff in the devils advocate office is made up of extremely experienced and talented officers who are known to have a creative "out of the box" way of thinking".

The Devils Advocates Office is an excellent and systematic defence against the perils of group-think. An alternative approach, taken by many project management organisations, is what they call "The Black Hat review" - a destructive review questioning the assumptions underlying a proposal.

When you think about some of the crazy decisions taken by companies, and the even crazier ones taken by governments, it makes you think that this sort of systematic challenge should be institutionalised more often.

Perhaps more organisations should have a VP of Devils Advocacy, a Chief Black Hat, or a Director of Challenge, to act as "The Tenth Man"

Someone whose role and accountability is to be the Chief Pricker of the Knowledge Bubbles.

Care needed when "working out loud"

---

LOUD speaker by woodleywonderworks on Flickr

There is a lot of interest in "Working out loud" and "narrating your work" at the moment. Here are 4 things you need to watch out for, to ensure this approach adds value to the organisation.

"Working out loud" (WOL) is, at first sight, a simple and attractive idea. Social Media and group-ware enable us to narrate what we are doing so that others can be aware (and so avoid duplication and offer insights), and to put our work products in common areas so that others can re-use them and build on them.

Indeed, tools such as Yammer encourage WOL, by prompting you with the question "What are you doing today?"

However there are a number of ways in which WOL, taken superficially, can go badly wrong, as shown by a case study at the end of this post.

Here are 4 pitfalls you need to address.

1. WOL must address demand as well as supply - Pull as well as Push.

Although WOL greatly increases knowledge sharing, the goal of Knowledge Management is not Knowledge Sharing but Knowledge Use. KM is ultimately about giving people access to better knowledge that will solve their problems, and setting a culture whereby they want to find and use that knowledge.

Knowledge re-use requires knowledge demand, and not just supply.  People need to be actively seeking and asking, as well as actively telling and sharing. Any unbalanced market, where supply exceeds demand, leads to a crash in the value of the commodity (in this case, knowledge). Conversely where demand exceeds supply, the value of the commodity rises. Demand stimulates supply; supply does not always stimulate demand.

WOL can fail when it becomes only a mechanism for Telling - telling people what you are doing, telling people what you have done - a supply mechanism only.

If WOL is going to work, it needs to refocused as Asking Out Loud, or Questioning Out Loud. A sharing culture needs to be replaced by (or augmented by) an Asking Culture.  In-house Yammer should be asking "What do you need help with today?". This way WOL becomes a demand-side mechanism.

Remember Shell's maxim of "Ask, Learn, Share" and remember that they prioritise them in that order.

Don't replace "Ask, Learn, Share" with "Tell, Tell, Tell"

There is often an assumption that telling what you are doing, and sharing work in progress, tacitly invites commentary, and is a proxy for seeking and asking. If you are doing something wrong, the assumption is that someone will correct you without you having to ask. The reality is determined by culture, and in many cultures around the world people hesitate to correct someone unasked, or to offer unsought feedback.  If you want commentary then Ask, don't just Tell.

2. WOL creates "just-in-case" knowledge, not "just in time".

WOL, applied incorrectly, becomes a set of answers looking for a question. You narrate your work "Just In Case" someone is interested. You store your work products "Just In Case" they are of use to someone.

However we know that KM is most effective when it operates through "Just In Time" rather than "Just In Case". People don't know what they need to know, until they need to know it (this is one of the demand-side principles of Knowledge Management), and when they need it, they need it NOW.

There are cases where Just In Case knowledge is valuable, namely when you are sure that such a case will recur, and that people will come looking for the knowledge. In situations like this, knowledge is "because we will" knowledge. Such knowledge should be synthesised into knowledge assets tailored to the needs of the user. Just creating compilations of work produces will not be as useful.

3. Noise drowns out signal.

Imagine you are one of 100 people working out loud. Your piece of knowledge might be useful to one of those people. For the remaining 99%, it is noise.  You are putting the onus onto the user to filter out the signal, rather than removing the load from the user. Given that re-use is the biggest challenge in KM then anything that adds barriers to re-use is counter productive, and that includes the noise to signal ratio.

Unwanted knowledge is of no value - it is just noise (until the time when it IS wanted, of course). Wanted knowledge - sought knowledge - is of immediate value.

You can reduce noise by working out loud within communities of practice.  This is a way to focus your sharing - narrating only within a community of people doing the same sort of work as you, who therefore are more likely.  Even better, reduce noise by sharing what is essential and useful.

4. What you are doing, and what you have produced, is not the same as what others should do or produce.

Until you have finished a piece of work and tried the result in practice, you don't know whether what you did was the right thing to do. Any piece of work - a bid, an intervention, a project, a product, a business plan - can only be judged by whether it achieved its results. Therefore narration of work on its own is of little value to others, just as sharing work products is of little value to others. What you should be sharing is the results of reflection on your work; the things you should have done, the things you would do if you were to do it over, and the things you recommend others do.  This is more like coaching out load than working out loud.

And beyond this - if knowledge is, as described above "because we will" knowledge, then such knowledge should be synthesised into knowledge assets tailored to the needs of the user. Just creating compilations of work products will not be as useful; you end up with a mass of material to wade through, some of it out of date, some of in contradictory, some of it wrong.. If knowledge is important, then it requires some investment in synthesising results, insights, and the current best work products, in order to create the best resource base possible for the knowledge user.

When WOL goes horribly wrong.

Here is a story about a company that takes the ideas of "Public sharing" to excess. They were not strictly Working Out Loud, as much of what they shared was finished product rather than work in progress, but their Knowledge Management approach was very much "Tell, Tell, Tell" with little evidence of Learning and no evidence of Asking. They were "Telling out loud" what they had done.

This company had introduced

• A blogging platform for all staff
• Incentives for blogging and publishing. Directors and other senior staff were taking the lead, people ranked each other's blogs, and star bloggers were given prominence and recognition. Blogging was therefore pursued enthusiastically
• A platform for publishing work product articles, again linked to recognition. 
• Many blog posts were repeats of these articles 
• A wiki platform. Much wiki content was repeated on blogs, or duplicated the contents of articles. There was no synthesis of knowledge on the wiki; no creation of Knowledge Assets.
• A discussion forum, used for announcements. Many of the posts were notifications of new articles.
• A microblogging platform, mostly used for narration, and for notification of new blogs, articles and wiki pages 

Activity levels were enormous, driven by powerful incentives. The re-use rate for this mass of material was miniscule -  less than 0.7%.

The net cost to this large organisation was about 42 mandays per day in publishing, checking, reading and maintaining material that will never be re-used, and will seldom be read. There would be big savings in abandoning the system entirely.

This company was fantastic at knowledge sharing and lousy at knowledge re-use. They "Told out loud" to deafening levels, and lost value as a result.

What to do instead

• Ask out loud and Question out loud, so others can Answer out loud. Aim for a culture of asking. Ask before doing. Fill in the knowledge gaps that you are aware of before you start your work, then ask others whether there is anything else you are missing.  
• Share your knowledge and insights, not your actions and products. Reflect in your teams about how effective your work was, and share the results of the reflections. Share what you think others should know, not what you yourself did.  Coach out loud.
• Aim for "Just in Time" knowledge and "Because We Will" knowledge, rather than "Just In Case" knowledge.
• Narrowcast your questions and your knowledge to those most likely to need to know, within the relevant communities of practice.

Above all, avoid the pitfall of "Tell, Tell, Tell"

A legal KM role description.

---

Lawyer fortune cookie by sigckgc on Flickr

Here is another addition to our collection of Knowledge management role descriptions (find more here).

Found on Linked-In - a role description for a Legal KM role, the "KM Lawyer". Although, like in most Legal KM approaches, there is a strong focus on model forms and precedents, we also see the introduction of post-matter review and lessons learned (highlighted below). This is a welcome extension of the traditional curation-focused legal approach.

The Labor & Employment Knowledge Management Lawyer (“KM Lawyer”) will be an experienced lawyer reporting directly to the Knowledge Management Office

Specific reponsibilities include, but are not limited to:

Knowledge Strategy

• Work with the Groups and the Knowledge Management Officer to assess the relevant knowledge needs, define and implement a plan to meet those needs, and establish mechanisms for regular review of the plan.

Organizing and Sharing Knowledge

• Work with members from the Groups to create and capture practice-related knowledge content and encourage the sharing of information and knowledge generally;
• Operate and implement procedures for capturing, filtering, storing, accessing and disseminating materials and information, including model forms and precedents;
• Co-ordinate and support the lawyers to ensure that all models and forms are updated to reflect changes in applicable laws, regulations, market standards and best practices; and
• Ensure seamless accessibility of information and precedents via the appropriate practice portals.

 Lawyer Training and Technical Expertise

• Identify practice-related training needs and coordinate with the Professional Development team to organize, design and deliver (personally or with others) training, including seminars, workshops and offsite training;
• Train on how to access knowledge resources in the practice portals, on the Intranet, and elsewhere;
• Provide direct support to individual practitioners to assist them with locating practice-related internal and external knowledge resources; and
• Be a source of legal, market and practical expertise.

Legal Project Management

• Work with the lawyers, Knowledge Management Officer and other stakeholders to establish legal project management processes to capture matter information at all stages of an engagement and conduct post-matter review of lessons learned.

 Client-Facing Initiatives and Business Development

• Work with the Business Development department staff to identify opportunities to develop business from new and existing clients through articles, briefing notes, client training, etc.; and
• Help to identify issues and developments of relevance to key clients as part of ongoing business development.

 Current Awareness and Thought Leadership 

• Monitor and keep the Groups informed about important developments in applicable statutes, regulations, judicial decisions and the business environment through bulletins, training, know-how meetings and other processes;
• Identify trends in the law or business environment and suggest innovative ways to deliver the Firm’s services to clients more efficiently and effectively; and
• Participate in industry events to raise the Firm’s profile as a thought leader and keep up to date with developments when feasible.

 Other

• Participate in the planning of training and other knowledge-related activities;
• Participate in regular meetings with the Knowledge Management Officer and other KM Lawyers to facilitate the sharing of best practices and knowledge; and
• Attend external training and conferences to keep up-to-date with relevant developments in the law, business environment and professional support.

Desired Skills and Experience

• Five or more years of sound legal experience in the labor & employment law context at a large law firm or relevant in-house legal department;
• Prior experience providing knowledge management support would be highly desirable;
• High professional standards with a passion for quality work product;
• Excellent drafting and research skills;
• Well-developed organizational and communication skills;
• Understanding of learning processes and different methods of training;
• Effective interpersonal skills and the ability to interact with people at all levels;
• Aptitude for and interest in technology and integration issues; and
• Pragmatic, self-motivated, flexible and team oriented attitude.

What's unique about Knowledge Management?

---

Unique Selling Proposition by Photosteve101 on Flickr

Any management discipline needs to have a defined unique area of scope if it is to add value. It needs to be different enough from other disciplines, and distinct enough, that it has its own niche of operation. So what's distinct and unique about knowledge management?

Knowledge Management is a discipline that is often confused with others. Knowledge Management and information management, for example, often are confused or conflated. Knowledge Management and Training also is an area of confusion, as is KM and content management.

Here is what distinguishes KM from those other disciplines.

Knowledge Management and Information Management

Information management covers the management of all information resources, whether they are knowledge resources or not. Knowledge Management covers the management of knowledge, some of which may be codified as information. There is therefore an overlap between the two, as well as distinct areas.

• The overlap is all codified knowledge - knowledge (ie know-how) in documented form, such as guidance, instructions, FAQs, checklists and lessons.
• The area unique to IM is the management of all of the other (non-knowledge) information resources. 
• The area unique to KM is the management of undocumented knowledge resources; largely done. through promoting connection between people using interventions such as Communities of Practice. 

Knowledge Management and document management/ECM

Document management is a subset of information management. Document management covers the management of electronic documents, whether they are knowledge or not. Knowledge Management covers the management of knowledge, some of which may be codified within documents. As above, there is an overlap between the two, as well as distinct separate areas.

Knowledge Management and Organisational Learning

These two are very closely related, and to be honest the two could be combined. However I would suggest that Organisational Learning is the objective, and Knowledge Management is the method.

Knowledge Management and business intelligence

Business intelligence is the gathering and supply of business related data and information which can then be used for either supporting decisions, forecasting future events or discovering trends within a set of information.
Knowledge management is about the development of the know-how that allows people to make decisions, based on these (and other) data.  It s what enables an organisation to know what to do with the intelligence.

Knowledge Management and Internal Communications

Internal communications is about providing and publishing news and information to people.

Knowledge Management is about the exchange and re-use of knowledge between people.

Knowledge Management and Training

Training focuses on the developing the learning  and knowledge of the individual.
Knowledge management focuses on the developing the learning and knowledge of the organisation.

Knowledge Management and Innovation

see here.