Programme Management
Programme management is the co-ordination of several related projects towards an outcome that none of them delivers alone. The programme owns the dependencies between projects, the shared resources, the benefits, and the governance that resolves conflicts between them. Individual projects keep their own scope, plan and delivery accountability.
What it contains
A programme is defined by an outcome — a platform replaced, a business model changed, a regulatory position reached — and by the projects assembled to reach it. The programme layer holds a small number of artefacts that no single project can hold: an integrated plan showing how the projects sequence, a cross-project dependency register, a shared risk and issue view, a benefits map linking outputs to the outcome, and a governance structure with defined decision rights.
It also holds the things that are shared in practice: the environment plan, the release calendar, the vendor contracts, the communications plan, and often the test and data functions. When several projects need the same integration environment in the same fortnight, the programme resolves it.
How it is used
Day to day, programme management is dependency and decision work. Projects report their own status; the programme reads across them for conflicts, then escalates what cannot be resolved at that level. The mechanism is usually a weekly or fortnightly programme board of project managers, feeding a monthly steering committee that owns funding, scope changes and unresolved escalations.
The dependency register does most of the work. Each entry names a provider, a receiver, what is being provided, the date it is needed, and the current confidence. Dependencies between teams are the commitments most likely to fail quietly, which is why the guide on tracking what you don't control treats confidence as a field rather than an opinion.
Programme governance also sets the reporting standard so that a dozen projects report in one format. A governance pack covering RAID, dependencies, actions and status exists precisely so the roll-up is mechanical rather than a weekly assembly job.
Where it goes wrong
The usual failure is a programme that adds a reporting layer without adding decision-making. Projects report twice — once to the programme, once to their own sponsor — and the programme has no authority to reallocate money or people. It becomes a consolidation service, and the dependencies it identifies go unresolved because nobody at that level can resolve them.
The second is scope by absorption. Anything vaguely related is attached to the programme because the programme has funding and attention. The outcome becomes unmeasurable and the critical path stretches until the original rationale is forgotten.
The third is benefits that belong to nobody. The programme delivers outputs and closes; the benefits were owned by an operational director who was never involved in defining them. This is a closure problem as much as a programme one, and it is why benefits handover is a specific step in closing down rather than an assumption.
A fourth: the programme plan is maintained at a level of detail that duplicates the project plans. Two versions of the truth then diverge within a month. The programme plan is useful when it holds milestones and interfaces, not tasks.
Related terms
Project management delivers a defined output to time, cost and quality; programme management delivers an outcome across several such outputs. Portfolio management sits above both and decides what runs at all. Programme office is the support function serving one programme, distinct from a standing PMO. Dependency is the unit of work a programme exists to manage. Steering committee is the board that holds programme-level decision rights.
Questions
When does work need a programme rather than a set of projects?
When the projects share dependencies, resources or a single outcome, and resolving conflicts between them requires authority no individual project manager holds.
Does a programme manager manage the project managers?
Often, but not always. In some structures project managers report to their own business units and the programme manager co-ordinates without line authority, which makes governance and escalation routes more important.
What does a programme plan contain?
Milestones, interfaces between projects, shared resource commitments and gate dates. Task-level detail stays in the project plans to avoid maintaining two versions of the same schedule.
How long should a programme run?
Long enough to deliver the outcome and no longer. Programmes that outlive their original rationale usually continue because the funding and the team exist, not because the outcome is still pending.