One Forecast or Several Scenarios? Show What Changes the Business Case

A revenue slide with three lines on it looks like diligence. Often it is a decision nobody has made yet, drawn three times.

The tell is what separates the lines. If the difference is a multiplier — 0.8, 1.0, 1.2 applied down every row — the deck has not described three futures. It has described one future at three volumes, and the reader learns only that someone is nervous.

Scenarios earn their space when a single unresolved assumption would change what the business does. Not what the chart looks like: what the team commits to, when it spends, which route it takes. When that is true, a second case is a working instrument. When it isn't, the second case is scenery, and it makes the first case harder to read because the reader must now work out which line anyone actually believes.

Name the decision before adding another forecast

Start with the commitment, not the graph. What is the deck asking someone to accept, fund, staff or schedule? Then ask the only question that decides whether you need more than one line: if the reader believed the alternative instead, what would they do differently?

If the honest answer is "nothing this quarter," you have a chart. Keep the single forecast, make its assumptions visible, and spend the recovered slide on the assumptions themselves.

The Small Business Administration's Plan your business guide (inspected 18 September 2026) asks for financial projections to be explained and connected to the funding request. That is a modest observation and worth taking at face value: a projection is in service of something — here, the ask. It is business-plan guidance rather than a universal pitch format, and it prescribes neither a horizon nor a method. But the underlying test is sound. A number that isn't attached to a decision is a number the reader has no way to use.

The common failure is the optimistic/pessimistic pair produced by scaling. It survives review because it looks humble. It fails because a plan is rarely wrong in that shape. Businesses are not surprised by everything moving 20% together; they are surprised by one thing happening on a different schedule than the one assumed. Scaling every row down by a fifth changes the arithmetic while leaving the story identical, and it quietly asserts that all your risks are correlated and symmetrical. They usually are not.

There is a related piece of equipment worth keeping separate. A sensitivity analysis takes one input, moves it, and holds everything else mechanically still. It answers "which knob matters most," and it is genuinely useful for triage. A scenario describes a condition — the customer's environment is not available until June — and lets the consequences move together. Both are legitimate. They answer different questions, and decision slides usually need the second one.

Preserve a coherent baseline and a consequential alternative

A baseline is not a number. It is a set of assumptions wearing a number, and the useful work is labelling them. Three labels will do:

• Observed — it has happened, or it is on a returned order form, or it is a term both sides have written down.
• Estimated — your best current judgement, and it would be useful to say whose.
• Conditional — it depends on someone else doing something by a date.

Conditional assumptions are where business cases die, and they are indistinguishable from observed ones once they are inside a total. That is the whole problem.

Then choose the alternative by finding a driver, not a level. A driver is a condition that determines several numbers at once: when capacity becomes available, when a build passes, when a licence is granted, when a partner's change window opens. Move a driver and the case reorganises itself. Move a level and you have only made a row smaller.

Say plainly why the alternative deserves a slide. You are not claiming it is likely. You are not claiming the two cases bracket the future. "We examine this because it would change the hiring decision" is a complete justification and needs no probability attached to it.

Here is an invented company to work with. The numbers are chosen to make the dependencies visible. They are not a forecast, nothing below describes a real customer, contract or employment decision, and no likelihood is being asserted anywhere.

Ridgeline, an invented software company, sells a scheduling module. One prospective customer must integrate its own systems with Ridgeline's before a pilot can begin. Ridgeline has committed to a delivery hire who starts on 1 March, at $9,000 a month fully loaded, and the plan has no other pilot for that role in the period.

Baseline assumptions

The conditional row is the one doing the work. Everything downstream — when the pilot runs, when the subscription starts, when invoices go out, when cash arrives — sits on a date the customer controls.

Carry the change through dependent assumptions

The alternative: the customer's environment is not available until the end of May. The integration completes then, the pilot runs June through August, and the subscription starts on 1 September. The hire still starts on 1 March, because that date is a commitment the company has made. Moving it is a decision with its own consequences — recruitment, renegotiation, the risk of losing the candidate — and it is not an arithmetic adjustment available to whoever edits the spreadsheet.

Now trace it, in order.

Activation. The pilot moves from March to June. Nothing about the pilot changed; its start was pinned to a date that moved.

Delivery. The role was planned around this pilot. In the alternative, three months of committed delivery capacity arrive before there is a pilot for it to deliver. That is not a saving. It is the shape of the problem the scenario exists to expose.

Recognised revenue. Subscription revenue falls from seven months (June–December, $126,000) to four (September–December, $72,000).

Collections. Billing is monthly in arrears with net-30 terms, so each month's invoice becomes cash in the following month. Baseline cash inside the year is July–December, six months, $108,000; December's invoice lands in January. The alternative collects October–December, three months, $54,000, with the same $18,000 tail arriving in January. Both cases carry that tail. Neither brings it forward.

Spending. Hosting follows activity, so it falls with the pilot and subscription months: $34,000 becomes $22,000. The integration partner's fixed fee does not change at all — the delay is the customer's environment, not less work — though the month it leaves the bank moves from March to June. Same amount, different timing.

