The 2 axes of "KM space" in a project-based organisation

In a project-based organisation, we can look at Knowledge Management on two orthogonal axes which together map out the space within which knowledge flows. These are the in-project axis and the cross-project axis.

Imagine a large project-based organisation, with multi-disciplinary projects operating in many different regions or divisions. KM needs to be addressed within the projects themselves, and it also needs to be addressed between the projects, for example within the functions or the communities of practice.

The in-project KM elements are focused on knowledge creation and sharing, and knowledge seeking and application.

The cross-project elements are focused on management of the knowledge as it grows and evolves over a series of projects. The cr

In-project KM

The in-project KM axis represents those knowledge elements that occur within a project, involving the project team. These elements can include

These in-project elements include the creation of knowledge products from the projects.
Cross-project KM
The cross-project KM axis represents those knowledge elements that link the projects, and that “breach the silo walls” that can separate projects and divisions. These elements can include
These cross-project elements manage the knowledge workstream for the organisation, which runs in parallel to the project delivery workstream.

Integration of the two axes.

The two axes need to be integrated. Any knowledge outputs from the projects need to be fed into the correct communities of practice, knowledge bases and knowledge owners. Also the knowledge owners and communities should be responsive to the needs of current and future projects. The knowledge taxonomy needs to be consistent across both axes.

When integrated together, the two axes of in-project KM and cross-project KM allow knowledge to be created, shared, sought and re-used, and to flow across and between the silos, as shown in the picture above.

Both these axes need to be included in any effective Knowledge Management Framework for a project-based organisation.

View Original Source ( Here.

The 3 types of knowledge output from a project

All projects deliver not just a product, but knowledge as well, and there needs to be a clear understanding of what form that knowledge will take. 

Part of any Knowledge Management policy therefore has to be a definition of the expected  knowledge output from project work.  This knowledge output is distinct from any information products, or project files, or project reports.

Remember what we mean by “Knowledge” – “a human or organizational asset enabling effective decisions and action in context” according to the ISO standard. Therefore any knowledge output should be something that enables others to make better decisions or take better actions.

There are three main types of Knowledge output, which should be carefully defined in the project Knowledge Management plan.

  1. Better ways of doing things. These are recorded as Lessons throughout the project, and especially at the end of project stages. The lessons will be entered into the company Lessons Management System, and fed through into improvements in guidance, training, procedures or standards. For product development projects, there may also be product design improvements that were introduced, and these can be documented as Toyota-style A3 sheets, and stored in the product folder. For R&D projects, the increments in learning are recorded in the R$D knowledge base, to allow future R&D projects to build on the insights gained. In each case, these outputs allow future workers to make better decisions based on better process, better design, or a better knowledge base. 
  2. Good examples. These are project outputs that are “best in class” and can be offered to other projects as templates. They will be stored in the knowledge base associated with that process. These are offered to future workers as things to copy to give them a head start.
  3. Knowledge that is needed further down the value chain. The project may deliver “information products” like installation manuals, as-built designs and so on, but in addition there may need to be knowledge products. These will describe WHY products were designed the way they were (captured in documents such as Basis of Design, or the Rolls Royce Decision Rationale editor, or may capture HOW knowledge such as how best to sell, maintain, install or operate products. They help people further down the value chain – the sales staff, the service staff and maintenance staff, to make better decisions and take better actions.

These knowledge outputs benefits people other than the project team, and therefore should not be started and archived with the project files, but should find their way into the “common knowledge” of the organisation, through the lessons management system, the communities of practice, and the organisational knowledge bases.

The projects should know that it is their responsibility to create this output and to share it through these designated channels. 

View Original Source ( Here.

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.