Program Risk Management: How It Differs from Project Risk and How to Run It

Program risk management is the practice of identifying, assessing and responding to uncertain events that could affect a programme's objectives. Those objectives are strategic and tied to benefits. Project risk management does the same for one project's scope, time and cost. The difference between programme risk and project risk is the objective at stake, not the size of the work.

Programme risk is not the sum of project risks. Many project risks never matter to the programme. Some programme risks appear in no project's register at all, such as a handover between two components that nobody owns.

Early practice often copied the project process upwards. A PMI Global Congress paper of 19 October 2008 (Hillson) argues that programmes are not large projects and that their risk needs a different approach. It was written when programme management was less mature than project management, so treat it as the foundation and adapt it to your programme.

Program-level risk management works on two levels. Overall programme risk is the programme's total exposure, managed implicitly through how the programme is designed. Individual programme risks are specific uncertain events, managed explicitly through a register, an owner, and a response.

A project manager works mostly at the explicit level. A programme manager has to work at both. In our view, the implicit level comes first because it is cheaper: a risk you never took needs no register line. We cover it in the section on reducing risk before a register exists. The explicit process follows in the section on running the process.

The sources of program risk are three: components below the programme, strategy above it, and the programme itself. Each reaches the register by a different route, and a programme that watches only one source misses the others. The table sets the three side by side.

Every route ends in the same place: the programme risk register, where each risk has one owner, one exposure figure and one route.

Escalated or aggregated from components

Component risks reach the programme in two ways. A single large risk is escalated. Related small risks are aggregated. Risk aggregation, as Hillson (2008) describes it, works in two ways: by summation, where ten insignificant project risks may add up to one significant programme risk, or by synergy, where the whole exceeds the sum of its parts.

A shared risk breakdown structure, a common tree of risk categories used by every component, makes related risks easier to spot. Escalation criteria decide which risks move up, and the programme's risk plan should record them.

For cumulative exposure, one of the 12 US defence programmes in a PMI research paper of 16 July 2008 (Patanakul) reported the sum of its individual exposures, each being likelihood multiplied by impact. That study used self-reported documents from defence contractors, so adapt the idea rather than copy it.

Delegated from strategy

Some risks start above the programme: a sponsor's concern about funding, or a strategic assumption that may not hold. The programme takes on the response. The principle, in Hillson’s words, is “delegation without abdication”. In our reading, the programme manager acts and reports back, and the sponsor stays accountable for the strategic risk.

Arising in the programme itself

Two things belong here: the interfaces between components, and the risks of executing and managing the programme. Neither sits in any one project's register. Preventing them is mostly a design matter, which the next section covers.

A note on dates. The Hillson paper (19 October 2008) and the Patanakul paper (16 July 2008) are both older. The APM piece is a summary, published on 7 August 2018, of a webinar held on 2 July 2018. PMI has since published The Standard for Program Management, Fifth Edition, so read it alongside these papers and check the detail against your own organisation’s governance.

You reduce programme risk by how you build the programme. Choose components so that total exposure stays within the organisation's risk appetite, the amount of exposure it is willing to carry, while still delivering the return required. Then split delivery into tranches with stable points, so later tranches can respond to the exposure you actually have.

A register only manages the risks you have already accepted, so this is the cheaper lever. Our recommendation:

1. Before adding a component, ask what exposure it adds on top of the components already in the programme.
2. Mark stable points. A stable point is a place where the programme could pause with something usable intact.
3. Hold back the scope of later tranches. Fix it at the gate, once current exposure is known.

This is the implicit level of programme risk. The APM summary also treats component selection as a way of managing risk before any individual risk is logged.

Small component risks become programme risks when components depend on each other or draw on the same people, vendors or environments. One delay then reaches every component downstream or sharing the resource. Exposures that look separate on component registers land on the same date.

Two patterns cause most of it:

• Dependencies. Component B cannot start until component A hands over. A's six-week slip is also B's.
• Shared resources. Components A and B need the same engineers, or the same test environment, in the same weeks. Neither project sees the clash.

