PMO & Programme Governance
The PMO is the function that makes an ERP programme legible: what is being spent, what is being decided, what is slipping and who is accountable. It is a delivery concern rather than a business one, and confusing the two is how programmes end up governed by the people who cannot change anything.
If you change this
It implies 2 topics across 2 modules, including Projects and Portfolio (PPM) which you might not expect.
See the path ahead →Why it matters
An ERP programme runs for a year or more, spends millions, and touches every part of the organisation. Without a function holding the plan, the money, the decisions and the risks in one place, each workstream optimises for itself and the integration cost surfaces at testing.
- It holds the single plan: One schedule across streams, so a dependency between payroll and the ledger is visible before it bites.
- It holds the decision record: Decisions made once, recorded, and not relitigated every steering committee.
- It holds the truth about progress: Status that reflects what is finished, not what is nearly finished.
The workflow
- 01
Set up
Governance bodies, delegations, cadence and the artefacts each one owns, agreed before mobilisation.
- 02
Plan
One integrated schedule across workstreams, with dependencies named rather than implied.
- 03
Track
Progress, spend, risk, issue and decision status collected on a fixed cadence.
- 04
Report
Each forum given what it can act on — steering decides, working groups resolve.
- 05
Control
Change requests, budget movements and scope decisions handled through one route.
- 06
Assure
Independent checkpoints at gates, testing the evidence rather than the confidence.
- 07
Close
Benefits handed to owners, lessons recorded, and the programme actually stood down.
A PMO that only collects status is an overhead. A PMO that owns the dependency map, the decision log and the change route is the thing that keeps the programme finishable.
What you need in place
- A delegation instrument for the programme: What the programme director can approve, what the steering committee must, and what goes to the board.
- A single integrated plan: Not one plan per workstream stapled together.
- One change route: Scope, budget and schedule changes assessed the same way regardless of who raises them.
- A risk and issue register with owners: Risks without named owners are observations.
- Definition of done per deliverable: Agreed before work starts, or status is opinion.
- Independent assurance at gates: Someone whose job is not to deliver the programme.
Questions to ask
01Authority
What can the programme decide without going to the business?
Ambiguity here produces either paralysis or decisions the business does not accept.
02Single plan
Is there one schedule, or one per workstream?
Cross-stream dependencies live in the gaps between separate plans.
03Status honesty
How is percent complete determined?
If it is self-reported effort, it will be ninety percent for months.
04Change route
Can scope change without a change request?
It always can informally; the question is whether anyone sees it.
05Assurance
Who checks the programme independently, and who do they report to?
Assurance reporting to the programme director is not assurance.
06Closure
What has to be true for this programme to end?
Programmes without an end condition become operating costs.
Metrics and KPIs to track
Schedule performance
Milestones met on the baseline date, and cumulative slip.
Budget performance
Spend and committed against baseline, forecast to complete.
Decision latency
Time from a decision being requested to it being made.
Open risks by severity
With owner and mitigation currency.
Change request volume
Raised, approved and their aggregate schedule and cost impact.
Deliverable acceptance
Deliverables accepted first time against those reworked.
Covers