The top 7 types of plan you may need as part of KM in the new normal

 Introducing KM means also introducing plans for KM, at different levels in the organisation. Here are a few of the plans you may need, depending on your context. 

Compo, CC BY-SA 3.0, via Wikimedia Commons

Any management discipline involves plans, and KM is no different. You could not have project management without project plans, you could not have financial management without financial planning, and you could not have HR management without manpower planning. KM is no different.

This is particularly true in the new normal, when much work is still being done remotely. Studies such as the recent Microsoft study show that hybrid working can deliver excellent communication within the team, but that cross-team collaboration such as sharing of lessons and knowledge can suffer if you are not careful. 

Those ad-hoc chance unplanned conversations in the corridor, the canteen or around the water cooler, where crucial knowledge may be shared from one team to another, just will not happen in a hybrid world. Instead, these conversations much be planned if they are to happen at all. Now is therefore the time to introduce a planned element to KM, if you have not done it already. 

Look at the plans below, and decide which of these may be relevant to you.

The KM implementation/improvement plan

Almost certainly, if you have KM in place or are actively implementing it now, you will have a plan for KM itself. You will have assessed the current state of the KM management framework within your organisation, and you will have identified gaps, areas for improvement, and areas for further deployment. Then you will have a plan for filling the gaps and/or delivering the improvements and uptake. This is your basic KM implementation/improvement plan, owned by the KM team and funded by the KM sponsor. 

Part of this plan will almost certainly be a cultural improvement plan. KM involves culture change, so you will have a good idea of the culture, attitudes and behaviours you would like to promote, you will have analysed the current culture and the drivers behind it, and you will have a plan for removing the negative drivers and promoting (through stories, recognition and other means) the culture you need to sustain KM. 

A subset of the implementation plan is the plan for a KM pilot project. KM pilots are projects focused on applying a simple form of KM to a business issue, as a component of agile implementation. These pilot projects need to be scoped carefully, and need a charter, a terms of reference, and a plan. The plan will include some or all of the following:

• Objectives of the pilot
• Key stakeholders
• Metrics (to measure success)
• Scope
• Approach
• KM framework to be applied
• Activities and milestones
• Risks and opportunities.

Knowledge domain plans

Each individual knowledge domain (sales knowledge, for example, or systems engineering knowledge, or product manufacturing knowledge) may need it's own plan. You should have clear owners for each knowledge domains, and also ideally have performed some sort of domain audit which allows you to see how well that knowledge is managed at the moment, and highlights the risks and opportunities. 

• Perhaps the knowledge is held by only a few people at risk of loss, and these people need to be high-graded for knowledge retention and transfer. 
• Perhaps the knowledge is mostly tacit, and some of it needs to be documented for the sake of a wider user community. 
• Maybe the user community is scattered (potentially many of them working from home) and a community of practice needs to be set up to allow people to ask questions of each other. 
• Maybe there are gaps in your in-house knowledge, and key components of that knowledge need to be developed or acquired. 
• Maybe activity on the knowledge domain is ceasing, and the knowledge needs to be archived in case is needs to be resurrected in the future. 

The domain audit should identify issues such as these, and the knowledge domain owner should therefore create a knowledge domain plan, with actions to cover the risks and seize the opportunities. This should be closely allied to competency and skills planning, which will make sure that enough skilled people are on-board in order to apply the knowledge.

Components of the knowledge domain plan may be delegated, in the form of the next three types of plan.

Knowledge development plans

Imagine the knowledge domain owner recognises a knowledge gap in the organisation. They may say "we need to know more about technology X, or customer Y". Filling the gap can be delegated downwards to the relevant person; maybe to the R&D department, or maybe to the relevant customer relationship manager. They then can then put together their own knowledge development plan. (I have called these "knowledge development plans" rather than "knowledge acquisition plans" as the latter are a technical term used in building and populating expert systems).

Knowledge retention and transfer/archival plans

