When a project is in trouble, the instinct is to look at the delivery team. Occasionally that is right. More often the team is competent and the structure around it is not.
The observable symptoms of governance failure look like delivery failure — slipping dates, growing change, deteriorating relationships — which is why the diagnosis is so frequently wrong, and why replacing people so frequently fails to fix anything.
Decision latency is the usual mechanism
Every project generates decisions continuously. The rate at which those decisions are closed determines the rate at which work proceeds.
Where a decision requires an authority that meets monthly, the project acquires a floor on its response time. Where it requires consensus among parties with different incentives, it may not close at all. Where nobody is certain who holds the authority, the decision circulates.
The cost is invisible in reporting, because there is no line item for a decision that took eleven weeks instead of two. It shows up later as change, as acceleration, or as a design that was developed around an assumption while everyone waited.
The most expensive thing on most projects is not what was decided. It is how long it took to decide it.
Authority that does not match accountability
The second pattern is a mismatch between who is accountable for an outcome and who can actually direct it.
A project director accountable for a date but unable to approve expenditure above a low threshold cannot manage the trade-off between cost and time — which is the central trade-off on any project. Every such decision escalates, and the escalation path was designed for exceptions rather than for the daily operation of a large program.
The diagnostic question is simple: for each of the three or four decisions that most determine the outcome, who can make it, and are they close enough to the work to make it well?
Reporting designed to reassure
The third pattern is a reporting structure that answers the wrong question.
Most project reporting answers is the project on track against plan. The more useful questions are what has changed, what is now known that was not known before, and what remains undecided. A report structured around the first question will show a stable position for as long as the plan has not been formally revised, which can be well past the point at which it stopped being true.
What good structure looks like
Effective project governance is unglamorous and consists largely of writing things down.
A decision register with named owners and required-by dates, reviewed at the same cadence as cost and schedule. Delegated authority set at a level that allows the majority of decisions to be taken by people close to the work. A defined escalation path with a committed response time. Reporting that shows change and open decisions rather than only status. And a single point of accountability for the owner's interest across the whole program, rather than an interest distributed across several parties, each responsible for part of it.
That last point is the one most often missing. Every other participant on a project has a contract that rewards something narrower than the project's success. The owner's overall interest is the only one that nobody is specifically paid to hold, and unless it is deliberately assigned, it is held by nobody.
Where to start
On a project already in difficulty, the fastest diagnostic is to list every decision currently open, how long each has been open, and who owns it.
The list is usually longer than management expects, the durations longer still, and a material share of the entries will have no owner at all. That list, on its own, generally explains more of the position than the cost report does.
