Risk identification is the process of recognising and describing uncertainties that could affect objectives.
It is the first practical step in risk management. A team cannot assess, treat, or monitor a risk that it has not identified. Weak identification therefore creates weaknesses throughout the rest of the risk-management process.
Effective risk identification is not simply a matter of asking, “What could go wrong?” It requires a structured examination of the project or organisation from several perspectives:
- what has happened before;
- what is happening now;
- what may happen in the future;
- what assumptions may prove false;
- what dependencies may fail;
- what favourable events may create opportunities; and
- what knowledgeable stakeholders can see that the core team cannot.
No single technique will uncover every risk. Historical methods may miss novel threats. Analytical methods are limited by the quality of available information. Creative methods depend on the imagination and diversity of participants.
The strongest approach combines several complementary techniques.
What is risk identification?
Risk identification involves finding, recognising, and describing risks that may help or hinder the achievement of objectives.
A useful identification process should establish:
- the source or cause of uncertainty;
- the uncertain event or condition;
- the objectives that may be affected;
- the potential consequences;
- whether the effect may be negative, positive, or both;
- who is best placed to own the risk; and
- what information is still missing.
Risk identification is not the same as risk analysis.
During identification, the team determines what uncertainties exist. During analysis, it examines matters such as probability, impact, existing controls, and potential exposure.
The two activities may overlap in practice, but it is usually helpful to identify risks broadly before ranking or rejecting them too quickly.
When should risks be identified?
Risk identification should occur throughout the life of a project, program, product, or operational activity.
Important points include:
- during strategic planning;
- before approving a business case;
- during project initiation;
- while defining scope, schedule, budget, and resources;
- before selecting technology or suppliers;
- at major milestones;
- following significant changes;
- when assumptions are invalidated;
- after incidents or near misses;
- during regular risk reviews; and
- during project retrospectives.
A one-off workshop at the start of a project is not enough. Risks emerge as objectives, dependencies, stakeholders, technologies, markets, and external conditions change.
Use the past, present, and future
A practical way to organise risk-identification techniques is to examine the past, present, and future.
Each perspective reveals different types of uncertainty.
Learn from the past
Historical techniques use prior experience to identify risks that may recur.
They are valuable because organisations often repeat similar work, rely on similar suppliers, use the same systems, or encounter recurring governance and delivery problems.
Lessons learned and retrospectives
Review completed projects and ask:
- What went wrong?
- What nearly went wrong?
- What took longer or cost more than expected?
- Which assumptions proved incorrect?
- Which dependencies failed?
- Which treatments worked?
- Which opportunities arose unexpectedly?
A risk retrospective should produce reusable information rather than merely document what happened.
Useful outputs include:
- recurring risk categories;
- typical causes;
- warning indicators;
- treatment effectiveness;
- common control failures; and
- risks that were missed during planning.
Historical information should not be copied mechanically into a new register. Each prior risk must be tested against the current context.
Risk checklists and templates
A risk checklist provides prompts based on previous experience.
Common checklist categories include:
- scope and requirements;
- schedule and dependencies;
- budget and procurement;
- people and resources;
- technology and integration;
- suppliers and contracts;
- security and compliance;
- stakeholders and governance; and
- external or market conditions.
Checklists are efficient and help avoid obvious omissions. Their limitation is that teams may stop thinking once the list has been reviewed.
Use a checklist as a starting point, not as the complete identification process.
Historical data and trend analysis
Past data may reveal recurring patterns such as:
- typical schedule overruns;
- seasonal demand changes;
- staff turnover rates;
- defect levels;
- supplier delays;
- approval lead times;
- incident frequencies; or
- cost volatility.
This evidence can reveal risks that are difficult to identify through discussion alone.
Analyse the present
Present-focused techniques examine the project, organisation, or environment as it exists now.
These methods are particularly useful for exposing risks embedded in current plans, assumptions, structures, and dependencies.
Comprehensive project review
Review the project’s key documents with a risk perspective.
Examine:
- objectives;
- business case;
- scope;
- requirements;
- work breakdown structure;
- schedule;
- budget;
- resource plan;
- procurement plan;
- architecture;
- stakeholder plan;
- governance arrangements; and
- delivery approach.
Do not ask only whether each document is complete. Ask what uncertainty sits behind it.
For example:
- Which schedule tasks have little contingency?
- Which requirements remain ambiguous?
- Which deliverables depend on one specialist?
- Which estimates rely on unfamiliar technology?
- Which approvals are outside the project’s control?
- Which interfaces are not yet understood?
- Which benefits depend on user behaviour?
A structured review often identifies more useful risks than a general workshop because it anchors discussion in actual project commitments.
Assumption analysis
Every plan contains assumptions. Some are explicit; many remain hidden.
An assumption is something treated as true for planning purposes even though it has not been fully verified.
Examples include:
- a supplier will deliver by a particular date;
- a specialist will remain available;
- a regulator will approve the proposal;
- users will adopt a new process;
- an integration will perform as expected;
- demand will remain within a forecast range; or
- funding will continue.
To analyse assumptions:
- List the assumptions supporting the plan.
- Identify the owner or source of each assumption.
- Record the evidence supporting it.
- Assess how stable it is.
- Ask what happens if it is false.
- Identify indicators that the assumption is weakening.
- Convert material uncertainty into a risk.
A practical assumption-analysis table may include:
| Assumption | Evidence | Confidence | What if it is false? | Resulting risk |
|---|---|---|---|---|
| Specialist available in October | Verbal commitment only | Low | Critical design work is delayed | Resource availability risk |
| Approval completed in six weeks | Prior average | Medium | Launch date slips | Regulatory approval risk |
| Interface supports required volume | Vendor statement | Medium | Performance is inadequate | Integration performance risk |
Assumption analysis is only as good as the assumptions that have been surfaced. Hidden assumptions remain invisible unless the team deliberately questions the plan.
Useful prompts include:
- What must be true for this plan to work?
- What are we taking for granted?
- Which statements are based on hope rather than evidence?
- What has not yet been tested?
- Which estimates depend on stable conditions?
- What would surprise us if it changed?
SWOT analysis
SWOT analysis examines:
- strengths;
- weaknesses;
- opportunities; and
- threats.
Weaknesses and threats provide obvious sources of downside risk. Strengths and opportunities may reveal positive risks or conditions that can be exploited.
A broad SWOT statement should be converted into a specific uncertainty.
For example:
Weakness: dependence on one technical specialist.
can become:
Because critical system knowledge is concentrated in one specialist, there is a risk that unplanned absence or reassignment will delay design decisions and defect resolution.
PESTLE analysis
PESTLE examines the external environment through six lenses:
- political;
- economic;
- social;
- technological;
- legal; and
- environmental.
It is especially useful for strategic, enterprise, regulatory, and long-duration projects.
Example prompts include:
- What government decisions could affect the activity?
- What inflation, interest-rate, or currency movements matter?
- What social or workforce trends may change demand?
- What emerging technology could disrupt the plan?
- What legal or regulatory obligations may change?
- What environmental conditions could affect operations or reputation?
Failure Mode and Effects Analysis
Failure Mode and Effects Analysis, or FMEA, identifies how a process, product, or system might fail and what effects would follow.
For each component or process step, ask:
- How could this fail?
- What would cause the failure?
- What would the effect be?
- How would we detect it?
- What controls already exist?
FMEA is particularly useful in engineering, manufacturing, service design, technology, and operational processes.
Root cause analysis
Root cause analysis can be used prospectively as well as after an incident.
Start with an undesirable outcome, such as:
- critical resource loss;
- major schedule delay;
- system outage;
- quality failure;
- cost escalation; or
- compliance breach.
Then work backwards to identify plausible causes and contributing conditions.
Methods may include:
- the five whys;
- fishbone diagrams;
- fault-tree analysis; and
- failure-mode analysis.
This approach often reveals risks that do not emerge when a team begins with a blank sheet.
Stakeholder interviews
Interviews draw on knowledge outside the immediate project team.
Relevant participants may include:
- subject-matter experts;
- customers;
- suppliers;
- operational staff;
- legal advisers;
- security specialists;
- finance representatives;
- senior leaders; and
- people who worked on similar initiatives.
Use structured or semi-structured questions such as:
- What could prevent us from achieving this objective?
- Which part of the plan appears most optimistic?
- What has failed in similar work?
- Which dependency concerns you most?
- What are we not discussing?
- What change in the external environment would matter?
- What opportunity could improve the outcome?
Interviews can reduce group pressure and allow specialists to raise sensitive concerns more freely than they might in a workshop.
Anticipate the future
Future-focused techniques help teams identify risks that are not visible in past records or current plans.
They are especially useful when the work involves innovation, changing markets, emerging technology, long time horizons, or unfamiliar conditions.
Scenario analysis
Scenario analysis examines several plausible future conditions.
Common scenarios include:
- best case;
- expected case;
- worst case;
- rapid growth;
- prolonged delay;
- supplier failure;
- regulatory change;
- market contraction; or
- technology disruption.
For each scenario, ask:
- What would have to happen for this scenario to occur?
- Which objectives would be affected?
- What warning indicators would appear?
- Which risks and opportunities emerge?
- What decisions would we need to make?
Scenario analysis is more useful when scenarios are plausible and materially different rather than merely optimistic and pessimistic versions of the same forecast.
Futures thinking
Futures thinking examines long-term change, uncertainty, and alternative futures.
Useful prompts include:
- Which trends may reshape the operating environment?
- What emerging issues are currently weak but significant?
- Which present assumptions may no longer hold in three or five years?
- What technological, social, economic, or regulatory discontinuities are possible?
- What would make the current strategy obsolete?
This method is particularly valuable where conventional risk registers focus too heavily on immediate operational concerns.
Brainstorming for risk identification
Brainstorming is widely used because it is quick, inclusive, and easy to organise.
It can help teams:
- combine different perspectives;
- build shared understanding;
- surface concerns;
- generate a broad initial list; and
- create ownership of the resulting risks.
However, conventional brainstorming has important limitations.
Problems with traditional brainstorming
Dominant participants
Senior, confident, or vocal people may shape the discussion and suppress alternative views.
Production blocking
Only one person can speak at a time. Other participants may forget ideas, stop listening, or decide not to contribute.
Group conformity
Participants may align with the emerging consensus and avoid ideas that seem unusual or unpopular.
Uneven attendance
Critical specialists and senior decision-makers may not be available for the workshop.
Quantity without quality
Traditional brainstorming encourages large numbers of ideas and deferred judgement. This may produce:
- issues rather than risks;
- vague concerns;
- causes without uncertain events;
- consequences without causes;
- duplicates; and
- statements that cannot be assessed or owned.
Brainstorming was originally developed as an idea-generation method, not specifically as a risk-identification technique.
How to improve risk brainstorming
Use a more structured process.
Prepare participants
Provide project objectives, scope, assumptions, dependencies, and relevant background before the session.
Generate ideas individually first
Ask participants to record risks silently before group discussion. This reduces conformity and gives quieter participants equal opportunity.
Use categories and prompts
Work through categories such as schedule, resources, technology, suppliers, stakeholders, security, compliance, and external factors.
Evaluate ideas in stages
Do not allow extended debate during initial generation, but do test whether each item is genuinely an uncertainty before it enters the register.
Use a standard risk statement
A useful format is:
Because of cause, there is a risk that uncertain event may occur, resulting in consequence.
This helps distinguish risks from issues, causes, and impacts.
Use an independent facilitator
The facilitator should encourage participation, control dominant voices, challenge vague statements, and keep the group focused on objectives.
Follow up outside the workshop
Interviews, document review, and assumption analysis should supplement the workshop rather than treating it as complete.
Creative risk-identification techniques
When teams repeatedly identify the same familiar risks, creative techniques can help them move beyond prior experience.
Role-playing
Participants adopt the perspective of another stakeholder.
For example:
- a developer takes the role of the customer;
- a project manager takes the role of a regulator;
- an operations specialist takes the role of the supplier;
- a team member takes the role of a competitor or attacker.
Ask each participant:
- What would concern this stakeholder?
- What could prevent their objectives?
- What changes would they make?
- What would they notice that the project team may overlook?
Role-playing encourages lateral thinking and exposes different interests, incentives, and information.
Reverse brainstorming
Instead of asking how the project might succeed, ask how it could fail spectacularly.
Prompts include:
- How could we make the project finish 200% over budget?
- How could we guarantee a six-month delay?
- How could we cause users to reject the new system?
- How could we create a major security incident?
- How could we ensure the supplier relationship fails?
Once participants have generated failure mechanisms, reverse them into plausible risks and preventive actions.
This technique gives people permission to explore uncomfortable or unconventional possibilities.
Random stimulus
Introduce an unrelated word, image, object, or concept and use it to prompt associations.
For example, the word “bridge” might generate questions about:
- single points of connection;
- load capacity;
- maintenance;
- access;
- bottlenecks;
- failure consequences; or
- alternative routes.
Random stimulus can be useful when discussion has become repetitive, although it requires skilled facilitation to convert imaginative ideas into credible risks.
Pre-mortem analysis
Ask the team to imagine that the project has already failed.
Then ask:
It is one year from now, and the project has failed badly. What happened?
Participants independently write plausible explanations before discussing them.
Pre-mortems reduce optimism bias and make it easier to raise concerns without appearing negative.
Perspective shifting
Examine the project through different lenses:
- customer;
- supplier;
- regulator;
- attacker;
- executive;
- frontline employee;
- competitor;
- auditor; or
- future operator.
Each lens reveals different objectives and vulnerabilities.
Identify opportunities as well as threats
Risk identification should not focus exclusively on adverse outcomes.
Ask:
- What could finish earlier than expected?
- What favourable change could reduce cost?
- What new capability might the project create?
- What if demand is greater than forecast?
- What beneficial secondary effects could arise?
- What becomes possible if a threat does not occur?
Positive risks, or opportunities, should be described, assessed, owned, and monitored with the same discipline as threats.
How to run a risk-identification workshop
A practical workshop may follow this structure.
Before the workshop
- Define the objectives and scope.
- Select participants with diverse knowledge.
- Gather project documents and historical information.
- Prepare categories, assumptions, and prompts.
- Ask participants to identify risks individually.
- Appoint a facilitator and note-taker.
During the workshop
- Confirm the objectives under consideration.
- Explain what counts as a risk.
- Review historical risks and lessons.
- Examine current plans and assumptions.
- Work through categories and dependencies.
- Explore future scenarios.
- Use one or two creative techniques.
- Identify positive as well as negative risks.
- Clarify and combine duplicates.
- Assign provisional owners.
After the workshop
- Rewrite vague entries as clear risk statements.
- Separate risks from issues, causes, and consequences.
- Confirm owners.
- Analyse probability and impact.
- identify treatment options.
- Record actions and review dates.
- circulate the register for further input.
- Schedule ongoing reviews.
Common risk-identification mistakes
Relying on one technique
A single workshop, checklist, or interview will produce an incomplete picture.
Confusing issues with risks
An issue has already occurred. A risk concerns an uncertain event or condition.
Recording vague concerns
Statements such as “resources,” “security,” or “supplier problems” are not assessable risks.
Identifying only immediate threats
Longer-term, external, strategic, and positive uncertainties may be missed.
Ignoring objectives
A risk matters because it may affect an objective. Without clear objectives, identification becomes unfocused.
Allowing seniority to control discussion
People closest to delivery often see risks that executives do not.
Treating the initial register as complete
New risks emerge as conditions and information change.
Failing to assign ownership
Unowned risks are less likely to be monitored, analysed, or treated.
Recording identified risks
A risk register should capture enough information to support analysis and action.
Useful fields include:
| Field | What to record |
|---|---|
| Risk title | A concise identifier |
| Risk statement | Cause, uncertain event, and consequence |
| Category | The relevant risk grouping |
| Objectives affected | What may be helped or hindered |
| Owner | The person accountable for the risk |
| Source | Workshop, assumption, incident, interview, or other source |
| Existing controls | Measures already in place |
| Date identified | When the risk was recorded |
| Status | Open, monitoring, treated, closed, or another state |
| Review date | When the risk will next be considered |
After identification, the risk should be analysed for probability and impact, prioritised, assigned a response, and monitored over time.
Risk identification in Jira
Risk identification is more effective when identified risks can be connected directly to the work, systems, dependencies, and treatment actions that relate to them.
With Risk Register by ProjectBalm, teams can record risks in Jira, assign owners, classify risks, assess probability and impact, visualise exposure, and link treatment work to Jira items.
This keeps risk identification connected to delivery rather than isolated in a spreadsheet.
Learn more about risk management in Jira
Explore Risk Register features
Review common project-risk examples
Frequently asked questions
What are the main risk-identification techniques?
Common techniques include project reviews, lessons learned, checklists, assumption analysis, SWOT, PESTLE, FMEA, interviews, scenario analysis, brainstorming, pre-mortems, and creative methods such as role-playing and reverse brainstorming.
What is the best method for identifying risks?
There is no single best method. A strong process combines historical, analytical, stakeholder, and future-focused techniques.
When should risk identification take place?
Risk identification should begin during planning and continue throughout the project or operational lifecycle, especially after major changes, decisions, incidents, and milestones.
What is assumption analysis?
Assumption analysis examines the unverified beliefs supporting a plan and identifies risks that may arise if those assumptions prove false.
Is brainstorming effective for risk identification?
It can be useful, but it is vulnerable to dominance, conformity, weak attendance, and vague output. Structured prompts, individual idea generation, skilled facilitation, and standard risk wording improve its effectiveness.
How do you write an identified risk?
A useful structure is: “Because of [cause], there is a risk that [uncertain event] may occur, resulting in [consequence].”
Should opportunities be included?
Yes. Positive uncertainties may improve objectives and should be identified, assessed, owned, and managed alongside threats.
References
- Hillson, D. (2004), Assumptions and Constraints, Risk Doctor Briefing Note #8.
- ISO 31000:2018, Risk management — Guidelines.