Insights

Construction Lessons Learned That Actually Change the Next Project

Oct 23, 2026 · 7 min read · Ben Abbasi, PMP

A wall covered in yellow and orange sticky notes from a review session

Every owner with a capital program has a lessons-learned folder. Few can point to a single change in how they run projects that came out of it. The pattern is familiar: a close-out workshop, a long list of what went wrong, a report filed on a shared drive, and the same problems turning up on the next project with a different team.

The problem isn't capture. It's what happens after. This guide explains how to collect lessons that are worth having, how to code them so they can be found, and, most importantly, how to feed them into the templates and standards that the next project will actually use.

Why lessons don't stick

The evidence on this is old and consistent. In 2002, the U.S. Government Accountability Office surveyed NASA program and project managers about the agency's lessons-learned system. The results would be familiar to most construction owners. More than half said the system didn't let them retrieve the right lessons at the right time. About a quarter weren't aware the system existed. The barriers managers cited included lack of time, lack of trust, and an intolerance for mistakes that made people reluctant to share negative lessons.

NASA project managers' views of their lessons-learned system, 2001 survey Share of surveyed NASA program and project managers: 58 percent said the system did not let them retrieve the right lessons at the right time; 53 percent found lessons useful less than 25 percent of the time; 43 percent had not submitted a lesson in two years; 39 percent said lessons contribute only some or little to mission effectiveness; 27 percent were unaware of the system. Capture isn't the problem. Use is. NASA managers on their lessons-learned system (GAO survey) Can't retrieve the right lessons at the right time Can't retrieve the right lessons at the right time: 58% 58% Found lessons useful less than 25% of the time Found lessons useful less than 25% of the time: 53% 53% Hadn't submitted a lesson in the past two years Hadn't submitted a lesson in the past two years: 43% 43% Lessons add only some or little to mission effectiveness Lessons add only some or little to mission effectiveness: 39% 39% Weren't aware of the lessons system before the survey Weren't aware of the lessons system before the survey: 27% 27%
Percent of surveyed NASA program and project managers. The problem wasn't a shortage of lessons; it was finding and using them. Source: U.S. GAO, GAO-02-195 (January 2002), survey conducted June–July 2001.
View the data
Survey findingShare of managers
Can't retrieve the right lessons at the right time58%
Found lessons useful less than 25% of the time53%
Hadn't submitted a lesson in the past two years43%
Lessons add only some or little to mission effectiveness39%
Weren't aware of the lessons system before the survey27%

Sandra Rowe, writing for PMI in 2008, put the core issue plainly: the value of lessons learned is in their use, not their capture. Many organizations, she noted, have a capture process but nothing that makes sure the lessons are applied. Lessons sessions get skipped when the next project is urgent, or treated as something to do if time permits.

Construction makes this harder. Project teams disband at turnover. Consultants and contractors move on to other clients. The owner's project manager may run one project every two or three years. Unless lessons are built into something that outlasts the team, they leave with the people.

Capture during the project, not just at the end

A close-out workshop held months after the hard decisions were made will produce general observations. "Communication could be better." "Design should be more complete at tender." True, and useless.

Rowe's process recommends capturing lessons at phase ends and in real time, not only at close. For a building project, natural points are each stage gate, tender award, substantial performance and the end of the first year of operation. Short sessions at those points catch detail while people still remember it.

A few practices improve what comes out:

  • Use a neutral facilitator. PMI's guidance recommends someone other than the project manager, so people can speak about decisions the PM made.
  • Ask three questions. What went right, what went wrong, what needs improving. Start with what went right to lower defensiveness.
  • Ban blame. The aim is to fix the system, not to record who made a mistake. If people expect a lesson to hurt their career, they won't share it, as the NASA survey found.
  • Bring evidence. Change logs, RFI logs, schedule updates and cost reports show what actually happened. Memory is selective; the change log isn't.
  • Include the operators. The first-year operations review is where you learn whether the building does what the Owner's Project Requirements said it should.

Write lessons people can act on

A useful lesson has four parts: what happened, why it happened, what it cost, and what should change. Compare:

  • Weak: "Mechanical coordination was poor."
  • Useful: "Rooftop unit curbs were not coordinated with the structural steel layout because the mechanical drawings were issued after the steel shop drawings. This caused three change orders and two weeks of delay. Next time, require the mechanical layout of roof equipment to be frozen before steel shop drawings are released."

The useful version names a root cause and a specific change. Rowe recommends root cause analysis, asking "why" repeatedly until the underlying cause appears, then prioritizing causes and assigning an owner to each. Without that step, lessons describe symptoms and the fixes don't work.

Code lessons so they can be found

A lesson that can't be found is the same as one that was never written. NASA managers told GAO the system was hard to search, with relevant lessons buried among irrelevant ones. Rowe recommends a standard input form with fields such as category, lesson, action taken, root cause and keywords. For a construction owner, a practical coding scheme uses a handful of fields:

  • Phase: planning, design, procurement, construction, commissioning, operations.
  • Topic: scope, cost, schedule, quality, safety, contract, approvals, stakeholders.
  • Discipline or system: structural, envelope, mechanical, electrical, fire protection, interiors, IT.
  • Project type: new build, renovation, fit-out, occupied building, multi-site rollout.
  • Impact: estimated cost and schedule effect, even as a rough range.
  • Destination: the template or standard that should change, and who owns it.

