Delphi technique for risk identification: from expert input to a usable risk register
A practical workflow for finding overlooked risks, clarifying assumptions, and deciding what needs further investigation.
From expert input to a useful risk register
The Delphi technique for risk identification gathers judgments from a selected panel through independent responses, structured feedback, and reconsideration. It can help a team discover overlooked risks and understand why experts disagree before deciding what to investigate or address.
A risk workshop can fill a whiteboard quickly. The harder task is finding the concerns that nobody feels comfortable raising, distinguishing different causes hidden behind the same label, and deciding which judgments have enough support to guide action. Delphi gives that work a repeatable structure.
When is Delphi useful for identifying risks?
Consider Delphi when knowledge is distributed across departments or organizations, the project is new, or historical records leave important questions unanswered. For example, a technology rollout may depend on operations staff, suppliers, security specialists, and the people who will use the system. Each group sees a different part of the risk.
RAND describes Delphi as a method for eliciting expert judgment under uncertainty, including judgments about future events and priorities. The workflow below is an illustrative application to project risk planning; it is not a prescribed risk standard. RAND methodological guidance.
Use existing incident records, technical assessments, and other relevant evidence alongside the panel. Delphi does not establish that a risk is real, calculate an objective probability from opinions, or replace a specialist assessment when one is needed. For an urgent operational incident, take the appropriate immediate action rather than wait for another questionnaire round.
A practical Delphi risk-identification workflow
1. Define the scope before asking for risks
Write down the system or activity, the time horizon, the affected groups, and the assumptions panelists should use. “What could go wrong?” produces a different list from “What could prevent the new service from meeting its operating targets during its first six months?”
Also decide what the panel will deliver: a candidate risk list, a shortlist for investigation, or recommendations for mitigation. Identifying risks, estimating their likelihood, and choosing actions are different judgments.
2. Recruit people with different views of the problem
Map the knowledge required before inviting names. Include people who understand implementation and consequences as well as the proposed design. Ask participants to disclose relevant interests. Explain who can see their identities and how comments will be shared; anonymity among panelists does not necessarily mean anonymity to the study administrator.
3. Collect independent risk statements
Use an open question when the purpose is discovery. If you already have an evidence-based risk list, ask panelists to review it and suggest omissions. Describe that starting point in the study report.
Sample discovery questions
- Which events or conditions could prevent this project from meeting its stated objectives within the next six months?
- For each risk, what could cause it, what might happen, and who would be affected?
- What evidence or experience supports your concern?
- What early signal would suggest that the risk is becoming more likely?
- Which assumptions are you least confident about?
4. Turn the responses into clear, traceable items
Give each candidate risk a stable identifier. Merge true duplicates, but keep distinct causes or consequences separate. Replace broad labels such as “training problems” with a specific statement. Record substantive wording changes and let the panel check that the revised item preserves its meaning.
5. Rate the dimensions separately
A useful questionnaire might ask about likelihood within the stated period, severity if the event occurs, and priority for further investigation. Define the scale anchors for each. A 1–9 importance score is not a percentage probability. Do not multiply ordinal scale values and present the result as a precise financial loss estimate.
Include an “unable to judge” response where appropriate and report it separately. It can reveal a knowledge gap rather than a low-risk judgment. See our guide to separate rating criteria.
6. Share feedback, then invite reconsideration
Show the response distribution and a balanced summary of the reasoning. Ask whether panelists wish to keep or revise their ratings. Retaining an informed minority position is a valid response. If groups interpret an assumption differently, clarify it before treating the difference as a disagreement about risk.
7. Close with a decision record
Set the stopping rule in advance. The end product may contain supported priorities, disputed risks, and items requiring more evidence. A project owner should decide what happens next, including who will investigate or manage each issue.
Worked example: a new service rollout
This fictional example shows how a Delphi process can improve the usefulness of a risk list. It does not describe a Calibrum client or report measured results.
| Initial concern | Clarified risk | Useful follow-up |
|---|---|---|
| Training | If evening-shift staff miss the practice sessions, requests may be handled incorrectly during the first month. | Check coverage by shift and assess readiness before launch. |
| Supplier delays | If a required component arrives after the agreed installation date, the pilot may start without a tested fallback. | Confirm the dependency and ask the panel to assess the proposed fallback separately. |
| Low adoption | If the new workflow adds duplicate entry, staff may continue using the old process. | Test the workflow with users and revisit the assumption behind the rating. |
Suppose technical specialists judge a fallback to be adequate while frontline staff remain concerned about using it. An overall median could conceal this difference. Review the group-level distributions and comments before presenting the risk as resolved. Our stakeholder panel guide explains why a large group can dominate a pooled result.
What should the final risk output contain?
- The scope, assumptions, panel composition, and participation by round.
- A stable ID and definition for every retained risk.
- Ratings for each dimension, with denominators and unable-to-judge responses.
- The reasons behind high-priority and disputed assessments.
- Changes to wording or assumptions between rounds.
- A proposed next action, responsible owner, and review point.
For a prioritization exercise, a consensus rule might identify risks the panel agrees deserve investigation. That agreement is different from a conclusion that the event is highly probable. Make the distinction explicit in the report.
Using Surveylet for a risk-focused Delphi
Surveylet supports structured questionnaires, multiple rating dimensions, panel management, group feedback, and multi-round or Real-Time Delphi workflows. Stakeholder Analysis can help examine differences between participant groups. The study team still defines the risks, criteria, feedback policy, and decisions the findings will inform.
For a scheduled workshop, a Live Consensus Session can combine independent ratings with discussion and reconsideration. For an asynchronous panel, compare Real-Time Delphi with separated rounds. In either format, allow enough time for the judgment the task requires.
Common questions
Is Delphi the same as brainstorming?
Brainstorming can generate candidate risks. A Delphi design adds structured feedback and another opportunity to judge the items. A single anonymous questionnaire by itself does not provide that iterative process.
Does every risk need consensus?
No. A credible minority concern may warrant investigation even when it does not meet a priority threshold. Decide how to handle such concerns before the results arrive.
Plan your Delphi project
Tell us what your panel needs to evaluate and what you need to deliver. We can discuss the Surveylet workflow and support that fit your project.