We use one test for every component risk: what else moves if this happens? If the answer names another component, the risk probably belongs in a programme-level view. If it names nothing, it stays with the project. The worked example below applies this test to a shared vendor team and a shared test environment.

Run the program risk management process in six steps, with one named owner on every risk at every step: plan, identify, assess, respond, review, and close with lessons learned. The process follows Hillson (2008). The ownership and cadence advice is our recommendation.

A risk goes up when its owner cannot respond within the authority they hold, and down when a component is best placed to act on it. It goes to the programme board when its exposure is above what the programme manager may decide alone. The programme's governance sets those limits.

Aggregation is a form of moving up: related component risks rise together as one programme risk. Do not push everything up. Escalating minor project issues buries the few risks that matter.

For the tests that decide whether a risk moves, read our page on when a programme should escalate a risk. For who decides at each exposure level, see our programme governance framework.

This program risk register uses the same illustrative programme as our governance article: a ₹40 crore baseline budget, an 18-month plan and a ₹15 crore annual benefit forecast. Every figure is illustrative, not data from a real programme.

The decision limits come from that article. The programme manager decides up to ₹0.8 crore of exposure, the programme board above ₹0.8 crore up to ₹2 crore, and the sponsor above ₹2 crore or on any legal or regulatory breach. There are four components: A platform build, B data migration, C staff training and D test environment. Exposure is probability multiplied by impact, in ₹ crore.

The working for PR-1. R1, R2 and R4 share a common cause: components A and B compete for the same scarce delivery resources, one pool of vendor engineers (R1, R2) and one test environment (R4). That shared constraint is why they are aggregated into one programme risk. Their exposures are:

• R1: 40% × ₹1.50 crore = ₹0.60 crore
• R2: 50% × ₹0.80 crore = ₹0.40 crore
• R4: 40% × ₹1.00 crore = ₹0.40 crore

Their sum is ₹1.40 crore. Each is below ₹0.8 crore, so each is within the programme manager's own decision limit and would not reach the board on its own. The project managers own and manage them day to day. Together they sit in the board's band, so PR-1 goes to the programme board.

Method and assumptions.

• Method: we aggregate by simple summation. The figure is a screening number. If the owners judge that the delays would overlap and absorb each other, the true exposure is lower. If one slip triggers another, it is higher.
• Limits: we apply the ₹0.8 crore and ₹2 crore limits to each risk, including each aggregated risk, one at a time.
• Total: the register's total screening exposure is PR-1 ₹1.40 crore + R3 ₹0.27 crore + S1 ₹0.50 crore + P1 ₹0.36 crore = ₹2.53 crore, or 6.3% of the ₹40 crore baseline.

If your governance applies the limits cumulatively instead, that total crosses ₹2 crore and goes to the sponsor. Settle that rule when you design governance, before the first risk arrives.

Practise by writing one register line for every scenario: where the risk came from, who owns it, what exposure it carries and which level decides. That is our recommendation for PgMP® preparation. Program Management Professional (PgMP®) is PMI's certification for programme managers, and PMI sets its exam content and eligibility rules, so read the current versions on PMI's PgMP page.

If you hold Project Management Professional (PMP®) certification and are moving into programme work, our guide to the PMP to PgMP transition covers how project artefacts such as risk registers are reframed.

If you would like the fundamentals in a structured form first, Program Management Essentials is our foundation course. It is not PgMP® exam preparation.

To check where you stand against the exam, try our PgMP® exam readiness scorecard.

Programme risk management comes down to a few habits. Know the two levels: the exposure you build into the programme, and the individual risks you log. Watch all three sources, not only the components. Aggregate related component risks into one programme risk, and give it one owner and one route.

Start with how the programme is designed, then build the register. Do that, and the board sees the risks that matter instead of a pile of project registers.

If you would like to talk through your goals before enrolling, book a free discovery consultation, or write to support@augmentconsultancy.com or call or WhatsApp +91 9816 360 116.