Friday, 21 October 2016

Why you shouldn't leave your knowledge in project files.

Project files are the worst place to leave your knowledge, if you ever want to see it again. Think of "Raiders of the Lost Ark"


Each project creates two types of work product.
  • First there are the project files themselves - transactional files related to the delivery of the project itself. We can call these files "project collateral".
  • Secondly there is knowledge, created by the project, which needs to be shared for the benefit of future projects.  We can call these files "knowledge collateral".

Knowledge collateral

Examples of knowledge collateral include;
  • Project overview or case history
  • Bid win/loss lessons
  • New processes or new approaches developed by the project which others can use
  • New solutions which have been tested by the project and which failed
  • New knowledge of the client, the market or the product
  • Project delivery lessons

Knowledge collateral needs to be stored in the public domain, where all future projects can access it, and it needs to be organised and tagged by topic, not by project. People coming to look for this collateral will not know which projects it came from; they will be searching for the collateral based on their immediate need; to satisfy questions such as;


  • What do we know about Client X's buying habits?
  • What do we know about building an X in a remote location?
  • What is the current state of knowledge of designing an X product?
  • What projects have we done in the past in the X industry?

So the knowledge collateral has to be a) in the public domain, and b) tagged by client, activity, product and/or industry.

Project collateral

Examples of project collateral include;
  • Client agreement
  • Project meeting minutes
  • Project budget submission
  • Project agreements with subcontractors
  • Project testing plan
  • Project financial return
Project collateral needs to be stored in the project domain, often held under conditions of security, and it needs to be tagged by project and by document type. People coming to look for this collateral will be searching for it within the context of the project, to satisfy questions such as;


  • Did the project meet the customer needs?
  • Was the project well managed?
  • How much did we pay the subcontractor?
  • Why did we make the project decisions that we did?
So the project collateral has to be a) in the project domain, and b) tagged by document type.


The common mistake, and the impact this has

The common mistake is to treat knowledge collateral as if it is project collateral, and to keep it with the project files.

  • Maybe the project has a folder for "lessons learned" where all the lessons go, 
  • Or even worse, the lessons are bundled in the end-of-project report
  • Maybe the project has a folder for "case history"
  • Maybe the new approach developed by the project are described in the "technical" folder,
  • and so on

The first impact of this mistake is that knowledge collateral becomes very difficult to find, scattered (in many organisations) across multiple repositories; SharePoint, file drives, DropBox, legacy applications. It may even be impossible to find the knowledge, where the collateral is held in locked folders.

Maybe a good search engine - semantic enterprise search for example - could draw all this collateral from the many repositories, but this still leaves problem number two.

The second impact of scattering knowledge collateral across many repositories is that it becomes impossible to curate.  Old knowledge cannot be archived in favour of new, old designs cannot be replaced by new, case studies cannot be put in order of prominence.

An analogy

Leaving knowledge collateral in project files, scattered across multiple folders, always reminds me of this scene from Raiders of the Lost Ark shown below.


  • Think of the crate with it's incredibly valuable cargo as being knowledge gathered from a project
  • Think of the huge and cluttered warehouse being the mass of project files stored in your organisation's repositories
  • Think of the "Top Men" as the well-meaning project teams, with never a thought for KM
  • And then ask - will that knowledge ever be seen again?



1 comment:

Myles Burke said...

I am very familiar with the 'Lessons Learned' graveyard, where all the unused lessons learned go...usually most of them!

Blog Archive