Project risk management helps a team identify uncertainties that could affect delivery, assess their consequences and agree how to respond. It belongs in planning, progress meetings and decisions about change, with named people responsible for keeping risks and actions under review.
The aim is to make better decisions about scope, schedule, cost and quality. A register supports that work, but the useful part is the discussion and follow-through behind it.
Start with the project's objectives and dependencies
Agree what the project needs to deliver and the limits within which it must operate. Include deadlines, budget, quality expectations and any dependencies on other teams, suppliers or approvals.
Then ask where uncertainty could affect those commitments. For example, a system launch might depend on supplier delivery, data migration, user testing and staff availability. A delay in one area could change the risk elsewhere.
Separate a future risk from an existing issue. A supplier that might miss a date is a risk; a delivery already confirmed as late is an issue to manage. The issue may also create new risks for later milestones.
Identify project risks with the right people
Involve the people who understand the work, including delivery staff, business owners and relevant specialists. Use project plans, lessons from earlier work and risk identification techniques to prompt discussion.
Describe each risk in terms of its cause, possible event and effect. “Testing” is too broad to act on. “Limited user availability could delay acceptance testing and put the launch date at risk” gives the team a decision to make.
Record assumptions that need checking. A plan based on an unconfirmed approval date should make that dependency visible, with someone responsible for obtaining confirmation.
Assess the effect on delivery
Consider likelihood and consequences over the relevant project period. Assess the controls already in place and explain the basis for the judgement.
Use criteria the team understands. For example, agree what a significant delay means for this project and whether a cost increase is within the project manager's authority. A rating without that context gives little guidance about escalation.
Look beyond individual scores. Two risks may depend on the same specialist or supplier, making the combined exposure more important than either entry suggests. Our guide to risk assessment methods explains ways to analyse risks and the limits of different approaches.
Agree a response and an owner
Choose a response that addresses the risk and is proportionate to its effect on the project. Options include changing the plan to avoid an exposure, reducing likelihood or impact, sharing some consequences through an appropriate arrangement, or accepting the remaining risk through an authorised decision.
For each response, record:
- The risk owner who will monitor the position.
- The action owner responsible for completing a specific task.
- A due date tied to the milestone or decision it protects.
- The evidence needed to show the action is complete.
- The point at which the risk should be escalated.
Acceptance should be an informed decision. Record the reasons and any conditions or contingency arrangements, rather than treating an unanswered risk as accepted.
A practical project risk example
A business is preparing to introduce a new customer service system. The launch depends on successful data migration and staff training.
Risk: limited time for testing could allow migration errors to reach the live system, disrupting customer support.
Response: schedule a trial migration, agree acceptance checks and give the service manager responsibility for confirming the results before launch.
Contingency: define how staff will access essential records if launch is delayed, and who can authorise a revised date.
Review: revisit the risk after the trial and before the launch decision. A completed test does not automatically make the risk low; the team needs to consider the findings and remaining problems.
This is an illustrative example. The checks, ratings and approval arrangements would depend on the actual project.
Keep risk review part of delivery
Review risks at project meetings and before important decisions. Focus on what has changed: new evidence, missed actions, revised dependencies or controls that did not work as expected.
Useful prompts include:
- Has a risk become an issue?
- Does a change request introduce new exposure?
- Are actions complete before the decisions they support?
- Is the remaining risk within the team's authority to accept?
- Do stakeholders need to know about a change in the delivery outlook?
The government project delivery standard provides a wider reference for project governance and delivery practice. Your own review arrangements should reflect the scale and needs of the project.
Record lessons at handover and closure
Before closure, identify risks that continue into operations and agree who will own them. Hand over outstanding actions, dependencies and contingency arrangements with the service or product.
Record which assumptions proved wrong and which responses worked. These lessons give future teams evidence to use when planning similar work.
Managing project risks in RiskMate
RiskMate supports project risk assessment and reporting, with shared records, assigned responsibilities and action tracking. Teams can use the information to review progress and prepare reports for management.
For the broader cycle of identifying, analysing, evaluating, treating and reviewing risks, see our risk management process guide. To explore the software with your own project needs in mind, request a demo.