Every PMO manager has seen it. A project delivers badly. An escalation reaches leadership. A review is conducted, findings are documented, and a corrective action is agreed. Six months later, a different project — different team, different client, different sector — produces the same failure in almost identical form.
The ownership gap that caused the first escalation causes the second one. The scope dispute that derailed the first delivery derails the second. The communication breakdown that surprised the client the first time surprises a different client the next time.
The fix did not stick. It never does. And the reason is consistent across organisations, sectors, and project types: the intervention addressed the symptom, not the structure.
What organisations typically try
When project delivery breaks down repeatedly, the response tends to follow a predictable sequence.
The first intervention is usually a tool. A new project management platform is introduced — a centralised system that will make work visible, track progress, and give leadership the reporting it needs. The tool is procured, configured, and rolled out. Within months, adoption is inconsistent. Some teams use it fully. Others use it partially. Others revert to spreadsheets and email. The visibility problem remains because the tool did not address why visibility was absent in the first place.
The second intervention is usually training. Project managers are sent on courses. Methodology frameworks are introduced or refreshed — PRINCE2, PMP, Agile. Governance templates are redistributed. The training is completed, the certificates are issued, and delivery continues largely as before. Individual PMs may improve. The organisational pattern does not change because the training addressed individual capability, not structural conditions.
The third intervention is usually restructuring. Reporting lines are changed. A PMO is created, or the existing PMO is reorganised. Roles are redefined. New governance forums are established. For a period, the increased attention produces improvement. Then the new structure settles, the forums become routine, and the same failure modes resurface — because the restructuring changed who is accountable without clarifying what they are accountable for, or how accountability is exercised when something goes wrong.
None of these interventions are wrong in principle. Tools, training, and structure all have legitimate roles in a well-functioning project environment. The problem is sequencing. They are applied before the structural conditions that make them effective are in place.
What the structural conditions actually are
A project management tool makes work visible. It cannot make ownership clear. If the decision about who is accountable for a piece of work has not been made explicitly — documented, communicated, and agreed — a tool will show you that the work exists. It will not tell you who is responsible when it stalls.
A methodology framework provides a process to follow. It cannot install the organisational will to follow it. If escalation criteria are defined in a framework but never translated into specific agreements for a specific project with specific named owners, the framework is a reference document. It is not an operating agreement.
A restructured PMO creates a governance function. It cannot create governance behaviour. If the people in the new structure have not made explicit decisions about decision rights — who approves what, under what conditions, within what timeframe — the structure will produce meetings and reports. It will not produce the closed-loop decision-making that governance requires.
The structural conditions that determine whether any of these interventions will work are simpler than they appear. Is decision ownership explicit and named — not a team, not a function, but a person? Is the workflow documented step by step, not as it is supposed to work, but as it actually works today? Is there a defined failure mode — a documented answer to the question of what happens when something goes wrong at each critical point?
When these conditions are not in place, tools amplify existing confusion, training produces individual improvement that the structure absorbs and neutralises, and restructuring moves the problem rather than resolving it.
Why the pattern persists
The persistence of the pattern is not a failure of effort or intention. Most organisations invest seriously in improvement. The pattern persists because the diagnostic that precedes the intervention is almost always incomplete.
Post-project reviews identify what went wrong. They rarely identify why the structural conditions that allowed it to go wrong were present in the first place, or whether those conditions exist across other projects and functions. The review is project-scoped. The problem is organisation-scoped.
Corrective actions address the proximate cause — the specific communication failure, the specific ownership dispute, the specific scope gap — without addressing the structural gap underneath it. The proximate cause is resolved. The structural gap remains. It surfaces again in the next project, in a slightly different form, with slightly different people, producing a slightly different complaint from a different client.
This is why lessons learned registers rarely produce learning. The lessons are captured at the project level. The structural conditions that generated them exist at the organisational level. There is no mechanism to translate a project-level observation into an organisational-level change in governance structure.
The fix does not stick because it is applied at the wrong level.
What a structural intervention looks like
A structural intervention does not start with a solution. It starts with a diagnosis — a deliberate, evidence-based assessment of the governance conditions across the project environment, not just within a single project.
It asks whether ownership is explicit at every critical handoff point, not in a specific project that just failed, but as a general condition of how work is managed. It asks whether workflows are documented as they actually operate, not as the methodology says they should operate. It asks whether failure modes are defined — whether the organisation has explicit answers to what happens when a handoff is missed, an approval is delayed, or a risk materialises.
The output of that diagnosis is not a set of recommendations. It is a verdict. Either the structural conditions are in place and the environment is ready for a redesign or an improvement intervention — or they are not, and the intervention must address the structural gaps first.
This sequencing is not a formality. It is the difference between an improvement programme that produces lasting change and one that produces a well-documented record of effort with no durable outcome.
The fix sticks when it is applied to the right level of the problem. It never sticks when it is not.
"The fix does not stick because it is applied at the wrong level. Lessons are captured at the project level. The structural conditions that generate them exist at the organisational level."