The project is finished.
The budget has been reconciled. The punch list is complete. The team gathers for the lessons-learned session.
Someone asks what went well. Someone asks what could have gone better.
A list is created, documented, and eventually archived.
The project is closed, and everyone leaves believing the organization has become a little smarter.
I’m not sure it has.
Some of the most difficult capital projects I’ve worked on became less understood after the post-project review than before it. Nobody was lying. Nobody was trying to hide anything.
The process simply wasn’t built to produce understanding.
It was built to produce closure.
And those are not the same thing.
When the Story Replaces the Project
Once a project ends, something interesting happens.
The organization starts deciding what the project meant.
The delay happened because Operations wasn’t involved early enough.
The overrun happened because the program wasn’t finalized.
The change orders happened because stakeholder alignment was poor.
Everyone in the room has heard versions of these explanations before. They sound reasonable. They might even be partially true.
The problem is that complex projects rarely fail—or succeed—for a single reason.
Most major capital projects unfold over years. Leadership changes. Budgets change. Markets change. Business priorities change. Decisions made early in the project continue shaping outcomes long after the people who made them have left.
A budget reduction leads to a smaller facility.
The smaller facility changes how the operation works.
Operational changes affect staffing.
Staffing assumptions alter revenue projections.
Three years later, the lesson learned is documented as:
“Stakeholder alignment.”
The explanation isn’t necessarily wrong.
It just doesn’t explain very much.
The Seduction of Root Cause
Organizations love root causes.
Post-project reviews often assume that if the team digs deeply enough, one answer will eventually emerge.
Was it budgeting? Governance? Leadership? Scope? Operations?
The honest answer is usually all of them.
Large projects are systems. Outcomes emerge from the interaction of dozens of decisions made over long periods of time. But systems are difficult to document. A single cause fits neatly into a report.
So the system gets reduced to an explanation.
The explanation gets recorded as a lesson.
The lesson becomes institutional knowledge.
That’s when the real risk begins.
Explanations don’t stay explanations.
They become assumptions.
Those assumptions shape the next project.
Most of the time, the real answer is inconvenient. It usually points to a decision someone in the room made, or didn’t make, and would rather not revisit. That’s not a coincidence. That’s the whole reason “stakeholder alignment” gets written down instead.
The Wrong Lesson
Imagine a project finishes with the conclusion that Operations wasn’t involved early enough.
The lesson is documented. The next project responds by requiring Operations participation during schematic design.
Problem solved.
Except it may not be.
What if the overrun wasn’t caused by late Operations involvement? What if the real issue was months of unresolved governance decisions? Or a business case that changed after design began? Or funding assumptions that were never revisited as project conditions evolved?
Those conditions never make it into the lessons-learned report because they never fit neatly into the explanation the team accepted.
So the organization changes a process to solve the explanation it recorded—not necessarily the condition that produced the outcome.
The cost doesn’t appear in the review meeting.
It appears in the next capital program.
A Better Filter
I’ve found that the most useful post-project reviews don’t start by asking for lessons. They apply one filter, consistently, before any answer gets written down:
Don’t let a lesson get recorded until you can identify the decision behind it—and who made it, on purpose or by default.
“Stakeholder alignment” fails immediately. There’s no decision in it. Nobody can point to a moment, a person, a choice. It’s a mood, not a lesson.
Run the filter on the same three problems every project team blames on someone else.
“The design didn’t meet Operations’ needs.” Whose decision excluded Operations when the space program was established? Sometimes there’s an answer. Sometimes there isn’t one.
“We had too many change orders because the drawings were incomplete.” Who decided the drawings were sufficiently developed to bid? Sometimes that was a deliberate call—the owner knowingly accepted that risk to protect schedule. That’s a very different lesson than blaming the design team.
“The conference room technology didn’t meet expectations.” Who decided what the room was supposed to do before equipment was selected? The technology may have performed exactly as specified. Nobody may have ever defined what the room needed to do.
Same filter, three different rooms. Notice it never asks who’s to blame. It asks whether a decision actually exists beneath the explanation.
Closure Versus Understanding
Most lessons-learned sessions end when the room reaches agreement on an explanation. That’s the wrong finish line.
Before a lesson gets documented, ask one thing: can I name the decision this lesson is really about, and who made it?
If you can, write it down. It has a chance of surviving contact with the next project.
If you can’t, you don’t have a lesson yet. You have a story everyone was ready to believe—which is the more comfortable outcome, but not the same thing as understanding what happened.
Next in the Series
The Building Gets Transferred. The Reasoning Often Doesn’t.
Buildings transfer. Drawings transfer. Operations transfer.
The reasoning behind thousands of capital decisions often doesn’t.
In the next article, I’ll explore why organizations inherit facilities long before they inherit the judgment that shaped them.
About the Author: Richard Neuman advises organizations on capital planning, project governance, and complex capital programs. He has overseen more than $2 billion in capital investments across commercial real estate, healthcare, utilities, industrial, broadcast, and development projects.
He writes candidly from an owner-side perspective about the executive decisions and organizational dynamics that shape capital project outcomes.
Leading a major capital program or facing a complex capital decision?
Contact Richard.
Subscribe for insights on capital planning, project governance, and the executive decisions that shape project outcomes long before construction begins.
