Is knowledge a project deliverable?

Knowledge Management is a beautiful concept. And a poor practice.

It comes naturally with a fixed team or an operational setting, thanks to employee networking. Even here conscious knowledge transfer is a rare thing (i.e. knowledge transfer standards, knowledge maps, sound databases, menthoring and the like).

Knowledge Management is particularly useful for temporary organizations. Typically known as projects. Here the organization is often disbanded upon closure. Deliverables remain (hopefully). And so does knowledge. Why not store it?

Why isn’t knowledge treated as a project deliverable by itself?

Transferring knowledge requires standards or even better — habits. Best if the PMO or the Sponsor are keeping score. As a Project Manager, we’d do best to obtain early buy-in from them, agree with the team, and make sure we codify the knowledge according to the PMOs requirements (e.g. information needed, categorization by process groups, standard project phases or governance rules etc.).

Here’s an important thing… We talk about lessons learned at the end of a project usually. Why not make it a regular practice during weekly updates or daily stand-ups (in Scrum we perform a retrospective for every sprint.), i.e. adding the following questions when synchronizing with the team:

  • What went well?
  • What could we improve?
  • What have I learned?

We could then make use of our dust-covered lessons logs (described e.g. in PRINCE2) and make sure we have something to share with the organization upon the project’s completion.