3 Identifying and Recording Project Risks
Learn how to identify project risks systematically, distinguish causes from uncertain events and effects, and record validated risks consistently.
Understand project risks
A is an uncertain event or condition that could affect one or more project objectives if it occurs. Risks may be threats, with possible negative effects, or opportunities, with possible positive effects. By contrast, an is a problem that has already happened and should be recorded through the appropriate -tracking process.
Start identification by clarifying project objectives and scope. Consider what uncertain events might affect the schedule, cost, quality, safety, benefits, or other agreed objectives.
Identify risks systematically
Use more than one method because different perspectives can reveal different risks. Choose techniques suited to the project and involve people with relevant experience, including stakeholders and subject-matter experts.
Workshops and brainstorming: Gather the team to generate possible threats and opportunities. Encourage ideas without judging them at first, then clarify and validate the candidates.
Interviews: Ask team members, stakeholders, suppliers, and people who have delivered similar projects about uncertainties and warning signs.
Checklists and prompt lists: Draw on lessons from comparable work and prompts organized by project phase, deliverable, or risk category. Use them as prompts, not as a complete list.
Document and assumption analysis: Examine plans, estimates, contracts, requirements, dependencies, constraints, and assumptions. Consider what could happen if an assumption proves false or a constraint changes.
SWOT and risk-category review: Consider strengths, weaknesses, opportunities, and threats, or scan categories such as technical, commercial, operational, external, and organizational risks.
The techniques complement one another. For example, document analysis may surface an uncertain supplier dependency that the team can explore in an interview or workshop.
Describe cause, event, and effect
A common identification mistake is to record only a cause or a consequence as if it were the risk. A clear separates three elements:
Cause: A known condition, source, or circumstance that creates uncertainty.
: Something uncertain that may happen.
Effect: The consequence for a project objective if the event occurs.
Use this pattern:
As a result of [cause], [uncertain event] may occur, which would affect [objective] by [effect].
For example: “Because the project depends on a single supplier with a long lead time, delivery of the specialist equipment may be delayed, which would push system testing beyond the planned completion date.” The supplier dependency is the cause, a late delivery is the uncertain event, and a delay to testing is the effect.
“Supplier problems” is too vague, while “testing will be late” states an effect without identifying the uncertainty. Naming all three parts makes the risk easier to understand and later assess.
Record and maintain risks
Use a as the shared record of identified risks, with one agreed format so the team can compare entries, assign responsibility, and update information consistently. A practical register can include:
Risk ID: A unique identifier that remains stable when the register is updated.
Date identified: When the risk was added or last reviewed.
Category or source: An agreed category, such as technical, supplier, operational, or external.
: A clear cause–event–effect description.
Objective affected: The relevant project objective or deliverable.
Threat or opportunity: Whether the uncertain event could hinder or benefit the project.
: The person responsible for keeping the entry current and coordinating its management.
Assessment and status: The project’s agreed assessment fields and the current state of the risk.
Use the project’s agreed categories and assessment scales instead of inventing labels for individual entries. Keep descriptions specific, concise, and focused on uncertainty. Avoid duplicate entries, vague concerns, and statements that merely describe existing issues. Review the register as plans, assumptions, and project conditions change.
Identifying risks against project objectives, using structured methods and informed input, and recording validated risks consistently creates a reliable basis for subsequent assessment and management.