Forecasting: planning, execution and measurement

The first question to settle about any forecast is which of three things it actually is, because organizations routinely conflate them and then argue about the wrong disagreement.

A forecast is your honest estimate of what will happen. A target is what you want to happen. A plan is what you will commit resources to. They should be different numbers, and the gaps between them are the useful information: the gap between forecast and target is the size of the problem, and the gap between forecast and plan is how much risk you are carrying.

When leadership asks the data team to "forecast" and means "produce a number that supports the target we already set," the exercise stops being measurement. Say the word out loud early. It saves a lot of downstream confusion.

What to take away

• A forecast without an error history is an opinion with a chart.
• People with domain knowledge often know things the data does not: a large contract closing, a price change shipping, a competitor exiting.
• Every forecast has a horizon past which it stops informing anything.

Start with the naive baseline you have to beat

Before any model, compute the dumbest possible forecast on your own history:

• Last period repeated. Next month equals this month.
• Same period last year. Handles annual seasonality for free.
• A trailing average. The last several periods, averaged.
• Last year's value times a growth factor derived from your own recent data.

Then score your sophisticated approach against these on held-out history. This one habit prevents most wasted forecasting effort. A large share of business series are hard to beat with anything clever, and knowing that early lets you spend your time on the parts of the problem where judgment actually adds value.

If your model cannot beat "same period last year," do not ship the model. Ship the baseline and say so. The NIST handbook's introduction to time series analysis sets out the same order of work: characterize the series before fitting anything to it.

Measure error before you trust anything

A forecast without an error history is an opinion with a chart. Build the error record from day one:

Question	How to answer it	Why it matters
How wrong, typically?	Average absolute error across held-out periods	The headline accuracy number readers should see
Wrong in which direction?	Average signed error: do you run high or low?	Persistent one-directional error is bias, and it is correctable
Wrong when?	Error by period, segment, and horizon	Errors usually cluster; the cluster tells you the missing driver
Worse further out?	Error broken out by how many periods ahead	Sets the horizon beyond which you should stop publishing a number
Better than naive?	Same errors computed for the baseline	The only comparison that establishes value

Backtest honestly. Only use information that would have been available at the time you would have made the forecast: no columns that were backfilled later, no target-period data leaking into features. A backtest that quietly uses the future is the most common reason a model performs beautifully in development and poorly in production.

Publish a range, and be specific about what the range means

Point forecasts get treated as promises. Ranges get treated as forecasts. Always publish an interval, and always say where it came from, remembering that a prediction interval is a statement about a future observation rather than about a parameter.

Two honest ways to build one:

From your own error history. If your forecasts for this horizon have historically been off by a certain amount, that spread is a defensible interval. It is empirical, it is easy to explain, and it widens automatically as your accuracy degrades at longer horizons.

From explicit scenarios. State the two or three assumptions that drive the outcome, give each a plausible range, and show what the forecast becomes at each combination. This is more work but far more useful for planning, because the scenarios name the things a decision-maker can act on.

Whichever you use, label the interval clearly and never present the middle of a scenario range as the expected case unless you actually believe the scenarios are equally likely.

Judgment overrides belong in the record, not in the model

People with domain knowledge often know things the data does not: a large contract closing, a price change shipping, a competitor exiting. Their input improves forecasts. The discipline is to keep it separate and visible.

• Publish the statistical forecast first, unmodified.
• Record each override as its own line: what changed, by how much, who made the call, and the reason.
• Score the overrides at the end of the period alongside the model.

Do this for a few cycles and you will learn something valuable: which people's adjustments genuinely help, and which are systematically optimistic. That is not an accusation, optimism bias in forecasts is close to universal, and it is only fixable if it is measured.

Watch for the reverse too. Where a forecast becomes a target, people sandbag, and the forecast drifts low on purpose. Both distortions come from the same root cause, which is attaching consequences to the forecast rather than to the outcome.

Match the horizon to the decision, then stop

Every forecast has a horizon past which it stops informing anything. Find yours from the error-by-horizon table and refuse to publish beyond it. A five-year monthly forecast is not five years of information; it is a trend line with a false sense of resolution.

Pick the horizon from the decision. Hiring decisions need a couple of quarters. Inventory decisions need the lead time plus a buffer. Cash runway needs the point at which you would have to act. Forecasting further than the decision requires adds no value and adds a lot of arguing.

The forecast review is the part that makes it work

Once per cycle, hold a short review with a fixed agenda:

1. What did we forecast last time, and what happened? Before anything else. Every time.
2. Where was the error concentrated? Which segment, which week, which assumption.
3. Was the miss a model problem or a world problem? A change in the business is not a modeling failure, but it may mean the model needs a new input.
4. What are we changing? Either the method, the inputs, or nothing, but say which.
5. Only then, the new forecast.

Putting the accuracy review first is what stops forecasting from becoming theater. A team that never revisits its last forecast will produce confident numbers indefinitely without ever getting better at it.

Series that need special handling

Short history. With only a few periods, you cannot detect seasonality and you should not pretend to. Use a range built from analogous segments, and say the uncertainty is large.

Intermittent demand. Series that are zero most periods and occasionally large break standard averaging approaches. Forecast the frequency and the size separately.

Structural breaks. A pricing change, a market exit, an acquisition, a tracking migration: after any of these, history before the break is a different series. Either exclude it or model the break explicitly. Do not let a model average across it silently.

One-off events. Promotions, outages, launches. Flag them in the history so the model does not learn them as a recurring pattern, and re-add their expected effect deliberately.

When not to forecast

Some things should not get a number. A market you have no history in. The effect of a strategy that has never been tried. Anything where the outcome depends mostly on a single decision someone has not made yet.

For these, replace the forecast with a decision framework: what has to be true for this to work, what would you observe early if it is going well, and at what point would you stop. That is more honest and considerably more useful than a spreadsheet extrapolating from a number you made up.

Related reading on this site

Forecast reviews depend on stable historical definitions: if a metric is redefined mid-history, every backtest is invalid. See data governance for change control, and reporting for how forecast-versus-actual belongs in the recurring cycle. The measurement chain a forecast inherits is described in analytics foundations, the sequence for interrogating a series is in how to work through a question, and the delivery choices are covered in dashboard design.

Common questions

How often should we re-forecast?

At the cadence of the decision it supports, and immediately after anything that changes the underlying business. Re-forecasting more often than you can act produces churn and invites people to shop for the version they like.

Should the data team own the forecast number?

The data team should own the method, the error history, and the honest statistical view. The business should own the plan and the commitments. Blurring those makes the forecast negotiable, and a negotiable forecast is not a forecast.

How do we handle a forecast that leadership rejects?

Publish both, with names attached, and score both at the end of the period. This is not a confrontation tactic: it is the only way the disagreement becomes learnable rather than repeated.

Do we need a specialized forecasting tool?

Usually not at the start. The bottleneck is almost always clean history, agreed definitions, and a review habit, none of which a tool provides. Revisit the question once you have those and can name a specific limitation you have actually hit.