The dashboard is green; the programme cannot choose
Written in 2026, this retrospective examines a governance problem in 2018 IT programmes: the gap between document consolidation and the ability to decide. Characters and figures are educational, unrelated to a real CYTIZEN engagement. The programme management office, or PMO, is a programme leadership function here; it replaces neither the sponsor nor business owners.
Thomas finishes Monday's pack. Four vendors have supplied numbers; ten workstreams are green or amber. Julie, customer service owner, asks whether an incomplete order can be handled on day one. Nobody knows. CRM is green because its screens are developed. ERP is green because standard interfaces are tested. Support is amber because training is late. No status says the combined journey has never been executed.
The PMO has consolidated the requested information perfectly. It has nevertheless lost the question the sponsor needs answered. Its value is not choosing a more pessimistic colour. It is rebuilding the dependency, specifying the obstacle to an outcome, framing options and getting an authorised decision-maker to give a clear answer.
Organise around decisions that matter
Before selecting a tool, Thomas inventories recurring decisions: commit budget, move a date, accept a process deviation, allocate a shared expert, authorise service release or change a contract. Each has an authority. A business department can prioritise locally; it cannot alone allocate an architect committed to three programmes. The PMO exposes that boundary instead of maintaining an implicit approval route.
The mandate also states what the PMO can do: request evidence, return an incomplete status, bring dependency owners together, propose a scenario and maintain the log. It cannot invent a missing estimate or accept a quality exception on behalf of the accountable authority. Precision protects the team and prevents authority inflation.
The inventory need not contain every design choice. Retain decisions crossing teams, changing commitments or creating material exposure. For others, delegated authority and a backlog record suffice. Governance that escalates everything eventually leaves waiting the very decisions that genuinely require escalation.
Replace a percentage with journey evidence
Thomas asks teams to replay an incomplete order with a missing product reference, an address amended after approval and a credit note. The test is not a trap for the integrator. It crosses responsibilities hidden in component-level acceptance. The team records identifiers, events, recovery rules and support intervention. A screenshot of success does not explain how the journey was controlled.
The test reveals that an address correction originates in CRM while ERP keeps the old value. Recovery needs an administrator outside the support model. The gap is now explicit: this service cannot guarantee recovery of these orders without project assistance. The PMO connects it to the sponsor's release criterion. The team stops spending twenty minutes debating shades of green and amber.
Percentages remain useful, but acquire a precise meaning. “Ninety per cent of tests executed” is work information; it does not establish critical-case coverage. Accepted critical scenarios are reported separately, showing the expected total and remaining defects.
A decision pack the sponsor can use
| Element | Content |
|---|---|
| Required outcome | Support can recover an amended order without a project administrator. |
| Observation | Three of five recoveries fail on CRM-to-ERP address updates. |
| Option 1 | Delay one week; integration fixes the defect and support replays all five cases. |
| Option 2 | Open a limited scope with controlled manual recovery and dedicated capacity. |
| Excluded option | Release full volumes using an undocumented workaround. |
| Decision | Sponsor decides date/cost; business approves scope restriction; support accepts recovery. |
| Evidence | Five complete recoveries, reconciled addresses and no project-only privileges. |
Do not plan with imaginary capacity
The plan shows one data expert available to five workstreams at once. Each assumes a quick response. The PMO converts requests into comparable slots: preparation, analysis, execution and validation. It distinguishes contractual attendance from useful capacity. An expert present five days may have only three available after incidents, meetings and recurring duties.
Here, requests total twenty days over two weeks; useful capacity is six. Asking teams to “be more agile” does not close the gap. The PMO prepares three options: sequence workstreams, reduce scope or mobilise another expert with an allowance for learning. The sponsor sees which dates and evidence change. Each workstream's plan is then amended, not just the executive summary.
Business and vendor capacity also need checking. Scheduling thirty approvals during financial close is not credible. An oral promise is not a reservation. The responsible manager explicitly confirms slots and a replacement when needed.
Maintain one decision, not five versions
After approval, Thomas gives the decision an identifier and links its brief, assumptions and agreed changes. The vendor receives the same reference as business and finance. A shared register can suffice when tools differ: consistency and versioning matter more than immediately buying a platform.
A date change affects contracts, training, support and downstream dependencies. The PMO checks these consequences with their owners. A clearly worded decision that is never reflected in execution is an instruction without implementation. The next review shows what is done, what remains conditional and which new facts could alter the choice.
The history retains superseded decisions. Finding a judgement invalidated by a new constraint is preferable to erasing every trace to make the plan look flawless. Leadership can distinguish learning from the concealment of earlier commitments.
Measure useful PMO work
Decision lead time runs from readiness to approval by the appropriate authority. Readiness means options, impacts and owners are identified; dating the first email would make cases incomparable. Track the median and the oldest decisions. A critical case blocked for thirty days can disappear among many quick, low-consequence responses.
Decision implementation rate is commitments met by their deadline divided by commitments due. Conditions and agreed changes accompany it. Critical dependency coverage is dependencies with an owner, date and resolution test divided by those identified. These three measures can guide a review without turning the PMO into an indicator factory.
In this scenario, an alert is raised when a critical decision waits more than five working days or a release dependency lacks an owner. These are agreed educational thresholds. An urgent security matter might require an answer within hours; a business-model change could need more preparation.
Different sectors need different evidence
In pharmaceuticals, progress evidence may include qualification, approved procedures and deviation handling. The PMO maintains the quality link rather than renaming documentation as business acceptance to accelerate a milestone. Versions and approvals are rollout dependencies, not late appendices.
In banking, a journey transformation must address reconciliation, access, close periods and risk acceptance. Average availability does not establish the ability to complete a sensitive operation. Tests are linked to the periods and activities where impact is greatest.
In an international industrial group, site calendars, languages and local capacity can require sequencing. A technically ready wave may not be operable across shift changes. The PMO makes these limits negotiable before publishing a global date. In a small organisation, the same work may fit into a weekly hour and a register: the method does not justify expanding governance headcount.
Install the practice without stopping delivery
In week one, select five open decisions and check their wording. In week two, link two critical journeys to acceptance evidence and support responsibilities. In week three, review only skills that block several workstreams. In week four, the sponsor decides which old reports can disappear because they add no useful information.
Do not rebuild the entire framework before handling today's obstacle. The PMO demonstrates value on a real decision, then extends working rules. Thomas does not obtain a trouble-free programme. He obtains leadership able to explain why the next date may move, which option deserves investment and who must answer before Friday.
Sources and method
This article separates governance method, constructed example and official references. Current pages inform mandates and measurement; scenarios, thresholds and working arrangements remain original recommendations. GovS 002 existed in 2018, but its 2025 update is cited as a current reference without backdating. No PMO success rate or real client benefit is inferred from these sources.
- GOV.UK — Governance principles for agile service delivery
- GOV.UK — GovS 002, Project Delivery; first published in 2018, current version updated in 2025
- GOV.UK — How to set performance metrics for your service
Links checked on 4 October 2026. The scenarios and thresholds in this article are educational; they do not describe a client engagement or an outcome delivered by CYTIZEN.