Knowledge Management in projects

It has been fifteen years since I wrote my first solo KM book, “Knowledge Management for Teams and Projects“.

I reproduce below the final chapter, that attempts to summarize the main conclusions for three groups of key Knowledge Management actors; the project managers and knowledge managers, the Community coordinators and SMEs, and the company management, and outlines their roles in driving KM in projects.

Some added activities have been developed over the past decade and a half, and these are included in italics

For the project manager, and project knowledge manager 

The project manager needs to ensure that the project staff are “Learning Before Doing

  • The project manager should ensure the project has a Knowledge Management plan, and performs some form of knowledge gap analysis.
  • Right-Scoping meetings are a way of bringing knowledge during the Scoping phase of the project 
  • Customer Interview maximizes the team’s knowledge of the customers’ needs and context
  • The earlier you can bring in Contractors’ knowledge, the better
  • Peer Assist is one of the simplest and most effective ways of bringing in existing knowledge from past projects
  • Optioneering is one form of Peer Assist 
  • If there is no existing knowledge, some level of Business Driven Action learning may be needed
  •  Peer Review is more of an assurance process than a Knowledge Management process 

The project manager needs to ensure that the project staff are “Learning While Doing” 

  • The After Action Review is an excellent way of doing this
  • Communities of Practice are a crucial resource for “Learning While Doing”
  • Knowledge Management can be built into project review meetings
  • The project manager will need to appoint a Knowledge Manager for the project 
  • The project knowledge manager manages the project KM plan
  • Knowledge engineers and/or learning historians may also be needed in major projects
  • A Lessons and Action Log will be needed 

The project manager needs to ensure that the project staff are “Learning After Doing”

  • Retrospects need to be scheduled after each project stage (and perhaps more frequently)
  • On a large or dispersed project, a Knowledge History may be needed 
  • Knowledge Management needs to be linked with Performance Management, Risk management, and SSHE management
  • A “knowledge handover” meeting should be held at the end of the project to share the lessons with other projects
  • The project team should conduct a baton-passing meeting with the operations team

For the Community coordinators and SMEs 

  • Ownership needs to be established for the management of knowledge between the projects, for the derivation of Best Practices and Standards, and for the operation and maintenance of communities or practice
  • Best Practices, Knowledge assets and other knowledge-related guidelines should be constructed for key areas of knowledge
  • Subject Matter Experts are needed for these key knowledge areas
  •  Transfer of tacit knowledge can be facilitated through Staff Transfer and Communities of Practice
  • A Yellow Pages system is also a useful tool
  • The communities of practice require a Q&A tool, a document library, and a place to build best practice (eg a wiki).

For management 

View Original Source ( Here.

How KM works in projects

Projects require their own KM Framework. Here’s one view of what this might look like. 

Image from
“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 main stakeholder groupings of Project Manager, SMEs, and Management. This describes an ideal project-level Knowledge Management Framework

The last chapter of my book

The bullet-point summary is reproduced below with a few updates representing evolution of the field since the book was written in 2005.

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. The project should create a project Knowledge Management Plan or  Knowledge Gap Analysis plan to determine what knowledge the project needs before they start.
  3. This should include a clear knowledge of the customers’ needs and context.
  4. This should include knowledge from past similar projects, including a review of their cost and schedule data, and their lessons learned.
  5. The earlier you can bring in contractors’ knowledge, the better. 
  6. Peer Assist is one of the simplest and most effective ways of bringing in existing knowledge from past projects. 
  7. If there is no existing knowledge, some level of business-driven action learning (or other innovation process) may be needed to create any new knowledg which is needed. 
  8. The project manager needs to ensure that the project staff are ‘Learning While Doing”. 
  9. The After Action Review (AAR) is an excellent way of doing this (as part of a Project Learning System). 
  10. AARs can be built into project review meetings. 
  11. Communities of practice are a crucial resource for learning while doing. 
  12. The project manager will need to appoint a knowledge manager for the project. 
  13. Knowledge engineers and/or learning historians may also be needed in major projects or projects which are “pioneer” projects for the organisation (these are a specific type of knowledge manager dedicated to recording the details of the project, and the detailed lessons). 
  14. A lessons and action log will be needed. 
  15. The project manager needs to ensure that the project staff are “Learning After Doing”. 
  16. Retrospects need to be scheduled after each project stage (and perhaps more frequently). 
  17. On a large, unique, pioneering or dispersed project, a Learning History may be needed. 
  18. Knowledge management needs to be linked with performance management, risk management, and SSHE management

Advice for the Communities of Practice and Knowledge Owners

  1. There should be a community of practice covering all main work topics in the organisation
  2. There should be a “Knowledge Owner” for all main knowledge topics. 
  3. Best practices, knowledge assets and corporate standards should be constructed for key areas of knowledge (potentially hosted on wikis). 
  4. Any individual on the project working on these topics should join the community of practice and get familiar with the community knowledge and the community discussions

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).
  6. Lesson Learning System will be needed to cover all projects (including Lessons Management software and a Lesson Management team to manage this). 

