2 Risk Identification

Purpose and timing

Risk identification is the systematic search for uncertain events or conditions that could affect project objectives. It continues throughout a project because plans, assumptions, and circumstances can change. The aim at this stage is to describe plausible risks clearly, not yet to estimate their likelihood or choose responses.

Write clear risk statements

A useful risk statement separates three parts:

• Cause: a current condition or source of uncertainty.

• Event: something uncertain that may or may not happen.

• Effect: the possible consequence for a project objective.

Use this structure:

Because of [cause], [uncertain event] may occur, resulting in [effect on an objective].

For example: “Because the supplier’s interface specification is still changing, integration may fail the first acceptance test, delaying the pilot launch.” In this example, the changing specification is the cause, failure of the test is the uncertain event, and a delayed launch is the effect.

A statement should be specific enough to understand and act on. Name the objective at stake, such as schedule, cost, scope, quality, safety, or performance, and add context when it helps explain the scenario. A risk statement may describe a threat, with a possible negative effect, or an opportunity, with a possible positive effect.

Distinguish a complete risk from a cause alone or an effect alone. “The specification is changing” gives a condition but not an uncertain event and its possible effect; “the launch may be delayed” gives a possible effect without explaining the cause and event.

Use structured prompts

Begin with project objectives and ask what uncertainty could affect each one. Structured prompts help a team look beyond risks that come immediately to mind, but they are starting points rather than a checklist that guarantees completeness. Tailor them to the project and follow up with questions such as “What could happen?”, “Why might it happen?”, and “Which objective could be affected?”

Useful areas to explore include:

• Requirements and scope: What remains unclear, changing, or dependent on approval?

• Schedule and resources: What depends on scarce staff, equipment, access, or a tight sequence of tasks?

• Technology and quality: What is new, untested, difficult to integrate, or dependent on external systems?

• Suppliers and partners: What depends on another organization’s decisions, capacity, or delivery?

• Stakeholders and decisions: Whose availability, expectations, or approval could affect progress?

• External conditions: What regulatory, environmental, market, or security conditions could change?

Run a risk-identification workshop

A short, facilitated workshop can bring together people who see different parts of the project. A practical sequence is:

1. Set the context. Review objectives, scope, boundaries, and the time period being considered.

2. Generate candidate risks. Use prompts, brainstorming, interviews, or small-group discussion. Capture ideas without judging them too early.

3. Challenge assumptions. Ask what the team is treating as true without proof and what could happen if an assumption is wrong.

4. Shape each candidate. Separate cause, uncertain event, and effect, and clarify which objective is affected.

5. Check and record. Combine duplicates, distinguish current issues from future uncertainties, and record enough context for later review.

Encourage participants to question assumptions and raise concerns without blame. Project documents, prompt lists, lessons learned, and stakeholder discussions can support identification.

Examine assumptions and documents

An assumption is a statement treated as true for planning even though it may be uncertain. For each important assumption, ask:

• What evidence supports it?

• Who or what does it depend on?

• By when must it hold true?

• If it is false, what uncertain event could follow, and which objective could be affected?

For example, “The agency will approve the design by June” is an assumption, not yet a complete risk statement. If approval is uncertain, it can be expressed as: “Because agency review timing is not confirmed, approval may arrive after procurement begins, requiring rework and delaying the planned start.”

Review project documents for dependencies, constraints, gaps, and uncertainty. Useful sources include the charter and business case, scope and requirements, schedule, budget, contracts, technical designs, resource plans, stakeholder information, and lessons from prior projects. A document does not prove that a risk will occur; it can help reveal conditions that may create one.

Capture identified risks

Record each distinct risk in the project’s designated risk register or other agreed risk list, using the agreed format. At identification, include a unique label if the project uses one, the cause–event–effect statement, the relevant objective, the source or context, and the person who can clarify it. Keep the wording understandable to someone who did not attend the discussion.

Likelihood and impact ratings, priority, and response planning belong to later steps unless the project’s process asks for them during the same session. Clear risk statements provide a useful basis for later analysis and management.