Project Management guide · Risk, quality and control
What Is Project Risk? Types, Examples and Risk Statements
A project risk is an uncertain event or condition that, if it happens, would have a positive or negative effect on at least one project objective, such as scope, schedule, cost or quality. Negative risks are threats and positive risks are opportunities. This guide explains how to describe risks clearly, the main types with examples, and how to find them before they turn into problems.
Key takeaways
- A project risk is uncertain and in the future; once it has happened it is an issue.
- Risks can be threats (negative) or opportunities (positive), and both deserve attention.
- Write every risk as cause, event and effect so the team can analyse it and act on it.
- Group risks by type (schedule, cost, scope, technical, resource, external and more) to spot gaps.
- Identify risks continuously, from the charter onwards, and record them in a risk register with an owner.
What is project risk?
Project risk is an uncertain event or condition that, if it occurs, has a positive or negative effect on one or more project objectives. PMI uses this definition in the PMBOK Guide. The key ideas are uncertainty (it may or may not happen), the future (it has not happened yet) and an effect on what the project is trying to achieve.
Those three ideas are a useful test. If something is certain, it is a fact to plan for, not a risk. If it has already happened, it is an issue. If it would not affect scope, time, cost, quality or the expected benefits, it is not worth tracking as a project risk.
- Objectives a risk can affect: scope, schedule, cost, quality, benefits, safety, reputation or stakeholder satisfaction.
- What a risk is not: a certainty ('the office move is in March'), a current problem ('the server is down') or a vague worry ('resourcing').
- Why it matters: projects are temporary and unique, so they always carry uncertainty. Naming it early gives you time to respond while options are still cheap.
The most recent edition of the PMBOK Guide (the eighth, published in November 2025) keeps risk as one of its performance domains and continues to distinguish risks, which have not yet occurred, from issues, which have.
Threats and opportunities
Most people hear 'risk' and think of something bad. In project management a risk can go either way.
| Threat (negative risk) | Opportunity (positive risk) | |
|---|---|---|
| Effect if it happens | Harms one or more objectives | Benefits one or more objectives |
| Example | A key supplier may deliver three weeks late | A new test tool may halve regression testing time |
| Typical responses | Avoid, mitigate, transfer, accept, escalate | Exploit, enhance, share, accept, escalate |
| Common mistake | Ignoring threats outside the team's control | Not looking for opportunities at all |
Teams rarely find opportunities by accident. Ask directly in risk workshops: 'What could go better than planned, and how could we make it more likely?' Typical opportunities include reusing work from another project, a price fall, an early approval or a supplier finishing ahead of schedule.
The three parts of a risk: cause, event and effect
A well-described risk has three parts. Separating them stops teams confusing the reason for a risk with the risk itself, or with its consequence.
| Part | Question it answers | Example |
|---|---|---|
| Cause | What fact or condition exists now? | The supplier has only one production line |
| Event | What uncertain thing might happen? | The line may break down during our order |
| Effect | What would that do to our objectives? | Delivery slips by three weeks and the launch date is missed |
A simple template turns the three parts into one sentence: Because of [cause], there is a risk that [event], which would lead to [effect].
How to write a project risk statement
A risk statement is the sentence you put in the risk register. Writing it well makes scoring, ownership and responses much easier.
- Start with the cause. State the fact or condition that creates the uncertainty, such as a constraint, an assumption or a dependency.
- Describe one uncertain event. Use 'may' or 'might'. If you find two events, split them into two risks.
- State the effect on an objective. Make it measurable where you can: days of delay, cost, scope lost or quality affected.
- Check it is not an issue or a certainty. If it has happened or definitely will, handle it differently.
- Check someone can act on it. A good statement suggests who should own it and what a response might look like.
| Poor risk statement | Better risk statement |
|---|---|
| Resources | Because the data engineer is also on the finance project, they may be unavailable in May, delaying the data migration by two weeks. |
| Budget overrun | Because hardware is priced in US dollars, a weaker pound may raise equipment costs by up to 8%, exceeding the budget. |
| Requirements might change | Because the sales team has not reviewed the requirements, new features may be requested after sign-off, adding rework and scope creep. |
| Weather | Because the roof works are scheduled for November, heavy rain may stop work for several days, delaying the watertight milestone. |
Types of project risk
Grouping risks by type helps you check that identification has covered every area, and helps you compare risks across projects. There is no single official list; use categories that suit your organisation. The table shows a common set.
| Type | Typical sources | Example risk |
|---|---|---|
| Schedule | Optimistic estimates, late approvals, dependencies | Planning permission may take longer than eight weeks, delaying the start on site |
| Cost | Price rises, exchange rates, rework, inaccurate estimates | Material prices may rise before orders are placed, increasing costs |
| Scope | Unclear requirements, changing priorities | Stakeholders may request extra reports after design sign-off |
| Technical | New technology, integration, performance | The new API may not handle peak volumes, causing slow response times |
| Resource | Skills gaps, competing projects, staff turnover | The only specialist may leave, stalling testing |
| Quality | Defects, unclear acceptance criteria | Acceptance criteria may be interpreted differently, causing rejected deliverables |
| Procurement and supplier | Supplier capacity, contract terms, insolvency | A subcontractor may go out of business mid-project |
| Stakeholder and communication | Low engagement, conflicting interests | The sponsor may lose interest after a reorganisation |
| Organisational | Funding cuts, restructuring, competing initiatives | The budget may be cut at the mid-year review |
| External | Regulation, weather, market, political events | New data rules may require extra security controls |
Many organisations turn their categories into a risk breakdown structure (RBS), a hierarchy of risk sources similar to a work breakdown structure. Walking through it in a workshop is a quick way to find gaps.
Individual risk and overall project risk
PMI distinguishes individual project risks, the specific events in your register, from overall project risk, the effect of all uncertainty on the project as a whole. A project can have no single critical risk and still be very risky overall because of many medium risks, ambitious targets or complexity. Overall risk is usually discussed at sponsor or board level and can be estimated with techniques such as Monte Carlo simulation.
Known and unknown risks
- Known risks have been identified and analysed. You plan responses for them and usually cover their expected cost with a contingency reserve inside the cost baseline.
- Unknown risks cannot be identified in advance. Organisations often cover them with a management reserve held outside the baseline and released through governance.
- Emergent risks are those that only become visible as the project progresses, which is why identification must continue throughout.
Project risk, business risk and operational risk
Project risk affects the project's own objectives: delivering the agreed scope on time, on budget and to quality. Business risk affects the wider organisation's goals, for example whether a new product sells once it is launched. Operational risk sits in day-to-day running of the business after handover, such as a system outage. The three are linked: a project often exists to reduce a business risk, and shortcuts taken during a project can create operational risk later.
Exam guides also separate speculative risk, which can lead to a gain or a loss, from pure risk, which can only lead to a loss, such as fire or theft. Pure risks are often transferred through insurance.
Project risk examples by industry
Real risk statements are specific to the project. These examples show what threats and opportunities look like in different settings.
| Industry | Risk statement | Threat or opportunity |
|---|---|---|
| IT and software | Because the legacy database has undocumented fields, data may fail validation during migration, delaying go-live. | Threat |
| IT and software | Because the cloud provider offers a managed service for this component, we may be able to drop two weeks of build work. | Opportunity |
| Construction | Because the site has not been surveyed for contamination, ground works may uncover hazardous material, adding cost and delay. | Threat |
| Construction | Because the neighbouring project uses the same crane supplier, we may be able to share mobilisation costs. | Opportunity |
| Events | Because the venue is in a flood zone, heavy rain may close access roads, cancelling the event. | Threat |
| Marketing | Because the brand team is reviewing guidelines, creative may need reworking, delaying the campaign launch. | Threat |
| Product | Because a component supplier is launching a cheaper model, unit costs may fall by around 10%. | Opportunity |
| Public sector | Because the policy is under consultation, reporting requirements may change during delivery. | Threat |
Common project risks and early warning signs
Some risks appear on almost every project. Knowing their early warning signs, called triggers, helps you act before they become issues.
| Common risk | Possible trigger |
|---|---|
| Unclear or changing requirements | Stakeholders disagree in reviews; open questions grow week by week |
| Optimistic estimates | Early tasks finish late; the team reports 'nearly done' for several days |
| Key people unavailable | Repeated meeting cancellations; people booked on other projects |
| Supplier delay | A supplier misses an interim milestone or stops replying promptly |
| Scope creep | Small requests bypass change control |
| Technical uncertainty | Prototype results differ from expectations; performance tests fail |
| Weak sponsor support | Decisions are deferred; the sponsor misses steering meetings |
| Budget pressure | Spend runs ahead of progress; estimates to complete keep rising |
| Low stakeholder engagement | Feedback arrives late or not at all; few people attend demos |
Record the trigger next to each risk so the owner knows what to watch for. Our guide to stakeholder management covers many of the people-related risks in more depth.
Risk attributes you should record
A risk statement on its own is not enough to manage the risk. Most teams record these attributes for each one.
| Attribute | What it means |
|---|---|
| ID and category | A unique reference and the type of risk |
| Probability | How likely the event is, on an agreed scale such as 1 to 5 |
| Impact | How severe the effect would be, on an agreed scale |
| Score | Probability multiplied by impact, used to rank risks |
| Proximity | When the risk could occur, so near-term risks get attention first |
| Owner | The named person who monitors the risk and makes sure the response happens |
| Trigger | The warning sign that the risk is occurring |
| Response | The chosen strategy and actions, with dates |
| Status | Open, monitoring, closed or occurred |
Our free risk register template includes the core attributes with an automatic probability x impact score.
Risk vs issue vs assumption vs constraint
These terms are often mixed up. Each one is handled differently, so it is worth separating them.
| Term | Definition | Example | Where it is tracked |
|---|---|---|---|
| Risk | An uncertain future event that would affect objectives | The supplier may deliver late | Risk register |
| Issue | Something that has happened and needs action now | The supplier has delivered late | Issue log |
| Assumption | Something believed to be true for planning, without proof | The supplier can deliver in six weeks | Assumptions log or RAID log |
| Constraint | A fixed limit the project must work within | The launch date is 1 March | Charter and plan |
| Dependency | A link where one piece of work relies on another | Installation depends on the delivery | Schedule or RAID log |
Assumptions are one of the best sources of risk. For every assumption, ask what would happen if it proved false. If the answer is serious, log a risk. A RAID log keeps risks, assumptions, issues and dependencies together, which suits smaller projects; see our RAID log template.
How to identify project risks
Risk identification works best as a team activity that starts during initiation and continues to closure.
- Review the project documents. Read the project charter, scope, schedule, budget, assumptions and constraints, asking what could go differently.
- Challenge assumptions. For each one, ask how confident you are and what happens if it is wrong.
- Walk through the work. Go through the work breakdown structure and schedule, especially the critical path and external dependencies.
- Run a risk workshop. Bring together the team, sponsor, users and key suppliers. Brainstorm threats and opportunities by category.
- Use past experience. Check lessons learned and risk registers from similar projects.
- Ask specialists. Use expert judgment for technical, legal, safety or commercial areas.
- Use structured techniques. Checklists, a risk breakdown structure, SWOT analysis and root cause tools such as a fishbone diagram help teams think beyond the obvious.
- Record and assign. Write each risk as cause, event and effect, log it in the register and name an owner.
Identification is the first step of a wider process that includes analysis, response planning and monitoring.
Project risk in Agile projects
Agile ways of working reduce many risks by design. Short iterations, frequent demos and a prioritised backlog surface problems early and limit how much work is lost if direction changes. Risk still needs attention, though.
- Raise risks in sprint planning, daily stand-ups and retrospectives rather than only in a separate meeting.
- Tackle high technical risks early, for example with a time-boxed spike in an early sprint.
- Add risk-reducing work to the backlog so it is prioritised alongside features.
- Use a clear Definition of Done to reduce quality risk.
- Keep a lightweight risk list or board for risks that span several sprints or depend on other teams.
Common mistakes when describing project risks
- Writing categories instead of risks. 'Staff risk' cannot be scored or owned; 'the lead developer may leave in Q2' can.
- Recording issues as risks. If it is already happening, move it to the issue log and act now.
- Listing certainties. A known public holiday is a planning fact, not a risk.
- Mixing several events in one statement. Split them so each can be scored and owned.
- Ignoring opportunities. A register with only threats misses ways to finish sooner or cheaper.
- Identifying risks once. New risks appear at every phase; review the list at each stage gate and when anything significant changes.
- No owner. A risk without a named owner is rarely managed.
Free templates for this topic
Frequently asked questions
What is a project risk?
A project risk is an uncertain event or condition that, if it occurs, would have a positive or negative effect on at least one project objective such as scope, schedule, cost or quality.
Can a project risk be positive?
Yes. Positive risks are called opportunities. Examples include a price falling, a task finishing early or a new tool reducing effort. They are managed with responses such as exploit, enhance and share.
What is the difference between a project risk and an issue?
A risk might happen in the future; an issue has already happened and needs action now. When a risk occurs it becomes an issue and is usually moved to the issue log.
What is a project risk statement?
A sentence that describes a risk's cause, uncertain event and effect, for example: 'Because of [cause], there is a risk that [event], which would lead to [effect].' It makes the risk specific enough to analyse and act on.
What are the main types of project risk?
Common types are schedule, cost, scope, technical, resource, quality, procurement, stakeholder, organisational and external risk. Risks can also be classified as threats or opportunities, known or unknown, and individual or overall.
What are the most common project risks?
Unclear or changing requirements, optimistic estimates, key people being unavailable, supplier delays, technical uncertainty, scope creep and weak sponsor support appear on many projects.
What is a risk trigger?
A warning sign that a risk is about to occur or has occurred, such as a supplier missing an interim milestone. Recording triggers helps risk owners act early.
What is overall project risk?
The effect of uncertainty on the project as a whole. It combines individual risks with other sources of variability such as complexity and ambitious targets.
What is a secondary risk?
A new risk that arises directly from carrying out a response to another risk. For example, outsourcing a task to reduce a skills risk can introduce a supplier performance risk.
What is risk tolerance in project management?
The acceptable range of variation around an objective, such as a budget overrun of no more than 5%. Risks that could push the project outside its tolerances need a response or escalation.
Who is responsible for identifying project risks?
Everyone involved. The project manager facilitates identification, but team members, the sponsor, users and suppliers often see risks the project manager cannot.
Is an assumption a project risk?
Not by itself, but an assumption that might prove false is a source of risk. Reviewing assumptions is one of the most effective ways to identify risks.
What is the difference between project risk and business risk?
Project risk affects the project's objectives, such as delivering on time and budget. Business risk, in the organisational sense, affects the wider organisation, for example whether the product sells once delivered. The two are linked, and a project can reduce or create business risk.
Where should project risks be recorded?
In a risk register, or in a RAID log on smaller projects, with an owner, score, response and status for each risk.