A working guide to building a forecasting framework, not a spreadsheet

Most forecasting effort goes into method selection, which is the part that matters least. What decides whether a forecast is useful is the structure around it: what gets forecast, by whom, on what cycle, and what happens to the number afterwards.

This page gives that structure. It has three parts: a register that says what you forecast and why, a route from the shape of a series to a class of method, and a review cycle that makes the whole thing self-correcting.

What to take away

Start from the decision and work backward to the series. Most forecast portfolios contain items nobody has ever acted on.
Method choice is a short conversation once you have looked at the series. Series shape rules out most options immediately.
The review cycle is the part that decides whether you improve. A forecast that is never scored is a forecast that cannot get better.

Part one: the forecast register

One row per forecast, kept somewhere people will actually look.

Field	What to record	The test of a good entry
Series	The measure, population, and unit	Two people would extract the same numbers
Decision	What changes because of this forecast	A verb, not a topic
Horizon	How far ahead, and why that far	Tied to a lead time or a commitment date
Cadence	How often it is reproduced	Matches how often the decision is made
Baseline	The naive comparison in use	Named, not implied
Interval	What is published around the point	Stated in words, not just as a band
Override rule	Who may adjust, and how it is logged	A name and a place
Owner	One person	Not a team
Review date	When accuracy is next scored	In the calendar, not in someone's memory

Building the register usually removes a third of a portfolio. Series with no decision attached are the first to go, and nobody misses them.

Part two: from series shape to method class

Look at the series before choosing anything. The characteristics that matter are visible in a plot: trend, seasonality, volatility, the frequency of zeros, and whether there are drivers you can actually observe in advance.

What the series looks like	Sensible starting class	What to avoid
Flat with noise	Repeat the last value, or a short average	Fitting a trend to noise
Strong repeating pattern	Seasonal naive, then seasonal smoothing	Comparing to last period rather than last cycle
Trend plus seasonality	Smoothing with trend and seasonal terms	A straight line fitted to a curve
Driven by something you know in advance	Regression on the known driver	Using a driver you must also forecast
Mostly zeros with occasional demand	Methods built for intermittent series	Percentage error measures
Short history, new product	Analogy to comparable series, stated as judgment	Any model presented as data-driven

Two classes cover most internal work. Exponential smoothing handles level, trend, and seasonal structure with a small number of parameters and degrades gracefully. Plain moving averages are cruder but transparent, and the NIST handbook's treatment of moving average and smoothing techniques is enough to implement either one correctly.

Before any of that, characterize the series itself. Penn State's applied time series course opens with exactly this step, and its first lesson on time series basics is a compact way to learn what to look for in a plot.

Part three: the review cycle

Four stages, run on a fixed calendar.

Produce. The model runs, the baseline runs alongside it, and both are stored. Storing the baseline is what makes everything later possible.

Adjust. Judgment overrides are applied, each with a reason and an owner recorded at the moment it is made. Overrides written afterwards are reconstructions.

Publish. Point, interval, baseline comparison, and the expiry condition. The published version is frozen; later corrections appear as a new version rather than as an edit.

Score. When the actuals land, the forecast, the baseline, and the pre-override version are all scored. Three numbers rather than one, because the interesting question is usually whether the overrides helped.

That last part is the whole reason to keep the pre-override version. In many organizations, judgment overrides make forecasts worse on average while feeling indispensable, and the only way to find out which case you are in is to have kept the number.

Roles that need naming

Three, and they should not all be the same person.

The producer runs the process and owns reproducibility. The overrider holds domain knowledge and may adjust, within a written rule. The scorer grades the result and reports it, and should not report to the overrider.

Where the last two collapse into one person, forecast accuracy stops being measured honestly, usually without anyone deciding that it should.

Common questions

How big does a portfolio have to be before a register is worth it?

About five. Below that you can hold it in your head, and above it you will start forecasting things nobody uses without noticing.

Our overrides are made in a meeting. How do we log them?

Write the pre-meeting number down first and have someone record the adjusted number and one sentence of reason before the meeting ends. Anything reconstructed later will be a rationalization rather than a record.

Should the same team forecast and plan?

They can, provided the scoring is done by someone with no stake in the plan. The failure to avoid is the one where the forecast quietly becomes the target and then stops being a forecast at all.

What if the series is too short to fit anything?

Then say so, use an analogy or a judgment forecast, and label it as such. A judgment forecast with an honest label is respectable. The same forecast dressed as a model is not.