Risk Management as a Working Practice

Project risk management is the ongoing practice of identifying uncertainty, understanding its effect on objectives, and acting before the team loses its options. A risk can threaten scope, schedule, cost, quality, safety or benefits; it can also create an opportunity. The goal is not a risk-free project. It is informed decisions, clear accountability and fewer avoidable surprises.

Risk, issue, assumption or dependency?

Not every issue began as a recorded risk. Once a risk materialises, link it to the issue log rather than continuing to describe an existing problem as merely possible. Keep any remaining uncertainty—for example, whether recovery will miss go-live—as a separate risk.

Start with a risk management approach

• Agree which objectives matter most: a fixed launch date, a spending limit, patient safety, service availability, regulatory obligations or measurable business benefits.
• Define likelihood and impact scales, assessment horizons and escalation thresholds with the sponsor. A generic matrix cannot decide what an unacceptable safety or compliance exposure is.
• Assign responsibilities: the PM coordinates the process; risk owners manage individual risks; action owners deliver responses; sponsors and governance bodies decide matters beyond delegated authority.
• Set a review rhythm and identify event-driven reviews, such as a design change, failed test, vendor delay or phase gate.
• Agree where the register lives, who may access sensitive entries, and how response costs and contingency decisions will be approved.

How to identify risks before they become problems

Use several identification methods rather than relying on a single brainstorming meeting. Different people see different failure modes: a sponsor sees funding and benefits, a developer sees technical dependencies, and a frontline user sees workarounds that a process map may hide. Include people who do the work as well as those approving it.

1. 1Prepare: share the project objectives, scope, delivery approach, assumptions and main dependencies before the workshop.
2. 2Collect: let participants record concerns independently before discussion so senior voices do not dominate.
3. 3Clarify: turn each concern into a cause, an uncertain event and an effect on an objective; separate existing issues.
4. 4Consolidate: merge duplicates, retain distinct causes, and mark what needs investigation instead of inventing confidence.
5. 5Assign: nominate a risk owner, agree the next assessment or action, and set a review date. Identification without follow-up is only a list of worries.

Write risks properly

Write enough detail to support a decision. 'Lack of resources' is a category, not a useful risk statement. 'Because the specialist analyst is committed to another programme, requirements approval may slip beyond the planned date, reducing the time available for testing' identifies a cause, event and consequence. Any estimated delay or cost range should be supported by delivery evidence, not presented as a certainty.

Different types of project risks

A risk breakdown structure groups risks by source and helps the team check for blind spots. Categories are prompts, not mutually exclusive boxes: a vendor delay can affect both schedule and cost. Give the risk one primary category and record all relevant impacts rather than duplicating the same exposure across the register.

Assess and prioritise: likelihood is not the whole story

Qualitative assessment compares likelihood and impact using agreed definitions. On a 1–5 scale, likelihood × impact produces a score from 1 to 25. The site's Risk Matrix Builder uses Low (1–4), Medium (5–9), High (10–14) and Critical (15–25). These are the tool's screening bands, not universal PMI thresholds. A rating of 4 is an ordinal judgement, not automatically a 40% probability, and multiplying ratings does not produce an expected financial loss.

• Assess impact against the relevant objective: cost, delay, quality, safety, compliance or benefits. Apply your agreed method when several objectives are affected.
• Consider proximity and urgency: a moderate exposure whose response deadline is tomorrow may need attention before a higher-scoring distant risk.
• Record confidence and evidence. Missing information is a reason to investigate, not a reason to label a risk low.
• Look for connected risks: several work packages may depend on the same specialist, vendor or assumption. Separate ratings can hide concentrated exposure.
• Escalate unacceptable safety, security or compliance risks according to policy even when their matrix score is low.

For decisions that justify deeper analysis, use quantitative techniques such as sensitivity analysis, decision trees or schedule and cost simulation with credible inputs. Expected monetary value is probability × financial consequence. For example, a supported 30% probability of a £20,000 loss gives £6,000 expected monetary value—not a prediction of the actual loss or an automatic contingency budget. Simulation can account for interacting uncertainties, but only if dependencies and assumptions are modelled sensibly.

Choose the right response strategy

Avoidance could mean removing an unproven feature from the launch scope. Mitigation could mean testing that feature early. Transfer could involve insurance or a contract allocating a defined financial exposure, but a contract does not make delivery, safety or reputational consequences disappear. Acceptance is a deliberate decision within agreed authority: active acceptance prepares contingency, while passive acceptance monitors without a planned response. Escalate a risk when its response or ownership sits outside the project's authority; record the receiving owner rather than simply removing it from view.

