What Delivery Teams Need to Know About Risk Assessment and Mitigation

Risk registers aren't paperwork exercises. They're the difference between a 2 week schedule slip and an 8 week cascade failure across your entire portfolio. Every delivery programme I've managed has had a risk register. But most risk registers I've reviewed on other programmes have been compliance documents rather than operational tools. The distinction between a risk register that actually prevents risk materialising and one that merely records risks that have already materialised is what separates proactive risk management from reactive damage limitation.

Risk Identification Methodology

Effective risk identification on highways programmes requires structured review across five categories. Programme risks affect the delivery timeline and include utility approval delays, weather impacts, and contractor availability constraints. Technical risks affect the quality of the delivered scheme and include design errors, TSRGD compliance failures, and ground condition surprises. Commercial risks affect the budget and include variations in material costs, contractor performance failures, and scope changes requested by the client. Stakeholder risks affect the political environment around the programme and include public opposition, media attention, and local authority political pressure. Safety risks affect the wellbeing of the workforce and the public and include utility strike incidents, traffic management failures, and excavation collapses.

Risk identification at programme initiation should be structured around each of these five categories with specific prompts for each. The prompts should be drawn from historical experience on similar programmes, not generated fresh for each project. Historical risk data from previous programmes is the most reliable source of risk identification prompts because it reflects risks that have actually materialised, not risks that seem theoretically plausible.

Probability and Impact Assessment

Risk probability assessment on highways programmes should use historical frequency data where available. If a Thames Water permit process has experienced a 30% rate of first-pass rejection on similar schemes in the same borough, that 30% probability is a more reliable estimate than a qualitative judgement about whether the permit seems complex.

Impact assessment requires translating risk outcomes into programme terms. A Thames Water permit delay of 4 weeks has a specific impact on the programme schedule depending on whether the permit is on the critical path, near-critical, or has substantial float. A non-critical path item with 8 weeks of float has zero programme impact even if it delays by 4 weeks. A critical path item with zero float creates a 4-week programme extension if it delays by a single day. Impact assessment has to be based on programme position, not on the severity of the risk event in isolation.

Risk Register Governance

A risk register that isn't actively maintained is worse than no risk register. It creates a false sense of risk control. On my programmes, risk register review is a standing agenda item on the weekly governance meeting. Every risk is reviewed, probability and impact reassessed, and mitigation action status updated. Risks that have been mitigated to the point where they no longer represent material programme exposure are closed. New risks identified during the week are added.

This governance discipline means the risk register reflects the current risk position of the programme, not the risk position at initiation. The register is a live tool, not a historical document. When a programme team member identifies a new risk during site operations, there's a clear process for raising it, reviewing it, and adding it to the register if it meets the threshold for inclusion.

Distinguishing Site-Level from Programme-Level Risk

The most important governance discipline on concurrent delivery programmes is the separation of site-level risks from programme-level risks. Site-level risks are local to a specific project and can be managed by the site delivery team without programme-level escalation. Programme-level risks affect multiple projects or have implications for the client's broader programme.

On Old Street and Farringdon, the Gas Networks critical path risk was a programme-level risk because it affected both sites simultaneously and had implications for TfL's connectivity programme. A contractor absence on one site was a site-level risk that could be managed locally without programme-level escalation. Maintaining that separation in the risk register governance ensured that programme-level attention went to programme-level risks, not to site-level issues that the site team was already managing. Real examples from both programmes at olamapped.com/old-street-farringdon-programme.