Identifying Risks: Why a Bigger List Is Not Always a Better List

A risk workshop that produces sixty entries feels like a productive afternoon. Everybody contributed, the register looks thorough, and the project has visible evidence that risk was taken seriously. Three months later that register is still sixty lines long, most of the entries unchanged since the day they were written, and when the sponsor asks which risks could realistically stop delivery, the room hesitates.

Identifying risks well is not a volume exercise. The purpose is to find the uncertainties that could genuinely move a project objective, describe each one so that a named person can own it and act, and keep doing that as the project learns. A register of fifteen risks that are reviewed and decided on will do more for a project than a register of ninety that is only maintained.

Length carries a cost that rarely gets counted. Every entry consumes review time, and review time is finite. When forty of the sixty entries are generic, the meeting spends its attention confirming that nothing has changed on the generic ones, and the two entries that should have triggered a decision get the same thirty seconds as the rest. A long register also creates a false sense of coverage. Nobody feels the need to ask what is missing from a document that already looks exhaustive.

What a risk entry has to do to earn its place

Before adding anything to a register, put the candidate through four tests: whether you can name the project objective it would affect and roughly by how much, whether it is still uncertain or has already happened, whether one named person could own it, and whether there is a response the project would actually take or a trigger it would actually watch for.

An entry that fails all four is context rather than risk. "The organisation is going through a restructure" is a condition the project has to work within. It belongs in the assumptions and constraints the team is managing against, and it may well generate several risks, but on its own it gives nobody anything to do.

That points to the most common weakness in identification, which is the collapse of cause, risk and effect into a single line. "New supplier" is a cause. "Project delivered late" is an effect. The risk sits between them, and only becomes useful when all three are visible. Compare "supplier risk" with this: because the interfaces to the legacy payroll system have never been documented, integration testing may find undefined behaviour late, which would push the go-live decision past the regulatory reporting date. The second version tells you who to talk to, what to watch for and what is at stake. The first tells you nothing you did not already suspect.

Granularity matters as much as wording. "Integration risk" is too broad to own, because no single response addresses it and no single person can be accountable for it. Splitting it into one entry per interface is usually too narrow, because forty near-identical lines will be reviewed as a block or not at all. The practical test is whether one meaningful response can be defined and one person can hold it. If yes, the entry is the right size.

Section 2.7.2 of the PMBOK® Guide treats Identify Risks as a process in its own right within the Risk Performance Domain, sitting alongside planning how risk will be managed, analysing what matters and deciding responses. That ordering is worth taking seriously. Deciding what counts as a risk on this project, what thresholds apply and how much analysis is proportionate should come before the list, not after it. Teams that skip straight to the workshop tend to produce a list that reflects who was in the room, and not what the project is actually exposed to.

Where the risks you are missing usually come from

Brainstorming with the delivery team is a reasonable place to start and a poor place to stop. A group tends to surface the risks it is already worrying about, which are the ones already receiving attention. The risks that hurt are usually the ones nobody in that particular room can see.

More productive places to look include:

• assumptions, both the ones recorded and the ones nobody has written down;
• estimates with the widest spread between best and worst case;
• dependencies on parties the project does not control;
• interfaces between teams, contracts, systems or funding streams;
• anything the organisation is attempting for the first time;
• constraints imposed on the project rather than chosen by it;
• the handover into operations, which is where benefits are usually lost;
• the issue log from the last comparable project.

Consider a shared services transition moving payroll processing out of three regional teams into a single centre. The register held seventy-four entries, most of them recognisable from any transition of that type: resistance to change, resource availability, data quality, scope creep. Go-live slipped twice. The first cause was that two people in one regional team held all the working knowledge of a group of non-standard cases, and neither the transition plan nor the register mentioned it, because the identification workshop had involved the programme team and nobody who actually processed the payroll. The second was a statutory reporting date that appeared in the register as "compliance risk" with no owner, no date and no response.

Both were findable. The first needed somebody to sit with the people doing the work, which surfaces the workarounds, undocumented exceptions and single points of dependency that no group session will produce. The second needed the generic entry to be challenged once, because "compliance risk" is the kind of line that survives review indefinitely precisely because it cannot be disproved.

