Business Case Assumptions Register Template: Evidence, Sensitivity, Owners and Kill Criteria

A business case assumptions register is a decision control, not an appendix of optimistic guesses. It records every material assumption, the evidence behind it, its uncertainty range, the financial or operational variable it affects, the person responsible for testing it, the next review date, and the threshold that would stop or redesign the initiative. Used properly, the register turns a static business case into a testable management system.

This guide provides ASSUME-12, a copyable twelve-field register, an evidence-grading method, a sensitivity workflow, a worked investment example, and meeting rules for approval and post-approval review. It is designed for product launches, digital transformation, process automation, capital investment, procurement, market entry, and other proposals where a confident base-case number can conceal fragile logic.

Why a normal assumptions list is not enough

Many business cases include a section labelled “assumptions” with entries such as “10% adoption,” “stable pricing,” or “implementation in six months.” The list records what the model uses, but not whether the assumption is credible, how wrong it might be, or what management should do when reality differs. It often becomes a disclosure device rather than a decision tool.

Three failures follow. First, assumptions with very different evidence quality are treated as equal. A signed supplier quote and an executive’s intuition may both appear as one-line inputs. Second, linked assumptions are ignored. Adoption affects revenue, support demand, capacity, and working capital simultaneously. Third, nobody owns validation after approval. The model is archived while the project continues on momentum.

ASSUME-12 fixes those failures by making provenance, uncertainty, impact, ownership, and action explicit. It does not eliminate uncertainty. It makes uncertainty governable.

The ASSUME-12 register

Create one row for every assumption that could materially change the recommendation. Use the following fields.

Field Required content
1. ID Stable code such as DEM-01, COST-03 or TIME-02
2. Decision claim The concise assumption used by the case
3. Driver Revenue, cost, timing, capacity, risk, adoption, compliance or dependency
4. Base value The number or condition in the approved base case
5. Plausible range Low, base and high values with units and period
6. Evidence grade A–E grade using the method below
7. Evidence source Named document, dataset, experiment, contract or expert judgement
8. Model link Exact line, formula, milestone or risk affected
9. Sensitivity effect Output change when the assumption moves through its range
10. Owner One accountable role, not a committee
11. Test and date Validation action, evidence required and next review date
12. Trigger and response Threshold, escalation route, redesign action or kill criterion

The ID lets a decision memo, model, risk register, contract, and benefits plan refer to the same assumption. The decision claim must be falsifiable. “Customers value convenience” is vague; “at least 35% of eligible customers will activate the service within 90 days” can be tested. Units matter: 35% of invited customers is different from 35% of all accounts.

The plausible range is not a decorative best/base/worst trio. It should describe a defensible interval using observed variation, pilot results, comparable initiatives, contractual limits, or expert elicitation. The sensitivity effect then translates uncertainty into the output the decision maker cares about: NPV, payback, contribution margin, service level, capacity, compliance exposure, or completion date.

Evidence grades: separate observed facts from hopeful inputs

Use a five-level evidence scale.

Grade A — binding or directly observed. Examples include a signed price, a regulatory deadline, measured production data, or a completed controlled test in the relevant environment. Grade A still needs a date and scope; a contract can expire and an experiment can have limited external validity.

Grade B — strong relevant evidence. Examples include several comparable internal projects, a representative customer study, audited historical data, or a supplier proposal with clear inclusions and exclusions. The evidence is relevant but not fully binding.

Grade C — bounded proxy. Examples include industry benchmarks, a small pilot, a related market, or an expert estimate supported by an explicit method. Grade C can be appropriate, but its range should be wider and its validation plan stronger.

Grade D — structured judgement. The assumption comes from named experts or management judgement, with reasoning but little direct evidence. Record dissent and use a wide range. Do not disguise it as a benchmark.

Grade E — placeholder. The model requires a value, but usable evidence is not yet available. Grade E assumptions are not automatically fatal. They should, however, trigger a validation gate before irreversible spending.

Do not average grades into a reassuring score. A business case with nine Grade A assumptions and one untested demand assumption may still be fragile if demand drives the entire benefit. Evidence grade must be read together with sensitivity and reversibility.

How to decide which assumptions deserve a row

Start with the model and the implementation plan. Trace the recommendation backward. What must be true for the claimed benefit, cost, timing, and risk position to hold? Convert each dependency into a testable statement.

Include an assumption when at least one of these conditions applies: moving it through a plausible range changes NPV or payback materially; it can delay a critical milestone; it determines compliance or safety; it controls capacity or service quality; it is outside the team’s direct control; it has weak evidence; or it creates a dependency on one supplier, dataset, platform, or specialist.

Avoid flooding the register with stable accounting identities or trivial facts. A useful register normally contains fewer rows than the model contains inputs. The test is decision materiality: would a reasonable approver want to know if this were wrong?

Group assumptions by driver. Demand rows cover volume, conversion, retention, price, and cannibalisation. Cost rows cover labour, licences, integration, support, inflation, and exit. Timing rows cover procurement, data readiness, approvals, migration, adoption, and benefit ramp. Operating rows cover capacity, quality, staffing, and dependencies. Risk rows cover regulation, security, safety, resilience, and reputation.

