Building and Running a Programme Management Office

What a PMO Should Do

A Programme Management Office exists to make delivery easier, not harder. Its core functions:

• Standards and consistency: Common templates, processes, and quality bars across projects
• Reporting and visibility: Aggregated programme health for governance forums
• Resource coordination: Visibility of capacity and demand across the programme
• Risk and issue escalation: Structured path from project-level to programme-level
• Knowledge management: Lessons learned, best practices, and reusable assets
• Assurance: Independent health checks that surface problems early

What a PMO should NOT do:

• Police compliance for its own sake
• Create reports nobody reads
• Add approval gates that slow delivery without reducing risk
• Duplicate work that Project Managers already do
• Become a bottleneck for routine decisions

PMO Models

Supportive PMO (Lightest)

Provides templates, tools, and guidance. Projects choose whether to use them. No enforcement.

Best for: Mature organisations with experienced PMs who need coordination, not control. Risk: Inconsistency across projects makes aggregated reporting difficult.

Controlling PMO (Medium)

Defines standards and requires compliance. Reviews project artefacts for quality. Provides reporting.

Best for: Organisations with mixed PM maturity that need consistency for governance. Risk: Can become bureaucratic if standards are excessive or enforcement is rigid.

Directive PMO (Heaviest)

Directly manages projects. PMs report to the PMO. Full control over methodology, tools, and delivery.

Best for: Organisations with low PM maturity or very high-risk programmes requiring tight control. Risk: Removes autonomy from delivery teams. Can create a command-and-control culture.

Recommendation: Start with Supportive, evolve to Controlling only where inconsistency causes real problems. Directive is rarely appropriate for Agile delivery environments.

Setting Up the PMO

Step 1: Define the Value Proposition

Before building anything, answer: "What problem does this PMO solve?" Common answers:

• "We can't see aggregate programme health across projects"
• "Every project uses different templates and processes — governance is inconsistent"
• "Lessons from one project never reach the next project"
• "Resource conflicts between projects are resolved by whoever shouts loudest"

The PMO's scope should be limited to solving these specific problems — not expanding into everything project-related.

Step 2: Define Core Services

Start with 3-5 core services. Add more only when demand demonstrates the need:

1. Reporting: Aggregate programme dashboard from project data 2. Standards: Common templates for status reporting, RAID, and change control 3. Resource visibility: Capacity and demand view across all projects 4. Governance support: Steering committee preparation and decision tracking 5. Assurance: Quarterly project health checks (supportive, not punitive)

Step 3: Staff Appropriately

A PMO doesn't need to be large:

• Small programme (3-5 projects): 1 PMO coordinator (part-time may suffice)
• Medium programme (5-10 projects): 1-2 PMO analysts + PMO lead
• Large programme (10+ projects): PMO lead + 2-3 analysts + reporting specialist

Key principle: PMO staff should have delivery experience. A PMO staffed by people who've never managed a project will create processes that don't work in practice.

Step 4: Establish the Operating Rhythm

• Weekly: Collect project status data, update programme dashboard, flag exceptions
• Fortnightly: Prepare steering committee pack, coordinate pre-reads, track decisions
• Monthly: Resource demand review, financial consolidation, risk aggregation
• Quarterly: Lessons learned synthesis, standards review, PMO effectiveness assessment

PMO Deliverables

The Programme Dashboard

Aggregated view of all projects:

• RAG status per project with trend
• Milestone delivery rate across the programme
• Budget performance (aggregate CPI)
• Resource utilisation and demand forecast
• Top programme-level risks

The Standards Library

Maintained set of templates and guides:

• Project status report template
• RAID register template
• Change request form
• Lessons learned template
• Estimation guidelines
• Definition of Done standards

Key principle: Templates should save time, not add work. If a template takes longer to fill in than the value it provides, simplify it.

The Resource View

Cross-project resource visibility:

• Who is allocated to which projects at what percentage
• Where are the conflicts (same person, multiple projects, same period)
• Where are the gaps (skills needed but not available)
• Forecast demand for the next quarter

The Assurance Report

Quarterly independent assessment of project health:

• Is the project following agreed standards?
• Are risks being managed actively?
• Is the team delivering against commitments?
• Are there early warning signs of trouble?

Critical: Assurance must be supportive, not punitive. The goal is to help projects succeed, not to catch them failing. Share findings with the PM first, give them time to respond, then report to governance.

Measuring PMO Value

The PMO must demonstrate its own value — otherwise it's just overhead:

• PM satisfaction: Do PMs find the PMO helpful? (Quarterly survey, target: >4/5)
• Reporting efficiency: Time PMs spend on governance reporting (should decrease with PMO support)
• Decision speed: Time from "decision needed" to "decision made" (should improve with PMO coordination)
• Standards adoption: % of projects using PMO templates and processes (voluntary adoption = genuine value)
• Governance effectiveness: Steering committee satisfaction with information quality

If PMs actively avoid the PMO or work around its processes, the PMO is adding friction, not value. Listen to that signal.

PMO Anti-Patterns

The process factory: Creates elaborate processes that nobody follows because they're disconnected from delivery reality. Fix: co-create processes with PMs. If they won't use it voluntarily, it's not useful.

The reporting machine: Spends all capacity producing reports and dashboards that nobody reads. Fix: ask consumers: "What do you actually use from this report?" Remove everything else.

The compliance police: Focuses on catching non-compliance rather than enabling success. Fix: shift from "you didn't fill in the template correctly" to "how can I help you get this information to steering effectively?"

The empire builder: Continuously expanding scope and headcount without demonstrating proportional value. Fix: PMO scope should be demand-driven. Add services only when projects request them.

---

Download the [Delivery Dashboard template](/templates) for a PMO-ready programme health reporting format.