Home Templates Calculators Videos Academy Software Merchandise About Contact Login
Define Phase · DMAIC Template

Project Risk Assessment Template

Identify and rate project risks early so you can put mitigations in place before they become issues.

SimplicityHub Project Risk Assessment Template — editable Excel template

What is a Project Risk Assessment Template?

A project risk assessment identifies every risk that could prevent a project from achieving its objectives, scores each risk by likelihood and impact, and defines specific mitigation actions to reduce or remove the risk before it materialises.

In Lean Six Sigma, risk assessment is completed in the Define phase as part of project setup. Projects that identify risks early can plan mitigations proactively. Those that ignore risks discover them mid-delivery, when they are far more expensive and disruptive to manage.

The output is a risk log that is reviewed and updated at every phase gate throughout the project lifecycle.

When to use a Project Risk Assessment Template

Complete the risk assessment at project initiation and review it at every phase gate. Use it when:

  • A project involves significant organisational change or cross-functional dependencies
  • The sponsor wants assurance that risks have been identified and planned for
  • A project has a tight timeline or budget that leaves little room for setbacks
  • Previous similar projects have failed and you want to understand why and plan differently

Who should use a Project Risk Assessment Template

  • Green Belts and Black Belts — as a Define phase deliverable on every formal DMAIC project
  • CI Managers — to assess risks across a portfolio of improvement projects
  • Project Sponsors — to understand what could prevent the project from delivering its goals
  • Operations Leaders — when commissioning improvement work with significant change implications
Project Risk Assessment Template guide
Step-by-step

How to complete the Project Risk Assessment

Run the risk assessment as a team exercise — each team member will see different risks based on their experience and role. The most dangerous risks are the ones nobody on the team has thought to raise.

How to complete the Project Risk Assessment — step by step

  1. 1
    Brainstorm all potential risks

    Ask the team: what could prevent this project from achieving its goal? Include technical risks, stakeholder risks, data risks, resource risks and timing risks. Capture everything before filtering.

  2. 2
    Score likelihood (1–5)

    For each risk, score how likely it is to occur: 1=Very Unlikely, 2=Unlikely, 3=Possible, 4=Likely, 5=Very Likely. Base scores on evidence and team knowledge, not gut feel.

  3. 3
    Score impact (1–5)

    For each risk, score the impact if it occurs: 1=Negligible, 3=Moderate, 5=Severe. Consider impact on timeline, cost, quality and stakeholder confidence.

  4. 4
    Calculate risk score

    Multiply likelihood by impact to get the risk score (max 25). Rank risks from highest to lowest score. Scores above 12 are high priority for mitigation planning.

  5. 5
    Define mitigation actions

    For each high-priority risk, define at least one specific mitigation: what will be done, by whom, and by when. Mitigations either reduce likelihood, reduce impact, or both.

  6. 6
    Assign a risk owner

    Every risk needs a named owner who monitors it and implements the mitigation. The project lead cannot own every risk — distribute ownership across the team.

  7. 7
    Review at every phase gate

    New risks emerge as the project progresses. Review the risk log at the end of Define, Measure, Analyse and Improve. Close risks that have passed and add new ones as they are identified.

Worked example — New Shift Pattern Project Risks

A completed risk assessment for a shift pattern change project, showing likelihood/impact scoring, risk scores and mitigation actions for the top five risks.

Completed project risk assessment showing risks scored by likelihood and impact with mitigation actions

Common mistakes — and how to avoid them

⚠️

Only identifying technical risks. The most common project-killing risks are stakeholder resistance, data availability and resource conflicts — not technical failures. Cast the net wide across all risk categories.

⚠️

No mitigation actions. A risk log that identifies risks without mitigation actions is a worry list. Every risk above the threshold needs a specific action that reduces its likelihood or impact.

⚠️

Not reviewing during the project. A risk assessment completed in Define and never revisited is useless by the time you reach Improve. Review it at every phase gate and after any significant project event.

⚠️

Scoring risks without evidence. Gut-feel risk scoring produces unreliable prioritisation. Use historical data, lessons learned from previous projects and stakeholder input to ground your scores in reality.

Tips for getting better results

💡

Include a 'watch list' for low-scoring risks. Risks scored below the action threshold should be monitored, not ignored. A low-likelihood, high-impact risk may need a contingency plan even if no active mitigation is warranted.

💡

Use the risk assessment in sponsor conversations. Presenting the risk assessment to the sponsor demonstrates rigour and opens a conversation about which risks they can help mitigate — particularly stakeholder and resource risks.

💡

Learn from previous project risks. Before starting, review the lessons learned log from similar previous projects. The risks they encountered are the most likely risks you will face.

Free Download

Download the Project Risk Assessment Template

A clean, editable Excel template for immediate use — structured, professional and ready to fill in.

Frequently asked questions

Risk assessment vs risk register?

A risk assessment identifies and rates risks. A risk register tracks those risks and mitigation actions over time.

How do I rate a risk?

Score likelihood times impact. High-rated risks need active mitigation; low-rated can be monitored.

How many risks should I identify?

Identify every meaningful risk then prioritise. 10-20 is typical for a standard project.

How often should it be reviewed?

At each phase gate and any time the project context changes significantly.