KM accountabilities within projects and programmes.

 In a project based organisation, project managers bear much of the accountability for KM within the projects. 

There are two dimensions to KM within a project based organisation. These are

• KM within individual projects, and
• KM across and between the projects.

Any project based organisation needs to consider both dimensions, and to make sure the correct roles and accountabilities are in place in both. Below is something I recently found in my files which I think is a nice description of the KM accountabilities in the domain of projects and programmes.

The project/programme manager carries single point accountability for KM activity at project/programme level. This includes accountability for:

• Identifying knowledge deliverables for the project/programme consistent with those required by the organisation;
• Ensuring that required knowledge deliverables are created and shared appropriately;
• Ensuring the team(s) seek and re-use existing organisational knowledge wherever appropriate, and 
• Ensuring that appropriate KM processes and systems are in place for the project to manages its own tacit and explicit knowledge though the life of the project; 
• Ensuring that required KM activities are included in the project/programme plan and resources assigned accordingly; and 
• Monitoring to ensure the required KM activity is taking place.  

A programme manager can, if required, delegate accountability for KM within component projects to the relevant project managers, while still retaining accountability at programme level. 

A project manager can, if required, delegate accountability for KM within component sub-projects or workstreams to the relevant sub-project or workstream managers, while still retaining accountability at project level. 

Responsibility for specific KM activities can be delegated within the project team as needed.

In larger projects the project manager can consider assigning KM coordination duties to a named individual e.g the project controller, project risk manager, project quality manager or project services manager.

Project/programme performance against KM requirements will be assessed at stage gates as part of the project/programme review process.

Use of a project/programme knowledge management plan may be considered, to aid monitoring and clarify KM responsibilities and activities at project/programme level. 

 

 

 

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

• Creation of a project KM plan
• Appointment of a project Knowledge Manager
• Activities to bring Knowledge into the project, such as Peer Assist
• Activities for learning within the project, such as After Action Review
• Collection of knowledge from the project, such as Lessons Learned and other knowledge artefacts

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

• Communities of practice or other knowledge sharing networks
• Appointment of Knowledge Owners for key knowledge topics
• Development of "Best Practice" where appropriate
• Creation of Knowledge Bases
• Management of lessons learned
• In some of the bigger organisations, Knowledge Centers may be set up to support the projects with their knowledge-based requests.

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.

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. 

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 

• The organization needs a Knowledge Management framework
• A KM policy will need to be developed
• Knowledge Management Plans should be introduced at project level
• Some sort of audit or assessment of KM capability is needed
• A small resource is needed for monitoring, support, and coordination of KM (including performance measurement and the provision of training)
• The project organisation needs a lessons management system
• There will need to be a resource, probably within the PMO, to administer the lessons management system

How KM works in projects

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

Image from science.dodlive.mil

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

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, 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.

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".

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.

2. 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.

3. 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.

4. 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.

5. 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.

How projects and organisations work together to make a KM system

Projects and the wider organisation are linked in a Knowledge-handling cycle

Please note, in this article you can replace the word "project" with "department" or "division" or "team" or "office" throughout.

The Boston Square here is one that I have used with projects as part of their Knowledge Management planning, and is a useful framework to allow projects to reflect about the knowledge sharing they need to do.

The thinking is as follows.

• The project knows some things
• The wider organisation (the centre, the functional departments and other projects) knows some things as well.
• At the start of the project, they need to learn as much from the wider organisation as they can. If there are important things the organisation knows but the project doesn't, the project needs to learn these things.
• At the end of the project, if the project has learned things the rest of the organisation does not know, then the project needs to share this knowledge.
• At all other times, the project and the organisation should be in synch - in the green boxes in the diagram.
• If there is any knowledge held in the red boxes, meaning that the organisation doesn't learn what the project knows, or the project doesn't learn what the organisation knows, then this is evidence of organisational silos, and of the lack of knowledge sharing. 

The projects therefore import knowledge from the organisation at the start, and export new knowledge at the end. They are the users and the creators of knowledge. In many ways the rest of the organisation exists as a knowledge-handling mechanism to service the projects with knowledge. 

Knowledge circulates through the interactions between the projects and the organisation, as shown below, and grows, deepens, evolves and develops as it does so.

 

The projects and the organisations are like two chambers of a beating heart, responsible for the circulatory flow of Knowledge

One way to decide how much effort to put into KM in your project.

How much of your project spend should be on KM?

image from wikimedia commons

That's an interesting question, and one way to answer it is to look at the value of the knowledge in proportion to the value of the project itself (please note this argument only really works for projects that deliver a value stream).

Take for example a large construction and engineering project - the first of its kind in a new location. The project will create two things -

1. An income stream for the owner
2. Knowledge, which can be used to reduce cost for future projects

