Rosana Inacio – PM Insights

Most project management frameworks include a lessons learned process.

The concept is straightforward. At the end of a project, the team reflects on what went well and what did not. The findings are documented. Recommendations are captured. The organisation learns and improves.

In theory, every project makes the next one better.

In practice, it rarely works that way.

What Usually Happens Instead

Lessons learned sessions get scheduled at project close-out, when teams are already exhausted and mentally moving on to the next priority.

When they do happen, the conversation is often surface-level. People highlight what went well. Critical issues get softened. Nobody wants to assign blame this late in the game.

The output gets documented, usually in a shared drive or a project management tool.

And then nobody reads it.

Six months later, a new project starts. The team repeats the same mistakes. The documentation exists, but it did not influence anything.

This is not a documentation problem.

It is a timing problem.

Why Lessons Learned Fail to Transfer

The PMP framework treats lessons learned as a process output. Something you produce at the end of a phase or project.

But learning does not work that way.

By the time you sit down to formally document what happened, the project is over. The team has dispersed. The context has faded. The moment when that learning could have changed a decision has already passed.

There is also an organisational reality that frameworks do not address directly.

Lessons learned documentation assumes the next team will find it, read it, understand the context behind it, and apply it to a different situation.

That is a lot of steps.

Each one is a point of failure.

Most organisations have a lessons learned library that nobody uses. Not because people are careless, but because the format does not transfer learning effectively.

What Experienced PMs Do Differently

The PMs who actually make retrospective thinking work do not wait for close-out.

They build reflection into how they run the project week to week.

That looks like:

• Brief check-ins during project reviews, not just status updates. What is working? What is slowing us down? What should we do differently?

• Capturing concerns when they arise, not months later when the detail is gone.

• Naming patterns mid-project when there is still time to adjust. If a dependency keeps causing delays, that becomes a conversation now, not a note in a close-out document.

• Sharing observations with stakeholders in real time, rather than saving everything for a retrospective that most of them will not attend.

The goal is not to skip the formal process.

The goal is to make sure real learning happens before the formal process runs.

Because by close-out, the most useful lessons are the ones that have already changed how the project ran.

The Real Question

The real question is not what we learned.

It is when.

Lessons learned only have value if they influence decisions.

A document that sits unread in a repository does not improve the next project.

A conversation that happens mid-sprint, when there is still time to act, might.

The PMP process gives you the structure.

What it cannot give you is the discipline to apply it continuously rather than just at the end.

That discipline is what separates PMs who document lessons from PMs who actually learn from them.

Rosana Inacio – PM Insights