View Original Source ( Here.

The most expensive part of a project is the mistakes

In any project, the most expensive item is the mistakes. Use KM, modularisation and standardisation to keep mistakes to the minimum.

Arches by Paul Ebbo
Arches, a photo by Paul Ebbo on Flickr.

The title of this blog post comes from a quote by the author Ken Follet in his book “The Pillars of the Earth”.

Follet’s book is a novel set against the background of cathedral-building in the Middle Ages, when cathedrals were the mega-projects of the time. The original quote, attributed to the fictional master-builder, is “The most expensive part of a building is the mistakes”. The cathedral builders knew that any mistake would be massively costly in terms of time, labour and materials, and took great precautions to avoid error.

These precautions included using a modular design, where every bay in the cathedral was square, and each arch was identical. This allowed the design and build process to be perfected on the first bay and arches, and then re-used throughout the whole building project. Building components such as the falsework arches and the templates for the stones could be perfected once and re-applied a hundred times.

The same principle can be applied in other projects, including today’s megaprojects. This blog has already argued for a combination of modularisation, standardisation and Knowledge Management as a way of reducing project mistakes to a minimum, and re-using designs and knowledge throughout. Use KM to perfect your approach on the first use of any module, through “learning while doing“, so the knowledge can be safely re-used thereafter.

If your senior managers are still not convinced of the value of Knowledge Management, help them to see that the most expensive part of a project is the mistakes, and that effective “learning while doing” combined with a modular approach can reduce those mistakes to a minimum.

View Original Source ( Here.

The four most costly words in KM – "this time it’s different"

“This time it’s different” can be the four most costly words in project knowledge management, if they are used as a reason not to learn from the past.

Albert Einstein’s definition of insanity was “doing the same thing over and over again and expecting different results”.

And yet, any analysis of a collection of corporate lessons will show the same mistakes being made time after time. So organisations obviously DO “do the same thing over and over again and expect different results”.

Are organisations insane?  Or is there another factor at work?

The factor may well be what the Farnam Street blog calls the “This time it’s different” fallacy. I quote from the blog –

“This time is different” could be the 4 most costly words ever spoken. 

It’s not the words that are costly so much as the conclusions they encourage us to draw. We incorrectly think that differences are more valuable than similarities. After all, anyone can see what’s the same but it takes true insight to see what’s different, right? We’re all so busy trying to find differences that we forget to pay attention to what is the same.

Different is exciting and new, same is old hat. People focus on the differences and neglect the similarities. In projects, this becomes the “my project is different” fallacy that I described here. People look at their projects, see the unique situations, find the differences, overlook the similarities to all similar projects on the past, and assume that “this time it will be different”.

It never is.

The same old mistakes will creep up on you and bite you in the bottom, as they always do.

Instead of assuming “this project is different”, perhaps we should start with the assumption that “this project is just like any project. It involves building and understanding client requirements, choosing and forming the team, selecting and managing sub contractors, balancing the innovation against the risk, communicating within the team and with the client, keeping the client requirements always in mind, managing quality, managing cost, managing time, managing expectations, managing risk, and so on”.

Then look for the lessons that will help you with all those tasks, and will help you avoid all the old pitfalls. As the Farnam Street blog says,

If you catch yourself reasoning based on “this time is different” remember that you are probably speculating. While you may be right, odds are, this time is not different. You just haven’t looked for the similarities.

A great antidote to the “This time it’s different” fallacy is that good old, tried and tested mainstay of Knowledge Management, the Peer Assist. Once a project team gets into a room with a bunch of people with experience, the conversation automatically focuses on the similarities. “Yes, we’ve seen that, we’ve been there, here’s what we learned” and it becomes increasingly difficult to maintain that “This time it will be different”.

View Original Source ( Here.

The 4 steps of learning within a project

As a project learns, it goes through 4 stages (see Donald Rumsfeld)

I blogged yesterday about the need for knowledge transfer between a project and an organisation.

This post goes a little further, and talks about the development of knowledge within a project.

The diagram here shows how KM can take a project through a progression of learning in a project, and is particularly applicable to product development projects or R&D projects.

  1. In step 1, the project becomes clear about what it already knows (about the challenges, about the technology, about the market). These are the Known Knowns.
  1. In step 2, the project should identify its knowledge gaps, through a process such as Knowledge Gap Analysis or KM planning. Through this process, the team becomes clear what they don’t know, but can learn from others.   As far as the project team is concerned, these are the Unknown Knowns; things that others know, that the project team doesn’t. Here the team needs to learn from the wider organisation as described in yesterday’s post, or learn from other organisations. By mapping out the known knowns, the project team can then limit their scope to the truly unknown (because if they start researching known territory. they are wasting effort and reinventing the wheel). (See for example Wilbur Wright’s attempt to map out the known knowns when researching Powered Flight). This step also helps overcome the overconfidence bias.
  1. In step 3, the project steps into the unknown. They define what they need to learn about but cannot just learn from others (the Known Unknowns), and put in place processes to gain that knowledge – R&D, Market Research, Rapid Prototyping, Business Driven Action Learning.  Through these processes, they fill in the Known Unknowns  as they become known.
  1. In step 4 the project butts up against the Unknown Unknowns – the nasty surprises. They can only address these by a secure process of “Learning while Doing” – through After Action Reviews or some other process of project learning. They won’t discover all the Unknown Unknowns, but can make some headway into this territory.
  1. Then of course comes step 5, where all of this knowledge is fed back to the organisation, as described yesterday.
And then, of course, at the end of the project, they can share what they have learned with the rest of the organisation.  All of these steps should be covered by the project Knowledge Management Plan

Through this series of steps, the project can build on the known and learn about the unknown in a planned and efficient way.

View Original Source ( Here.