What a Forecast Is Actually For
A forecast exists to feed a decision with a lead time. What changes when the decision is named, and what a number becomes when it is not.
The same volume forecast, named by the decision each horizon feeds
Next week
118
±4
The roster is published; nothing left to decide.
Next month
121
±11
Overtime offers and agency cover.
Next quarter
126
±23
Recruitment, which takes eleven weeks.
Next year
134
±48
Headcount budget and the second floor lease.
Two of the four horizons have a decision attached, and they are the two with the widest bands. The precise figure governs nothing; the vague one governs the budget. One employer's own set, not a benchmark.
A forecast exists to feed a decision somebody has to take before the thing being forecast happens. That is its entire job, and a forecast without a named decision behind it is not a forecast — it is a number that will be quoted back at somebody in six months.
The method in “What a Forecast Is Actually For” is only as useful as the definitions and source records behind it. A team exploring review the current product details for apps for tracking work hours can add timely work and project context, with transparent settings, limited access and a documented correction route around every consequential use.
Almost every problem in workforce forecasting traces back to this. The horizon is wrong because nobody asked what decision it feeds. The granularity is wrong for the same reason. The argument about accuracy is unresolvable because nobody has said what being right would have been worth.
Additional context for “What a Forecast Is Actually For” is available from Prophet forecasting documentation. External material is most useful when it prompts a specific validation check rather than replacing local judgement.
The question that comes first
"What will we decide, and by when?" Not "what will demand be" — that question has no answer until the first one does.
Asked at the start, it takes a minute and settles the horizon, the granularity and the form of the output. Asked at the end, it produces a rebuild.
What a decision has that a topic does not
A date by which it must be taken, a person who takes it, and an option set. "Should we recruit?" has all three. "How is demand looking?" has none, and the forecast made to answer it will be used for whatever anybody wants.
Three questions and the thing is specified. Nobody asks them because they feel like process, and the rebuild that follows feels like work.
Decisions a workforce forecast usually feeds
Recruitment, which has the longest lead time and the least reversibility. Training starts. Overtime offers and agency bookings. Shift pattern changes, which need consultation. Premises and equipment. And the annual budget, which is a decision whatever anybody calls it.
Each has a different lead time, and each therefore wants a different horizon from the same underlying series.
One forecast, several decisions
The common arrangement, and it is fine as long as each decision's horizon is published separately rather than one number being stretched across all of them.
What goes wrong is a single annual figure used to justify next week's overtime and next year's lease. The figure was built for neither.
The forecast that feeds nothing
Produced monthly, circulated, filed. Nobody has ever acted differently because of it, and nobody will say so because saying so would end the activity.
The honest test: name a decision in the last year that went differently because of this forecast. If the answer is none, the work is a report, not a forecast, and it should either acquire a decision or stop.
Naming the decision changes the form
A recruitment decision wants a quarterly figure with a band wide enough to be honest, because the question is "how many people, roughly". A rostering decision wants half-hourly intervals for a fortnight, because the question is "who is on at two o'clock".
Same demand, same data, two outputs that share almost nothing. Produced from one template, both are wrong.
What the decision maker actually needs to see
The point, the band, and the threshold at which their answer would change. That third thing is what makes a forecast usable, and it is almost never supplied.
"Below 124 we do nothing; above 131 we start recruiting" turns a number into an instrument, and it is the decision maker who supplies the thresholds, not the forecaster.
Writing the purpose into the document
One line at the top: what this forecast is for, who decides, and by when. It takes a sentence and it survives the forecaster leaving.
Six months on, it is the only thing that lets anybody judge whether the forecast was any good, because it says what being good would have meant.
When the decision changes
It does, often. The recruitment freeze lifts, the lease is signed, the service moves. The forecast built for the old decision is not automatically wrong, but it is no longer aimed at anything.
The review is short: does the named decision still exist, does it still have the same lead time, and does the horizon still match it.
The decision that is taken anyway
Some decisions get taken on a date whether or not anybody has a number: the budget round, the annual establishment review. These are the ones most worth serving, because the alternative to a forecast there is not a delay but a guess.
Identifying them is a matter of looking at the organisation's own calendar rather than at anybody's request.
What this does not fix
Bad data, absent drivers and a method that does not fit still produce a bad number. Naming the decision does not make the forecast accurate.
It makes the forecast assessable, which is a different and more fundamental property: an inaccurate forecast aimed at a named decision teaches something next quarter, and an accurate one aimed at nothing teaches nothing at all.