Every meaningful business case sits on a stack of uncertainties: market response, adoption, technology performance, operational capacity, regulation, and more. The goal is not to pretend those uncertainties don’t exist, but to surface, structure, and manage them so decision-makers can make an informed choice.
This chapter covers how to manage assumptions and confidence levels, use scenarios and real options intelligently, design experiments and pilots to learn fast, maintain a disciplined assumptions log, and pressure-test your evidence base with a simple checklist.
19.1 Assumption Management and Confidence Levels
Assumptions are the hinges on which your case turns. If you don’t manage them explicitly, they become invisible failure modes.
What counts as an assumption
An assumption is any statement that:
- Is not a directly observed fact; and
- Materially affects costs, benefits, timing, or risk; and
- Could realistically turn out differently.
Examples:
- “Digital adoption will reach 60% of eligible users within two years.”
- “We can reduce handling time by 25% with the new workflow.”
- “Vendor X can deliver full functionality within 9 months.”
Classifying assumptions
Useful dimensions:
- Type
- Market: demand, pricing, competitive response.
- Customer / user: adoption, behavior change, churn.
- Operational: productivity, throughput, error rates, capacity.
- Technical: performance, stability, integration effort.
- Financial: discount rate, FX, inflation, tax.
- Regulatory / risk: interpretation of rules, timing of approvals.
- Materiality
- High: could move NPV or payback meaningfully, or change recommendations.
- Medium: moves economics but is unlikely to change decisions.
- Low: minor impact, mostly useful for completeness.
Focus your energy on high-materiality assumptions.
Confidence levels
Treat assumptions like hypotheses with confidence bands, not truths. A simple scheme:
- High confidence: Strong data, repeated experience, or robust pilot results.
- Medium confidence: Some data or comparable examples, but not fully analogous.
- Low confidence: Expert judgment or weak proxies; limited or no direct data.
For each high-materiality assumption, ask:
- What is our confidence level?
- Why do we believe this? (Data, benchmark, expert, pilot.)
- What would it take to increase confidence?
You don’t need to show confidence flags for every minor number in the case; focus on the few that really matter.
Linking assumptions to sensitivities
Every assumption with high materiality and less-than-high confidence should:
- Appear explicitly in your assumptions log.
- Have a sensitivity in the model (how NPV changes if it moves up/down).
- Be referenced in your risk section if changing it creates a risk, not just volatility.
This is how you move from “hand-wavy optimism” to “structured uncertainty.”
19.2 Scenario Planning and Real Options
Scenarios and real options help you answer two questions:
- What if the world turns out differently than we expect?
- How can we design flexibility into our decision?
Scenarios vs sensitivities
- Sensitivities: change one driver at a time, holding others constant; answer “what matters most?”
- Scenarios: combine consistent sets of assumptions; answer “what could the future look like?”
For most cases, three scenarios are enough:
- Base case – your honest best estimate.
- Downside case – more conservative adoption/benefits, slower ramp, some cost overrun.
- Severe / stress case – adverse but plausible combination, used for resilience and risk discussion.
Always describe in words how each scenario differs:
- “Downside assumes 50% of planned adoption and 20% higher implementation cost.”
- “Severe assumes a 2-year delay plus significantly weaker market growth.”
Real options thinking (without the math jargon)
Many initiatives can be staged to buy information before committing fully. That’s the spirit of real options:
- Option to expand: Start small; if KPIs beat threshold, scale aggressively.
- Option to defer: Wait for a trigger (e.g., regulatory clarity, market signal) before committing heavy Capex.
- Option to pivot: Design so you can repurpose assets or tech if initial use case disappoints.
- Option to abandon: Build explicit off-ramps (stop-loss gates) with clear conditions.
In your case, “real options” show up as:
- Pilot and staged rollout designs.
- Funding tied to stage-gates.
- Design choices that preserve flexibility (e.g., modular tech, shorter contracts).
You do not need formal option pricing. You do need to show flexibility as a deliberate design choice, not a vague intention.
19.3 Experiments, Pilots, and A/B Testing
Experiments convert low-confidence assumptions into measured facts. In a business-case context, three patterns are especially useful:
- Experiments / A/B tests – controlled tests within an existing environment.
- Pilots / MVPs – limited implementations in “real life” segments or sites.
- Prototypes / dry runs – operational or technical simulations.
When to experiment vs pilot
- Use experiments / A/B tests when you can isolate a change on a subset of users or traffic (e.g., digital journeys, pricing, messaging, process tweaks).
- Use pilots when change is more complex and interdependent (e.g., new operating model, new platform in a single geography, new contracting arrangement).
The common goal: validate key drivers cheaply and early.
Good experiment design in a business case setting
You don’t need academic perfection, but you do need basic rigor:
- Clear hypothesis: “If we do X, we expect the Y metric to move by Z.”
- Treatment vs control: Two groups comparable on relevant dimensions.
- Sample size and duration: Enough to detect the expected effect with reasonable confidence.
- Pre-defined metrics and success criteria: Agreed before you look at results.
In the case, briefly document:
- The design (who/what/where/for how long).
- The key metrics and results vs baseline.
- Any caveats (biases, representativeness).
Pilots as learning engines, not mini-rollouts
A pilot should be designed primarily to learn, not to maximize short-term benefit. In your business case, make that explicit:
- Which assumptions the pilot is testing (e.g., adoption, productivity gain, defect rate).
- What success looks like numerically (thresholds for scaling).
- How you will feed pilot results back into the economics and implementation plan.
A strong pilot section includes:
- A clear scope (sites, segments, channels).
- Duration long enough to capture steady-state behavior (not just the launch excitement).
- Defined exit options: scale, modify and repeat, or stop.
Incorporating results into the case
When you already have experiment or pilot results:
- Use them to anchor your benefits assumptions.
- Show where you have discounted pilot results to be conservative at scale (e.g., assume only part of pilot uplift for group-wide rollout).
- Explain any non-intuitive findings and how they changed your design or assumptions.
Nothing builds credibility faster than: “We ran a pilot; it didn’t fully meet expectations; we adjusted the design and economics accordingly.”
19.4 Step-by-Step Assumption Log Guide
The assumptions log is your single source of truth for uncertainty. Done well, it saves you in challenge sessions and post-implementation reviews.
Step 1 – Set up the structure
Use a simple table or sheet with at least these columns:
- ID (A001, A002, …)
- Assumption description
- Category (market, customer, operational, technical, financial, regulatory, etc.)
- Affected areas (costs, benefits, timing, risk; and which options/scenarios)
- Baseline value or statement
- Range (low/base/high) if known
- Confidence level (high/medium/low)
- Evidence type (internal data, external benchmark, pilot, expert judgment)
- Owner (who is responsible for updating/defending this assumption)
- Last updated date
- Notes / links (to data book, model, or documentation)
You can add more fields if useful, but start lean.
Step 2 – Populate from the model and narrative
Go through your model and case and list:
- All high-materiality drivers (top 5–15 things that really move NPV and payback).
- Any other assumptions that stakeholders have already questioned.
Don’t waste time logging obscure, low-impact parameters first. Start with the “big stones.”
Step 3 – Assign categories and owners
For each assumption:
- Tag the category.
- Assign an owner, usually the most relevant functional lead (e.g., Sales for volume, Ops for productivity, Tech for performance, Risk for loss rates).
The owner is not the only person who cares, but they are the one who must defend and adjust it.
Step 4 – Add evidence and confidence
For each assumption:
- Record what it’s based on (e.g., “CRM data FY24,” “benchmark from X report,” “pilot in region Y,” “expert judgment from head of Z”).
- Set confidence (H/M/L) as a team; don’t do it in isolation.
Where evidence is weak, note that explicitly—this is a candidate for experiments, pilots, or more data.
Step 5 – Link to model and scenarios
In the log:
- Note where in the model the assumption is used (sheet/tab, cell area, or named range).
- Note whether it changes across scenarios and, if so, how.
This makes it easy to update and explain scenario differences:
- “In the downside scenario, A003 (adoption) is 50% of base; A004 (implementation cost) is +20%.”
Step 6 – Identify “red list” assumptions
From the full set, highlight:
- The small subset (often 5–10) that are both high materiality and less than high confidence.
For these:
- Ensure you have sensitivities in the model.
- Consider additional tests (pilot, A/B) or external validation.
- Feature them in your risk discussion: “Our downside case assumes these three assumptions lean negative.”
Step 7 – Keep it live
During development:
- Update the log when new data arrives or design choices change.
- Use versioning (v0.1, v0.2…) with dates so you can see how assumptions evolved.
After approval:
- Use the log in post-implementation reviews to ask: “Which assumptions held? Which didn’t? What did we learn?”
Over time, your organization can reuse high-quality assumptions (or the lessons from failed ones) in new cases.
19.5 Evidence Quality Checklist
Finally, a simple checklist to test whether your evidence base is strong enough for a serious decision.
Coverage
- For each major benefit and cost driver, at least one data point, benchmark, or expert rationale is documented.
- Market, customer, operational, and risk dimensions have all been considered; none is ignored because data is inconvenient.
- The most material assumptions (top 5–10) have some empirical grounding (internal data, pilot, external benchmark) or are clearly flagged as judgment.
Traceability
- Every key number in the executive summary (NPV, IRR, payback, total benefits, total costs) can be traced to:
- An assumption in the log;
- A calculation in the model;
- A source in the data book.
- External benchmarks and market figures have citations (report name, provider, year) and are not just “industry says.”
- Where expert judgment is used, the expert is identified (role, not necessarily name) and the reasoning is briefly captured.
Quality and relevance
- Internal data covers a sufficient period to be representative (not just one unusual month or project).
- External benchmarks are comparable (similar segments, channels, geographies, business models) or adjustments are explained.
- Pilots and experiments have adequate scale and duration to be credible, or limitations are clearly stated.
- Averages do not hide important extremes (e.g., overall NPS is flat but critical segment is deteriorating and that’s noted).
Uncertainty handling
- Where data is sparse or noisy, assumptions are expressed as ranges or scenarios, not single “magic numbers.”
- Key uncertainties are reflected in sensitivity and scenario analysis.
- Management is explicit about where the case is most fragile (which 2–3 assumptions could really break it).
Consistency
- Numbers are consistent across text, charts, and tables (spot-checked).
- Assumptions in different sections do not contradict (e.g., adoption rate in benefits vs usage in cost sizing).
- The story told by the evidence matches the “why now / problem” section; you are not cherry-picking data that contradicts your own baseline.
Independence and challenge
- Finance (or equivalent) has reviewed the model and key assumptions.
- Risk/compliance, security/privacy, and architecture have reviewed evidence in their domains where relevant.
- At least one independent challenger (peer, controller, or audit) has probed for optimism bias and blind spots on big cases.
- Any adjustments made after challenge are reflected back into the assumptions log and model, not just patched in the slides.
If you can walk through this checklist and tick the boxes honestly, your case is no longer just a hopeful forecast. It becomes a structured argument that is explicit about what you know, what you don’t know, and how you’ve handled the gap between the two—which is the essence of working professionally with uncertainty.
