The most common way risks get identified on projects is informally: someone mentions a concern in a meeting, a few people nod, and maybe it gets written down. Maybe. This works when the project is small and the team is tight. It breaks down the moment complexity increases, because informal identification is biased towards whatever is top of mind for the loudest person in the room.
A risk workshop is a structured session designed to systematically identify, assess, and document risks as a team. Done well, it surfaces threats that no single person would have spotted alone and produces a working risk register in 60 to 90 minutes.
This guide gives you everything you need to facilitate one: a ready-to-use agenda, facilitation techniques that draw out quiet team members, and practical advice on capturing the output.
When to run a risk workshop
Project kickoff is the most common trigger. Before work begins, bring the core team together to identify what could go wrong. This is the foundation of your risk register.
Phase transitions are the next best time. When a project moves from design to build, from development to testing, or from setup to live event, the risk profile changes. A short workshop at each transition catches risks specific to the upcoming phase.
After a significant change. A major scope change, a key team member leaving, a supplier issue, or an external event (regulatory change, market shift) all warrant a focused risk review.
Regular intervals on long projects. For projects running 6+ months, a quarterly risk workshop keeps the register fresh and catches risks that emerge gradually.
Who should be in the room
The quality of your risk workshop depends entirely on who participates. You need people with different perspectives on the project:
- The project manager (who sees the overall plan and dependencies).
- Technical leads (who understand what is technically difficult or uncertain).
- The person closest to the budget (who knows where the financial uncertainty lives).
- A client or stakeholder representative if possible (who brings the external perspective on what matters most).
- Frontline team members (the site foreman, the developer writing the code, the event coordinator on the ground, anyone who sees the day-to-day reality rather than the plan).
Aim for 4 to 8 people. Fewer than four and you miss perspectives. More than eight and the session becomes hard to facilitate and people disengage.
The agenda: 90 minutes
Here is a ready-to-use agenda. Adjust the timing to fit your project, but protect the identification phase. That is where the value is.
Time |
Activity |
Duration |
|---|---|---|
0:00 |
Opening and context |
10 min |
0:10 |
Silent brainstorm |
10 min |
0:20 |
Group sharing and discussion |
25 min |
0:45 |
Scoring |
20 min |
1:05 |
Owner assignment and next steps |
15 min |
1:20 |
Wrap-up |
10 min |
Opening and context (10 minutes)
Set the scene. Explain the purpose of the session: "We are here to identify what could go wrong on this project and decide what to do about the biggest risks."
Share a brief project summary: scope, timeline, key milestones, budget, and any known constraints. If participants are not equally familiar with the project, this levels the playing field.
Establish ground rules: there are no stupid risks (capture everything, filter later), we are identifying risks not solving them (solutions come after scoring), and every perspective is valuable (the intern might spot something the director misses).
Silent brainstorm (10 minutes)
This is the most important technique in the entire workshop. Give everyone sticky notes (physical or digital) and ask them to write down every risk they can think of, one per note, in silence.
Silent brainstorming works dramatically better than open discussion for initial identification because it eliminates anchoring (the first person to speak frames everyone else's thinking), it gives introverts equal airtime, it prevents groupthink, and it generates 2 to 3 times more risks than verbal brainstorming.
Use prompts to guide thinking. Work through the project timeline phase by phase, or use category prompts:
- What could go wrong with people (availability, skills, turnover)?
- What could go wrong with technology (tools, integrations, infrastructure)?
- What could go wrong with suppliers and dependencies (third parties, approvals, deliverables)?
- What could go wrong with scope (requirements changes, stakeholder expectations)?
- What could go wrong with budget (cost estimates, cash flow, variations)?
- What could go wrong with schedule (dependencies, resource availability, external delays)?
- What could go wrong with external factors (regulations, market, weather, politics)?
Group sharing and discussion (25 minutes)
Go around the room and have each person share their risks one at a time. As each risk is shared, stick it on a wall or board grouped by theme. Other participants add related risks or build on what they hear.
As facilitator, your job is to:
- Clarify vague risks. If someone says "technology problems," ask: "What specifically? Which technology? What kind of failure?" A risk needs to be specific enough that someone could monitor it and know when it was materialising.
- Combine duplicates. Multiple people will identify the same risk in different words. Group these together but do not discard any: the fact that three people independently identified the same risk is useful signal about its importance.
- Draw out quiet participants. "Sarah, you have been working on the integration. What risks do you see in that area?" Direct questions to specific people ensure that domain expertise gets captured.
- Park solutions. When someone starts describing how to fix a risk, gently redirect: "That is a great mitigation idea, let's capture it. But first, let's make sure we have identified all the risks."
- By the end of this phase, you should have 15 to 30 risks on the board (more for complex projects, fewer for simple ones).
Scoring (20 minutes)
Now score each risk for probability and impact using the 1 to 5 scales. For efficiency in a workshop setting, use one of these approaches:
- Facilitator-led scoring: Read each risk aloud and ask the group to agree on probability and impact. This is fastest but can be dominated by senior voices.
- Fist-of-five: For each risk, everyone simultaneously holds up 1 to 5 fingers for probability, then again for impact. If there is broad agreement (within one point), take the median. If there is disagreement (spread of 2+ points), discuss briefly and then re-vote.
- Dot voting for speed: If you have many risks and limited time, have everyone place coloured dots on the risks they consider most significant. The risks with the most dots get scored in detail. Lower-voted risks get a quick consensus score.
Record each risk's probability, impact, and calculated score. Identify the High (12 to 19) and Critical (20 to 25) risks, as these will get the most attention in the next phase.
Owner assignment and next steps (15 minutes)
For every High and Critical risk, assign an owner: the person who will be responsible for developing the treatment plan, tracking actions, and reporting on status at the next review.
For Medium risks, assign owners if time allows, or agree on a deadline for the project manager to assign them after the workshop.
For Low risks, note them in the register for monitoring but do not spend workshop time on treatment plans.
Agree on the review cadence: "We will review the risk register every Tuesday in the project meeting" or "Monthly risk review on the first Monday."
Wrap-up (10 minutes)
Summarise what was identified: total number of risks, number of Critical/High/Medium/Low, and the top 3 to 5 risks by score. Confirm who is entering the risks into the register (this should happen the same day, not next week). Thank the team for their input.
Facilitation tips
Energy management. Risk workshops can feel heavy because you are spending 90 minutes thinking about everything that could go wrong. Keep the energy up with a brisk pace, genuine acknowledgement of good contributions, and occasional lightness ("Well, that is a cheerful list. Let's make sure none of it actually happens.").
The "pre-mortem" technique. If the team is struggling to think of risks, try a pre-mortem: "Imagine it is six months from now and the project has failed spectacularly. What went wrong?" This framing is surprisingly effective at unlocking risks people are reluctant to voice in a forward-looking context.
Separate identification from judgement. The biggest facilitation mistake is letting people filter risks during identification ("Oh, that would never happen" or "We have already handled that"). Capture everything first. Score later. Some "unlikely" risks turn out to be the most important ones.
Watch for groupthink. If the team is too harmonious and every risk gets scored as a 2 or 3, push back: "Is there anything on this project that keeps you up at night? Anything where you think, 'I really hope that does not happen'?"
Time-box ruthlessly. It is easy to spend 15 minutes discussing a single risk. As facilitator, keep the pace: "We have scored R-003 as High. The owner will develop the mitigation plan. Let's move to R-004."
After the workshop
The workshop produces raw material. Someone (usually the project manager) needs to enter the risks into the risk register within 24 hours while the detail is fresh.
For each risk, capture: the description (specific and clear), probability and impact scores, the risk score, the assigned owner, and the agreed treatment strategy (if discussed) or a note that the owner will develop one by a specific date.
Then send the completed register to all workshop participants for review. They will catch anything that was misrecorded or missing.
Schedule the first risk review meeting. The register is only valuable if it stays alive.
Capture your workshop output directly in Riskjar. Add risks, score them, assign owners, and your heat map builds itself in real time. No post-workshop data entry into spreadsheets. Try it free.