Closing a sprint, phase, or project includes a meeting where the team comes together to talk about what went well, what went poorly, and what could be done better.  Diligent PMs document the findings and in rigorous organizations, there may even be a database for these items. 

Yet even with great lengths of effort to capture these lessons, we find time and time again that these methods are often abandoned, not timely, and impossible to find all relevant information. Does this make such reflection pointless? The short answer is “kind of.”

Capture

Timing is key to everything.  Agile methodology calls for a retro after each sprint to assess what we should start, stop or continue doing so that you can refine the team as you go.  This is a dramatic shift from waterfall in that you are constantly evaluating success, however, if your sprints are even 2 weeks long, that’s putting distance between you and the pain.  Relying on memory risks items or conditions being left out.  Asking team members to track it until the next retro increases risk that it could happen again OR another team could face the same issue if not communicated.

A bookend meeting is still useful to review what was accomplished, the metrics, and to brainstorm future ideas, but should not be relied on to capture all lessons learned.  Instead, useful information should be raised as it occurs.

Discern

A common mistake is knowing what to share with the organization at large and what is relevant to future projects.  By breaking lessons into 4 buckets, you can easily judge what to do with each.

1: Procedural

These lessons arise when a organization policies and procedures do not meet the needs of the projects, leading to a project issue.  Whether it is accounting for an exception, adding clarity, or implementing a new process, a change needs to be considered for projects going forward. 

Lessons of this type should be submitted to leadership for consideration.

2: Coaching

These lessons apply to a specific team member to facilitate their growth and success on the team and in future projects.

Lessons of this type should be delivered in a 1:1 conversation with the team member. Documentation should not be available outside of the team member and their manager.

3: Project Specific

These lessons are important to the team in a given project but would not extend usefulness to other teams. Examples may include needing to adjust meeting times to avoid conflicts with a specific set of team members and a client, or adjusting estimates to reflect historical variance within an effort.  

Lessons of this type should be discussed with the team and adjusted as needed.

4: Project General

These lessons may apply to all projects, projects of a common type, industry or client.  These are the gotchas that lessons learned meetings are aiming to convert from institutional knowledge to be readily available to any new team spinning up.

Lessons of this type should be documented and readily available to project teams.

Compile

You may be thinking at this point, “OK, I’m half way through this post and she still hasn’t said what to do with this stuff so that I’ll actually use it… or explained what Clue has to do with this.”

Fair.

One fault in many databases and registers to capture lessons learned is that they are full lessons from the first three buckets.  Dealing with each type appropriately will cut the bloat and make what remains much easier to search and digest.

Still, as time moves forward, items are kept in perpetuity and key words can only be so helpful.  Instead, lessons should be curated into risk register templates or project considerations.  Templates would be adjusted as knowledge is added or obsoleted (via procedural feedback).  Teams would then address each potential item, cancelling, mitigating or accepting as appropriate.  As knowledge is added, PMs would add it to their own register and deal with it as necessary.  

Having the checklist provided at the outset also gives to the benefit of jump starting the risk identification process with a new team.

Format

Some additional notes on delivery…

• There is not a one size fits all approach to how many checklists you may create.  You may find that your organization needs one for procurement, development, and a per client basis.  Or you may decide that a single list fits you fine.  Strike a balance that does not overwhelm teams who must take the time to strike out several items that will never apply to them and tracking down multiple lists that do apply.
• Keep the lesson brief and as broadly worded as possible so that multiple lessons do not need to be created for each consideration.  This keeps lists shorter and much more useful to teams.
• Phrase items as an actionable recommendation or task for the next team to avoid the same lesson being learned.  Rather than detailing that a schedule was impacted by an unknown regulatory process that must be completed prior to go live, you may add “Consult regulatory compliance expert to determine all steps required.”

By adjusting the way we use lessons learned we can stop asking everyone about the revolver in the library when you’ve already been shown those cards three times over!  Keeping track helps you where your mere memory might fail.