The knowledge domain plan will have identified areas where knowledge needs to be retained, either for immediate use or for potential future use. This may be related either to the risk of loss of key experts due to retirement or other factors, or to closure of a major program. Some sort of knowledge retention plan will be needed. This can either be at an individual level, where planned knowledge capture and/or transfer activities are timetabled over the last year or so of a retirees life (see for example the knowledge retention plan template provided by the International Atomic Energy Authority), or it may be an end project exercise (see the NASA Ares report for an example, or the example on Nancy Dixon's blog on the Constellation knowledge capture planning).

Community of Practice plans

Elements of knowledge domain plans can also be delegated down to individual communities of practice, or communities can develop their own plans. For example the World Bank Group "Gardeners guide to communities of practice" recommends developing Connectivity plans and action plans for communities of practice. Given that communities of practice are as much bottom-up structures as they are top-down, member involvement in these plans will be essential. 

Community plans may cover the start-up and development of the community, or may (in fully operational communities) determine particular areas of focus for community members, and/or set the timetable for community events. If the community is financed by a sponsor, the sponsor will almost certainly want to see a plan to describe how, and on what the money will be spent.

Departmental or regional KM plans

Individual departments may need to develop their KM plan. Where a department covers a single knowledge domain (for example the sales department covering the sales knowledge domain, the engineering department covering the engineering knowledge domain) these plans will be the same as the corresponding knowledge domain plans. In other cases, they cover knowledge related to the operations of the department. This knowledge may be identified during the operational planning and reporting cycle, or through other means. For example, the regional departments in the Asian Development Bank develop "Country Knowledge plans" on a regular basis to coordinate their knowledge support to the developing countries. 

Project KM plans

Finally, and this is a topic we have covered many times, each project may need a project KM plan, particularly the big, pioneering and important project. Contact us if you want a copy of a template suitable for developing a project KM plan. These plans generally list the project knowledge deliverables, the key project knowledge inputs, and the KM activities to be carried out during the life of the project.

ISO 30401, the management systems standard for KM, requires that KM accountabilities be cascaded within the organisation, KM objectives set and KM plans created at all relevant levels. This is because ISO recognises that planning is a crucial component of good management discipline. So to comply with the standard, you will need to decide which of the above plans you need, and put them in place.

KM can no longer be left to chance unplanned encounters. You need to get serious about KM plans at multiple levels.

4 more types of KM plan

 I wrote a blog post yesterday on 4 types of KM plan, and (too late) realised that there were more than 4. Here are another four types. 

Yesterday's blog post mentioned the following 4 types of plan, which are all at a fairly high level of granularity. These are:

• The organisational KM strategy
• The organisational KM implementation plan
• A KM plan for a project
• A KM plan for an operational department

If we drop down another level of granularity, we can see four more levels of plan:

• A KM pilot project plan
• A CoP "launch and grow" plan
• A knowledge domain plan
• A knowledge retention and transfer plan for an expert

 More detail of these additional four types of plan can be found below.

KM Pilot Project plan

Your KM implementation plan (one of the plans described yesterday), will almost certainly involve a series of KM pilot projects - projects focused on applying a simple form of KM to a business issue. These pilot projects need to be scoped carefully, and need a charter, a terms of reference, and a plan. The plan will include some or all of the following:

• Objectives of the pilot
• Key stakeholders
• Metrics (to measure success)
• Scope
• Approach
• KM framework to be applied
• Activities and milestones
• Risks and opportunities.

Community of practice development plan

Communities of practice benefit from a development plan, which can be helped considerably by tracking community maturity. Depending on the stage of the community, the plan may include some or all of the activities below:

• Appoint sponsor and leader 
• Identify core participants 
• Hold Launch meeting 
• Define charter 
• Define key knowledge topics 
• Identify experts and adopters
• Expand community membership 
• Start Community site  
• Hold community meeting 
• Transfer Quick Win practice
• Develop practice knowledge base 
• Track metrics
• Report progress to sponsor
• Run community maturity metrics
• Update CoP plan

Knowledge domain plan

The departmental KM plan, mentioned yesterday, may identify a number of knowledge domains that need to be better managed. The experts accountable for these domains will need to create their own "domain refresh" plan. This may include activities such as:

• Identify support/facilitation requirements 
• Capture lessons
• Exchange best practice
• Interview experts
• Create/update domain resources

Expert KRT plan

Many organisations develop a knowledge retention and transfer (KRT) strategy to deal with the risk of knowledge loss from departing experts. Once an expert has been identified as representing a risk of knowledge loss (e.g. holding critical knowledge in their head, and due to retire soon), then the KM team work with the expert to develop a KRT plan. This involves listing the topics which the expert knows about, deciding the best way to capture and transfer this knowledge, and then creating an action plan.

Each of the plans mentioned within this blog post is a subset of one of the higher level plans described yesterday, as shown in the graphic at the head of this post. Together, the plans represent a structured method of KM implementation.

4 types of KM plan

Knowledge Management plans exist at many scales. Here are 4 of them.

KM planning session

Implementing KM is a project, and a project needs a plan. However KM can be implemented at many scales, and many variants of KM plan may be needed. In this post we describe 4 of them:

• The organisational KM strategy
• The organisational KM implementation plan
• A KM plan for a project
• A KM plan for an operational department

KM strategy 

A KM strategy is the framework document that sets the context, direction and principles for KM implementation. The strategy ensures that the Knowledge Management implementation proceeds in a way that is aligned with the current business approaches, is targeted on the right problems, and is coordinated with other existing change initiatives.

One of the key components in the strategy is an analysis of “What Knowledge do we most need to Manage? These strategic knowledge areas are identified through discussion at the highest level (CEO if possible).

One of our clients had an excellent discussion with their senior management, while preparing their KM strategy, on this topic of key knowledge, and were given a strong steer to “focus on driving growth in new consumer markets, through knowledge sharing networks”. That decision set their KM strategy, and formed a framework for the next 4 years of KM activity.

KM implementation plan 

Once you have your strategy in place, you can start on your implementation planning. This is where you plan your activities and resources, in order to develop and embed an effective KM “system”. The plan will be based on

• the Knowledge Management strategy 
• an assessment and benchmarking of your current state of KM 
• an outline “desired end state” (KM framework) 
• a staged, change management approach 
• a full analysis of the risks to Knowledge Management delivery 

The KM implementation plan maps out the steps from the current state to the end state, guided by the strategy and the assessment. It defines your timeline, and the resource needs.

Project KM plan 

The project-level Knowledge Management plan is a device that allows KM to be fully embedded into project controls, at the same level of rigour as risk management, or document management. It allows the assignment of accountabilities to individual project team members, and allows these accountabilities to be monitored and reviewed. Some organisations also address.

 A KM plan has three main components.

1. A Knowledge Register, which defines the key areas of knowledge needed by the project (“key knowledge inputs”), and the assigned actions to make sure this knowledge is accessed. It also defines the key areas of knowledge which the project will be learning about, and which they need to share with the rest of the organisation (“knowledge outputs”), and the actions to make sure this sharing happens. 
2. A KM Protocol, which defines the system by which knowledge will be managed in the project. It defines the roles and accountabilities, the technologies (such as lessons databases) which will be used, and the processes which will be applied and when they will be applied as part of the project timeline. 
3. An implementation plan for the project, to make sure the protocol is ready to use. This will require training of staff in the tools and technologies, induction of new staff, registration of staff onto the relevant communities of practice, installation of technology onto people’s desktops, and so on. 

The plan is created at a KM Planning work-shop, early in the project, held as part of the set-up activities; about the same time the team are developing their risk management plan, their document management plan, and other front-end planning activities.

Operational KM plans 

Just as a project KM plan is built into the planning and review framework of a project, an Operational KM plan needs to be built into the operational planning and review framework. This should be done as follows;

1. During the annual planning cycle, the operation will agree its annual objectives and budget. The next step will be to create the annual KM plan. 
2. The KM plan will contain the same components as a project KM, though the key topics in the knowledge register will be set by the new operational objectives. The operational management team will get together for a KM planning workshop, and start with the question – “What do we need to know (or to learn) in order to deliver our operational objectives”?
3.  The main deadline for the operation to capture new knowledge for other operations will be at the end of the year, when they review performance against objectives, and ask “What were the causes of any deviation from planned performance (either a positive or a negative deviation), and what have we learned from these to improve next year’s performance”? They will also review the application of the KM plan through the year.
4. The operational department may also assess the level of management of key operational topics or knowledge domains, for example through a KM audit or Scan. If any knowledge domain needs to be better managed (better documented for example, or updated, or a community of practice initiated), or is at risk of loss through potential departure of key experts, then the KM plan will define the remedial actions that need to be taken.

Contact Knoco for help with KM planning at all scales

KM plans at NASA

This blog has often argued for Knowledge Management Plans as part of a KM Framework. Here is NASA's take on the topic.

You can find NASA's introduction to KM plans here.

Screengrab from NASA Appel KM toolbox site

This document makes the following points:

1. The plan is a requirement for all projects and programs at NASA, under the NASA Procedural Requirements and NASA Policy Directives.
2. The KM plan is part of the project or program plan, and there is a place-holder on the standard NASA project plan template for KM
3. The project manager crafts the KM plan in cooperation with KM support.
4.  The Knowledge Management Plan should
   •  Bring value to the project by driving learning from other projects
   • Bring value to subsequent projects through capturing and sharing knowledge and lessons
   • Leverage available resources
   • Be realistic in terms of cost and schedule implications; and 
   • Be flexible enough to adjust to the evolving needs of the project.
5. The KM plan has three components:
   • Defining how the project will "Learn before" through accessing the knowledge of others (for example through Peer Assist, through reviewing collections of lessons, or through use of processes and procedures within which lessons have been embedded)
   • Defining how the project will "Learn During" its activity (for example through use of After Action Reviews, creating a Lessons Log, or interfacing with key communities of practice)
   • Defining how the project will "Learn after" the project is over (for the example through the use of Retrospects to identify and document lessons, and Knowledge handover meetings to share these with others)/
6.   Special credit for KM Plan tool content goes to NASA Goddard Space Flight Center (GSFC) Center Office of the Chief Knowledge Office (OCKO) and Barbara Fillip, former Knowledge Lead, Flight Projects Directorate.

Try KM plans in your own organisation, wherever you conduct large projects that need to learn from, and share knowledge with, each other. 

Order a KM plan template from our download page

Reduce, re-use, recycle knowledge

We are all into recycling. Recycling conserves sparse resources. But what about intellectual recycling? Maybe this is what KM is all about?

Recycle Logo From Recycling Bin
Originally uploaded by chrissatchwell

Let’s follow this train of thought for a bit. Let’s think of a busy team with very constrained resources (people, time, energy, budget). Let’s suggest they apply some green principles to their knowledge work. Let’s suggest they consider Reduce, Reuse, Recycle.

Reduce. Maybe they don’t need to do this knowledge work at all. Maybe they can actually reduce the amount of work they need to do. There are various processes available, such as Rightscoping, Technical Limit, or customer interrogation, designed to reduce unnecessary work. This could save a lot of their resources

Re-use. If they do need to do the work, perhaps they can reuse solutions which already exist. Perhaps they can reuse something off-the-peg, which has been applied elsewhere in the business. This can save almost as much intellectual resource as reducing the work.

Recycle. If there is no solution they can use off-the-peg, perhaps they can recycle existing ideas. Perhaps they can take what has already been done, and adapt it for their own situation; re-craft it for their own context, and improve it to fit their need. This requires resource, but nowhere near as much as creating the solution from scratch. Peer Assist could be a powerful tool here.

If they can’t reduce, can’t reuse and can’t recycle, then they have to create or invent their own solution. This is the most costly approach.

I can imagine a knowledge planning meeting, where a team divides their project into tasks, and asks, for each task, can we reduce? Can we reuse? Can we recycle? Or do we need to create and invent? This could be an excellent format for ensuring that innovation is focused only on those tasks and activities where innovation is needed. Think of the intellectual resources that could be conserved by such a recycling approach!!

Knowledge inputs and knowledge outputs in project activity.

Knowledge is both and input to, and an output from, project activity. This gives us a handle by which that knowledge can be managed. 

Projects consume and create resources. They consume money, time and equipment, and they create products and income streams. They also consume (or, rather, apply) and create knowledge. 

Each project needs an input of knowledge. This is knowledge that the team will need in order to deliver the project; knowledge of the practices to be used, the technology to be applied, the client and how they operate, and other insights and guidance.

Much of that knowledge enters the project in the heads of the project team, but there can be other knowledge inputs as well, particularly if the project team are facing factors which are unknown to them. Maybe they need to hold a peer assist with another project, maybe they need to look in the knowledge base for useful guidance, or maybe they have to ask the relevant communities of practice for help or advice.  All of these are mechanisms for knowledge input.

A project team can map out the required knowledge inputs in a knowledge gap analysis meeting, for example, where the team will identify the crucial topics where knowledge is needed. It can also then be useful to plot these topics on the Boston Square above, based on the importance of the topic to the project outcome and the availability of knowledge on the topic.  This gives you some idea of the actions to take for each of the topics. 

Projects also generate knowledge. Not only will the project create monetary value, it can also create knowledge value, so long as that knowledge is captured. This is particularly true when the project is covering a new area, where a considerable amount of new knowledge could be created for the organisation. Knowledge outputs may include guidance, procedures, lessons learned, templates, checksheets and other artefacts that might be of use to future projects, and which capture .

You therefore need to discuss with the project team not only what knowledge the project needs, but what knowledge the project will create. You may want to rank these knowledge outputs in order of importance for the rest of the organisation, although the project team may not be the best placed people to comment on this.

The conversation about knowledge inputs and outputs, and any actions that should be assigned to gather the inputs and plan to create the outputs, should be recorded in a project Knowledge Management plan which will act as the governance document for KM in the project. 

What's the point of project KM plans?

One of the push-backs we often get when we introduce KM plans is “why do we need a plan? Any good engineer will naturally do all the learning they need; surely a KM plan or learning plan is just added work for no added value?”

Post-its, by adactio, on Flickr

My usual reply is to draw the analogy with a risk management plan. Any good engineer will naturally be aware of risk, and will put in place mitigations against all the risks he or she can think of, but there is still value in the whole team sitting down and discussing the risks to the project, and developing a risk management plan to address those risks. By adding structure, and by involving the whole team, the project comes out with a better approach to risk.

The same is true for knowledge. There is value in the whole team sitting down and discussing the knowledge needed by the project, and developing a plan to acquire that knowledge. By adding structure, and by involving the whole team, the project comes out with a better approach to learning.

In addition, a KM plan is documented evidence that the project has addressed the issue of knowledge, just as a risk management plan or quality management plan shows that they have addressed the issues of risk and quality.

The KM plan is therefore as much a governance document as it is a planning document. 

How to conduct a Knowledge Gap Analysis

A knowledge gap analysis is the product equivalent of the Knowledge Management Plan used by process-based organisations.  It can be used to map out the unknown areas related to a product already under development, or soon to be developed.

What a whiteboard  in a gap analysis session may look like

I blogged on Monday about the Bombardier KM Framework, and one of their process elements is the Knowledge Gap Analysis. It struck me I had never blogged about this particular tool.

A Knowledge gap analysis session runs like this:

Hold a workshop involving the design team, the chief engineer(s) and representatives from marketing, sales and support.

Put a schematic of the product up on the whiteboard. Break it down into its main  subcomponents or modules (you could do this as a schematic, or as a concept map).

Also write up the known operating requirements or functional requirements, and the known market forces (competitors, component suppliers etc).

Ask the participants to brainstorm on a series of post it notes, remaining open questions about the whole product, the modules, subcomponents, market and/or requirements. As them to express these as questions, and as sentences, and stick them on the whiteboard next to the part of the product they refer to.

Challenge the team to think deeply - maybe there are some knowledge gaps we have not thought of before - the previously unknown unknowns. 

Once you have plenty of post-it notes, you assign individuals or groups to work on question areas. A couple of people might work on the questions on the impeller pump, someone on bearings, someone on the competitive landscape and so on.

Give them 30 minutes to decide the best way(s) to answer the questions on the relevant post-it notes. 

Then reconvene the whole group, and develop an action list to close the knowledge gaps. Ask for additional suggestions for actions, that the individuals or groups may have overlooked. Prioritise the actions, and assign them to individuals.

Finally discuss with the team how and when they will capture their own knowledge as the project progresses, and who has what accountability for KM within the project.

You should be able to complete this workshop in 4 hours to a day, depending on the product complexity. 

Does knowledge look different, looking back to looking forward?

I am recently returned from a busy few days with a manufacturing client, which has given me some food for thought.

We conducted a number of KM activities, including a Retrospect to identify and capture lessons from the last version of the product, and some knowledge gap analysis (KM planning) of future work. And it was only afterwards that I realised that all the backward looking conversation had been about Process, and all the forward looking conversation had been about Product.

Any manufacturing client looks at knowledge of product and of process - the ternary diagram from our 2014 KM Survey shows Manufacturing as half-way up the left hand side of the picture, midway between the Process and Product corners.

However the conversations we have about these two knowledge focus areas are different.

Looking back, the standard processes of Retrospect and After Action Review tend to identify the successes and failures in Process - the processes of design, manufacture, testing, technical decision making, and so on. If we want to review a Product, we need to specifically address this, maybe using something like the A3 process, or the Knowledge Briefs. 

Looking forward, the Knowledge Gap Analysis (part of the KM Planning methodology) tends to look at gaps in Product knowledge, rather than gaps in Process knowledge, unless we were deliberately to focus the conversation on process.

Both Knowledge Management methodologies come up with a list of improvement actions, and the combined list covers Product and Process, so all learning areas were eventually covered, but the reflection on this experience leaves me with a clear lesson.

When an organisation needs knowledge of more than one type (eg knowledge of Product and Process, or Product and Customer) we need to deliberately incorporate discussion of both of these knowledge types in our KM processes.

If we don't, then our knowledge focus may seem different depending on the KM processes we use, either looking backwards in a Retrospect, or forwards in a KM plan.

Types of KM plans

I blogged a few days ago about project KM plans, but these are not the only type of plan you will need to create as part of your Knowledge Management implementation. Here are the four main types.

Planning session by WorldIslandInfo on Flickr

KM strategy 

A KM strategy is the framework document that sets the context, direction and principles for KM implementation. The strategy ensures that the Knowledge Management implementation proceeds in a way that is aligned with the current business approaches, is targeted on the right problems, and is coordinated with other existing change initiatives.

One of the key components in the strategy is an analysis of “What Knowledge do we most need to Manage? These strategic knowledge areas are identified through discussion at the highest level (CEO if possible).

One of our clients had an excellent discussion with their senior management, while preparing their KM strategy, on this topic of key knowledge, and were given a strong steer to “focus on driving growth in new consumer markets, through knowledge sharing networks”. That decision set their KM strategy, and formed a framework for the next 4 years of KM activity.

KM implementation plan 

Once you have your strategy in place, you can start on your implementation planning. This is where you plan your activities and resources, in order to develop and embed an effective KM “system”. The plan will be based on

• the Knowledge Management strategy 
• an assessment andbenchmarking of your current state of KM 
• an outline “desired end state” (KM framework) 
• a staged, change management approach 
• a full analysis of the risks to Knowledge Management delivery 

The KM implementation plan maps out the steps from the current state to the end state, guided by the strategy and the assessment. It defines your timeline, and the resource needs.

Project KM plan 

The project-level Knowledge Management plan is a device that allows KM to be fully embedded into project controls, at the same level of rigour as risk management, or document management. It allows the assignment of accountabilities to individual project team members, and allows these accountabilities to be monitored and reviewed. Some organisations also address.

 A KM plan has three main components.

1. A Knowledge Register, which defines the key areas of knowledge needed by the project (“key knowledge inputs”), and the assigned actions to make sure this knowledge is accessed. It also defines the key areas of knowledge which the project will be learning about, and which they need to share with the rest of the organisation (“knowledge outputs”), and the actions to make sure this sharing happens. 
2. A KM Protocol, which defines the system by which knowledge will be managed in the project. It defines the roles and accountabilities, the technologies (such as lessons databases) which will be used, and the processes which will be applied and when they will be applied as part of the project timeline. 
3. An implementation plan for the project, to make sure the protocol is ready to use. This will require training of staff in the tools and technologies, induction of new staff, registration of staff onto the relevant communities of practice, installation of technology onto people’s desktops, and so on. 

The plan is created at a KM Planning work-shop, early in the project, held as part of the set-up activities; about the same time the team are developing their risk management plan, their document management plan, and other front-end planning activities.

Operational KM plans 

Just as a project KM plan is built into the planning and review framework of a project, an Operational KM plan needs to be built into the operational planning and review framework. This should be done as follows;

1. During the annual planning cycle, the operation will agree its annual objectives and budget. The next step will be to create the annual KM plan. 
2. The KM plan will contain the same components as a project KM, though the key topics in the knowledge register will be set by the new operational objectives. The operational management team will get together for a KM planning workshop, and start with the question – “What do we need to know (or to learn) in order to deliver our operational objectives”?
3.  The main deadline for the operation to capture new knowledge for other operations will be at the end of the year, when they review performance against objectives, and ask “What were the causes of any deviation from planned performance (either a positive or a negative deviation), and what have we learned from these to improve next year’s performance”? They will also review the application of the KM plan through the year.

Contact Knoco for help with KM planning at all scales

Knowledge Management Plans

One of the more exciting KM developments in the last few years is the introduction of project-level Knowledge Management Plans. These documents may well provide the ‘missing link’ between an organisation’s desire to learn and improve, and the need of each individual employee to know ‘what I need to do’. 

Project team, KM planning session

An addition to high level strategic plans, which often identify and address critical organisational knowledge, a KM plan for a project provides a tactical focus on the critical knowledge for the project itself.

These plans provide a way both to focus the KM effort for the project, and also to make clear the actions needed to deliver the value inherent in that knowledge. We have helped apply KM plans in the mining, construction and petroleum sectors, and are convinced of the value they can bring.

Those of you familiar with risk management processes will understand some of the principles involved. Before a project or major cycle of work, the team members meet in a KM Planning Workshop and define the core knowledge they need to acquire in order to deliver their aspirational performance. They discuss where this knowledge may be sourced from, the processes that need to be put into place to acquire it, the actions which need to be taken, identify accountable individuals, and the mechanisms by which any new knowledge will be captured and shared with the rest of the organisation.

By creating a KM plan and keeping it live as work progresses, the team not only ensures that the right people take the right actions to get the right knowledge at the right time, but also provides an audit trail so that senior management can be confident that their expectations for KM are being met, and that their investment in KM is worthwhile.  This auditable demonstration of KM will help you prepare for audits against the KM component of ISO 9001.

A KM plan also gives an external demonstration of KM, and at least one major procurement organisation recently used the ‘inclusion and description of the vendor’s KM plan’ as a key differentiator between bids.

The stages of project learning

---

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 a progression of learning in a project, and is particularly applicable to product development projects or R&D projects.

• 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.
• In step 2, the project becomes clear what is already known by others, which the project team doesn't know about yet. 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, 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).
• In step 3, the project steps into the unknown. They define what they need to learn about (the Known Unknowns), and put in place processes to gain that knowledge - R&D, Market Research, Business Driven Action Learning.  Through these processes, they fill in the Known Unknowns  as they become known.
• 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.

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 this should be covered by the project Knowledge Management Plan. 

The risk of hanging on to knowledge - the Wright brothers and Wing Warping

This is a story about the Winners' Curse - the observation that Leaders make poor Learners, often because they are unwilling to let go of the knowledge that made them leaders in the first place. The story is taken from the excellent book Profiles in Folly.

The Wright brothers are not a couple that you would expect to encounter in a book about Folly. Their development of the first powered flight reads like a manual in Knowledge Management. They created a Knowledge Management plan at the start of their "project", realising that there were three key areas of knowledge which they needed to develop before they could expect success - how to generate lift, how to power the aircraft, and how to control the flight.

They conscientiously did their Learning Before Doing - Wilbur's letter to the Smithsonian reads like the letter of a Knowledge Manager

“I am an enthusiast, but not a crank in the sense that I have some pet theories as to the proper construction of a flying machine. I wish to avail myself of all that is already known and then if possible add my mite to help on the future worker who will attain final success.” Wilbur Wright

They did meticulous research into lift, building the worlds first wind tunnel in order to devise the optimum wing profile, thereby inventing the science of aeronautics. They transferred that research into the design of the power system and the propeller, realising that the propeller was just a wing, oriented sideways. Finally they addressed the "Breakthrough concept", solving the problem of controlled flight through a solution known as "Wing Warping", which they tested extensively on unpowered gliders. They had addressed the three key areas of knowledge, and their maiden flight was almost a formality (as Wilbur wrote at the time, "“There is now no question of final success.”).

The rest is history. The first powered flight, the first patents on a viable flying machine, and a start at pole position in the aviation industry. Fame and fortune looked assured.

So where did it go wrong?

One key to the Wright brothers' initial success, and the one they were quickest to patent, had been Wing Warping. However steering an aeroplane by Wing Warping was very difficult to learn and very tricky to master, and it was far too easy to lose control. Already a better means of control was being developed by other inventors - the use of wing ailerons - hinged flaps at the trailing edge of the wings. According to the author of "Profiles in Folly" -

"The United States entered World War 1 with woefully obsolete aircraft. The Wrights stubbornly refused to abandon the wing-warping system, even after it repeatedly proved fatal. On September 17, 1908, Lt Thomas Selfridge became the first military pilot to die in a crash ..... more than 20 other aviators were killed in crashes almost certainly caused by a loss of control linked to wing warping.......Yet even after the Wrights clung to wing warping, even after they were manufacturing aircraft full-time through their own company, they stubbornly defended in court their patent right to the aileron system, discouraging others from using it for fear of suffering lawsuit. 

"The Wrights, who had made the greatest breakthrough in the development of aviation, then hobbled that development before finally abandoning the field altogether".

The Wright brothers suffered from winners curse. Having won the race, they clung to the knowledge they had developed, even as it became obsolete as better solutions were developed, and eventually sold their company and retired. First learner advantage only remains an advantage, if the learner continues to learn. If the leader doesn't continue to learn, they don't continue to lead.

(In a postscript, the author of Profiles in Folly points out that Wing Warping has returned as a viable technology in the 21st century (see for example the Active Aeroelastic Wing), but only because it relies on multiple servo motors controlled by advanced microprocessors, rather than Orville and Wilbur's pulleys and string.)

The output of the knowledge work stream

---

I blogged a while ago about the two parallel work streams in product development - the product work stream and the knowledge work stream.

A question came up last week - who defines the output for the knowledge work stream? The output from the product work stream is defined by the customer for the product - there are product specifications which meet the client requirements or the requirements of the market. But who defines the specs for the knowledge work stream?

The answer, of course, is simple, the knowledge customer (or the knowledge market) defines the specifications for the output from the knowledge work stream.

For a product going into service, the knowledge customers will be

• The manufacturing staff, who need to know how to build the thing
• The sales, service and support staff, who need to know the details of the product in order to sell it, to support the customers, and to service the product. They need to know the selling points, the functionality, and the as-built spec.
• Anyone in future who will make modifications to the product, who need to know the design rationale;  the choices made in design, why they were made, what the alternative choices were, and why they were rejected, what the core "don't mess with this" items are, and what the "options to improve" components are.
• Managers and teams of similar development projects, who want to know how to repeat the successes of this project, and avoid the pitfalls
• Owners of corporate process, who need to know if any modifications to those processes are needed
• Technical authorities and technical communities of practice, who need to know of any technological advances developed along the way, and what these may mean for future products.

You find the needs of these customers by asking them, or (if they are not yet identified) by predicting their needs as a sort of market research. The knowledge workstream, and the delivery of these results, are managed through the Knowledge Management Plan.

Knowledge management and risk management

---

Here's a very interesting blog post

It got me thinking about how KM starts to address the known and unknown areas

Hence the picture here, which shows how knowledge can grow through a project, as a result of Knowledge Management activity. 

In column one, a project maps out the important knowledge needed for the safe and effective delivery of the project objectives. There are known knowns, known unknowns etc etc, and we have shown these as equal in extent.

The first area they address is the known unknowns – the things they know they don’t know, and know that they need to know. Through Knowledge Management Planning they map these out, and put a set of learning activities in place to fill the knowledge gap. As a result, in column two, they eliminate this area, and increase the known knowns by “learning before doing”.

Then during the project they will encounter some of the unknown unknowns, which become apparent as nasty surprises. The fix these through learning from their own experience, or pulling in extra knowledge from elsewhere.  As a result, in column three, they reduce this area, and increase the known knowns by “learning during”.

At the end of the project they do some reflection, go through a facilitated learning exercise, and may discuss their learning with other projects. Through discussion and dialogue, they become aware of some of the other things they have learned. As a result, in column three, they reduce the area of unknown knowns, and increase the known knowns by “learning after”.

KM as a project resource

---

Wikipedia describes project management as follows

Project management is the discipline of planning, organizing, securing, and managing resources to achieve specific goals. 

What it does not do, is define what those resources are.

Typically, people think of project resources are being Human resources and Capital resources, such as

1. Money 
2. People
3. Time
4. Technology
5. Space

But lets add number 6 - Knowledge - an Intellectual resource.

I think knowledge is often ignored as a project resource, as it is assumed that the people hired onto the project team will bring knowledge with them, but those of us who work with KM know that knowledge can be treated independent of the people. Knowledge Management and HR management are not the same. 

That's why a project needs to treat knowledge as a resource, and manage it as such, through the use of a project Knowledge Management plan, and through the application of processes such as Peer Assist and After Action review. 

(for more detail of KM in projects, see here)

KM plans on the increase

---

Recently we have found increasing interest from clients for KM Plans and KM Planning workshops. 

 KM plans are a way of focusing a project team on the KM activities associated with their project. This concept has been taken up enthusiastically by a number of our clients, and the Planning Workshops have evolved as a means of creating the plan. These workshops last half a day to a day, and involve the whole team in a discussion of the critical knowledge needed by the project or the business, and of the actions that need to be taken to ensure this knowledge is managed. The process is a simple one, and the main benefit of these workshops really is to provide an opportunity and a structure for a team conversation about learning, in the very early stages of the activity, when learning is of most value. As one of our clients reported recently

“Various small projects and studies have starting up and every one is undergoing a K Planning workshop to create a Knowledge Plan. Of course, once you have done this, then it becomes easier to get Peer Assists done to. It helps to link in various KM activities of course, and we are starting to get a sense that the K Plan is being seen as something normal and routine”

I think what appeals to people about KM plans is that they are new, and they help you think through your project "through a knowledge lens". Project folk are used to planning, and knowledge-focused planning is a new way of looking at things, that often creates new insights (even if it is "Good grief, we have a lot to learn"!)

Why KM plans?

---

I spent Friday in the Midlands with a big engineering multinational, looking at the topic of project knowledge management plans.

One of the push-backs we often get when we introduce KM plans is “why do we need a plan? Any good engineer will naturally do all the learning they need; surely a KM plan or learning plan is just added work for no added value?”

My usual reply is to draw the analogy with a risk management plan. Any good engineer will naturally be aware of risk, and will put in place mitigations against all the risks he or she can think of, but there is still value in the whole team sitting down and discussing the risks to the project, and developing a risk management plan to address those risks. By adding structure, and by involving the whole team, the project comes out with a better approach to risk.

The same is true for knowledge. There is value in the whole team sitting down and discussing the knowledge needed by the project, and developing a plan to acquire that knowledge. By adding structure, and by involving the whole team, the project comes out with a better approach to learning.