Someone in the risk session says 'one more risk: the supplier', the note-taker types it straight into the table, and no one checks whether a category got skipped. The result is a register that mainly shows who happened to be at the table: the engineer names technology, the controller names budget, and the rest of the risk landscape goes unnamed.
A good risk analysis works the other way around: you systematically walk through a fixed set of categories and force yourself to ask, for each one, the uncomfortable question no one raises spontaneously. In this article, we cover the five categories that together cover virtually the entire risk landscape of a project plan. For each category: the classic pitfall, a recognisable example, and the question you should ask yourself.
1. Scope & Requirements
The classic pitfall: everyone thinks they mean the same thing
Scope risks rarely arise because the scope has not been described. They arise because the description leaves room for multiple interpretations, and everyone reads their own version. "The new system replaces the existing application" sounds clear, until it turns out the sponsor also meant the fourteen custom interfaces that appear in no document whatsoever.
The second variant is more insidious: scope creep. Not one big change, but thirty small "surely this logically belongs to it" requests, each of which sounds reasonable on its own and which together add up to half an extra project.
Recognisable example: a municipal IT project that starts as "replacement of the case management system" and gradually turns out to touch the website, the customer contact centre and three chain partners as well, without the budget or schedule ever being adjusted.
The question to ask yourself: Can I think of two different interpretations for every key term in the scope description, and if so, which one applies?
2. Planning & Resources
The classic pitfall: the schedule allows for no setbacks
Virtually every project schedule is built from best-case estimates glued together as if they were independent. Every step is "achievable", so the whole appears achievable. But ten steps that each have an 80% chance of success together produce a schedule that will almost certainly overrun.
The same applies to resources: the plan counts on "0.5 FTE senior architect", but that architect is meanwhile running three other projects and still has holiday leave booked. On paper the capacity is there; in practice you have to fight for it.
Recognisable example: an implementation project in which the only specialist with knowledge of the legacy system leaves in month four: exactly the scenario everyone said "yes, that would be unfortunate" about at the start, without doing anything about it.
The question to ask yourself: Which person or which moment in this schedule has no alternative whatsoever, and what happens if something goes wrong precisely there?
3. Budget & Finance
The classic pitfall: the contingency is a guess, not a calculation
Budget risks are often narrowed down to "it could get more expensive". But the interesting risk lies in the structure of the budget, not its size. Is the contingency based on the actual uncertainties in this project, or is it the standard ten percent that always goes on top? Have the structural costs after the project (maintenance, licences, further development) been included, or does the budget stop at go-live?
And then there is the silent assassin: price indexation and contract terms in multi-year projects. A quotation valid for twelve months is of little help on a thirty-month project.
Recognisable example: an organisation that carefully monitors the implementation budget, but discovers after go-live that the annual licence and maintenance costs are higher than what the business case was calculated on, causing the benefits to evaporate after all.
The question to ask yourself: If this project ends up 30% more expensive, where will that overrun most likely come from, and have I already made that scenario visible somewhere?
4. Quality & Compliance
The classic pitfall: quality only becomes a topic when it is too late
Quality risks share a nasty characteristic: they are invisible until just before the deadline. A project can be "green" for months while quality quietly erodes, because quality (unlike time and money) is rarely measured hard. Testing gets cut when the schedule tightens, because it is the only buffer left. Documentation shifts to "after go-live". Review rounds become formalities.
Compliance is the aggravated variant: privacy legislation, records management law, accessibility requirements, procurement rules, security baselines. The defining feature of compliance risks is that they are binary. You comply, or you do not, and fixing things afterwards is almost always more expensive than building them in from the start.
Recognisable example: a consultancy that delivers a platform for a public-sector client that works excellently in functional terms, but does not meet the accessibility requirements that are simply a legal obligation for government websites. The remediation costs exceed the original development costs.
The question to ask yourself: Which requirements are non-negotiable, and where in the plan is it demonstrated that we will meet them?
5. Stakeholders & Communication
The classic pitfall: support is confused with the absence of objection
This is the category that is most often underestimated, because the risks seem soft. They are not. More projects fail because of stakeholders than because of technology, it just never appears that way in the evaluation.
The pitfall: at the start, everyone is positive, or at least not negative. That gets recorded as support. But silence is not support. The department that will have to work differently may never have really read the plan. The executive who "supports" the project has no political capital to spend on it when things get tense. And the works council only mobilises once the change becomes concrete, precisely when the project has no room to manoeuvre left.
Recognisable example: a programme in which project leadership dutifully reports to the steering committee for months, while the people who will have to work with the result hear through the grapevine what is being decided about their work. The resistance that then emerges is called "poor adoption" in the evaluation, but it was a communication risk that was there from day one.
The question to ask yourself: Who can delay or derail this project without ever formally saying "no", and what am I already doing for that person or group?
Why these five together
The power lies not in the individual categories but in the combination. Those who steer only on schedule and budget miss the soft risks that cause the hard ones: most budget overruns start as scope ambiguity, and most delays start as stakeholder trouble. By systematically walking through all five, including the categories you feel comfortable with, you prevent your risk register from becoming a mirror of your own blind spots.
Want to know where your own risk register still has blind spots? Upload your project plan to RisicoRadar: the tool checks it against all five categories and fifteen underlying subcriteria and lays out the weak spots in a single radar chart.