Let's assume some facts for our imaginary project. Let's assume it's a big one but not quite a megaproject.

1. Budget of $500 million
2. Timescale 2.5 years
3. Net Present Value (NPV) $1 billion
4. Work-hour estimate 10 million
5. 2 similar projects planned
6. Conservative estimate of the value of the knowledge - $50 million (5% cost saving on 2 follow-on projects of the same size and scope through effective KM and lesson learning)

So if the value of the knowledge is $50 million and the value of the project is $1 billion, then logically you would expect the investment in KM to be in the same ration to the spend on the project - ie 5%. You would expect a total KM spend of $25 million (3% of $500m) producing lessons, guidance and other knowledge for the improvement of the two follow-on projects. 

Now a lot of the work on the main project would  be done by contractors, and you would need to make sure that they also were spending their share on KM.  Its also possible that you could discount the cost or materials, and instead look at time and labour costs.  The project management team itself might be, say 20 people, working 10,000 days over the life of the project. By the same logic, you would want 500 days (or 1 person full time) spent by the project management team on knowledge management. 

In most projects, the team would spend nowhere near this. They might have a one-day lessons learned meeting halfway through the project (1 day for 20 people is 20 workdays) and another one-day meeting at the end (another 20 workdays). That is a massive under-investment of time and resource, given the value of the knowledge. Instead they should spend 5% of their time on KM, or 2 hours a week.

For your organisation,you can do the math. Work out the value of the knowledge vs the value of the projects, and see what investment in KM would  be appropriate. 

It might surprise you - it surely will surprise your management, because in our (Knoco) experience, the vast majority of projects under-resource KM, compared to the value it delivers.

Video on KM in a USAID project

The video below is from the USAID-supported Vrisshi project in India, funded to scale up advances in reproductive, maternal, newborn and child health (+ adolescents as well).

The video talks about a knowledge base, or collection of publications, that was created through the project for use by medical and health practitioners. You can read more about Vriddhi here.

The simplest and best KM model?

Another reprise from the archives - a reminder of one of the simplest but most useful KM models for a project-driven organisation

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, UK, in 1997 (pre-PowerPoint - it was drawn on an acetate slide) and it has proved robust and valuable ever since. 

5 success factors for project learning

Learning effectively from projects is a goal for many organisations. Here are some ways how to do it.

Dams project team, by US Army Corps of Engineers, on Flickr

The 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 normal font.

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. Learning within the project is covered by After Action review, export of learning to other projects is covered by Retrospects.

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. This need not be a full time role, but it should be a single point accountability.

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. Lesson Learning shoul dbe emphasised in the project management policy.

4. Integration of learning and knowledge goals into project goals - Adding knowledge goals to every project step can foster systematic reflection about every milestone in a project. 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 or the project objectives, 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.

Knowledge Management in mega-projects

KM in mega-projects is much the same as KM in any project, but at a larger scale and a greater degree of rigour

image from wikipedia

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.

Setting up the KM framework. The KM system for a mega projects needs to be more robust, and better resourced, than for a normal project. You will need:

• a KM policy for the megaproject
• a good and robust KM plan, including a definition of all the unknowns, and how to make them known
• a dedicated knowledge manager (potentially full time)
• a lesson management system for the  megaproject
• a wiki, and blogs, for building knowledge as the project continues
• a set of KM processes, as described below.

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 may be online global communities of practice for megaprojects that you can draw on such as the PMI and the CII, and you can potentially 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.

Learning before, during and after; how it works in Sport

“Learning before, during and after” is a common principle applied to knowledge management in project-based organisations.  But what does it really mean?

We may have read about the principle of learning before, during and after in projects, but if you want to see how it really works in practice, take a look at sport. 

A sports team - a football team, or a rugby team or a cricket team - has built this learning rhythm into their working week.

The team do their Learning Before on a Friday. 

They study video recordings of their forthcoming opponents, they identify the other team's weaknesses and patterns of play, and they discuss the tactics and strategy they might use on the Saturday.  They look back on occasions when these opponents have been beaten, and analyse how best to beat them this weekend.

The team do their Learning After on a Monday.  They review and analyse, often in great detail and with the aid of computer analysis, the video footage of the weekend’s match.  They identify the things that have gone well, and analyse why they went well.  They analyse things which did not go to plan, look at the root causes behind this, and identify anything they need to work on during the week, and do differently in future matches.

What about Learning During?  Learning during takes place during the match, partly through messages sent on to the field from the management team, and partly through self analysis during the half time break. The purpose of Learning During is to identify and change things that are not working, and identify and repeat things that are. Often the team that learns and adapts the best on the pitch, wins the match. 

This is just the same way that a project can learn.  The team can analyse, before work starts, and challenges and problems they will face, and seek to learn from previous examples where those challenges have been overcome, through mechanisms such as Knowledge Management planning and Peer Assist.

