Choosing the Horizon from the Lead Time
A short procedure for setting the horizon of each forecast from the decision it feeds, including what to do when the lead time varies and when it is unknown.
Five decisions in one operation, each with the horizon its own lead time requires
Overtime
2 weeks
±5
Offered and withdrawn at a week's notice.
Agency cover
4 weeks
±9
Booked in blocks; cancellable at two weeks.
Training starts
8 weeks
±16
Course dates fixed a term ahead.
Recruitment
16 weeks
±28
Twelve-week lead time plus monthly review.
Premises
14 months
±52
Lease notice period, which cannot be shortened.
Five decisions, five horizons, one series. A single annual figure was being used for all five, and it had been built for the last one. One employer's own set, not a benchmark.
The horizon is the decision's lead time plus the interval between reviews, rounded up to the next convenient period. That is the whole rule, and almost every forecast horizon in use was set some other way.
The horizon in “Choosing the Horizon from the Lead Time” should determine which current records are relevant and how much detail the forecast can honestly support. A planning team evaluating how to calculate idle time for planning teams for how to calculate idle time can connect recent time and project context with short-term capacity questions, while keeping longer-range assumptions in a separately governed model.
The common alternatives — the financial year, whatever the system defaults to, what the last planner did — have in common that they are unrelated to any decision.
Teams documenting “Choosing the Horizon from the Lead Time” may use Oracle planning resources as an outside reference. Test the method against the real forecast horizon, known events and operational constraints.
The procedure
- Name the decision.
- Measure its lead time end to end.
- Add the review interval.
- Round up to a period the data supports.
- Check the resulting band is narrow enough to be worth publishing.
Five steps, half a day for a whole portfolio of forecasts.
Step five is the one people skip
A horizon can be arithmetically correct and still useless if the band at that distance is wider than the decision's tolerance.
Discovering that early is valuable: it says the problem is the lead time, not the forecast, and it moves the conversation to where it can be solved.
When the lead time varies by role
Take the longest within a group that is decided together, and split the group if the range is wide. A role family that fills in six weeks and one that fills in thirty do not belong on one horizon.
Splitting usually reveals that the long-lead roles are the ones nobody has been forecasting at all.
When the lead time is unknown
Measure it before building anything. The measurement is a query against the recruitment records and a conversation; it takes an afternoon and it determines everything downstream.
A horizon chosen before the lead time is known is a guess that will be defended for years.
Rounding to a convenient period
Sixteen weeks becomes a quarter plus a month, or four months. The rounding should always be upwards: a horizon slightly too long costs a wider band, and one slightly too short costs a late decision.
Those are not symmetric costs.
The horizon the data cannot support
Where the history is two years long, a two-year forecast is an extrapolation with no way to check it. Say so, give the band that honesty requires, and let the decision maker choose.
Saying so is not a failure of the forecast; it is the forecast doing its job.
Horizons for reversible decisions
Shorter than people expect. An overtime offer can be made eight days out and withdrawn; it does not need a quarterly view.
Reversibility is the second variable after lead time, and it usually argues for a shorter horizon and more frequent updating rather than a longer one.
Horizons for irreversible decisions
Longer, and with the band emphasised rather than the point. A lease, a redundancy, a site closure: these cannot be unwound, and the cost of being wrong is asymmetric and large.
For these the useful output is often not a forecast at all but a set of scenarios with their consequences priced.
The horizon that is set by the reporting cycle
Which is most of them. Monthly packs produce monthly forecasts, and the horizon becomes "to the end of the financial year" regardless of what anybody decides.
Breaking this does not require abolishing the pack. It requires adding one page per decision at its own horizon, and letting the pack's own page be what it is.
Recording the choice
One line: "Horizon 16 weeks: 12-week recruitment lead time plus monthly review." It makes the choice auditable and it tells the next planner what to re-examine when the lead time moves.
It also prevents the slow drift by which a horizon chosen for a reason becomes a horizon that is simply traditional.
When to revisit the horizon
When the lead time changes, when the decision changes, or annually, whichever comes first. The review is three questions and it rarely takes more than a few minutes.
The horizon somebody else set
Often the one in the system, chosen at implementation by a consultant working from a template. It is worth finding out whether anybody has ever examined it.
In most installations nobody has, and the answer to "why twelve months" turns out to be that twelve months was the default in a configuration screen six years ago.
Two horizons for one decision
Occasionally right: a long view for the commitment and a short one for the confirmation. A recruitment decision taken at twelve weeks and confirmed at six.
Where the decision has a cancellation point, publishing at both distances is more useful than publishing once, and it costs one extra row.
What changes when horizons are set this way
The forecasts get shorter. Most organisations discover they have been forecasting a year ahead for decisions with eight-week lead times, and that the long view was costing effort and supplying nothing.
The effort released usually goes into the one genuinely long-lead decision nobody had been serving.