Techniques for Building on Lessons Learned

Most teams do “lessons learned” sessions at the end of phases or projects, but the lessons are often forgotten or ignored on later projects.

The ability to internalize the project lessons and then incorporate them later tends to be dependent either on individual initiative (e.g. IT took 2 weeks instead of one on the last three projects, so I remember to schedule 2 weeks next time) or dependent on a PMO office updating processes.

studygroup

  • Having individual PMs and team members taking responsibility for refining their methods is great, but the knowledge can end up siloed in one person’s brain. That’s problematic when people leave or you build a new team that runs without shared resources.
  • PMO offices are awesome resources in larger companies or more projectized organizations. However, smaller companies usually lack this department while having less room for error. Also, most organizations are still functional or weak-matrix.

If you’re going to take the time to compile lessons learned, then you should make sure they really get learned and utilized properly. Here are some tools and techniques to leverage project lessons better:

1. Have a separate review session after the authoring is done.

Get the team back together for another review after the initial authoring round. The later review will reinforce the lessons in people’s memories, and also let them assess more objectively. Depending on team size, you can break into groups and have each take responsibility for explaining a lesson.

2. Create an easy-to-use format for recording the lessons and distributing them.

The key things to consider are clarity, centralization and access. If you want to put everything into Word or PowerPoint, then go ahead but make sure you A) Have an easy to understand format, B) compile all the lessons into the document & C) put it where anyone can access it (maybe a shared drive)

If you want something web-based, then consider setting up a wiki. Your intranet probably has a wiki template or you can setup software like MediaWiki to host your own. Any blogging software will also work in a pinch.

3. Run hypothetical scenarios where you incorporate lessons into past projects.

If you want to use your new learnings in the future, then you should get practice before you really need them.

Look at a closed project or a closed phase of a current one, and ask yourself what would happen if you incorporated some of the lessons learned. To maximize value, I suggest focusing on lessons related to the triple constraints (cost, time, scope). Identify a past situation where you had a cost overrun, or missed a milestone, or had change orders late in the project.

morpheus on your project scheduleAsk yourself:

  • If we’d used this formula to estimate X, would we have had enough budget?
  • If we finished Y earlier, then would we have delivered on time?
  • If we asked about Z upfront, would we have gotten the feature right the first time?

I’d suggest pulling from as many different phases as possible.

4. Build checklists to put lessons into action.

I won’t pretend that checklists are cool or a new technology. But they are ridiculously effective at making sure things get done.

Try taking 1 or 2 common work packages and breaking them down. Pull from your lessons learned, create the checklist, then test it. Assume you’ll need to keep iterating, but you’ll quickly end up with a trustworthy document that you can use for training and quality assurance.

You might have resources take responsibility for a particular checklist or checklist items (e.g. design team is responsible for checking image dimensions before sending to marketing), but make sure you distribute the checklists to less-experienced team members for critique — you don’t want industry jargon to throw off a project later on.

5. Include lessons learned in new project documents.

When it comes time to build your next project, make sure to incorporate language from the lessons learned into the the project documents: project charters, scope statements, work breakdown structure dictionary, and activity descriptions. Making the lessons part of the formal project documentation means you can’t avoid using them. It also creates another artifact with records of their use.

Similar to checklists, you’ll want to iterate on this. But don’t hesitate to adjust durations, add a work package, or identify a resource based on the lessons learned.

A Caveat: Not All Lessons Will Apply

Even if your projects are extremely similar, you will still encounter exceptions to the practices/policies you’re establishing. This is a good thing because it lets you add more nuance to your knowledge, but it can play havoc with your project planning. When exceptions arise, bring this up with your team to make sure it’s really an exception, then discuss the implications to determine what changes (if any) are needed.

Any more ideas for internalizing lessons learned? Please share in the comments.

More in planning, project tasks
In the Iron Triangle: Estimating Project Costs

Unnoticed differences in project requirements or unquestioned assumptions can lead to project estimating mistakes. Fortunately, these mistakes are avoidable if...

In the Iron Triangle: Resource Calendars & Schedule Coordination

Project schedule management relies on you being able to manage your resources but sometimes you don't have full authority over...

Close