They can learn after the project; they identify the things that have gone well, and analyse why they went well.  They analyse things which did not go to plan, look at the root causes behind this, and identify anything that needs to be done differently on future projects, through processes such as Retrospect.  Then during the project itself, they should be open to learnings both from the project team themselves, and from external observers. They can  identify and change things that are not working, and identify and repeat things that are.

That's how winning teams learn.

How to embed knowledge activities into organizational process

Another post from the archives - this time on embedding knowledge activities into organisational process

One of the aims of Knowledge Management Implementation is to develop and embed a Knowledge Management Framework, including building KM activities into business process. I thought I would expand a little on how to do this.

Most large organisations have pretty well-defined business processes. These may include

• Marketing process
• Sales process
• New Product Development process
• Manufacturing process
• Packaging/distribution process
• Project management process
• Service-call resolution process

and so on. These processes consist of a series of steps, often shown diagrammatically as a flow chart, like the example shown.

Embedding KM into these processes means putting Knowledge Management-specific steps into that flowchart.

• You can start, by identifying where, within the business process, there is the greatest need for the team to acquire knowledge, and adding a "Knowledge Acquisition" step, such as Peer Assist, Lessons Review, Knowledge Site Visit, Collaborative work session, or a Knowledge Management Plan. There may be several such steps needed within the business process.

• You can look at where,  within the business process, there is the greatest need for the team to create new knowledge, and add a "Knowledge Creation" step, such as Deep Dive, Think Tank, or Business Driven Action Learning.

• Then you can look at where, within the business process, there is the greatest need for  the team to discuss and identify learning. These will be steps which follow points where the greatest knowledge has been created, or the greatest learning acquired, and where you need to add a "Knowledge Capture" step. Some of these will capture knowledge for re-use by the same team, and may include small scale After Action Reviews. Some will capture knowledge and lessons for other teams, and may include Retrospect. Some may  include hand-over of knowledge to later stages in the project or product life-cycle, and may include Baton Passing or Knowledge handover. There may be several such steps needed within the business process.

That is your starting point - looking at the flow of knowledge into and out of the process. You may eventually add other steps where needed.

The important thing is to 1) find knowledge management processes which work in your context, and 2) make sure those KM process appear, as little boxes, within the business process flow chart.

That way, they will be applied.

The "Umbrella Week" as a means of sharing lessons.

The Umbrella week (aka Knowledge Handover) is a face-to-face process for sharing lessons with the rest of the organisation. 

Umbrella week image from army.mil

You can read about a recent Umbrella week here, where Captain Scott Kuhn of the 3rd Armoured Brigade described an event last week. According to Scott, 

An Umbrella Week is scheduled by brigade-level units or higher "within 6 weeks of completion of major deployments or Combat Training Center rotations in order to share lessons and best practices, and facilitating changes to Doctrine, Organization, Training, Materiel, Leadership and Education, Personnel, Facilities and Policy. 

The Umbrella Week basically gives other units a chance to come and gather knowledge from a unit right after a deployment, through a structured series of facilitated discussions. The  process is as follows:

1. There is an initial phase of lesson-gathering from the Brigade, for example through After Action reviews
2. The team from the Centre for Army Lessons Learned who organise the Umbrella week also create a collection plan to collect these lessons, and also to look at the points of interest for the rest of the organisation, and the issues where more knowledge needs to be discussed and gathered
3. Various departments and agencies are invited to the Umbrella week in order to take part in the discussions, which may be in a focus-group setting or may be individual discussions. Even though lessons are prepared in advance, the discussions are question-led, rather than being presentations to an audience. 
4. At the end of the week each agency takes away the lessons they gained and updates training, doctrine etc, and the Analysts at the Centre for Army Lessons Learned also update their own materials. 

Similar processes are run in industry as well, such as the 2-day Knowledge Handover process we ran at BP after a major pipeline project. The steps were the same - gathering of the lessons first, identification of the questions which needed to be answered and the people who needed to attend, and two days of facilitated discussion to ensure the knowledge was transferred to those teams an experts who needed to know.

So this is not just a military process; it is something that can and should be done in any organisation after a major piece of work, as a way to communicate the lessons and to facilitate any changes to procedures that need to be made.  And it uses that good old-fashioned technology - face to face discussion.

As one soldier said:

“Umbrella week is our chance to contribute to future engagements. What we share this week will ensure that units deploying in the future can build and learn from our lessons learned.”

The "learn before, during and after" model in KM

"Learning before, during and after" is one of the oldest models in KM, and still one of the most useful.

Learning before, during and after was one of the early bywords for Knowledge Management at BP in the 90s - a simple and memorable mantra that project staff can grasp easily and quickly. It forms the basis for an operating philosophy for KM, and describes how Knowledge Management activities can be embedded  within the cycle of business activity.