The sorting rule underneath all of this is worth stating on its own, because it generalises past this example. When a driver moves, ask which costs are attached to the activity and which are attached to a commitment. Hosting is attached to activity: no pilot, no pilot environment. The hire's salary is attached to a decision already made. The partner fee is attached to a completion event that has moved in time but not in amount.

Two errors appear here often enough to name directly.

The first is delaying revenue while quietly bringing forward the cash it generates. A version of the alternative that shows $72,000 collected inside the year has December's invoice paid in December, which net-30 terms do not permit. The correct figure is $54,000.

The second is assuming that reduced activity cancels committed costs. Falling revenue is a reason to look at costs, not a reason to delete them. If a scenario lowers the top line and the committed salary line falls with it, the scenario has stopped describing a possible future and started describing a desired one.

This is where the finance owner earns their place. Someone who owns the model has to confirm that a change to one input actually propagates, and that nothing has been pinned to last year's value out of habit. The presenter's job is to expose the dependency; it is not to certify the arithmetic. In the invented table below, no such review has happened, and a real version would need it before anyone relied on a figure.

Compare consequences and the evidence that would update them

Put the changed driver and the decision-relevant outputs in one place, side by side. Curves on separate charts make the reader do the reconciliation, and they will do it differently from each other.

These are only the lines this decision touches. They are not the company's cash position, and the negative figures reflect a plan that is carrying a full year of build ahead of a customer who has not yet gone live.

The third column is what a scaled version produces. It moves the hire's start to June, erasing $27,000 of committed salary, and trims the fixed partner fee by $10,000 because the window got shorter. Neither change is authorised by the alternative; both are imported from the wish that the delay be free. The consistent comparison says the year is $42,000 worse than baseline. The scaled version reports $5,000.

Notice what the honest column is not. It is not a prediction, and it is not a probability. The UK Government Office for Science's Futures Toolkit (updated 29 August 2024, inspected 18 September 2026) describes scenarios as possible futures rather than plans or predictions. That distinction is the one to borrow. The toolkit's setting is public-policy foresight — workshops and long horizons — and none of that transfers into a company deck's requirements, least of all into implied probabilities. Two cases do not span the range of what might happen. They show what two conditions would do, and the reader is entitled to know that is all they are getting.

Then say what would change your mind, in items someone can actually watch:

• The customer's written change-window confirmation. This is the assumption the whole baseline stands on.
• The status of the remaining integration tasks, and who owns each one.
• Test-environment access, which usually precedes the window rather than following it.
• The last date on which a February cutover could still be booked. That is your trigger. If it passes without a confirmed window, the team should be working from the alternative, not defending the baseline.

Attribute each of those to a person. A watch item with no owner is a hope with bullet points.

Keep the two kinds of response separate in the deck too. Contemplated: the team may ask the hiring owner to revisit the start date. Approved: nothing. It takes one line to distinguish them and it prevents a reader from assuming a decision has been made because it appeared on a slide.

The alternatives earn their keep by making one sentence sayable: this plan holds while the customer's February window holds, and here is the date that tells us whether it does. If no sentence that specific comes out of the exercise, the second case was decoration. Take it out — the baseline gets clearer without it.

Frequently asked questions

When does a second forecast or scenario earn its place?

When a single unresolved assumption would change what the business does: what it commits to, when it spends, or which route it takes. If the reader would do nothing differently this quarter under the alternative, keep one forecast and make its assumptions visible.

Why is scaling every row by 0.8, 1.0, and 1.2 usually weak?

It leaves the story identical and quietly asserts that all risks are correlated and symmetrical. Businesses are more often surprised by one thing happening on a different schedule than assumed. The scaled pair looks humble but rarely shows a consequential alternative.

How does a scenario differ from a sensitivity analysis?

A sensitivity moves one input while holding others mechanically still, which helps identify the most important knob. A scenario describes a condition and lets the consequences move together. Both are legitimate, but decision slides usually need the scenario.

What should be labeled in baseline assumptions?

Observed, estimated, and conditional. Conditional assumptions are where business cases often fail, and they become indistinguishable from observed ones once inside a total. Choose the alternative by moving a driver, not a level, and say why it deserves a slide without attaching a probability.

In the Ridgeline example, why doesn't the delivery hire cost fall when the pilot is delayed, and what errors does that expose?

The hire starts on 1 March as a committed decision. Moving that date has consequences such as recruitment, renegotiation, or losing the candidate; it is not an arithmetic adjustment. Hosting follows activity and falls, while the integration partner's fee stays the same amount but moves in timing. Delaying revenue while bringing cash forward is wrong because net-30 terms mean December's invoice is paid in January. A scaled version that cuts the committed salary and trims the fixed fee without authorization reports 5,000 worse instead of 42,000 worse than baseline.

Further reading

• Explain Cash Runway Without Hiding the Next Large Payment — Read when a committed payment lands in a month without the activity it serves, to put dated cash, a defined burn and one large payment on one path.