Lessons Learned

Definition

Lessons Learned is the disciplined practice of identifying, documenting, validating, and — most importantly — re-using the knowledge generated by a project. It is the bridge between one team's experience and the next team's starting point. Done well, it compounds organisational capability. Done badly, it produces lever-arch files that nobody opens.

A lesson is not a complaint, not a war story, and not a closeout slide. A lesson is a cause-and-effect statement paired with a recommended action that another project can apply. "The civil contractor was slow" is not a lesson. "Awarding civil works before the geotechnical interpretive report was issued caused a six-week rework cycle on pile design; future projects shall make the GIR a Stage-Gate-2 deliverable" is a lesson.

History and Origins

Formal lessons-learned practice emerged from aerospace and defence in the 1960s, when failure-mode analyses on programmes like Apollo and Polaris forced systematic post-event reviews. The U.S. Army's After-Action Review codified the four-question format still in use today: What was supposed to happen? What actually happened? Why was there a difference? What can we learn? Construction and IT adopted the practice through PMI's PMBOK, ISO 21500/21502, and — in software — Norm Kerth's Project Retrospectives (2001), which became the philosophical foundation of agile retrospectives.

Principles

• Capture continuously, not only at closeout. Memory decays fast; a lesson written six months after the event is half-fiction.
• Separate the event from the lesson. Anecdote is not evidence. Validate with data, photographs, schedule fragments, or cost variances before promoting an observation to a lesson.
• Make lessons findable. Tag by discipline, phase, contract type, and risk category. A repository without metadata is a graveyard.
• Mandate look-back at look-forward gates. The lesson is only useful when a future planner is forced to consult it during risk identification, estimating, and procurement strategy.
• Reward the sharer, not the hero. Teams that hide problems to look good destroy the feedback loop.
• Retire institutionalised lessons. When a lesson becomes a standard or a template, retire it from the active list. Procedure replaces memory.

The Lesson Lifecycle

1. Identify — surface observations during weekly progress meetings, risk reviews, NCR closeouts, change-order post-mortems, and stage-gate reviews.
2. Document — capture context, root cause, impact (cost, schedule, quality, safety), and recommended action in a structured template, not free prose.
3. Validate — a discipline lead or PMO reviewer confirms the lesson is generalisable, not project-specific noise.
4. Disseminate — publish to the searchable repository; brief the broader portfolio in a monthly knowledge bulletin.
5. Apply — mandatory consultation during the next project's risk register build, estimating basis, and procurement plan.
6. Retire — when institutionalised in a standard, procedure, or template, retire the lesson from the active library.

Real-World Construction Example

On a 132 kV substation project in the Gulf, the team commissioned protection relays before final cable schedules were frozen. Late changes to current-transformer ratios forced three rounds of relay re-configuration, costing 18 days of commissioning float and roughly USD 140,000 in standby crew time. The lesson — documented within ten days while details were fresh — read: "Relay configuration files shall be frozen only after CT ratios are signed off by both protection engineering and the utility; freeze date shall sit on the master schedule as a constraint, not a milestone." Two projects later the same EPC contractor saved an estimated 22 days on a comparable substation because the freeze constraint was embedded in the planning template. The lesson had become procedure.

Real-World IT / Agile Example

A fintech squad shipping a payments API ran retrospectives every two weeks but never tracked action items across sprints. The same incident — flaky integration tests caused by shared sandbox state — surfaced in four consecutive retros. After introducing a lightweight "Lessons Ledger" in Confluence with an owner and a due date for every action, the team closed the issue in one sprint by giving each pipeline its own ephemeral sandbox. The meta-lesson was structural: a retrospective without traceable actions is theatre.

Project Controls Perspective

From a controls standpoint, lessons learned feed three quantitative inputs. First, estimating norms — productivity factors, contingency percentages, and unit rates should be tuned by validated lessons from comparable projects rather than left as last-decade averages. Second, risk register seeding — the top quartile of lessons becomes the default risk list for the next project of similar type, complete with historic probability and impact ranges. Third, schedule logic — recurring sequence errors (for example, starting MEP rough-in before slab pour cure) become hard-coded logic rules in the planning template. Without these three feedback paths the lessons library is decorative.

Common Mistakes

• Treating lessons learned as a closeout formality run by an exhausted team the week before demob.
• Capturing complaints instead of causes. "Client was difficult" is not actionable.
• Storing lessons in a SharePoint folder no one has indexed.
• Never feeding lessons back into estimating, planning templates, or procurement strategy.
• Punishing the messenger — the fastest way to kill the feedback loop.
• Letting the library grow unbounded; without a retirement policy, signal-to-noise collapses.
• Confusing a lessons-learned register with an issues log — the issues log is operational, the lessons log is strategic.

Expert Tips

• Run a 30-minute "lesson harvest" at every monthly progress review. Three questions, one slide, captured live while the project is still bleeding.
• Tag every lesson with the WBS element or risk category it touches. Searchability is everything; a lesson nobody can find is a lesson nobody applies.
• Assign an owner to every lesson — usually the discipline lead — responsible for translating it into a procedure update within 60 days.
• Conduct a "pre-mortem" at project start. Imagine the project has already failed; what does the lessons-learned report say? This surfaces risk in hours, not years.
• Quantify the lesson. "Saved 18 days, USD 140,000" defends the PMO knowledge function at budget time far better than "improved efficiency."
• Read the previous project's top ten lessons in the kick-off meeting. If the team cannot summarise them, the system is broken.

Lessons Learned About Lessons Learned

The two most common organisational pathologies are the graveyard repository — a database of four thousand entries no one reads — and the blame log — a lessons file that names contractors and individuals. Both fail. A small library of eighty validated, tagged, owned lessons outperforms a giant library of unfiltered notes, and future readers learn nothing from blame except who to avoid in the bar. The fix is curation and depersonalisation, not capture volume.

A third pathology is worth naming: the orphaned action item. Lessons that produce recommendations but no owner, no due date, and no closeout review evaporate within a quarter. Treat every lesson as a small change request against the organisation's standards, complete with an approval path.

Key Takeaways

• A lesson is a validated cause-effect statement with a recommended action — not an opinion, not a complaint, not a war story.
• Capture early, validate quickly, disseminate widely, retire when institutionalised.
• Lessons must feed estimating, risk, schedule logic, and procurement — otherwise they are stories, not capital.
• Small, curated, findable libraries beat large unfiltered dumps every time.
• Pre-mortems extract tomorrow's lessons today; retrospectives only work when actions outlive the meeting.

Related Concepts

Lessons Learned underpins Risk Management, Quality Management, Stakeholder Engagement, Change Control, and KPI design. For practical templates and worked examples see the PMMilestone.org PM library and the project closeout playbook.