Connect the register to the financial model

Every quantitative assumption should map to a named input cell or model line. Do not copy numbers manually between files without a control. A simple model link might read “Model Inputs!B17 — monthly active users.” A non-financial link might read “Milestone M4 — regulatory approval” or “Risk R-08 — data residency.”

Use consistent units and periods. Annual revenue cannot be multiplied by monthly adoption without conversion. Headcount savings cannot begin before roles can actually be removed or redeployed. A one-time implementation cost should not recur accidentally. State whether values are nominal or real and whether tax, inflation, and discounting are included.

Add a change log. When an assumption changes, record old value, new value, date, evidence, model version, and decision impact. The point is not bureaucracy. It prevents a team from improving one input quietly while leaving the approval narrative unchanged.

Sensitivity analysis: test one variable before telling a story

Begin with one-way sensitivity. Move each material assumption from low to high while holding others at the base case. Record the effect on the primary decision output. This reveals which variables have leverage.

For example, if a £500,000 automation proposal has a base-case NPV of £240,000, test adoption at 40%, 60%, and 80%; implementation cost at £450,000, £500,000, and £650,000; annual time saved at 30,000, 45,000, and 55,000 hours; and benefit start at months 7, 10, and 13. If NPV becomes negative only when adoption falls below 48%, adoption is a key threshold. If a three-month delay removes half the NPV, schedule readiness deserves more attention than minor licence-price negotiation.

One-way sensitivity isolates leverage but misses correlation. Adoption may be lower precisely when implementation is late and training is weak. After identifying the top drivers, build coherent scenarios. A downside scenario should combine related conditions with an explanation, not automatically set every variable to its worst value. A recovery scenario should name the interventions required to return to viability.

Do not present sensitivity as certainty. The low and high bounds are management estimates, not probabilistic confidence intervals unless a statistical method supports that claim.

Impact tiers and review cadence

Assign an impact tier after sensitivity testing.

Tier 1 — decision critical. A plausible change reverses the recommendation, breaches a mandatory constraint, or causes unacceptable harm. Review before approval and at every governance gate.

Tier 2 — value material. A plausible change does not reverse the decision but materially changes NPV, payback, budget, timing, or benefits. Review monthly or at milestone transitions.

Tier 3 — operational. A plausible change requires local adaptation but stays inside approved tolerance. Review in the delivery cadence.

Tier 4 — monitor. The effect is small or easily reversible. Keep the source and owner, but avoid consuming executive attention.

Set a numerical materiality rule suitable for the organisation. It might be a 10% change in NPV, a one-quarter delay in payback, a £100,000 budget effect, or a breach of service tolerance. For safety, legal, or compliance assumptions, financial materiality is not enough; a mandatory requirement can be Tier 1 even if its modeled cost is small.

Worked example: a customer-service AI assistant

Consider a company proposing an AI assistant for 300 service agents. The base case claims £1.2 million annual labour capacity released, £350,000 annual technology and support cost, £600,000 implementation cost, and benefits beginning in month seven. The headline payback is attractive, but the value depends on adoption, time saved, answer quality, and whether released time becomes productive capacity.

The register contains these key rows:

ID Assumption Base and range Grade Model effect Trigger and response
ADP-01 75% of agents use the assistant weekly by month six 50% / 75% / 85% C Capacity benefit Below 60% for two months: redesign workflow and training; pause scale-up
PROD-02 Average handling time falls by 8% without repeat contacts rising 2% / 8% / 12% C Capacity and quality Less than 4% net improvement: stop benefit recognition
QUAL-03 Approved-answer accuracy remains at least 95% 92% / 96% / 98% B Risk and rework Below 95% in high-risk intents: disable those intents
COST-04 Annual platform and support cost is £350,000 £330k / £350k / £430k B Operating cost Above £400k without extra value: reopen sourcing decision
TIME-05 Production launch occurs by month seven Month 7 / 9 / 12 C Benefit start Forecast later than month nine: re-baseline NPV and return to board
CAP-06 Released time can be converted to productive capacity 40% / 70% / 90% D Realisable benefit No approved capacity plan: report time saved, not financial benefit

One-way sensitivity shows that CAP-06 and PROD-02 dominate value. Licence cost is visible but less influential. The team therefore changes the approval conditions: fund a bounded pilot, require a capacity-conversion plan, measure repeat contacts as well as handling time, and release later-stage funding only after two months of quality evidence. The register changes the decision from “approve the software” to “approve a staged test with explicit conversion evidence.”

Kill criteria: decide how to stop before enthusiasm rises

A kill criterion is a pre-agreed condition that makes continuation irrational, unsafe, or non-compliant. It should name the metric, threshold, measurement window, decision authority, and permitted response. “Poor performance” is not a criterion. “Verified answer accuracy below 95% for high-risk intents across two weekly samples, with no remediation accepted by the risk owner” is actionable.

