Planning vs Forecasting

A modeler delivers a forecast. The stakeholders are impressed by the accuracy, happy with the work, and then ask for a different number.

From the modeler’s perspective, this can seem absurd. The requirement was clear: predict next year’s attrition, or sales volume, or customer demand. The model was trained and evaluated against that requirement. Why build it if the answer is going to be negotiated afterward?

Sometimes the answer is pressure to make an unwelcome estimate disappear. But sometimes the stakeholders are trying to do something the requirements never described. They need to make a plan, and the forecast answers only part of their question.

Most organizations divide responsibility along familiar lines. A business or product person specifies what is needed; a technical person builds it. In modeling work, however, a precise technical specification can conceal an incomplete understanding of the decision. A target variable, a time horizon, and an accuracy target give a modeler plenty to work on. They can still leave out how the prediction will be used—and therefore which features the tool actually needs.

I replaced nine models used across a large workforce planning organization to forecast attrition and inform recruiting targets. “Predict attrition” was the original modeling task. But the planning need was broader: help us decide how much recruiting we need, given the workforce we have and the changes we intend to make.

That difference matters because next year’s workforce depends partly on what the organization chooses to do. Historical promotion patterns may be useful evidence, but planners may intend to change promotion policy. Locations may open or close, grow or shrink. Historical rates describe how the organization operated without necessarily describing how it plans to operate next year.

A forecast can incorporate those choices by estimating an outcome conditional on a hiring plan, a policy change, or another intervention. Planning involves choosing actions and comparing their consequences. The difficulty arises when the tool leaves those choices implicit, treating them as historical patterns to be learned rather than assumptions planners need to express.

In this organization, those choices were also distributed across teams. The promotion plan needed an estimate of the gaps attrition would create. Attrition estimates needed projected workforce counts by level and specialty so the appropriate learned rates could be applied. Each team’s work depended on quantities that other teams were still planning.

The learned estimates gave this process a starting point. Historical patterns supplied defaults from which the system could produce initial projections. Teams could then replace those defaults with the specific plans they had reviewed and adjusted. The model helped get the planning process started before all the plans were ready.

The design separated learned rates from explicit planning inputs. Input files supplied promotion rates, policy changes, and known plans. If the historical average differed from what planners intended for the next year, they could state that intention explicitly in a file that became part of the record.

The intermediate outputs mattered as much as the final recruiting number. Multiple people were responsible for the nine submodels, and many analyses contributed to their plans. Producing initial plans that teams could review and modify let the replacement fit the organization’s existing interfaces. It also preserved a place for judgment that was absent from the available data.

A single model producing only the final number would have left those contributions without a place to enter the process. It would also have failed to supply intermediate outputs that other analyses already depended on. Those outputs were part of the work the system needed to support, even though “predict attrition” did not describe them.

A historical promotion rate and a planned promotion rate might occupy the same column in a dataset. One summarizes observed behavior; the other records an intention. Their different meanings determine who should supply the value, when it should change, and what justification it needs.

The distinction is not simply between things the organization controls and things it does not. Attrition can respond to compensation, promotions, and policy, while a planned action may have uncertain implementation and effects. Making an input editable does not establish that the model accurately estimates the consequences of changing it. The relationships between assumptions and outcomes still need support, and their limits need to be understood.

Once the assumptions are explicit, asking for a different number can become a useful planning question.

If the recruiting requirement is higher than leadership wants, what would have to change? Is there new information about likely departures? Is leadership proposing a policy change? Or is it setting a target whose feasibility still needs to be assessed?

A model can help work backward from that target to the assumptions required to support it. Those assumptions may be implausible or far outside the conditions represented in the data. Discovering that is useful. Producing the desired number does not establish that the plan will achieve it.

The assumptions therefore need to remain visible and accountable: which came from evidence, which express intended actions, and which reflect someone’s judgment. People can then identify where they disagree and what would resolve the disagreement. A target can guide planning without being presented as an independent prediction.

This can sound like a return to interpretable models and explicit assumptions. But the important change was in how the system supported the planning process. Learned estimates provided a starting point. Responsible teams supplied their plans and judgment. Intermediate outputs connected their work to the rest of the organization.

The missing requirements concerned how the prediction would be used. What decision does it inform? Who contributes to that decision? Which inputs represent estimates, which represent choices, and which intermediate outputs do people need to review or use elsewhere?

Those answers determine the design of the tool as much as the choice of algorithm. “Predict next year’s attrition” can be satisfied by a forecast. “Help us decide how much recruiting we need” requires a system in which the people making the plan can express their choices and see how those choices affect the result.