Common project risks become easier to identify and manage when teams start with practical examples. This guide groups 40 project risk examples by category, then shows how to turn a generic concern into a useful risk-register entry with a cause, event, consequence, owner, and treatment.
Use the examples as prompts rather than copying them unchanged. A risk becomes actionable when it is rewritten for the objectives, constraints, dependencies, and people involved in your project.
What is a project risk?
A project risk is an uncertain event or condition that may affect a project objective such as scope, schedule, cost, quality, safety, or benefits. Risks can be threats or opportunities, although the examples below focus on threats.
A risk is different from an issue:
A risk may occur. It describes uncertainty that still needs to be assessed and managed.
An issue has already occurred. It requires action now rather than probability assessment.
For example, “a key engineer may become unavailable during testing” is a risk. “The key engineer is unavailable today” is an issue.
How to use this list
Review each category with the project team and relevant specialists.
Identify which examples are plausible for your project and objectives.
Rewrite each generic example using project-specific causes, events, and consequences.
Assign an owner who can monitor the risk and coordinate a response.
Assess probability and impact using your organisation’s risk model.
Select proportionate treatments and connect them to accountable work.
Review risks regularly as assumptions, dependencies, and delivery conditions change.
How to write a clear project-risk statement
A practical format is:
Because of cause, there is a risk that event may occur, resulting in consequence.
For example: Because requirements have not been validated with all business stakeholders, there is a risk that significant scope changes will be requested during development, resulting in rework, schedule delays, and additional cost.
This structure separates the source of uncertainty from the event and its effect. It also gives the team useful starting points for controls, treatments, monitoring, and escalation.
How many risks should a project register contain?
There is no universally correct number. A useful register contains the material, actionable uncertainties that decision-makers and delivery teams need to manage—not every conceivable problem. A small, complex project may have more meaningful risks than a larger but highly repeatable one.
Prioritise quality over volume. Combine duplicates, retire risks that are no longer plausible, move realised risks into issue management, and keep enough detail to support ownership and decisions.
Scope and requirements risks
Scope changes significantly after the project commences.
The volume of change requests exceeds the team’s capacity to assess and deliver them.
Vague requirements cause estimation errors.
New client constraints are introduced after the project starts.
Hidden assumptions make estimates unreliable.
Hidden complexity causes the required effort to be underestimated.
Regulatory changes introduce unplanned scope or rework.
Schedule and dependency risks
The delivery schedule is overly optimistic.
A prerequisite project is delivered late.
Required client approvals are late.
Required internal approvals are late.
Required regulatory approvals are late.
Resources required by the project arrive late.
Facilities are not available when planned.
Hardware is not available when planned.
Infrastructure is not available when planned.
New development tools are not available when planned.
People and resource risks
Key technical staff are unavailable when needed.
Internal subject-matter experts are unavailable when required.
Shared resources are reallocated to another project.
Project staff are reassigned before critical work is complete.
Recruitment takes longer than expected.
Staff turnover causes knowledge loss and delivery disruption.
Support obligations distract staff from planned project work.
Technology and infrastructure risks
Hardware fails during a critical project activity.
Infrastructure fails or performs below the required level.
Facilities or infrastructure become unavailable.
New development tools require more learning time than expected.
New technology requires more learning time than expected.
The selected technology is poorly understood by the delivery team.
Unexpected integration problems cause rework or reduced functionality.
Access to required hardware is restricted.
Access to required infrastructure is restricted.
Stakeholder and governance risks
Client decision cycles are slower than expected.
Client feedback is inadequate or unavailable.
Client feedback arrives later than planned.
Internal decision cycles delay delivery.
Supplier and vendor risks
A vendor delivers required components late.
Delivered components or services do not meet the required quality.
A vendor delivers required services late.
Worked project risk examples
Schedule risk
Risk statement: Because initial estimates exclude integration testing and contingency, there is a risk that the delivery schedule is overly optimistic, resulting in missed milestones and increased cost.
Possible treatment: Re-estimate with the delivery and testing teams, validate dependencies, and introduce appropriate schedule contingency.
Resource risk
Risk statement: Because specialist knowledge is concentrated among two employees who support competing projects, there is a risk that key technical staff will be unavailable, resulting in delayed design decisions and critical tasks.
Possible treatment: Nominate backups, cross-train team members, document key decisions, and confirm resource commitments with functional managers.
Supplier risk
Risk statement: Because the supplier plan has limited schedule detail and relies on international logistics, there is a risk that components will arrive late, resulting in delayed installation and dependent testing.
Possible treatment: Add contractual milestones, monitor leading indicators, hold schedule reviews, and identify alternate suppliers or substitute components.
Technology risk
Risk statement: Because external interfaces are incompletely documented, there is a risk that unexpected integration problems will arise, resulting in rework, delay, or reduced functionality.
Possible treatment: Run an early proof of concept, agree interface specifications, and define automated contract and integration tests.
Scope risk
Risk statement: Because requirements have not been validated with all business stakeholders, there is a risk that significant scope changes will be requested during development, resulting in rework, schedule delays, and additional cost.
Possible treatment: Complete stakeholder validation, document acceptance criteria, agree change control, and prioritise early demonstrations of high-uncertainty requirements.
Governance risk
Risk statement: Because approval responsibilities and decision deadlines are unclear, there is a risk that internal approvals will be delayed, resulting in idle delivery teams and missed milestones.
Possible treatment: Define decision owners and due dates, schedule approval forums, and establish an escalation path before approvals become critical.
