These should be collected as lessons learned. When you start a new project you raise the risk or change the way of working. For example, you have single point of failure, you raise the risk and you mitigate the risk (extra resource, extra time, limit involvment).
Cheers
Guillaume
...
1 reply by Imran Afzal
Apr 08, 2026 10:47 AM
Imran Afzal
...
That’s a fair point—most organizations do capture these as lessons learned.
But I’ve noticed something interesting:
Even when lessons are documented…
The same patterns still show up.
Different projects. Different teams. Same underlying issues.
I think part of the challenge is that lessons learned tend to stay local:
tied to a single project
reviewed at the end
rarely translated into how the organization actually operates
These should be collected as lessons learned. When you start a new project you raise the risk or change the way of working. For example, you have single point of failure, you raise the risk and you mitigate the risk (extra resource, extra time, limit involvment).
Cheers
Guillaume
That’s a fair point—most organizations do capture these as lessons learned.
But I’ve noticed something interesting:
Even when lessons are documented…
The same patterns still show up.
Different projects. Different teams. Same underlying issues.
I think part of the challenge is that lessons learned tend to stay local:
tied to a single project
reviewed at the end
rarely translated into how the organization actually operates
Senior Projects Manager | Field & Marten AssociatesNew Westminster, British Columbia, Canada
Imran, I think what’s happening is that teams often address the symptoms rather than the root cause.
They resolve what’s immediately visible, the (secondary effects) without fully understanding or tackling the underlying issue. As a result, the problem appears fixed in the short term, but the core driver remains untouched.
Over time, that same root cause resurfaces in different forms’ across projects, teams, or contexts, creating the illusion of new problems when it’s actually the same one repeating so until the root cause is clearly identified and addressed, recurrence isn’t surprising, it’s inevitable.
...
1 reply by Imran Afzal
Apr 08, 2026 1:34 PM
Imran Afzal
...
I think that’s exactly right—symptoms vs root cause is at the heart of it.
What I’ve noticed, though, is that even when teams do identify a root cause…
It often stays at the project level.
So the root cause gets documented, maybe even addressed locally—
But the underlying conditions that allowed it to happen in the first place don’t change.
That’s where the recurrence comes from.
Not because teams didn’t understand the issue…
But because the system that produced it is still intact.
So I’ve started to think about it less as:
Did we find the root cause?
And more as:
Did anything change beyond this project that would prevent it from happening again elsewhere?
Curious if you’ve seen examples where organizations actually made that leap—from root cause → systemic change.
Some of the hardest recurring issues I have seen across projects is unclear ownership and late escalations. They often show up as missed dependencies, shifting priorities or last-minute urgent change. Having greater clarity, clear ownership and timely decision-making can significantly help prevent these issues. Additionally, maintaining a centralized repository for risks, lessons learned and key decisions enables project professionals and teams to identify patterns early and address problems proactively before they recur.
...
1 reply by Imran Afzal
Apr 08, 2026 1:37 PM
Imran Afzal
...
Unclear ownership and late escalations show up everywhere—completely agree.
And I think your point about decision-making is key.
A lot of what we label as “execution issues” are really decision clarity issues in disguise.
On the centralized repository—
I’ve seen those created many times, but adoption is usually the challenge.
The information exists…
But it doesn’t consistently influence how future work is planned or executed.
What seems to make the difference is when patterns are actively surfaced and discussed at a portfolio level, not just stored:
“Where are we seeing this pattern again?”
“What does this tell us about how we’re operating?”
That’s when it starts to shift behavior.
Have you seen any approaches where teams actually use that centralized insight to change how decisions are made—not just document what happened?
Imran, I think what’s happening is that teams often address the symptoms rather than the root cause.
They resolve what’s immediately visible, the (secondary effects) without fully understanding or tackling the underlying issue. As a result, the problem appears fixed in the short term, but the core driver remains untouched.
Over time, that same root cause resurfaces in different forms’ across projects, teams, or contexts, creating the illusion of new problems when it’s actually the same one repeating so until the root cause is clearly identified and addressed, recurrence isn’t surprising, it’s inevitable.
I think that’s exactly right—symptoms vs root cause is at the heart of it.
What I’ve noticed, though, is that even when teams do identify a root cause…
It often stays at the project level.
So the root cause gets documented, maybe even addressed locally—
But the underlying conditions that allowed it to happen in the first place don’t change.
That’s where the recurrence comes from.
Not because teams didn’t understand the issue…
But because the system that produced it is still intact.
So I’ve started to think about it less as:
Did we find the root cause?
And more as:
Did anything change beyond this project that would prevent it from happening again elsewhere?
Curious if you’ve seen examples where organizations actually made that leap—from root cause → systemic change. Saving Changes...
Some of the hardest recurring issues I have seen across projects is unclear ownership and late escalations. They often show up as missed dependencies, shifting priorities or last-minute urgent change. Having greater clarity, clear ownership and timely decision-making can significantly help prevent these issues. Additionally, maintaining a centralized repository for risks, lessons learned and key decisions enables project professionals and teams to identify patterns early and address problems proactively before they recur.
Unclear ownership and late escalations show up everywhere—completely agree.
And I think your point about decision-making is key.
A lot of what we label as “execution issues” are really decision clarity issues in disguise.
On the centralized repository—
I’ve seen those created many times, but adoption is usually the challenge.
The information exists…
But it doesn’t consistently influence how future work is planned or executed.
What seems to make the difference is when patterns are actively surfaced and discussed at a portfolio level, not just stored:
“Where are we seeing this pattern again?”
“What does this tell us about how we’re operating?”
That’s when it starts to shift behavior.
Have you seen any approaches where teams actually use that centralized insight to change how decisions are made—not just document what happened?
...
1 reply by Srikana Ray
Apr 08, 2026 3:55 PM
Srikana Ray
...
Yes, using the centralized repository as an active documentation site instead of historical record will be more beneficial. The repository can be queried or linked to a dashboard for research and analysis. Also integrating the repository with project management tools helps to embed the repository in the project workflow.
For example periodic review of the documentation and sharing the challenging risks, decisions and outcomes with the project teams will create awareness and develop better understanding of the issues, thereby teams can identify risk patterns, root causes and relevant decisions and take appropriate actions early.
Unclear ownership and late escalations show up everywhere—completely agree.
And I think your point about decision-making is key.
A lot of what we label as “execution issues” are really decision clarity issues in disguise.
On the centralized repository—
I’ve seen those created many times, but adoption is usually the challenge.
The information exists…
But it doesn’t consistently influence how future work is planned or executed.
What seems to make the difference is when patterns are actively surfaced and discussed at a portfolio level, not just stored:
“Where are we seeing this pattern again?”
“What does this tell us about how we’re operating?”
That’s when it starts to shift behavior.
Have you seen any approaches where teams actually use that centralized insight to change how decisions are made—not just document what happened?
Yes, using the centralized repository as an active documentation site instead of historical record will be more beneficial. The repository can be queried or linked to a dashboard for research and analysis. Also integrating the repository with project management tools helps to embed the repository in the project workflow.
For example periodic review of the documentation and sharing the challenging risks, decisions and outcomes with the project teams will create awareness and develop better understanding of the issues, thereby teams can identify risk patterns, root causes and relevant decisions and take appropriate actions early. Saving Changes...
Anton OosthuizenSenior Business Analyst / Project Manager| Self EmployedPretoria, Gauteng, South Africa
If there are two things that really annoy the hell out of me, it is MVP and Lessons Learned. Both for the same reason - we seem to think that using the words adds value. Well, it does not. These are things that we need to do right for it to add value. Lessons learned are a great way to prevent issues from making a comeback, either in the current project or the next, BUT more often than not, it does nothing because a) we record lessons learned in our neat little registers AFTER project completion, and b) we file it.
IMO, lessons learned should be documented and implemented IMMEDIATELY, as you learn them, not after project completion.
...
1 reply by Imran Afzal
Apr 10, 2026 10:23 AM
Imran Afzal
...
Anton — completely agree on implementing lessons learned immediately.
That’s actually where I’ve seen the biggest gap between intent and impact.
Most teams are pretty good at capturing lessons.
Far fewer are good at operationalizing them.
Retrospectives help when they produce actionable changes, not just insights:
What are we changing next sprint?
What behavior actually needs to shift?
How will we know it worked?
And like you said, not everything can be implemented right away.
But the difference is whether the list becomes:
a parking lot
or
a backlog of system changes
The teams that improve treat those items like real work:
prioritized, revisited, and intentionally pulled in when conditions allow.
Otherwise, we end up with a very well-documented history of the same problems.
Curious—have you seen any approaches that actually force follow-through beyond the retro itself?
Product Operations Program ManagerBarcelona, Cataluña, Spain
Indeed, this is a common occurrence, and its recurrence depends on the nature of the root cause. If the root cause lies within a system (such as a documentation system, data analytics system, or business model), it should trigger corrective action to prevent future recurrences. If the root cause is human error, it may happen again if the mistake is not properly documented and shared. Without this, a new person may repeat the same error in the future. This often occurs when companies rely on external consultants who resolve the issue but leave without effectively transferring their knowledge to the organization.
...
1 reply by Imran Afzal
Apr 10, 2026 10:25 AM
Imran Afzal
...
Eduard — I like how you break this down between system and human causes.
Where I’d push the thinking a bit further is this:
Even when the root cause looks like human error, it’s often still a system issue.
Because the question becomes:
Why did the system allow that error to happen—and repeat?
Was ownership unclear?
Were decision points implicit?
Was there no forcing function to catch it earlier?
Documentation and knowledge transfer help, but they don’t always change behavior.
That’s where I’ve seen organizations struggle—
they invest in capturing knowledge, but not in changing the conditions that produce the issue.
So the recurrence isn’t just about lost knowledge.
It’s about the system continuing to generate the same outcomes.
Curious how others distinguish between:
“we need better documentation” vs. “we need to change how decisions get made.”
If there are two things that really annoy the hell out of me, it is MVP and Lessons Learned. Both for the same reason - we seem to think that using the words adds value. Well, it does not. These are things that we need to do right for it to add value. Lessons learned are a great way to prevent issues from making a comeback, either in the current project or the next, BUT more often than not, it does nothing because a) we record lessons learned in our neat little registers AFTER project completion, and b) we file it.
IMO, lessons learned should be documented and implemented IMMEDIATELY, as you learn them, not after project completion.
Anton — completely agree on implementing lessons learned immediately.
That’s actually where I’ve seen the biggest gap between intent and impact.
Most teams are pretty good at capturing lessons.
Far fewer are good at operationalizing them.
Retrospectives help when they produce actionable changes, not just insights:
What are we changing next sprint?
What behavior actually needs to shift?
How will we know it worked?
And like you said, not everything can be implemented right away.
But the difference is whether the list becomes:
a parking lot
or
a backlog of system changes
The teams that improve treat those items like real work:
prioritized, revisited, and intentionally pulled in when conditions allow.
Otherwise, we end up with a very well-documented history of the same problems.
Curious—have you seen any approaches that actually force follow-through beyond the retro itself?
...
1 reply by Anton Oosthuizen
Apr 11, 2026 10:31 AM
Anton Oosthuizen
...
Imran Afzal, I don't know if you can actually 'force' any process like you would in situations where you can build in validation. I find that the best way to 'force' something like this is to build in measures like KPIs. What this means is that it becomes a performance measure, and we all know how people like to satisfy performance measures ;) I follow the same approach for change management by building the change into a measurement. I suppose that you could create a stage gate during project closure to ensure that lessons learned are implemented, and while this would be after the fact, at least it would get done.
Community Champion