The management of knowledge, like any management discipline, needs to be systematic rather than ad hoc, and needs to be tied into the business cycle. In any project-focused business, where business activities (projects) have a beginning and an end, knowledge can be addressed at three points.

1. The project team can learn at the start of the project, so that the project begins from a state of complete knowledge (‘learning before’). This is where processes such as Knowledge handover and Peer Assist can be applied. 
2. They can learn during the project, so that plans can be changed and adapted as new knowledge becomes available (‘learning during’), for example through the use of After Action Review.
3. Finally, they can learn at the end of the project, so that knowledge is captured for future use (‘learning after’) and entered into the Lesson-Learned workflow.

These activities of "Learning before," "Learning during" and "Learning after" can become an expectation, or even a mandatory activity, for projects.  This model of ‘learn before, during and after’ was developed in BP during the 1990s, and was also developed independently in several other organizations. Shell refers to this as “Ask, Learn, Share”.

However, there is more to the model than the ‘learning before, during and after’ cycle. The knowledge generated from the project needs to be collated, synthesised, and stored as Knowledge Assets (guidance documents such as SoPs, or Wiki-based guidance) in order that knowledge deposited in the “knowledge bank” at the end of the project becomes more useful when accessed at the start of the next project. Communities of Practice need to be established to manage and share the tacit Knowledge Assets.

 This five component framework (learning before, learning during, learning after, synthesis of knowledge into Knowledge Assets, and building Communities of Practice) is a robust model which creates value wherever it is applied.

Using a "pretend customer" in knowledge capture reviews.

When capturing knowledge, sometimes its useful to have a pretend customer you can introduce. 

Image from wikimedia commons

I have blogged about the need to write knowledge as if it were for a "knowledge customer", and to "document for the customer" when capturing knowledge.  But what do you do if nobody knows who the customer is?

A friend of mine recently came up with an interesting solution to this, but introducing a fictional customer.

He was running a Retrospect, and was discussing the learning points from one particularly tricky set of events. The group were struggling to express the lessons in useful terms for future projects, so he reached into his bag and pulled out a little blue toy dog which he was taking home to his son.

"This is Blue Dog" he said. "Blue Dog is running the next project. What advice would you give to Blue Dog, to help avoid the problems you had this time around?"

OK, a bit corny, but it gave the discussion a focus, and the project team were able to come up with some specific and actionable recommendations for Blue Dog. Blue Dog became a very visible stand-in for the Unknown Knowledge User.

Another friend, Lisandro Gaertner fron Brazil, used a similar approach with a three months long training/best practices sharing online program with Sheriffs.

They were challenged to give advice to a new Sheriff called Sherlock Silva about the most common problems they faced it. That worked very well and Sherlock Silva turned in a kind of a meme in the community. "What should Sherlock Silva do?" 

So if your Retrospect is struggling, maybe its worth having a blue dog in your bag, or introducing Sherlock Silva!

What are the outputs of the KM workstream?

KM organisations need a Knowledge workstream as well as a Product/Project workstream. But what are the knowledge outputs?

I have blogged several times about the KM workstream you need in your organisation; the knowledge factory that runs alongside the product factory or the project factory.  But what are the outputs or  products of the knowledge factory?

The outputs of the product factory are clear - they are designed and manufactured products being sold to customers. The outputs of the project factory are also clear - the project deliverables which the internal or external client has ordered and paid for. 

We can look at the products of the KM workstream in a similar way. The clients and customers for these are knowledge workers in the organisation who need knowledge to do their work better; to deliver better projects and better products. It is they who define what knowledge is needed. Generally this knowledge comes in three forms:

• Standard practices which experience has shown are the required way to work. These might be design standards, product standards, standard operating procedures, norms, standard templates, algorithms and so on. These are mandatory, they must be followed, and have been endorsed by senior technical management.
• Best practices and best designs which lessons and experience have shown are currently the best way to work in a particular setting or context. These are advisory, they should be followed, and they have been endorsed by the community of practice as the current best approach.
• Good practices and good options which lessons from one or two projects have shown to be a successful way to work. These might be examples of successful bids, plans, templates or designs, and they have been endorsed by the community of practice as "good examples" which might be copied in similar circumstances, but which are not yet robust enough to be recognised as "the best". 
• More generic accumulated knowledge about specific tasks, materials, suppliers, customers, legal regimes, concepts etc.

The project/product workstream also creates outputs which act as inputs to the knowledge workstream; these are the knowledge deliverables, the lessons which capture hindsight, and the useful iterms which can be stored as good practices and good options. The link between lessons and best practices is described here, and shows how the two workstreams operate together to gather and deliver knowledge to optimise results.