The last chapter of my book "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 stakeholder groupings. This describes an ideal project-level Knowledge Management Framework
Advice for the project manager and project knowledge manager
- 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).
- Right-Scoping meetings are a way of bringing in knowledge during the scoping phase of the project (this is a type of Peer Assist focused on getting the project scope to its correct minimum level).
- Customer interview maximises 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 (looking at a series of options for the project, using the knowledge of others).
- If there is no existing knowledge, some level of business-driven action learning (or other innovation process) may be needed.
- Peer review is more of an assurance process than a knowledge management process.
- Technical limit is an excellent process for accessing the knowledge of the execution team prior to execution
- 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 (as part of a Project Learning System).
- AARs can be built into project review meetings.
- Communities of practice are a crucial resource for learning while doing.
- The project manager will need to appoint a knowledge manager for the project.
- Knowledge engineers and/or learning historians may also be needed in major projects (these are a specific type of knowledge manager dedicated to recording the details of the project, and the detailed lessons).
- 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, unique, pioneering or dispersed project, a Learning History may be needed.
- Knowledge management needs to be linked with performance management, risk management, and SSHE management
- (This one was not in the book, but we have learned, since its publication, that) All of the above project-level KM elements need to be documented in a Knowledge Management Plan, owned and monitored by the project Knowledge Manager.
Advice for the Communities of Practice and Knowledge Owners
- Ownership needs to be established for the management of knowledge between the projects, and for the derivation of best practices and standards (this is what we call the "Knowledge Owner" role, aka Practice Owner, SME, or technical Authority)
- A Lesson Learning System will be needed for the projects (including Lessons Management software and an individual or team to manage this).
- Best practices, knowledge assets and corporate standards should be constructed for key areas of knowledge (potentially hosted on wikis).
- Subject matter experts (Knowledge Owners) are needed for these key knowledge areas.
- Transfer of tacit knowledge can be facilitated through staff transfer and through discussions within communities of practice.
- A Yellow Pages (Expertise locator) system is also a useful tool.
Advice for Management
- The organisation needs a knowledge management framework.
- Knowledge management standards (for example a KM policy) need to be developed.
- Knowledge management plans should be introduced at project level.
- Some sort of audit or assessment of Knowledge management capability is needed.
- A small resource is needed for monitoring, support, and coordination of Knowledge Management (including performance measurement and the provision of training).