What separates a useful risk example from a useless one?
A useful entry names a cause, an uncertain event, and a consequence, in that order. “The payments team has not confirmed the API contract, which may delay the checkout integration and push the launch date by three weeks” can be managed. “Technical risk” cannot.
The test is simple: read the entry aloud and ask what you would do on Monday. If the answer is “watch it,” the entry is too vague to act on. If the answer is a specific action with a person attached, the entry is doing its job.
Two other habits raise quality immediately. Write risks as uncertain events, not as problems you already have (a problem is an issue and belongs in an issue log). And rate impact in the unit the business cares about: currency, weeks, or a quality threshold. “High” is not a unit.
The 40 project risks examples
The tables are grouped by source so a workshop can move category by category. The trigger column matters more than it looks: a trigger is what converts monitoring into action.
Join Doitify Today
Move projects forward without the chaos: all your tasks, progress, and team reports in one unified workspace. Built for companies, startups, and remote teams — with a quick setup and a free trial.
Scope and requirements (1–7)
| # | Risk | Trigger that tells you it is happening | First response |
|---|---|---|---|
| 1 | Requirements are unclear or contradictory | Two stakeholders describe the same feature differently | Run a structured requirements workshop with a written sign-off |
| 2 | Scope creep from small additions | Change requests rising without baseline updates | Require every change to state its schedule and cost impact |
| 3 | Priorities shift mid-project | Sponsor reorders the roadmap twice in a quarter | Re-plan with explicit trade-offs; something must leave |
| 4 | Acceptance criteria are missing | “Done” means different things to build and QA | Define Given/When/Then criteria before development starts |
| 5 | Gold-plating by the team | Features appear that nobody requested | Review the backlog against the approved scope monthly |
| 6 | Stakeholders disagree on success | Different definitions of “launched” or “complete” | Write one measurable success statement and circulate it |
| 7 | Undocumented assumptions | Decisions rest on facts nobody verified | Keep an assumptions log and convert the risky ones to risks |
Schedule (8–14)
| # | Risk | Trigger | First response |
|---|---|---|---|
| 8 | Optimistic estimates | Every task is “about a week” | Use three-point estimates for anything above a set size |
| 9 | Late external dependencies | A vendor milestone slips by a week | Track dependencies with owners and dates, not just tasks |
| 10 | Underestimated complexity | Rework appears in the first two sprints | Add a spike before committing to the estimate |
| 11 | Approval delays | A review sits in someone’s queue for days | Agree service levels for approvals and name a delegate |
| 12 | Resource conflicts across projects | The same specialist is booked twice | Publish a single workload view across projects |
| 13 | Deadline fixed before scope | The date is announced before the plan exists | Reconcile date, scope, and team size in one conversation |
| 14 | Sequential handoffs | Each phase waits for the previous to finish | Overlap phases or parallelise where dependencies allow |
Resources and people (15–21)
| # | Risk | Trigger | First response |
|---|---|---|---|
| 15 | Key person leaves or is unavailable | Annual leave or resignation in a single-owner area | Require a second person on every critical area |
| 16 | Skill gaps in a new area | The team estimates in days, not hours | Fund training or bring in a specialist early |
| 17 | Part-time availability | A specialist contributes two days a week | Plan around their calendar instead of assuming full time |
| 18 | Team conflict | Two people stop communicating directly | Address it in a facilitated conversation, not a status meeting |
| 19 | Slow hiring | A role open for more than six weeks | Start recruitment before the role is critical |
| 20 | Burnout and sustained overtime | Overtime becomes the plan rather than the exception | Cap sustained overtime and re-plan the scope |
| 21 | Onboarding lag for new members | A new hire is unproductive after three weeks | Assign a buddy and a first-week deliverable |
Technical (22–28)
| # | Risk | Trigger | First response |
|---|---|---|---|
| 22 | Unproven technology | No production reference for the chosen stack | Run a time-boxed spike with a go/no-go decision |
| 23 | Integration surprises | Two systems disagree on data shape or timing | Build and test the integration contract first |
| 24 | Performance shortfalls | Load tests are deferred to the end | Set a measurable threshold and test early |
| 25 | Poor data quality in migration | Repeated exceptions in sample extracts | Profile the data before migration, not during |
| 26 | Security vulnerability discovered late | Penetration testing scheduled for the final week | Threat-model at design and test continuously |
| 27 | Legacy technical debt slows change | Small changes require large workarounds | Ring-fence debt work in the estimate |
| 28 | Third-party API or dependency changes | A vendor announces a deprecation | Track vendor changelogs and pin versions |
External (29–34)
| # | Risk | Trigger | First response |
|---|---|---|---|
| 29 | Vendor failure or insolvency | Late deliveries and reduced responsiveness | Qualify a second source for critical supply |
| 30 | Price or currency swings | Input costs move beyond the estimate band | Fix prices where possible; hold a reserve |
| 31 | Regulatory or compliance change | A consultation paper appears in your sector | Assign a regulatory watch and a review date |
| 32 | Weather or site conditions | Seasonal patterns in the delivery window | Build weather days into the schedule |
| 33 | Stakeholder turnover | A sponsor or approver changes role | Document decisions so they survive the change |
| 34 | Supply chain lead times | Quoted lead times double | Order long-lead items before final design |
Management and governance (35–40)
| # | Risk | Trigger | First response |
|---|---|---|---|
| 35 | Missing or passive sponsor | Escalations go unanswered for a week | Agree a decision service level with the sponsor |
| 36 | Unclear roles and decision rights | The same decision is made twice | Publish a simple RACI for the top decisions |
| 37 | Communication gaps between teams | Two teams build overlapping components | One shared plan and a weekly dependency check |
| 38 | Uncontrolled change | Changes happen without a log | Require a change record with impact and approval |
| 39 | Invisible status | The report is green until the week it fails | Report variance, not just percentage complete |
| 40 | Decision latency | The same item appears in three meetings | Assign a decision owner and a deadline per item |
Forty rows is not a target for your register. It is a starting surface to react to: most projects will recognise six to ten of these as live, and those are the ones worth scoring properly.
How do you score these risks without spending a week on it?
Use a five-point likelihood scale and a five-point impact scale, multiply them, and set thresholds in advance. The maths is trivial; the discipline is agreeing the scales before the workshop so two people score the same risk similarly.
| Score (L × I) | Band | What it requires |
|---|---|---|
| 20–25 | Critical | Response plan, named owner, weekly review, sponsor visibility |
| 12–19 | High | Response plan and owner, reviewed each status cycle |
| 6–11 | Medium | Monitor with a defined trigger |
| 1–5 | Low | Recorded, reviewed quarterly |
Define the impact scale in units. For a $850,000 project, impact 3 might mean “up to $40,000 or two weeks,” impact 5 means “over $150,000 or the launch date moves a quarter.” Without that calibration, every risk becomes a 4.
Example: turning forty risks into a contingency figure
A team filters its register down to six scored risks on an $850,000 project and calculates expected monetary value as probability times cost impact.
| Risk | Probability | Cost impact | EMV |
|---|---|---|---|
| Scope creep from late requirements | 40% | $60,000 | $24,000 |
| Key developer unavailable for four weeks | 25% | $45,000 | $11,250 |
| Payment integration delayed | 30% | $80,000 | $24,000 |
| Vendor price increase at renewal | 20% | $35,000 | $7,000 |
| Regulatory clarification required | 10% | $120,000 | $12,000 |
| Performance shortfall requiring redesign | 35% | $50,000 | $17,500 |
| Total expected exposure | $95,750 |
The sum is 11.3% of the budget. That does not mean the contingency should be $95,750: EMV is an average, and the actual outcome will be closer to one of the individual rows than to the mean. A common approach is to hold the EMV as a baseline, then add a management reserve for the risks you have not identified. On this project, a $96,000 contingency plus a 5% management reserve is a defensible position that a finance committee can interrogate line by line.
The useful side effect is prioritisation. Two risks account for half the exposure, so the effort goes there rather than into polishing the low-scoring rows.
How do you estimate schedule risk properly?
Three-point estimating beats a single guess, and it takes two minutes per task. Ask for optimistic, most likely, and pessimistic durations, then weight them.
For an integration task: optimistic 40 days, most likely 55 days, pessimistic 85 days.
- Expected duration = (40 + 4 × 55 + 85) ÷ 6 = 345 ÷ 6 = 57.5 days
- Standard deviation = (85 − 40) ÷ 6 = 7.5 days
- An 80% confidence date sits at roughly 57.5 + (0.84 × 7.5) ≈ 63.8 days
That last number is the one to put in the plan if the date matters, because committing to the mean gives you a coin-flip chance of being late. The arithmetic also exposes an uncomfortable truth: a wide optimistic-to-pessimistic range is itself a signal that the task is poorly understood, and the right response may be a spike rather than a longer estimate.
Which response strategy fits which risk?
Five strategies cover almost everything, and choosing the wrong one is the most common reason a response plan does nothing.
| Strategy | Use when | Example from the list |
|---|---|---|
| Avoid | The risk is severe and the activity is not essential | Drop the unproven integration and use a proven alternative |
| Mitigate | Probability or impact can be reduced affordably | Prototype the integration contract before full build |
| Transfer | Someone else can carry the consequence | Fixed-price contract or insurance for a defined scope |
| Accept | The cost of response exceeds the exposure | Log it, set a trigger, hold contingency |
| Escalate | It sits above the project’s authority | Regulatory change or enterprise vendor risk goes to the portfolio |
Note what transfer does not do: it moves the financial consequence, not the schedule. A fixed-price contract for a late deliverable still leaves you late.
How often do these risks actually materialise?
More often than project plans assume. Oxford’s project database, covering more than 16,000 large projects, found that only about 0.5% came in on budget, on time, and with the promised benefits. IT projects in the same dataset show a mean cost overrun of 73%, with 59% delivered on budget or below and a small tail where overruns exceed 400%. That distribution is the argument for contingency: most IT projects land near plan, and a minority land catastrophically off it, which is exactly what a reserve is for.
The practical reading is not “everything fails.” It is that the tail is real, and the risks that produce the tail are usually identifiable at kickoff. Scope, integration, data quality, and sponsorship cover a large share of the disasters.
What makes a risk register useless?
- Vague entries. “Schedule risk” cannot be owned, triggered, or closed.
- No owner. A risk without a name attached is a wish with a spreadsheet row.
- Scores with no scale definition. Likelihood and impact mean different things to different people unless you write the definitions.
- A register that is only written at kickoff. Risks are discovered continuously; a register frozen in month one measures optimism, not exposure.
- Confusing risks with issues. An issue is already happening and needs action today; a risk may happen and needs a trigger.
- Responses that are really hopes. “Monitor closely” is not a response unless something specific happens when the trigger fires.
- Contingency without a rule. Money held for risks needs a stated way to release it, or it becomes either untouchable or free.
Who should own the register, and how often should it be reviewed?
The project manager owns the process; individual risk owners own the responses. That distinction matters, because a register where the PM owns all forty rows is a register nobody else uses.
Review cadence should match the delivery rhythm: weekly for fast-moving delivery work, monthly for construction and enterprise programmes, plus a full re-identification at each phase gate. Each review should close what has passed, update probabilities, and ask one fresh question: what changed since last time that nobody has written down?
Tooling is the quiet failure point. When the register is a separate spreadsheet, it drifts from the plan it is supposed to protect. Keeping risks, constraints, owners, and mitigation tasks in the same workspace as the delivery plan means a mitigation action is a real task with a date rather than a note. That is how Doitify handles risks and constraints: they live next to tasks, milestones, and reports, so the response work is visible in the same workload view as everything else. It suits teams that need the discipline without a dedicated risk module, and it is not a quantitative risk engine for a capital programme with Monte Carlo analysis.
FAQ
Conclusion
Forty examples will not make a project safe. They will make the first workshop faster and the register specific enough to act on. That is the entire benefit: a list of things that could go wrong, each with a trigger and a name beside it.
Start with the six categories, keep the ten risks that are genuinely live, score them on defined scales, and turn the top ones into a contingency figure you can defend. Then review the register at every status cycle, because the risks that hurt are usually the ones added in month three and never revisited.
If this post on project risks examples was helpful, you might also enjoy Project Dashboard: What Should It Include? and Software Development Project Template: Sections, Example, and How to Use It.
Join Doitify Today
Move projects forward without the chaos: all your tasks, progress, and team reports in one unified workspace. Built for companies, startups, and remote teams — with a quick setup and a free trial.
