Last updated: 2026-11-10
Finding Risks: Techniques for Identification
You can't respond to a risk nobody has written down. Identification is the step that produces the list everything else works from: a set of candidate risks, each with a cause, a trigger that would show it starting to happen, and a first guess at its category. It's also the step most easily done badly, because the obvious risks come quickly and give a false sense of completeness.the obvious ones are the least likely to surprise you
The techniques below fall into two families. Team-based techniques draw risks out of people's heads; analytical techniques draw them out of documents, history and structure. Both are needed, and both work better with a wide range of people involved: developers, testers, users, operations staff and the client each see different failure modes. After those come three ways of tracing causes, a way of sorting risks by how knowable they are, and two worked examples.
Write a Risk as Cause, Event and Consequence Applied / MethodologicalKnowledge with a 5–10 year half-life — stable practice
A risk written as a single noun ("security", "the database", "time") can't be estimated, owned or acted on. A risk written as a sentence with three parts can:
Because [cause], [uncertain event] may happen, which would lead to [consequence for an objective].
| Vague | Usable |
|---|---|
| "Staffing" | Because only one developer understands the deployment scripts, a release may stall if they're unavailable, which would delay the beta by one to two weeks. |
| "Performance" | Because search runs a full table scan, response times may exceed 2 seconds once the catalogue passes 50,000 items, which would fail the agreed usability criterion. |
| "Third-party API" | Because we depend on version 2 of the provider's API, a deprecation notice may arrive before launch, which would force unplanned migration work. |
The cause tells you where to act. The event tells you what to watch for. The consequence tells you how much it matters, and in which units, which is what Measuring Risk needs.consequence must be measurable to compare risks
Team-Based Techniques Applied / MethodologicalKnowledge with a 5–10 year half-life — stable practice
| Technique | How it works | Strength | Weakness |
|---|---|---|---|
| Brainstorming | Facilitated, free-form generation; no criticism until the list is complete | Fast, cheap, builds shared awareness | Loud voices and seniority dominate; the group converges early |
| Delphi technique | Experts respond anonymously in rounds, see a summary of the others' answers, and revise | Removes status effects; works across sites | Slow; needs a careful facilitator |
| Interviews | Structured questions to stakeholders one at a time | Reaches people who won't speak in a group; finds domain risks the team can't see | Time-consuming; quality depends on the questions |
| Pre-mortem | The team imagines the project has already failed and writes down why | Gives permission to voice doubts; finds risks optimism hides | Can drift into pessimism without facilitation |
The Delphi method came out of RAND in the early 1960s as a way of reaching a consensus of expert opinion through a series of questionnaires with controlled feedback between rounds1. Anonymity is the active ingredient. A junior developer who suspects the architecture won't scale is far more likely to say so on an anonymous form than across a table from the architect.
The pre-mortem, described by Klein, reverses the usual framing: instead of asking "what might go wrong?", the leader announces that the project has failed and asks each person to write down the reasons2. It draws on research into prospective hindsight, which found that the way people explain an event changes when they imagine it as having already happened rather than as something that might happen3. Klein also points out a side effect: a team that has run a pre-mortem is primed to notice early signs of trouble once the project is under way.framing shapes what we see
Analytical Techniques Applied / MethodologicalKnowledge with a 5–10 year half-life — stable practice
| Technique | How it works | Strength | Weakness |
|---|---|---|---|
| Checklists | Walk through a list of risks seen on past projects | Cheap; catches the common cases nobody thinks to mention | Only finds what has happened before; encourages box-ticking |
| SWOT analysis | Strengths, Weaknesses (internal), Opportunities, Threats (external) | Finds opportunities as well as threats; links risks to the team's own capability | Coarse; items need rewriting as cause–event–consequence afterwards |
| Assumptions analysis | List every assumption in the plan, then ask how sure you are of each and what happens if it's false | Turns hidden beliefs into explicit risks | Assumptions are hard to see from inside; works best with an outsider asking |
| Document review | Read requirements, contracts, architecture notes looking for ambiguity, gaps and dependencies | Finds risks in the agreed baseline before work starts | Only as good as the documents |
Two published checklists are worth knowing. Boehm's top-10 list of software risk items, built from a survey of experienced project managers, pairs each item with the techniques that had worked against it4. DeMarco and Lister later argued that five core risks account for most of the trouble on software projects: an inherent flaw in the schedule, requirements inflation, personnel turnover, specification breakdown, and under-performance5. The tagging in the right-hand column below is ours, not Boehm's; it shows how many of his "technical" items have their roots in how the work is organised.
| # | Boehm's risk item | Process or product? |
|---|---|---|
| 1 | Personnel shortfalls | Process |
| 2 | Unrealistic schedules and budgets | Process |
| 3 | Developing the wrong functions and properties | Product (caused by weak requirements process) |
| 4 | Developing the wrong user interface | Product (caused by too little user involvement) |
| 5 | Gold-plating | Process creating product risk |
| 6 | Continuing stream of requirements changes | Process |
| 7 | Shortfalls in externally furnished components | Product (via supplier) |
| 8 | Shortfalls in externally performed tasks | Process (via supplier) |
| 9 | Real-time performance shortfalls | Product |
| 10 | Straining computer-science capabilities | Product |
The list dates from 1991, and some items read differently now: "externally furnished components" today means open-source dependencies and cloud services as much as contracted hardware. Use any checklist as a prompt, then add your project's own history to it. The risks that bit the last project are the best checklist the next one can have.checklists miss unknown unknowns
Tracing Causes Applied / MethodologicalKnowledge with a 5–10 year half-life — stable practice
A risk list often records symptoms. Tracing back to causes matters because responses work on causes; mitigate a symptom and the same cause produces a different symptom next month.cf. debugging: tracing from symptom to cause
Five Whys
Associated with the Toyota Production System6, the technique asks "why?" repeatedly until a cause appears that the team can act on:
- Why did the release slip? Testing took longer than planned.
- Why? Many defects were found late.
- Why? Code reviews had been skipped.
- Why? The team was under time pressure.
- Why? The schedule was unrealistic from the start.
The chain starts with a product symptom (defects) and ends at a process cause (estimation). That's typical, and it's why improving estimation, rather than adding a testing phase, is the response that stops it recurring.
The technique has known limits. Card's review of its use in healthcare root-cause analysis argues that it forces a single linear chain onto events that usually have several interacting causes, that where it stops is arbitrary, and that two people asking the same questions often reach different "root" causes; he suggests it suits teaching better than serious investigation7. Use it to get a team thinking causally, then switch to a diagram that allows more than one branch.
Cause-and-Effect (Fishbone) Diagrams
Ishikawa's cause-and-effect diagram places the effect at the head and groups possible causes along bones by category8. For a software risk, categories split naturally between process and product:
one person knows deploy"] P2["Method:
no code review under pressure"] P3["Estimation:
no buffer for integration"] end subgraph Product T1["Design:
tight coupling to vendor API"] T2["Technology:
new framework, little experience"] T3["Environment:
staging differs from production"] end P1 --> E["Effect:
release slips
with critical defects"] P2 --> E P3 --> E T1 --> E T2 --> E T3 --> E style E fill:#FFC857
Each bone is a candidate risk in its own right, and the diagram makes it obvious when one category is empty because nobody thought to look there.
Influence Diagrams and Process Flowcharts
Influence diagrams, formalised by Howard and Matheson, show decisions, uncertain quantities and outcomes as nodes, with arrows for the relationships between them9. They're useful when risks interact, because the arrows show which uncertainty feeds which:
adopt new framework?"] --> L["Uncertain:
team learning time"] D --> P["Uncertain:
framework performance"] L --> S["Uncertain:
schedule slip"] P --> Q["Uncertain:
meets response-time target"] S --> V{"Outcome:
project value"} Q --> V
A process flowchart does a similar job for a workflow: draw the steps from commit to production, then mark every hand-off and manual step as a candidate failure point.
Known, Unknown and Unpredictable Risks FoundationalKnowledge that endures for decades — core principles
| Type | Description | How to manage |
|---|---|---|
| Known | Identified and understood | Specific responses, owners, triggers |
| Unknown | Foreseeable, but nobody has identified it yet | Checklists, reviews, outside perspectives, regular re-identification |
| Unpredictable | Rare, high-impact events that couldn't reasonably have been foreseen | Management reserve, and designs that degrade gracefully |
Taleb's "black swan" names the third category: an outlier, beyond regular expectations, with extreme impact, which people explain after the fact as if it had been predictable10. You can't list black swans in a register by definition. What you can do is build systems and plans that don't collapse when one arrives, which is where architectural resilience (see engineering practice as standing mitigation) earns its place.
Identification effort pays best on the middle row. Every identification session moves some unknown risks into the known row; the measure of a good session is how many it moves.move means: spot it, name it, add to register
Worked Example: An Individual Project Applied / MethodologicalKnowledge with a 5–10 year half-life — stable practice
A student starting a major coursework project lists risks quickly: data loss, a laptop failure, missed deadlines, an unavailable partner, no access to a resource. Rewritten as cause–event–consequence and split by where each one lives, the list looks like this:
| Risk | Process or product | Obvious response |
|---|---|---|
| Because work is only on one laptop, a disk failure may lose weeks of work, delaying submission | Process | Version control with a remote; this alone removes most of the impact |
| Because three deadlines fall in week 9, the project may get no time that week, compressing testing | Process | Move testing earlier; plan week 9 as a gap |
| Because my partner also has a placement interview cycle, they may be unavailable for integration, delaying the demo | Process | Agree integration dates now; define interfaces so each half runs alone |
| Because the dataset licence hasn't been confirmed, access may be refused, removing the evaluation | Product | Request confirmation now; identify a public fallback dataset |
| Because I've never used this library, it may not support the feature I need, forcing a redesign | Product | Build a one-day spike before committing the design |
| Because the evaluation needs participants, recruitment may fall short, weakening the results | Product | Recruit early; design an evaluation that works with fewer participants |
Most of the first list was process risk. Adding the product rows usually needs a second pass with a different question: not "what could stop me finishing?" but "what could make what I finish wrong?" Risk Analysis for a Project takes this example further.product risk: the thing is wrong, not just late
Worked Example: A Software Project Applied / MethodologicalKnowledge with a 5–10 year half-life — stable practice
| Source | Example | Category |
|---|---|---|
| Vendor | A third-party component is delivered late or doesn't meet its specification | Process (schedule) and product (quality) |
| Personnel | A critical developer leaves mid-project | Process |
| Scope | Requirements keep changing after design is agreed | Process |
| Technical | Two subsystems fail to integrate under production load | Product |
| Infrastructure | A data-centre outage or regional disaster takes services offline | Product (availability) |
| Organisational | Project sponsorship changes hands and priorities shift | Business |
From List to Register Applied / MethodologicalKnowledge with a 5–10 year half-life — stable practice
Each identified risk becomes a row in the risk register: an ID, the cause–event–consequence description, a category, a trigger and a provisional owner. Probability, impact and exposure come next, in Measuring Risk. Identification doesn't end there; it's repeated at every review, because new risks appear as the project learns more (see Keeping Risk Management Alive).
Related Topics
- Risk Management & Mitigation: the overview and full cycle.
- What Counts as a Risk: risk versus issue, opportunities, and the process/product split used above.
- Measuring Risk: the next step for every risk on the list.
- Where Requirements Get Hard: wicked problems and assumptions engineering, the requirements-side version of assumptions analysis.
- Threat Surfaces in Practice: security-focused identification applied to a working system.
References
-
Dalkey, N., & Helmer, O. (1963). An experimental application of the Delphi method to the use of experts. Management Science, 9(3), 458–467. https://doi.org/10.1287/mnsc.9.3.458 ↩
-
Klein, G. (2007). Performing a project premortem. Harvard Business Review, September 2007. https://hbr.org/2007/09/performing-a-project-premortem ↩
-
Mitchell, D. J., Russo, J. E., & Pennington, N. (1989). Back to the future: Temporal perspective in the explanation of events. Journal of Behavioral Decision Making, 2(1), 25–38. https://doi.org/10.1002/bdm.3960020103 ↩
-
Boehm, B. W. (1991). Software risk management: Principles and practices. IEEE Software, 8(1), 32–41. https://doi.org/10.1109/52.62930 ↩
-
DeMarco, T., & Lister, T. (2003). Waltzing with Bears: Managing Risk on Software Projects. Dorset House. ↩
-
Ohno, T. (1988). Toyota Production System: Beyond Large-Scale Production. Productivity Press. ↩
-
Card, A. J. (2017). The problem with '5 whys'. BMJ Quality & Safety, 26(8), 671–677. https://doi.org/10.1136/bmjqs-2016-005849 ↩
-
Ishikawa, K. (1976). Guide to Quality Control. Asian Productivity Organization. (Original Japanese edition 1968.) ↩
-
Howard, R. A., & Matheson, J. E. (2005). Influence diagrams. Decision Analysis, 2(3), 127–143. https://doi.org/10.1287/deca.1050.0020 ↩
-
Taleb, N. N. (2007). The Black Swan: The Impact of the Highly Improbable. Random House. ↩
Graduate Attributes
Directly developed
- Critical Thinker: Readers evaluate the limitations of the Five Whys technique against evidence of its arbitrary stopping points before deciding whether to use it.
- Collaborative: Readers consider how different professional roles such as developers and testers perceive distinct failure modes during risk identification.
Modelled on this page
- Reflective: The text examines the assumptions behind standard checklists by noting how historical items like externally furnished components have shifted meaning over time.
- Subject Specialist: Discipline-specific frameworks such as cause-event-consequence structures are applied to transform vague concerns into actionable risk statements.
- Resilient: Strategies for building systems that withstand unpredictable high-impact events are presented as a way to maintain stability when standard predictions fail.
University of Reading Graduate Attributes framework.