In the plan of approach for a municipal system migration, the word 'once' appears four times: once the supplier delivers, once the users are retrained, once the legislation doesn't change. Nobody ever asked out loud what happens if one of those 'onces' doesn't come true — until the supplier turns out to be five months late. Every plan of approach rests on such a set of assumptions: that the supplier delivers on time, that users cooperate, that the technology does what the brochure promises, that the organisation can handle the change. The question is never whether a plan rests on assumptions, but whether those assumptions were written down or crept in silently. And silent assumptions are the most dangerous, because you cannot manage a risk you haven't named.
The core question
There is one question that lays bare the quality of a plan: what all has to be true for this plan to hold? Whoever asks that question seriously often discovers a long list of conditions the plan treats as self-evident. Every condition that must be true but is not certain is an assumption. And every assumption is a potential fracture point.
Assumptions are the hinge between optimism and testability. As long as they remain implicit, a plan can be as optimistic as it likes without anyone being able to check it. The moment they are explicitly on paper, all optimism suddenly becomes verifiable: does this assumption actually hold? On what is it based? What happens if it turns out to be false?
Assumptions make optimism testable
This is the direct bridge to the bias literature. Estimates and schedules are systematically too optimistic — not out of ill will, but because people naturally assume the favourable outcome. Optimism, however, cannot be countered with the call to "be more realistic". It can be countered by making the presumptions on which the optimism rests visible, one by one.
Take an estimate that assumes the full availability of a scarce team. As long as that assumption is implicit, the schedule looks tight and feasible. The moment you write down "this plan assumes that the three senior specialists are 100 percent available for six months", you immediately see how fragile it is. Making the assumption explicit does the optimism no violence — it makes it open to discussion.
An assumption you write down, you can test. An assumption you keep quiet tests itself — at the worst conceivable moment.
From assumption to risk
The moment assumptions are explicit, they become usable for risk management. For every assumption carries a risk within it: the risk that it is not true. A good plan links the two explicitly — for each critical assumption: how likely is it to hold, and what is the impact if it does not?
Williams and colleagues place risk assessment firmly at the core of quality-at-entry — it is a fixed part of the front-end review. The Advisory Board on IT Assessment names "risk management and project dependencies" as one of its risk areas. Those dependencies are nothing other than assumptions about other parties: that they deliver, cooperate, or finish their part on time.
The assumptions kept quiet most often
Some assumptions are almost never written down, precisely because they are so comfortable:
- Behavioural assumptions: that users will actually use the new system, that staff embrace the change.
- Capacity assumptions: that the organisation can handle this project alongside the regular work.
- External assumptions: that legislation, market or suppliers do not change over the duration.
- Knowledge assumptions: that the team knows what it thinks it knows about the complexity of the task.
These are precisely the assumptions that afterwards, in an evaluation of a failed project, are put forward as "unforeseen circumstances". They were rarely unforeseen — they were unnamed.
Testable, not exhaustive
A caveat: the aim is not an exhaustive list of every conceivable assumption. That bogs down into an unreadable document in which the critical assumptions drown among the trivial. It is about the assumptions that are material — the ones that make the plan wobble if they turn out to be false.
The test is simple: would the plan change fundamentally if this assumption did not hold? If so, it belongs explicitly in the plan, with an estimate of likelihood and impact. If not, it may remain implicit.
What this means for you
Take the plan of approach that's on your desk right now and ask one question out loud about its most important assumption: what happens if this turns out not to be true? Write the answer into the plan itself, with an estimate of likelihood and impact — not in your head, where it goes quiet again.
A plan that names its assumptions knows its own weak spot. A plan that hides them only discovers it when it's too late.
Sources
- Williams, T., Vo, H., Samset, K. & Edkins, A. (2019), The front-end of projects: a systematic literature review, Production Planning & Control.
- Adviescollege ICT-toetsing, Toetskader (risicogebied "Risicobeheersing en projectafhankelijkheden").