Tuesday 26 November 2019

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. 

No comments:

Blog Archive