Build an Assumption Register Before a Plan Hardens

Every plan rests on facts that have been checked, choices that have been made and conditions that are merely expected to remain true. Those categories are easy to confuse once the plan looks polished. The expected conditions disappear into timelines, budgets and confident prose. Later, when one changes, the plan appears to fail without warning.

An assumption register keeps those conditions visible. It is a short, maintained list of statements that the current plan depends on but does not yet control or know with enough confidence. The register is not a museum of every uncertainty. It is a decision instrument for finding which unknowns can change the choice.

Separate facts, assumptions, choices and constraints

A fact is a claim supported by current evidence appropriate to the decision. A choice is a preference or policy you can change. A constraint is a boundary the plan must respect. An assumption is a condition treated as true for planning even though it remains uncertain, external or unverified.

“The venue seats 120 under the current approved floor plan” can be a fact if the plan and approval are current. “Attendance will remain below 100” is an assumption. “We will cap registration at 90” is a choice. “The fire-code limit cannot be exceeded” is a constraint. Mixing them produces bad tests: you cannot gather evidence to discover a preference, and confidence does not allow you to negotiate away a constraint.

Assumptions are not evidence of poor planning. Planning requires them because the future is unfinished. The failure is allowing them to become anonymous.

Harvest assumptions from the plan

Read the plan one layer at a time and ask what must remain true for each step to work. Pay particular attention to words that compress uncertainty: “should,” “usually,” “available,” “compatible,” “on time,” “simple,” “enough,” “likely” and “users will.”

Then inspect the dependencies. A schedule assumes people, approvals, inputs and equipment will be available when required. A budget assumes quantities, rates and rework. A technology choice assumes compatibility, support and skill. A communication plan assumes the audience will see, understand and trust the message.

A dependency map is useful here, but the outputs differ. The dependency map shows what the function relies on. The assumption register records what you currently believe about those dependencies and what would make the belief unsafe.

Write each assumption so it can fail

“The supplier is reliable” is not testable enough. Write the condition, boundary and time window: “The named supplier can deliver 40 units meeting specification X by October 12.” Now the statement can be checked, challenged and assigned.

A good assumption is narrow enough that one kind of evidence bears on it. Do not write “The launch will succeed.” Separate demand, staffing, compatibility, approval and timing. Large assumptions hide the reason they might fail and make ownership symbolic.

Avoid smuggling action into the assumption. “We assume the team will work weekends if required” is partly a staffing policy and possibly a labor or wellbeing risk. Expose the decision instead of writing it as a fact about other people.

The eight-field assumption register

The owner does not “own” reality. They own the next verification step and the communication of a change. Do not assign someone responsibility for weather, markets, a vendor's behavior or another person's health.

Rank by sensitivity, not uncertainty alone

A very uncertain assumption may not matter. A mildly uncertain assumption can be decisive if being wrong changes the entire plan. Prioritize the intersection of uncertainty and consequence.

The U.S. Government Accountability Office's cost-estimating guidance treats ground rules, assumptions and sensitivity analysis as parts of a credible estimate. The scale is larger than an ordinary household or team plan, but the reasoning transfers: document important assumptions, vary the ones most likely to change and see which ones move the result.

For each important assumption, run a low and high case. You do not need a complex model. Ask, “If delivery takes twice as long, what changes?” “If participation is half the forecast, would we still choose this option?” “If the service requires a paid tier next year, is the exit cost acceptable?” The purpose is not to predict every future. It is to find which premise has leverage.

Attach evidence without promoting it to certainty

Record the actual source and date. “Vendor says supported” is weaker than a link to the current compatibility table for the exact model. “Worked last time” is evidence from one condition, not a timeless rule. “Everyone agrees” may be social confidence rather than external support.

Name the limitation beside the evidence. A quote may expire. A pilot may use friendlier users than the real launch. A forecast may depend on a stable rate. A manual may apply to a different revision. This preserves the bridge between the claim, evidence and inference instead of leaving future readers to reconstruct it.

When no evidence exists, say so. “Working assumption for planning; unverified” is more useful than a decorative 70% confidence number that nobody can defend.

Give every important assumption an expiry condition

Review dates are helpful, but event triggers are often better. Recheck compatibility when the device list changes. Reopen a staffing assumption when a named person becomes unavailable. Revisit demand when registration reaches a threshold. Reprice the plan when the quote expires.

A trigger should produce an action. “If the permit is not approved by October 1, switch to the indoor route” is better than “monitor permit.” Link the trigger to the smallest fallback that preserves the essential outcome.

Do not create alerts for every row. Use the notification escalation ladder to route routine review, approaching thresholds and immediate plan-breaking changes differently.

A 30-minute assumption-register session

1. Five minutes: state the decision, deadline and success boundary.
2. Seven minutes: underline every condition the plan treats as true.
3. Five minutes: separate facts, choices, constraints and assumptions.
4. Five minutes: score the assumptions by consequence and likelihood of change.
5. Five minutes: add evidence, owner and trigger to the top three.
6. Three minutes: choose one test or fallback and schedule the review.

Stop before the register becomes a second project. Ten live assumptions with owners and triggers are more useful than a hundred rows copied from a template. Archive assumptions when evidence establishes them, a decision removes them or the plan no longer depends on them.

Common failure modes

• The reassurance register: only comfortable assumptions are written, while socially difficult ones stay implicit.
• The risk-register clone: every assumption is rewritten as a vague threat without naming the condition the plan depends on.
• The owner as guarantor: a person's name is used to make an external condition feel controlled.
• The confidence theater: precise probabilities appear without a reference class, model or reason.
• The frozen spreadsheet: the register is completed at kickoff and never connected to a trigger.
• The universal fallback: every failure leads to “work harder” instead of a smaller alternative path.

Keep high-stakes domains inside qualified practice

This protocol can expose premises in a medical, legal, financial, structural or safety plan. It cannot validate them. Use qualified professionals and current governing requirements for those domains. Do not convert a serious risk into a homemade score simply because the register has a column for confidence.

The register's job is modest and valuable: prevent an unverified condition from disappearing into the architecture of a decision. A plan can contain uncertainty without pretending the uncertainty has been solved.

Sources and further reading

• U.S. GAO Cost Estimating and Assessment Guide, for ground rules, assumptions, sensitivity analysis and updating estimates.
• NASA Systems Engineering Handbook, Revision 2, for formal systems-engineering treatment of assumptions, constraints and verification.
• Life in the Simulation: How to Run a Pre-Mortem, for testing the plan against plausible failure before commitment hardens.