The last field is the one most registers lack, and it's the one that makes the rest work.

Feed lessons into templates and standards

This is the step that decides whether lessons change the next project. A lesson in a report depends on someone reading it. A lesson built into a template happens automatically.

For most owners, the documents that carry lessons forward are:

  • Design standards and the OPR template. Equipment preferences, maintainability requirements, room data sheets.
  • Specification masters. Products that failed, testing requirements that were missing.
  • Contract templates and supplementary conditions. Clauses that caused disputes, gaps in scope definitions. Get legal advice before changing contract wording.
  • Estimate and budget templates. Cost items that were missed, allowances that proved too low.
  • Risk register checklists. Risks that occurred but weren't on the register. Our post on building a risk register owners use covers how to carry them.
  • Schedule templates. Durations that were too short, approvals that took longer than planned, long-lead items that were ordered too late.

Each of these documents needs an owner. Rowe recommends involving process owners so changes are carried through the organization and supporting documents are updated. If nobody owns the design standard, nobody updates it, and the lesson stays in the report.

Lessons-learned process with the apply step added Five steps from PMI guidance: identify, document, analyze, store and retrieve. An added apply step, highlighted, changes the design standards, OPR, specifications, contract templates, estimates, risk checklists and schedule templates, so the next project starts from better defaults. Five steps, plus the one that matters From lesson to changed standard Identify At gates and first-year review Document Cause, cost and specific change Analyze Root cause, owner assigned Store Coded and searchable Retrieve Kickoff and risk workshop Apply: change the template or standard Design standards, OPR, specs, contracts, estimates, risk checklists, schedule templates the missing step Next project starts from better defaults
Identify, document, analyze, store and retrieve follow Rowe's five-step process (PMI, 2008). The highlighted apply step is what makes a lesson change the next project. Diagram by Benjamin R. Consulting.

Make it someone's job

GAO's recommendations to NASA translate well to an owner's capital program. It recommended designating a lessons-learned manager to coordinate the effort, creating incentives such as links to performance evaluations, improving how lessons were coded and searched, adding positive lessons rather than only failures, and tracking effectiveness with objective metrics.

For most owners, that doesn't need a new hire. It needs one person, often in the project management office or the owner's rep team, who is accountable for the lessons register: chasing open actions, routing each lesson to the owner of the right template, and reporting what changed. Without that role, lessons are everyone's job, which means they're nobody's.

Positive lessons deserve the same attention as failures. A procurement approach that drew strong bids, a commissioning plan that produced a clean handover, a user consultation process that avoided late changes: these belong in the standards too. Recording only failures also reinforces the idea that lessons learned is a blame exercise, which is exactly what stops people from contributing.

Keep the register small enough to maintain. Rowe recommends purging outdated lessons. A lesson that has already been built into a standard can be closed and archived, because the standard now carries it.

Retrieve lessons at the start of the next project

The last step is the one most often missed. Rowe recommends reviewing past lessons before projects start, putting them on kickoff agendas and using them in risk planning. For an owner, that means three habits:

  • Kickoff review. Before design starts, the project team reviews the lessons coded to this project type and phase.
  • Risk workshop input. Lessons from past projects become candidate risks for the new register.
  • Gate checks. At each gate, the decision-maker asks which relevant lessons have been applied.

On programs we've supported, the simplest test of a lessons system is to pick a lesson from two projects ago and ask where it now lives. If the answer is "in the close-out report", it hasn't been learned.

What owners should do

  1. Capture lessons at each gate and after the first year of operation, with a neutral facilitator and a no-blame rule.
  2. Write each lesson with a root cause and a specific change, not just a description of what went wrong.
  3. Code every lesson by phase, topic, discipline, project type and impact, and name the template it should change.
  4. Give each standard and template an owner who is responsible for updating it when lessons arrive.
  5. Review relevant lessons at every kickoff and risk workshop.
  6. Track one metric: how many lessons were closed by a change to a standard or template, not how many were recorded.

The bottom line

Lessons learned only pay off when they change what the next team does by default. That means fewer, better lessons, coded so they can be found, each one tied to a template or standard with an owner who will update it. A thick close-out report is not evidence of learning. A revised design standard is. Start with the last project you closed, and pick the three lessons that would have saved the most money.

Want help turning your past projects into better standards for the next ones? Book a 30-minute call with Benjamin R. Consulting.

Sources: Rowe, S. F., Applying lessons learned (PMI Global Congress, 2008); Ladika, S., Break the cycle, PM Network (PMI, 2008); U.S. GAO, NASA: Better Mechanisms Needed for Sharing Lessons Learned, GAO-02-195 (2002). The worked example is illustrative. This article is general information, not legal advice.

← All insights

Have a program that's slipping, or about to start?

Book a 30-minute call. We'll tell you where your schedule and budget are exposed, and what an owner's rep would change, before you commit to anything.

Book a 30-minute callinfo@benjaminr.ca