How to turn mitigation into practical action

1. 1Target the cause or consequence. Decide whether you need to reduce the chance of the event, reduce its impact, or both.
2. 2Write a specific deliverable. Replace 'monitor the supplier' with 'obtain and review an end-to-end integration test by the agreed date'. Monitoring alone does not reduce exposure.
3. 3Assign an action owner, due date and budget. The risk owner remains accountable for the overall exposure even when someone else performs the action.
4. 4Check feasibility and trade-offs. A response may cost more than the benefit it protects or introduce new technical, security or schedule risks.
5. 5Define proof of effectiveness: a successful test, confirmed backup capacity or an accepted operating procedure—not just a completed task.
6. 6Reassess residual exposure after the action is implemented and tested. Do not reduce the rating merely because a response has been promised.

Mitigation, contingency, fallback and reserves

Contingency reserve supports identified uncertainty and is generally included within the relevant cost or schedule baseline. Management reserve addresses unforeseen work within project scope and sits outside the cost baseline. Approval and access to either reserve depend on the organisation's governance; they do not automatically belong to the PM or sponsor. Do not treat reserve as a hidden allowance for uncontrolled scope growth.

Worked example: a supplier integration risk

This is an illustrative project scenario, not a reported client case. A team replacing its finance system depends on a supplier interface before user acceptance testing (UAT). The supplier has not yet demonstrated the required end-to-end transaction, and testing is approaching.

The useful result is not a greener cell in a report. It is earlier evidence, a named decision-maker and a credible plan if readiness fails. If the supplier actually misses the checkpoint, open or update the issue and manage recovery while continuing to track the remaining launch uncertainty.

More examples: different risks need different responses

• People risk: the only reporting specialist may leave before handover. Mitigate through paired work and tested documentation; arrange approved backup support if availability falls below the agreed level.
• Adoption risk: a new booking workflow may slow frontline staff and encourage workarounds. Observe real tasks, co-design with users and pilot the change; use readiness evidence to decide whether rollout should proceed.
• Security risk: a test environment may receive unnecessary personal data. Seek specialist review, minimise data and access, and verify controls before use. If exposure occurs, activate the applicable incident process rather than treating it only as a project issue.
• Opportunity: a proven shared component may shorten development. Validate fit and licensing, assign an owner and run a small integration trial; do not commit the schedule saving until evidence supports it.

Keep a risk register that drives decisions

• Record an ID, cause–event–effect statement, category, affected objective, date identified and current status.
• Keep likelihood, impact, assessment rationale, proximity and residual exposure visible; distinguish current assessments from hoped-for improvements.
• Assign a named risk owner and response action owners, with due dates, response costs and evidence of completion.
• Define triggers, contingency or fallback arrangements, escalation authority, next review date and links to related issues or dependencies.
• Store sensitive security, commercial or personal details with appropriate access controls; a public steering pack may need a summarised version.
• Close risks only when the event can no longer occur, exposure has ended or responsibility has formally transferred. Keep the rationale and history.

Review, escalate and communicate throughout delivery

Review active risks with delivery owners at a frequency proportionate to the project. A stable project may use a weekly rhythm; a high-risk cutover may require daily checkpoints. At each review, ask what changed, whether triggers are approaching, which responses are overdue, and whether evidence supports the current rating. Revisit the register after scope changes, incidents, failed tests and major supplier or staffing changes—not just before a steering meeting.

Give governance a decision-focused summary: the exposure, what has changed, what the team is doing, and the decision needed by when. Track overdue response actions, risks without owners, approaching triggers and recurring issues. A falling count of open risks is not proof of improvement; it may mean the team stopped identifying them. At closure, transfer continuing operational risks to an accepting owner and capture lessons for the next project.

Common risk management mistakes

• Writing categories such as 'budget' or 'supplier' instead of an uncertain event with a meaningful consequence.
• Keeping existing issues in the risk register without an active resolution path.
• Calling 'monitor' a mitigation when no action reduces likelihood or impact.
• Lowering ratings before responses are implemented and verified, or treating matrix scores as precise forecasts.
• Assuming a fixed-price contract transfers every delivery consequence, or that acceptance removes accountability.
• Ignoring opportunities, connected risks and the new risks introduced by a workaround.
• Reporting a list of colours without decisions, owners, deadlines or evidence.