Lessons. Learned?
Project managers talk a good talk when it comes to documenting lessons learned. PMI dedicates an entire chapter of its project management body of knowledge to project closeout, which on the surface seems fairly straightforward, right? As opposed to the hustle and bustle of project startup, project closeout seems like a breeze. Your deliverables are done; ergo, the project is over. I've learned over the years to be suspicious of those lulls because, before you know it, the action tends to rev up all over again. This is where the lessons learned part comes in. We PMs can take the time to pat ourselves on the back for all the good work we've done and theoretically gather suggestions on how to be even more awesome the next time around.
The problem is that these lessons learned never seem to be collected on an institutional level. They largely exist in the project or program manager's head, lazily gathered as an afterthought agenda item on a closeout meeting that was light on content anyway. How do we get better at learning our lessons?
Formalize the data collection process. Hold a dedicated "lessons learned" brainstorming session before the project team disperses. Agile PM calls these retrospectives. They are supposed to help the team recap what went before to get a better handle on what is to come. These are a great start for gathering feedback, but some team members may not feel comfortable providing feedback in a group setting. Supplement with a quick post-project survey and pledge to honor requests for anonymity. This will yield more objective feedback about project roles and project management.
Feng shui your format. I'm all for originality, but this is one area where it makes sense to stick with a standard data collection template. If you're serious about institutionalizing lessons learned, come up with a methodology for organizing this content in a repeatable fashion across projects. This might vary from team to team but should focus on ease of use and searchability. Some possibilities might include a social media thread, a Google Document, a Trello board, or an Access database. To engage your team in the process, poll them to see what would be preferred. Also consider designing a format that makes it easy to present one set of lessons learned to clients while restricting another set to the internal team.
Force the issue. PMs on your team shouldn't have a question about where your lessons learned template resides or how to use it. Update your team SOPs to make populating this information a requirement, offer training to your new PMs on why this matters, and ensure that the lessons are in fact learned when drafting a proposal and upon project startup. Identify an owner to make sure this process gets done. This can be the same team member(s) responsible for other common project startup and closeout processes.
DO NOT set it and forget it. Encourage staff at all levels to update the list as the project progresses. Incorporate lessons learned reviews after major deliverables have been submitted or at a previously determined frequency on a project of longer duration. Make adjustments throughout the project so that staff can see the utility of continuing to provide input.
