The Beliefs Beneath the Baseline: Making Delivery Assumptions Testable
Delivery plans are usually judged by their tasks: milestones, dependencies, resource allocations and completion dates. Yet many plans fail not because a task was missed but because a belief held quietly beneath the baseline turned out to be wrong. A supplier will be ready on time. A regulatory approval will take six weeks. A key system will integrate without rework. A named specialist will remain available. These are assumptions, and in too many UK delivery teams they live in slide notes, meeting memory or the private confidence of a workstream lead.
An assumption register is a modest response to a serious problem. It does not replace the plan, the risk log or the decision log. It gives the plan's hidden dependencies a visible place to be examined, owned and tested before they become slippage.
Why assumptions escape governance
Risk registers tend to capture threats and uncertainties that are already recognised. Assumptions are different: they are beliefs treated as true for planning purposes, often because the plan cannot proceed without them. That makes them easy to overlook. They sit inside cost estimates, dependency dates and resource plans without ever appearing as items requiring confirmation.
The problem is rarely a shortage of diligence. It is a shortage of structure. When an assumption is not written down, it cannot be assigned, tested or retired. It can only be discovered later, usually at the point when it has already changed the delivery position.
For UK delivery teams, the commercial and public-sector consequences are familiar. A programme board receives an assurance paper that looks complete because every task has a status. Beneath it, a load-bearing belief about supplier capacity, planning consent, data quality or specialist availability has not been examined for months. The plan is presentable. It is not yet reliable.
A register built for decisions, not decoration
An assumption register should be short enough to maintain and specific enough to act on. The test is not whether it looks thorough. The test is whether a weekly review can use it to make a decision.
Each entry should state the assumption in plain language, describe what changes if it proves false, and name a single owner. It should record the evidence currently supporting the belief, the method by which that evidence will be tested, and the date by which the test must be complete. A status field keeps the position visible: untested, testing, validated, invalidated or retired.
A decision trigger is also useful. If the assumption fails, what happens next? That may be a fallback option, a change request, a re-planning session or an escalation to the programme board. Recording the trigger in advance prevents a late surprise from becoming an unstructured argument.
The one-page format
A practical one-page register can use the following columns. It works as a spreadsheet, a shared document or a printed sheet for review meetings.
| Field | What it should answer |
|---|---|
| Assumption | What are we treating as true? |
| Consequence if false | What changes in cost, time, scope, compliance or service? |
| Owner | Who is accountable for testing and updating it? |
| Evidence | What currently supports the belief? |
| Test method | How will we prove or disprove it? |
| Test by | When must the test be complete? |
| Status | Untested, testing, validated, invalidated or retired. |
| Decision trigger | What decision follows if the evidence changes? |
The format is deliberately narrow. It does not ask teams to document every thought behind the plan. It asks them to identify the beliefs that carry weight and to give each one a route to confirmation or challenge.
Using it in the weekly review
A weekly delivery review does not need a long assumption session. Fifteen minutes is often enough if the register is current. The team should sort entries by test-by date and consequence, then ask three questions: which assumptions are due for testing, which have evidence that has expired, and which failures would require a decision this week?
The most useful discipline is to refuse vague statements. 'Monitor the situation' is not a test. 'Obtain written confirmation from the supplier by 20 November' is a test. 'The approval will be straightforward' is not an assumption with evidence. 'The regulator has confirmed the application is complete and the statutory clock has started' is evidence that can be checked.
Evidence also has a shelf life. A verbal assurance from a contractor in September may not support a delivery decision in December. A capacity commitment may hold until a framework call-off is made. The register should show when evidence was last confirmed, not merely that it once existed.
Turning tested assumptions into managed choices
When an assumption fails, the response should be a decision, not a fresh round of optimism. The owner records the new evidence, updates the status and brings the decision trigger into the appropriate governance forum. If the consequence is material, the plan and business case should be adjusted openly rather than protected by revised wording.
This is where the register earns its place. It links delivery detail to governance without turning every uncertainty into an escalation. The programme board sees the beliefs that matter, the evidence behind them and the dates by which they will be resolved. Workstream leads see what they are accountable for testing. The plan becomes a living set of propositions rather than a fixed statement of intent.
A simple example illustrates the point. A regeneration programme assumed that a utility diversion would be completed within a fixed window. The evidence was a verbal assurance from a contractor. The test-by date passed without written confirmation. The weekly review flagged the gap and triggered a fallback discussion before the diversion affected the construction sequence. The register did not predict the future. It made the dependency visible early enough to manage.
Start small, keep it alive
An assumption register should begin with the beliefs that would change the delivery position if they failed. Ten to twenty entries are usually enough for a workstream; more than that suggests the register is being used as a general risk log. Review it weekly, retire entries when they no longer carry weight, and add new ones when the plan changes.
The aim is not administrative completeness. It is clearer delivery. By exposing the beliefs beneath the baseline, UK delivery teams can test fragile dependencies before they harden into slippage and turn late surprises into managed decisions.
