Project Delivery · Project Control Methods
Project Risk Control Procedure
Risk control turns uncertainty into explicit decisions. It establishes appetite and tolerance, records cause-event-effect statements, assesses probability and impact, selects proportionate responses, assigns ownership and monitors residual exposure. Communication runs through every step so emerging threats and opportunities influence plans, business justification and authority before outcomes become unavoidable.
Executive summary
What this guide enables
Risk control turns uncertainty into explicit decisions. It establishes appetite and tolerance, records cause-event-effect statements, assesses probability and impact, selects proportionate responses, assigns ownership and monitors residual exposure. Communication runs through every step so emerging threats and opportunities influence plans, business justification and authority before outcomes become unavoidable.
Learning outcomes
- Define project risk context, appetite, exposure and tolerance.
- Write clear cause-event-effect risk statements for threats and opportunities.
- Assess inherent and residual exposure without presenting subjective scores as certainty.
- Plan, own, implement and communicate risk responses through project controls.
Control guidance
Risk control and project uncertainty
A risk is an uncertain event or set of events that, if it occurs, affects one or more objectives. Negative effects are threats; positive effects are opportunities. An issue is different because it has already happened or is happening. Treating every concern as a risk can postpone immediate action, while treating uncertainty as an issue can create premature certainty about impact.
The risk management approach explains how the project will identify, assess, respond to, implement, communicate and review risk. It defines scales, categories, appetite, tolerance, escalation, reporting, roles, timing, expected-value use, proximity, interdependencies, reserves and record standards. The risk register then records each specific risk, its analysis, owners, responses and status. Both must remain usable, not merely complete.
Risk is integrated with every control discipline. A threat can weaken the business case, change stage length, require a quality method, create contingency, affect supplier selection or trigger an exception forecast. An opportunity can justify acceleration or additional investment. Risk information that remains isolated in a register does not control the project.
Appetite
The amount and type of risk the organisation is willing to pursue or retain in pursuit of objectives.
Exposure
The assessed level of uncertainty the project currently presents, individually and in aggregate.
Tolerance
The permitted variation around objectives or risk boundary before escalation is required.
Proximity
When the risk could occur or when a response decision must be made.
Control guidance
Establish the risk context
Context defines what is at risk and which constraints govern response. Review the project objectives, products, acceptance, benefits, schedule, budget, stakeholders, delivery organisations, contracts, technical novelty, external environment, assumptions, dependencies and organisational policies. Identify mandatory safety, legal or regulatory boundaries that cannot be traded through ordinary project tolerance.
Risk appetite should be expressed by category where useful. An organisation may accept schedule experimentation but have very low appetite for safety, privacy or reputation exposure. The governing authority sets or interprets appetite; the project manager designs controls within it. Risk tolerance provides escalation boundaries, while project and stage tolerances cover forecast performance. These concepts should align but are not interchangeable.
Agree scales before scoring. Probability and impact definitions should be meaningful for this project, with impact considered across time, cost, quality, scope, benefits and other relevant consequences. If a matrix is used, document how scores map to action and escalation. Ordinal scores support prioritisation but should not be treated as mathematically precise quantities.
| Context element | Questions | Control output |
|---|---|---|
| Objectives | Which performance and benefit objectives can be affected? | Impact dimensions and ownership |
| Environment | Which market, policy, climate, community or supply factors matter? | External categories and monitoring sources |
| Delivery model | Which interfaces, contracts and capabilities create uncertainty? | Allocation and response constraints |
| Appetite | Which exposure is acceptable, conditional or prohibited? | Escalation and acceptance authority |
| Timing | When can the risk occur and by when must action be taken? | Proximity and response milestones |
Control guidance
Identify risks clearly
Risk identification combines structured workshops, product and schedule review, assumptions analysis, lessons, stakeholder interviews, supplier input, technical review, scenario analysis and ongoing observation. Seek opportunities as well as threats. Avoid generic labels such as 'supplier risk' or 'weather risk'; they are categories, not decision-ready statements.
Use cause-event-effect language. The cause is the existing condition or source of uncertainty, the event is what may happen, and the effect states the objective impact. For example: because a critical interface specification is not yet approved, the component supplier may begin manufacture using an outdated assumption, causing rework, delivery delay and potential quality failure. Separate causes from effects so responses can target the right part of the chain.
Record the risk owner, who is accountable for managing the risk, and later the risk actionee, who performs a specific response. One owner may coordinate several actionees. Ownership should go to a person with authority and access to influence exposure, not automatically to the person who first identified it.
Because of [cause], there is a possibility that [uncertain event], resulting in [effect on objectives].For an opportunity, describe the favourable event and beneficial effect with the same clarity.
Risk identification quality
- Statement contains a genuine uncertainty
- Cause, event and effect are distinguishable
- Affected objectives or products are named
- Risk is not a duplicate, issue, assumption or vague category
- Proximity and early-warning indicators are considered
- One accountable risk owner is assigned
- Linked risks and common causes are visible
- Source and date of identification are traceable
Control guidance
Assess probability, impact and aggregate exposure
Estimate how likely the risk is to occur and the magnitude of impact if it does. Consider the earliest, most likely and worst credible effect when useful, together with proximity and velocity. Evaluate inherent exposure before planned responses, then residual exposure expected after responses. Secondary risks created by the response require their own assessment.
A probability-impact matrix can rank attention, but the labels and boundaries are project-specific. A summary profile can show distribution and tolerance lines. Avoid using colour alone; retain text labels for accessibility and decision clarity. High-score items are not automatically the only priorities: a lower-scored risk with immediate proximity, limited response window or mandatory consequence may require urgent action.
Assess aggregate exposure, not only individual entries. Several moderate risks may share a cause, consume the same contingency or affect one milestone. Schedule simulation, cost ranges or expected monetary value may support material decisions, but models depend on assumptions and data quality. State limitations and do not represent model output as certainty.
Risk rating = defined probability band × defined impact bandThis is an ordinal prioritisation convention. Do not perform unsupported arithmetic or compare scores across projects with different scales.
EMV = probability of event × estimated monetary impactEMV can support aggregate contingency analysis when probability and monetary impact are credible; it is not the amount that will occur for a single event.
Control guidance
Plan responses for threats and opportunities
Threat responses include avoid, reduce, transfer or share, accept and prepare contingency. Avoid removes the uncertain situation or its effect, such as changing approach before exposure. Reduce lowers probability, impact or both. Transfer allocates financial or delivery consequence to another party through a valid mechanism, but responsibility to protect project objectives often remains. Accept means no proactive change beyond monitoring; it must be conscious and within authority.
Opportunity responses include exploit, enhance, share and accept. Exploit acts to make the opportunity occur; enhance increases probability or benefit; share allocates ownership to a party better able to realise it; accept takes advantage if it arises without proactive investment. Both threats and opportunities may need fallback plans and triggers.
Choose responses by expected effect, cost, feasibility, lead time, stakeholder consequence and secondary risk. Define actions, owner, actionee, due date, resources, trigger and target residual exposure. If the response changes an authorised product or baseline, follow issue and change control. If residual exposure exceeds appetite or tolerance, escalate for acceptance or a different decision.
| Risk type | Response | Intent | Control caution |
|---|---|---|---|
| Threat | Avoid | Remove cause or exposure | Confirm new approach does not create a larger secondary risk |
| Threat | Reduce | Lower probability or impact | Measure whether the action actually changes exposure |
| Threat | Transfer or share | Allocate consequence or response capability | Contract transfer does not remove all project accountability |
| Threat | Accept | Retain exposure consciously | Identify trigger, contingency and acceptance authority |
| Opportunity | Exploit or enhance | Make occurrence certain or more beneficial | Confirm additional cost and risk remain justified |
| Opportunity | Share or accept | Use another party's capability or act if it arises | Define ownership and benefit measurement |
Control guidance
Implement, communicate and review
Implementation converts response intent into authorised work. Risk actionees complete actions and report evidence; risk owners monitor indicators, residual exposure and effectiveness. The project manager integrates response work into the stage plan, work packages, budget, quality activities and reports. Closing a response action does not close the risk unless exposure has ended or been consciously accepted.
Communication is continuous across the procedure. Risks appear in checkpoints, highlight reports, stage reviews, issue reports, exception reports and decision papers according to audience and urgency. Escalate a forecast tolerance breach; do not wait for the risk event to occur. Communicate assumptions and uncertainty so decision-makers understand the confidence of the forecast.
Review frequency follows proximity and exposure. Retire expired risks with rationale, convert occurred risks into issues while preserving history, and capture lessons about indicators and response effectiveness. At stage boundaries, reassess context, appetite, aggregate exposure and next-stage risks. At closure, transfer residual operational risks to named owners.
| Control question | Evidence to inspect | Decision or response |
|---|---|---|
| Are responses implemented? | Action evidence, plan status, resource use and due dates | Continue, intervene or escalate |
| Has exposure changed? | Updated probability, impact, indicators and residual assessment | Close, revise response or seek acceptance |
| Is aggregate risk acceptable? | Profile, common causes, contingency demand and business-case sensitivity | Authorise stage, condition it or stop |
| Has a risk occurred? | Event evidence and actual impact | Create or update issue; execute contingency |
Control guidance
Worked scenario and review checklist
Controlling a long-lead supply threat
Situation: A specialist component has one qualified source and must arrive before an installation window. Lead-time variability could push the stage beyond its upper time tolerance.
- The risk is written with cause, uncertain event and effects on installation, cost and benefits; proximity is tied to the latest order date.
- The team assesses supplier evidence, alternative design feasibility and schedule paths rather than selecting a matrix score by intuition alone.
- Responses include early design freeze, reserved production capacity, an alternative component study and a decision trigger before the last recoverable date.
- The owner monitors confirmation milestones. If the stage forecast moves outside tolerance, the project manager raises an exception with options before the installation window is lost.
Control outcome: Risk control creates a decision window and executable actions; the register is evidence of the control, not the control itself.
Risk review
- Context and appetite remain current
- New risks and opportunities have been sought
- Statements, owners, proximity and indicators are clear
- Inherent and residual exposure are distinguished
- Responses are authorised, resourced and on plan
- Secondary and linked risks are assessed
- Forecast impact is reflected in plans and business case
- Escalations and acceptances use the correct authority
Is a risk score a fact?
No. It is a structured judgement based on defined scales and evidence. Record assumptions and use more analysis where the decision warrants it.
Can risk be transferred completely?
Financial or delivery consequences can be allocated contractually, but the project may retain integration, reputation, user or benefit exposure.
When does a risk become an issue?
When the uncertain event occurs or the condition is now certain and requires management action.
Who accepts residual risk?
The person whose delegated authority and risk appetite cover the exposure; higher exposure must be escalated.