Use three response levels. A correction trigger requires local remediation inside existing authority. An escalation trigger requires a new decision because approved tolerances are breached. A kill or redesign trigger stops scale-up, removes a use case, or terminates the initiative.

Avoid criteria that are impossible to exercise because contracts, reputational commitments, or sunk costs arrive first. Sequence commitments so that evidence is available before major irreversibility. A short pilot is useful only if the organisation is willing to stop.

Ownership: one accountable role per assumption

The owner is responsible for obtaining evidence and initiating the agreed response. The owner does not have to control the external variable. A commercial lead can own a customer-adoption assumption; a finance partner can own model integrity; a security lead can own a control assumption; a project manager can own schedule evidence.

Do not write “project team” as the owner. Name the role, and record a deputy for continuity if necessary. Distinguish assumption ownership from approval authority. The owner may escalate a breach, while a steering committee decides whether to continue.

At each review, the owner reports five things: current value, evidence date, confidence change, model impact, and recommended action. This format prevents a status meeting from turning into general reassurance.

The 45-minute assumptions review meeting

Run the meeting from the register, not from a slide narrative.

Minutes 0–5: restate the decision, approved case version, primary outcome, and materiality thresholds.
Minutes 5–15: review new or changed Tier 1 assumptions.
Minutes 15–25: review breached triggers and overdue tests.
Minutes 25–35: examine the top three sensitivity drivers and correlated downside scenario.
Minutes 35–42: decide corrections, escalation, funding release, redesign, or stop.
Minutes 42–45: confirm owners, evidence due dates, model version, and decision-log entry.

Record decisions immediately. A statement such as “continue” is incomplete without conditions. Write: “Continue pilot to 30 November; no production rollout until ADP-01 is at least 60%, QUAL-03 is at least 95%, and Finance validates CAP-06 conversion.”

Copyable register template

Use the following header row in a spreadsheet or project system:

Assumption ID
Decision claim
Driver
Base value, low, high, unit and period
Evidence grade, source and date
Model or milestone link
Sensitivity effect and impact tier
Owner and validation test
Evidence due date and review cadence
Correction trigger
Escalation trigger
Kill or redesign criterion
Decision authority
Status and last change

Although ASSUME-12 names twelve conceptual fields, the operational sheet separates ranges and triggers into columns so teams can filter and calculate. Add formulas for days overdue, current variance from base, and whether a trigger has been breached. Do not automate the decision itself; use formulas to surface rows that require judgement.

Quality checks before approval

Before an approver sees the case, confirm that every headline benefit maps to at least one assumption and every decision-critical assumption has a range. Ensure sources are dated and retrievable. Confirm the financial model uses the same values as the register. Test that downside values flow through formulas rather than being pasted into a presentation. Name owners and next review dates. Define at least one stop or redesign condition for every irreversible phase.

Ask an independent reviewer to select three rows and reproduce the logic. If the reviewer cannot locate the source, understand the unit, change the model input, or identify the response threshold, the register is not ready.

Common anti-patterns

False precision: writing adoption as 73.4% when the evidence supports only a wide range.
Best/base/worst theatre: changing values without explaining why the combinations are coherent.
Benefit double counting: treating time saved, headcount reduction, and extra revenue as three independent benefits.
Orphan assumptions: no owner, evidence date, or model link.
Permanent Grade E: placeholders survive approval and quietly become facts.
Trigger without authority: the threshold is clear, but nobody can pause spending.
Sunk-cost override: the team keeps going because money was spent, even though the original case has failed.
Confidential source fog: “internal data” is cited without a retrievable owner or version.

How the register connects to other governance tools

An assumption is an uncertain proposition used by the case. A risk is a possible event or condition that affects objectives. An issue has already occurred. A dependency is something the initiative requires from another party or system. A decision log records choices and reasons. A benefits register tracks expected outcomes, measures, owners, and realisation.

Do not collapse all five into one overloaded spreadsheet. Link them by stable IDs. An assumption breach may create a risk or issue. A decision may change the base value. A benefits review may show that a conversion assumption failed. Linked records preserve context without duplicating ownership.

For decision documentation, pair this template with an executive decision log and use the scenario planning versus sensitivity analysis guide to choose the right uncertainty method.

A useful next step

Take the last business case approved by your team and identify its five largest value drivers. Create ASSUME-12 rows for those drivers only. Grade the evidence, calculate low/base/high effects, assign owners, and define one correction, escalation, and kill criterion for each Tier 1 row. Review the result with Finance and the accountable executive before the next funding gate.

Managers who need to integrate strategy, finance, operations, governance, risk, and executive communication can evaluate the Advanced Executive Management & Business Administration programme against their development needs. A programme is relevant here when it makes learners build, challenge, and defend decision artifacts—not when it only introduces business vocabulary.

Sources and evidence boundary

ASSUME-12 is an MTF decision framework, not a substitute for an organisation’s finance, legal, safety, procurement, accounting, or investment policy. Thresholds and approval authorities must be adapted to the organisation and jurisdiction.