Practical Project Risk Management
A lightweight method for identifying, prioritising, owning, and responding to uncertainty in small
and medium projects.
Purpose: This concise guide is designed as a practical reference. It focuses on methods that can be
applied immediately, with enough explanation to understand why they work.
Contents
1. Risk as Decision Support
2. Risks vs Issues
3. Clear Risk Statements
4. Probability and Impact
5. Response Strategies
6. Owners and Triggers
7. Risk Register
8. Reviews
9. Minimal Routine
Practical Project Risk Management Page 1
1. Risk Management Is Decision Support
Risk management is not a paperwork exercise. Its purpose is to help a project team make better decisions before
a problem becomes expensive. A risk is an uncertain event or condition that could affect the project. The effect
can be negative, such as a supplier delay, or positive, such as unexpectedly strong customer demand that
requires more capacity.
A useful risk process is intentionally lightweight: identify the important uncertainties, estimate their significance,
decide what to do, assign an owner, and review the risks when the project changes.
2. Separate Risks From Issues
A risk has not happened yet. An issue is already happening. This distinction matters because the response is
different. Risks require prevention, preparation, or monitoring. Issues require active resolution.
Statement Type Reason
Supplier may deliver late Risk The event is uncertain
Supplier is already 5 days late Issue The event has occurred
Key employee may be unavailable Risk Future uncertainty
Key employee resigned yesterday Issue Current fact
3. Write Risks Clearly
A vague entry such as "budget risk" is difficult to manage. Use a cause-event-effect structure: because of a
cause, an uncertain event may occur, which could create an effect. Example: because the project depends on
one specialist supplier, delivery may be delayed, causing the launch date to slip.
Good risk statements answer three questions
• What could cause the risk?
• What uncertain event might happen?
• What would the consequence be?
4. Score Probability and Impact
A simple 1-to-5 scale is usually enough. Probability estimates how likely the event is. Impact estimates the
seriousness of the consequence. Multiply the two values to create a prioritisation score. The score is not scientific
truth; it is a consistent method for deciding which risks deserve attention first.
Score Probability guide Impact guide
1 Rare Negligible effect
2 Unlikely Minor rework or small delay
3 Possible Noticeable cost, delay, or quality effect
4 Likely Major effect on project objective
5 Very likely Could cause project failure or serious loss
Practical Project Risk Management Page 2
Do not spend excessive time arguing whether a probability is exactly 40% or 50%. The value of scoring
is consistent prioritisation, not false precision.
5. Choose a Response Strategy
Avoid
Change the plan so the risk no longer exists. Example: replace a single-source component with a standard
component available from several suppliers.
Reduce
Lower the probability or impact. Example: order critical materials earlier, create a prototype, add automated
checks, or cross-train another team member.
Transfer
Shift part of the financial or operational consequence to another party through insurance, warranties, contracts, or
outsourcing. Transfer rarely removes all responsibility, so the project still needs oversight.
Accept
Take no preventive action beyond monitoring because the cost of mitigation is greater than the expected harm.
Good acceptance still includes a trigger and contingency where the impact would be material.
6. Assign an Owner and a Trigger
Every important risk should have one named owner. The owner is responsible for monitoring the risk and making
sure the planned response occurs. Also define a trigger: an observable condition that tells the team the risk is
becoming more likely or has turned into an issue.
• Supplier risk trigger: delivery confirmation not received by a specified date.
• Budget risk trigger: committed cost reaches 80% of the budget before 60% of work is complete.
• Technical risk trigger: prototype fails the same critical test twice.
7. Keep a Compact Risk Register
ID Risk P I Score Response Owner
R1 Critical supplier delay 3 4 12 Reduce: order early Procurement
R2 Scope growth 4 4 16 Avoid: change control Project lead
R3 Specialist unavailable 2 5 10 Reduce: cross-train Team lead
8. Review Risks at Decision Points
Risk reviews are most valuable before commitments: approving a design, signing a supplier, releasing funds,
launching to customers, or changing scope. A short review at these points is more effective than a large risk
meeting that happens only because the calendar says so.
Ask during each review
• Which risks have changed?
• Which triggers have been reached?
Practical Project Risk Management Page 3
• Did any risk become an issue?
• Are the planned responses still worth their cost?
• Did the project change create new risks?
9. A Minimal Risk Routine for Small Projects
At project start, identify the ten most important uncertainties. Score them, choose responses for the
highest-priority items, and assign owners. Review the list weekly or at major decision points. Close risks that are
no longer relevant and add new ones only when they can affect an objective. This keeps the register useful rather
than turning it into an archive of every imaginable problem.
The goal is not to predict the future perfectly. The goal is to avoid being surprised by risks that were
visible and manageable in advance.
Practical Project Risk Management Page 4