Projects provide a great opportunity for teams to develop new skills and to learn what works and what doesn’t in a given context. But to truly institutionalize the knowledge gained by a given team, it needs to be communicated to others so that they might also benefit.
I’ve written a number of articles in the past about the challenges which delivery organizations face with learning lessons from past projects, and how these lessons are disseminated can make a big difference in value realization.
Four of the common approaches for doing this are:
- Capturing learnings within an individual information repository (e.g. wiki, standalone document) for each team
- Capturing learnings within a single, centralized information repository (e.g. knowledge base, database, wiki) for all teams
- Communicating learnings of interest to a specific skill set via Community of Practice meetings
- Embed learnings by updating or creating templates, checklists, standards or policies
The first approach is by far the simplest to implement and is highly effective for the team itself. However, it is usually useless for other teams as they will either lack the awareness or the motivation to locate and review multiple repositories in the hopes of locating a valuable learning. Additionally, when team-specific repositories are used, context regarding lessons might not be captured which will make it quite difficult for other teams to know whether a given lessons might apply to them or not.
The second approach requires more effort on the part of each team to adhere to a common learning format including the context surrounding each learning, and if the updates to the repository go through a quality review process by a different team such as a PMO, this administrative overhead might discourage teams from contributing many lessons. Assuming the centralized repository has good search capabilities and teams are able to subscribe to receive new lessons matching criteria they’ve provided, it can be useful. However, just because you build (and populate) it doesn’t mean, they will come and use it.
The third approach works well for both tacit and implicit knowledge and the live format enables the participants from other teams to ask questions to understand whether a given lesson is applicable or not. However, unless there is some attempt to capture the discussions and make them easily available for practitioners who were unable to attend the session, the knowledge will only be gained by those present.
Finally, embedding learnings has the benefit of eliminating any effort on the part of other teams as they will benefit merely by using the updated versions of the organization assets. However, it may require significant effort on the part of the contributing team and whatever standards governance groups exist within the organization.
As usual, I wanted to understand which approaches were most commonly used in practice. I ran a one week poll in PMI’s LinkedIn Project, Program and Portfolio Management discussion group as well as in the ProjectManagement.com community . Out of the 38 responses received, 45% used Community of Practice meetings as their primary approach, 26% used a separate information repository per team, 16% had a single, centralized repository and only 13% updated organization assets based on team learnings.
I also requested respondents to leave a comment if they used a different approach. While none of those who commented provided a completely new method of sharing learnings, a few indicated that they used a combination of methods. While this does take more effort, it is a highly effective strategy as it allows the optimal approach to be used for the type of lesson and it can mitigate the downsides of picking a single strategy.
When it comes to increasing organizational delivery capability, sharing lessons is truly caring!
(If you liked this article, why not read my book Easy in Theory, Difficult in Practice which contains 100 other lessons on project leadership? It’s available on Amazon.com and on Amazon.ca as well as a number of other online book stores).