Forecasting 2027: A Year-Agnostic Review Framework

For teams forecasting 2027, this year-agnostic review starts by settling which of three things a number 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. The gaps between them are useful: forecast to target is the problem's size; forecast to plan is how much risk you carry.

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

Start with the naive baseline you have to beat

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

Compare each baseline with the same rolling, held-out forecast origins and evaluate results separately by horizon.

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/SEMATECH e-Handbook of Statistical Methods, in its 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

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.

Choose the primary metric and decision-relevant horizons before looking at backtest results. MAE is in the same units as the forecast; MASE compares error with a naive baseline. MAPE can be misleading when actuals are zero or near zero, so do not rely on it in those cases.

Use a clear cycle grade rather than an invented universal cutoff. Pass when the backtest is leak-free, the candidate beats the strongest relevant baseline on the preselected metric at the decision horizons, bias stays within a business tolerance set in advance, and interval coverage matches its stated level over a suitable history. Review when the test is leak-free but a baseline performs as well or better, or bias or coverage misses the agreed tolerance; use the baseline or revise the approach. Fail when there is leakage, no auditable error record, or the score is based only on training data. There is no single numeric accuracy threshold that applies to every series and decision.

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. A published interval still leaves open which data analysis questions to ask about the number behind it.

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.

For a probabilistic prediction interval, track interval coverage: the share of later actuals that fall inside the published range, compared with its stated coverage level. Check it by horizon rather than pooling all periods. A scenario range is conditional on its assumptions, so assess whether those scenarios and assumptions held instead of treating the range as a calibrated probability interval.

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.

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. Sandbagging is one of the data analysis mistakes that shows up in process long before it shows up in arithmetic.

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.

Keep the error-by-horizon table separate for each decision-relevant horizon; do not hide a weak horizon inside a pooled score. Populate it from held-out forecasts:

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:

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. For change control, see data governance; for how forecast-versus-actual belongs in the recurring cycle, see reporting.

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 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. A spreadsheet such as Microsoft Excel can hold forecasts, actuals, baselines, horizons, and error metrics. 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.