Checklists and prompt lists have a place here, but the place is narrow. Use them at the end of identification to widen the search, not at the start to populate the register, because a checklist used first produces a project whose risks are the checklist's risks. It is also worth deliberately asking what could go better than planned. Identification that only looks at threats will miss the supplier who can deliver early, the component that turns out to be reusable, or the chance to release part of the scope ahead of the rest.

Identification does not stop when the workshop ends

Treating identification as an event at the start of planning is the reason registers go stale. The list should change when the project's information changes, and there are recognisable moments when it will: an assumption proves false, a design decision closes off options, an estimate is revised, a supplier changes hands, a key person leaves, a phase gate approaches, or an issue occurs. That last one is easy to miss. An issue rarely arrives alone, and asking what else the same underlying condition could produce is one of the more reliable ways of finding the next risk.

Predictive, adaptive and hybrid delivery each set a different rhythm for this. In predictive delivery, identification is often tied to planning cycles, gate reviews and change decisions, with a defined forward horizon. In adaptive delivery it happens continuously in refinement, review and retrospective, and much of the near-term uncertainty is handled by reprioritising work rather than by writing anything down. A register still earns its place there for the uncertainties that outlive an iteration: contractual exposure, regulatory dates, architectural commitments, dependencies on other teams. In hybrid delivery the split usually falls along that same line, with cross-workstream and commercial risk carried formally and team-level uncertainty carried in the team's own cadence.

What should not happen is forcing every sprint-level unknown into a formal register to demonstrate rigour. That is how a register reaches ninety lines and stops being read.

Pruning a register you have inherited

Most project managers do not start with a blank register. They inherit one, and inheriting a bloated register is a more common problem than building one from scratch.

A workable pass is to sort before adding. Move anything that has already happened to the issue log. Move causes and standing conditions into assumptions and constraints. Merge effects into the risk that produces them. Then look for duplicates written at different levels of detail, which are easy to miss because the wording differs. Anything left with no owner, no trigger and no response gets a decision: give it one or remove it. Only then ask what is missing, using the sources above, and expect to add fewer entries than you removed.

For a PMP candidate, the useful habit is recognising the type of thing described in a scenario before deciding what to do about it. Exam questions in this area tend to present a situation rather than a definition, and the first judgement is usually whether you are looking at a cause, a risk, a realised issue or simply the operating environment. The 2026 Examination Content Outline places risk work in the Business Environment domain, which accounts for 26 per cent of exam items, with tasks covering identifying, analysing, monitoring and controlling risks and maintaining a risk register, and separately covering the recognition that a risk has become an issue. Reading a scenario and telling those apart quickly is a skill that improves with repetition against other people's examples, which is one reason our PMP® Exam Preparation course works through risk material as a set of decisions rather than a set of definitions.

On a live project the payoff is straightforward. A register that has been pruned and properly worded can be reviewed in fifteen minutes, and the review produces decisions instead of confirmations. Senior stakeholders start to trust it, because when they ask what could stop delivery they get three specific answers with names against them. That trust is what makes escalation work later, when one of those three risks turns into something the project cannot absorb on its own.

Andre Malowney

Interested in going further?

Telling a cause from a risk, and a risk from something that has already happened, is one of the judgements that separates a register people use from one they tolerate. Structured preparation gives you repeated practice at making that call under scenario conditions, alongside the wider risk reasoning the current exam expects.

The PMBOK® Guide Eighth Edition sets Identify Risks in the context of the full Risk Performance Domain, which is useful if you want to see how identification connects to analysis, response and monitoring.

Ad · Amazon affiliate link.

References

A152: The PMBOK 8 Risk Performance Domain: What It Really Covers
A153: Risk vs Issue: The Difference That Changes What You Do Next
A154: When Does a Risk Become an Issue?
A155: Risk Register vs Risk Report vs Issue Log: What Goes Where?
A157: Do Agile and Hybrid Projects Still Use Risk Registers?

PMP and PMBOK are registered marks of the Project Management Institute, Inc.