---
{
  "title": "Project risk management",
  "summary": "Manage uncertainty that can affect the project’s objectives.",
  "topic": "delivery",
  "level": "Beginner",
  "updated": "2026-10-12",
  "units": [
    4
  ],
  "aliases": [],
  "sources": [
    {
      "title": "UK Government: Project Delivery Functional Standard",
      "url": "https://www.gov.uk/government/publications/project-delivery-functional-standard"
    }
  ],
  "published": "2026-10-02",
  "editorialVersion": 2
}
---

## The idea

Project risk concerns uncertain events or conditions that may affect delivery, cost, quality, or outcomes. Identify scenarios, assess likely effects, assign owners, and plan responses. Distinguish a risk from an issue that has already happened. Project risks can include unavailable skills, integration uncertainty, dependency failure, or weak adoption. Track them through delivery and reassess after decisions or new evidence.

## In practice

A rollout may fail to meet its date if a required identity integration is incompatible. A small early test reduces that uncertainty before a large commitment.

## A common misunderstanding

A risk register is not useful if owners never review actions or update assumptions.

## Check your understanding

When does a risk become an issue?

**Think it through:** When the uncertain event occurs or a present condition already requires action.


## Describe uncertainty as a scenario

A project risk is an uncertain event or condition that could affect the project's objectives. Distinguish it from an issue that has already happened. A supplier might miss a delivery date is a risk; the supplier has missed today's agreed delivery is an issue. Both require action, but the response and reporting differ.

Write a risk as a cause, possible event, and consequence. For example, because the migration depends on one specialist, their unexpected absence could delay configuration and the pilot. This wording makes possible responses visible: share knowledge, schedule backup capacity, or adjust the dependency. A label such as staffing risk provides much less guidance.

## A fictional capacity problem

A team plans a short security rollout during a busy enrollment period. Its risk review identifies that the support desk may be overwhelmed by recovery requests. The team estimates the likely demand, runs a small pilot, prepares guidance, and arranges an escalation contact. These actions reduce uncertainty before the broad rollout.

A risk owner follows up the response and looks for warning signs. Ownership does not mean that one person must perform every action; it means somebody remains accountable for tracking the scenario. After mitigation, assess what remains rather than marking the risk closed simply because an action was completed. The pilot may reveal that demand is still higher than the team can support.

## Separate four statements

Write one assumption, one uncertain risk, one current issue, and one external dependency for a fictional logging project. Explain which needs validation, which needs a preventive response, which needs resolution now, and which needs coordination. Then choose a warning sign for the risk. This exercise helps prevent a register from becoming a mixed list of concerns with no clear action.

## Keep exploring

- [[risk-register]]
- [[project-dependencies]]
- [[raid-log]]