Lessons Learned Register: Use It Before the Project Ends
The ritual is familiar. In the final fortnight, somebody books a session, the team assembles what it can remember of eighteen months, and a document is produced for the benefit of future projects that may or may not find it. The exercise is well intentioned and it is aimed at the wrong beneficiary, because the project best placed to use a lesson from month four is almost always the same project in month nine.
Section 4 of the PMBOK® Guide Eighth Edition lists the register among a project's artefacts. Treating it as a live record, maintained weekly and read at every repetition, changes what it is worth by a considerable margin.
Capture close to the event
Memory decays into narrative. A fortnight after something goes wrong, people can describe the sequence, the specific numbers and what they nearly did instead. Eight months later the same event has become a short story with a moral, and the detail that would let somebody else avoid it has gone.
People leave. Secondees return to their departments, contractors finish, suppliers move on. The person who best understands why the third integration attempt failed is frequently not there at closure, and their lesson leaves with them unless somebody wrote it down at the time.
Use them inside the same project
At the start of the next phase. Fifteen minutes at a phase kick-off spent on what the last phase taught us that applies here is the highest-return meeting slot on most projects, and it turns the register into something people have a reason to write into.
At the next site, release or wave. Multi-site and multi-release projects repeat themselves by design, and each repetition is an opportunity to do it better or to do it identically. Which of those happens depends entirely on whether anybody opens the record between them.
When somebody new joins. A register organised by topic is the fastest induction material a project has, because it describes the specific ways this project has already gone wrong. A new joiner given it in week one will ask better questions than one given a process document.
Site two, doing site one again
An insurer was rolling out a new claims handling process across four regional operations centres, one at a time, about ten weeks apart.
The first site went badly in specific ways. Training had been scheduled two weeks before go-live and most of it was forgotten by the day. The floorwalkers supporting the first week were project people who knew the system and not the work, so handlers with process questions had nowhere to go. And the reporting pack the team leaders needed had not been rebuilt for the new data, so for three weeks they managed their teams on figures they did not trust.
All three were written up in a closure report for that site, comb-bound and circulated, and it arrived on the desks of the second site's team about three weeks before their own go-live. One copy sat on the change manager's desk for a month in its shrink-wrap, which is how these things travel.
Site two repeated all three. Training at two weeks, project floorwalkers, no reporting pack. The second site's difficulties were almost identical to the first's and cost about the same, which for a large claims centre was a meaningful number, and the project's own view was that site two had simply been harder.
Before site three, a new programme manager did one thing: she took the three items, put them on the site three plan as activities with owners, and ran a fifteen-minute session with the site three leadership asking which of the three worried them most. Training moved to three days before go-live. Two experienced handlers from site one were seconded as floorwalkers, which also gave site one's people something to be proud of. The reporting pack was built and tested a fortnight ahead.
Site three's first week produced about a third of the support calls of the previous two, and the secondment of the two handlers became the standard pattern for site four and for two subsequent programmes.
What a usable lesson looks like
Situation, consequence, recommendation. Three sentences. What the circumstances were, what happened as a result, and what somebody in the same position should do. Anything shorter is unusable by a person who was not there; anything longer will not be read.
Filed by topic and not by project. Nobody searching for help with training timing thinks to look under the name of a rollout they were not on. A register organised by topic is found; one organised by project is archived.
For a PMP® candidate, what matters is that lessons are captured and applied throughout, so a scenario where a repeatable part of a project has repeated its problems is describing a register used as a closure document. A response that improves the closure process helps a future project and not this one. A structured PMP exam preparation course works over situations where the knowledge existed inside the project and was never applied.
If your project has a repeating element, put one item on the agenda before the next repetition: what did we learn last time that applies now, and who owns each of those this time. Fifteen minutes, before the work starts, and the return on it is usually visible within a fortnight.
Interested in going further?
The project most able to use a lesson is the one that produced it, and the closure ritual sends it somewhere else entirely. Omega's PMP® Exam Preparation works through knowledge capture as something done during delivery.
The lessons learned register is among the artefacts in the PMBOK® Guide Eighth Edition.
Ad · Amazon affiliate link.
References
A169: Assumption Log vs Risk Register
A170: Decision Log: The Forgotten Project Control
A155: Risk Register vs Risk Report vs Issue Log: What Goes Where?
A171: Change Log vs Issue Log
A167: Project Charter Explained: Purpose, Content and Common Misunderstandings
PMP and PMBOK are registered marks of the Project Management Institute, Inc.
