Consultant| Canarys Automation LtdBangalore, Karnataka, India
In many projects, I’ve observed that teams become very effective at managing issues—tracking them, escalating them, reporting them—but not always at truly resolving the root cause.
Over time, the same risks and issues tend to reappear across projects, often under different names.
This makes me wonder:
Are we, as project professionals, sometimes optimizing for control and visibility rather than actual problem resolution?
Curious to hear from the community:
How do you ensure your teams focus on root cause resolution, not just issue tracking
Have you seen recurring problems across projects that were never fully addressed
What practices (retrospectives, RCA techniques, governance changes) have helped break this cycle?
Project & PMO Manager | Research & Enterprise Mentor| GFB HoldingSouth America, Brazil
I've seen this exact pattern across my 100+ projects as a PMO manager, teams excel at dashboards and escalations but treat issues as isolated fires, leading to recurring headaches like scope creep from poor vendor syncs or delays from underestimated integrations. In one manufacturing rollout, delayed testing recurred in three sequential projects; we weren't just tracking but logging lessons learned sessions post resolution: for the first, a quick "vendor late" note; deeper RCA via 5 Whys revealed inconsistent SLAs, so we updated governance with mandatory vendor audits. Recurrence hit again? We escalated to portfolio level analysis, spotting a pattern in offshore teams response: centralized training and KPI dashboards tied to bonuses. This shifted focus from visibility to resolution, cutting repeats by 40%. Another chronic issue was resource overallocation causing burnout and slips, masked as "team capacity problems." Initial fixes were band-aids (add headcount), but lessons learned sessions evolved: first project postmortem flagged poor forecasting; recurrence prompted Fishbone diagrams in retros, uncovering hidden dependencies in backlogs. We broke the cycle with governance changes, a recurring issue registry across PMO projects, quarterly deep dives (even if teams differ), and tying RCA to OKRs. Practices like blameless retros every sprint, A3 problem-solving for majors, and PMO-mandated root cause templates ensure we treat repeats as systemic failures, not one-offs, forcing proactive fixes like skill matrices and AI forecasting tools. Saving Changes...
Program Manager| HARPER SRLSanto Domingo / Distrito Nacional, Dominican Republic
Teams get really good at tracking and reporting, but the same issues keep coming back. When something repeats, I treat it as a signal, not a coincidence. Instead of fixing it again, I push to understand why it keeps happening. Looking at patterns across projects also matters. Otherwise, each team ends up dealing with the same problem on their own. Saving Changes...
I think this happens because we’ve built systems that reward visibility of problems more than resolution of them.
Teams get very good at tracking, escalating, and reporting issues—because that’s what’s measured, reviewed, and recognized.
But root cause resolution is slower, messier, and often cuts across boundaries.
So it gets deprioritized.
Over time, you end up with what looks like strong control…
…but is really just well-managed recurrence.
The shift I’ve seen work is when you stop treating issues as isolated events and start treating them as signals of system behavior.
If the same issue shows up twice, it’s not a project problem anymore.
It’s a system problem.
That changes the response.
Instead of asking, “How do we resolve this issue?”
You start asking:
“Why does our system keep producing this outcome?” “What conditions allowed this to happen more than once?” “What needs to change so it can’t happen again?”
That’s where practices like RCA, retros, and lessons learned either work—or don’t.
Not because of the technique itself, but because of what happens after.
If the output doesn’t translate into changes in how work is planned, prioritized, or governed, the cycle continues.
So for me, it’s less about adding more problem-solving practices.
It’s about changing what the system is optimized for.
From managing issues… to eliminating the conditions that create them. Saving Changes...
Consultant| Timely Nexus Project LLPGreater NOIDA, Uttar Pradesh, India
This is a very valid observation, as many teams become highly efficient at tracking and reporting issues but less effective at addressing their root causes, which is why the same problems often reappear across projects. In many cases, the focus shifts toward visibility and control rather than true resolution. To counter this, it helps to make root cause analysis mandatory for recurring issues, use simple structured methods like the 5 Whys, and ensure that actions from retrospectives are actually implemented and reviewed. Tracking metrics such as repeat issues instead of just closures can also drive better behavior. Ultimately, lasting improvement comes from treating issues as signals of deeper systemic gaps and ensuring they are fully resolved, not just managed. Saving Changes...
My projects don't exist in a silo and my resources aren't dedicated. Some deadlines can't be moved. Business decisions drive priority, so yes, I do see recurring issues across some projects. For some, we understand the root cause and a decision has been made to not address it at this time. For others, we don't know the root cause, yet, and if they don't block project launch or critical features, sometimes, we keep moving.
To be clear, this is from the perspective of a corporate PM working in IT and business operations, leading internal software development, process changes, strategic change, transformations, and third party implementations. Understanding root cause is usually important, but addressing root cause is not always the immediate concern.
When you understand what the root cause is, do you always solve the root cause?
...
1 reply by Anton Oosthuizen
Apr 11, 2026 10:39 AM
Anton Oosthuizen
...
That is an interesting perspective Aaron Porter , and I'd venture to say no to your closing question. We do not always fix the root cause when we understand it. Why would that be? It sounds counterintuitive. IMO I believe that often we find the root cause, but we do not know that it is the root cause. But then, when we do realise that it is the root cause, we just as often ignore it because of the pain involved in fixing it. Too often have I seen people living with the pain of a problem but refuse to do something about it because fixing it would, according to them, it would be more painful to fix it that to live with it. We do not acknowledge that the pain of fixing it is temporary while the pain or ignoring it is permanent.
Senior IS Project Manager| Baycare Health SystemsClearwater, Fl, United States
I have been a project manager for more years than I want to recall, and in almost all cases there are some things that do not go perfectly during project execution. It has not always been the same issue, but every project with have some issues.
I agree with Aaron that finding the root cause does not always correct the root cause.
In other cases the impact of the issue was so small that it did not justify the time and resources to resolve.
Finally, there are sometime when the true root cause cannot be confirmed. Saving Changes...
In many projects, we are often better at managing issues than eliminating them. Tracking and escalation improve visibility, but without consistent root cause analysis, the same problems keep repeating in different forms.
In my experience, shifting focus from issue logs to structured RCA (like 5 Whys or Fishbone analysis) and ensuring ownership of corrective actions beyond closure helps move from control to real resolution. Saving Changes...
Anton OosthuizenSenior Business Analyst / Project Manager| Self EmployedPretoria, Gauteng, South Africa
Apr 08, 2026 10:42 AM
Replying to Aaron Porter
...
Is root cause always the answer?
My projects don't exist in a silo and my resources aren't dedicated. Some deadlines can't be moved. Business decisions drive priority, so yes, I do see recurring issues across some projects. For some, we understand the root cause and a decision has been made to not address it at this time. For others, we don't know the root cause, yet, and if they don't block project launch or critical features, sometimes, we keep moving.
To be clear, this is from the perspective of a corporate PM working in IT and business operations, leading internal software development, process changes, strategic change, transformations, and third party implementations. Understanding root cause is usually important, but addressing root cause is not always the immediate concern.
When you understand what the root cause is, do you always solve the root cause?
That is an interesting perspective Aaron Porter , and I'd venture to say no to your closing question. We do not always fix the root cause when we understand it. Why would that be? It sounds counterintuitive. IMO I believe that often we find the root cause, but we do not know that it is the root cause. But then, when we do realise that it is the root cause, we just as often ignore it because of the pain involved in fixing it. Too often have I seen people living with the pain of a problem but refuse to do something about it because fixing it would, according to them, it would be more painful to fix it that to live with it. We do not acknowledge that the pain of fixing it is temporary while the pain or ignoring it is permanent.
...
1 reply by Vinay Goswami
Apr 11, 2026 4:23 PM
Vinay Goswami
...
I beg to disagree. It rarely happens that we do not know the root cause and solution that can permanently fix the issue. However the issues linger due to following factors: .1. Lack of economic incentive and criticality of issue. 2 Issue is not customer facing or has no significant impact on the organisation's brand 3 Fixing cost of root cause is significant. BAU or project does not have budget.
Saving Changes...
Vinay GoswamiProgram/ Project Management Professional| Ananya Advisory Support ServicesWerribee, Victoria, Australia
Culturally, people (Leaders) are called HERO for dousing fires. You become Hero in the eyes of management for managing the issues (Fire), not resolving or fixing root cause. External incentives reward those who keep the controlled fire simmering in place of fixing the root cause. This is done due to two factors: 1. Budget savings: Project Sponsor and Project Manages show that they delivered project within budget despite having issues. Let the BAU team spend OPEX budget and fix the root cause. Pushing issues under the carpet is quite common to show savings in CAPEX. Timelines/Schedule - Fixing issues requires additional time and change requests - hence delays the GOTO production/Live. This has impact in bonus and reputation of many Sr management employees. Hence, they do not allocate budget or time. Additionally PMOs, auditors and QA play the politics of blame games. Hence, astute PMs do what saves their skin and allows them to move on to new good project with minimum backlash. To back up my above statements, I give the evidence of various statements that you will hear on regular basis from project sponsors, PMs and project teams, i.e. "We will cross the bridge when time comes." OR "It is not a Show stopper" OR "We will fix it next Qtr when budget is available" etc etc.. Literally all these statements means, let the issue/s (Fire) become critical, and then we will address it. During my three and half decades of engineering and ICT project management journey as Project and Program Manager, nobody in management has rewarded those project managers who had put additional efforts in business case preparation, project initiation and planning. Because it requires Thankless-effort in planning, budgeting and scheduling program/ project structure. Most of the project sponsors have their incentives linked to short term goals (i.e. Qtrly, Bi-Annual or Max - Annual). Rarely they have interest in long term view. Long term approach of fixing root causes does not earn bonus (in fact it is a dis-incentive) for Sr Managers, also it does not earn STARS for PMs. Hence, they do not address the risks unless they precipitate and become really critical in project life or warranty period. PMOs, Security Auditors and QA are only interested in playing tennis game of blaming PMs and teams. Turn-key projects which are bidded and executed by external/ consulting organisaitons further incetivise approach of cutting corners. Hence, PM intentionally do not do job of identifying and documenting all the risks. This approach is further encouraged by short term approach of Agile methodologies. Hence, you can not just blame the PMs or project teams for not addressing the root causes. Most of the project contractors manage their renewal of project contracts by keeping the issues alive and not addressing the root cause. You can experience it maximum in transformation projects which disturbs the power structures in organisations. By holding back information details of root cause, technical PMs and SMEs consolidate their position in corporate structure.
Saving Changes...
Vinay GoswamiProgram/ Project Management Professional| Ananya Advisory Support ServicesWerribee, Victoria, Australia
Apr 11, 2026 10:39 AM
Replying to Anton Oosthuizen
...
That is an interesting perspective Aaron Porter , and I'd venture to say no to your closing question. We do not always fix the root cause when we understand it. Why would that be? It sounds counterintuitive. IMO I believe that often we find the root cause, but we do not know that it is the root cause. But then, when we do realise that it is the root cause, we just as often ignore it because of the pain involved in fixing it. Too often have I seen people living with the pain of a problem but refuse to do something about it because fixing it would, according to them, it would be more painful to fix it that to live with it. We do not acknowledge that the pain of fixing it is temporary while the pain or ignoring it is permanent.
I beg to disagree. It rarely happens that we do not know the root cause and solution that can permanently fix the issue. However the issues linger due to following factors: .1. Lack of economic incentive and criticality of issue. 2 Issue is not customer facing or has no significant impact on the organisation's brand 3 Fixing cost of root cause is significant. BAU or project does not have budget. Saving Changes...
Community Champion
