Governance Should Reduce Work

Good governance should reduce the amount of coordination a programme needs, not increase it. That sounds obvious, but governance often grows in the opposite direction.

A programme becomes more complex, so more status meetings are added. More reports are requested. Central teams collect updates from workstream leads, rebuild dashboards and chase actions that already exist somewhere else. Eventually the governance layer becomes a second delivery system sitting on top of the real work.

I think that is usually a sign that the operating model is wrong.

Centralised status collection does not scale well

On one major programme I led, the delivery model grew to more than 500 activities, 85 milestones, 79 risks and 23 critical decisions across 15+ workstreams. Trying to manage that scale through a central PMO manually collecting status would have created a permanent coordination problem.

Instead, I designed the control model around distributed ownership. Workstream leads owned their detailed activities, milestones, risks and decisions, while the central programme layer concentrated on common definitions, cross-workstream dependencies, exceptions, critical decisions and executive reporting.

The point was not simply to put everything into Jira. It was to create one source of programme information that could support different audiences without asking teams to recreate the same status repeatedly.

That distinction is important because tooling alone does not make governance scalable. The underlying ownership model does.

Governance should be part of delivery, not reporting after delivery

A lot of governance fails because the information required for reporting is captured separately from the work itself. Teams execute in one place and then explain what happened somewhere else, creating delay, duplication and interpretation.

I prefer to define the information needed for programme control at source: ownership, milestone dates, dependencies, risks, issues, critical decisions and evidence of readiness. Once those things exist in a consistent structure, reporting becomes a view of the delivery system rather than a parallel process.

That is a much more scalable model because the programme is not reconstructed for every reporting cycle. The reporting layer reflects the state of the work rather than asking teams to produce a separate narrative about it.

Different audiences need different views, not different data

Executives do not need the same level of detail as delivery teams. A COO or CTO needs to know whether the programme is becoming ready, where material risk is increasing, which dependencies threaten a milestone and which decisions require intervention. A workstream lead needs more detailed actions and dependencies, while a delivery team needs the specific work it owns.

Those are different views of the same programme, not three separate reporting processes.

The governance model I built used that principle: executive, workstream and delivery views were generated from one underlying source of information. This also made conversations more useful because people were debating the same underlying reality rather than reconciling several versions of it.

Automation should remove coordination, not judgement

Automation is useful when it eliminates repetitive coordination. Upcoming and overdue reminders, workflow transitions, standard reporting views and recurring prompts can all be automated.

But automation should not replace the judgement that programme leadership is there to provide. A system can identify an overdue dependency, but it cannot decide whether the consequence justifies replanning the critical path. It can show that a decision is late, but it cannot determine the best trade-off between scope, timing and risk.

The aim is therefore to automate the mechanics so that programme-management time is spent on interpretation, challenge and decisions. That is where experienced judgement adds value and where a workflow tool, however sophisticated, still needs people around it.

Exception reporting is more useful than universal reporting

When every item receives the same reporting attention, the important things become harder to see. I prefer governance that makes normal delivery relatively quiet and causes exceptions to become visible.

That means agreeing what qualifies as an exception: a threatened critical milestone, an unresolved cross-workstream dependency, a material risk, a decision that is approaching its required date, or financial exposure outside the agreed range.

Leadership attention can then go to the places where intervention can actually change the outcome. This is particularly important on programmes with many workstreams because executive capacity is limited too.

Good governance therefore does not simply increase visibility. It helps prioritise attention.

Adoption is part of the design

A technically elegant governance framework is useless if teams do not maintain it. On the programme above, active adoption rose from approximately 60% to 95% as the model matured and workstream ownership became more established.

The increase mattered because the governance model depended on information being maintained where the work happened. That required making the process usable for functions with very different ways of working, including teams outside traditional technology delivery.

I later reused elements of the same framework on other programmes, adapted it with the Head of Legal for legal demand and reporting, and saw core elements incorporated into standard project and programme templates.

That reuse is a better test of governance quality than how impressive the original dashboard looks. A governance model has value when people can operate it without the person who designed it standing behind them.

Good governance creates less management overhead

The purpose of governance is control, but control does not require centralising everything. In many cases the opposite is true.

Clear ownership reduces chasing. Shared definitions reduce reconciliation. Automation reduces repetitive coordination. Exception reporting reduces unnecessary escalation. A common source of information reduces the need to rebuild status for every audience.

The result should be a programme that needs less manual management as the governance model matures, not more. That is the standard I use when assessing a PMO or programme-control system.

If the governance layer is creating more work than the complexity it removes, it is probably solving the wrong problem.