Workforce Planning Scenarios: Driver-Based Models vs Budget Arithmetic, and the Assumptions Register
Most workforce plans are budget arithmetic wearing a strategy costume: last year’s headcount, plus or minus a negotiated percentage, spread across cost centres. That process produces a number. It does not produce a plan, because it contains no model of how headcount relates to anything the business actually does. Driver-based planning is the alternative, and its track record is mixed for an instructive reason — teams build models with dozens of drivers when the variance is carried by five. This piece covers the structural difference, the small driver set that matters, and the publishing discipline that separates a scenario from a guess.
The structural difference
Budget arithmetic answers: given what we spent, what will we spend? It is an allocation procedure. Its headcount line is an output of negotiation, not of any stated relationship between work and workers.
A driver-based model inverts this. Headcount is computed from the work: demand volumes, throughput per person, and the flows in and out of the workforce. The skeleton is always the same recursion: required_fte = demand_volume / productivity, adjusted by hiring lead time, then reconciled against supply through end_headcount = start + hires − exits. The plan becomes a set of stated relationships, each of which can be contested, tested, and — this is the point — wrong in a documented way. Budget arithmetic cannot be wrong; it can only be renegotiated.
Scenario planning exists because the relationships hold but the inputs are uncertain. The scenario is not three irreconcilable spreadsheets named Base/Upside/Downside. It is one model run under stated input ranges, so that the difference between scenarios is legible: these three assumptions moved, by these amounts, and here is the headcount consequence.
The five drivers that carry the variance
Across the driver-based models we have reviewed — healthy and broken alike — sensitivity concentrates in a short list. Regardless of how many drivers the spreadsheet contains, the output usually moves on:
- Demand growth. The volume forecast feeding
required_fte. It is also the least controllable input, which is precisely why it belongs in a scenario range rather than a point. - Attrition rate. Small absolute changes in assumed exits compound through replacement hiring into large plan deltas. An illustrative example, constructed for demonstration, not measured: in a
1,000-person function at15%annual attrition, replacement consumes150hires before a single growth role is filled; at18%, the same growth plan requires30additional hires with zero change in demand. The attrition assumption is doing more work than the growth assumption, and it usually has the weakest evidence behind it. - Internal fill share. Every role filled internally is simultaneously one hire avoided and one vacancy created elsewhere. The internal mobility rate is not a footnote to the hiring plan; it is a multiplier on it.
- Productivity per person. Often the largest and least-examined driver. A model can absorb a demand miss if throughput assumptions hold; it cannot absorb a throughput miss, because productivity touches every role family at once.
- Hiring lead time. Time-to-fill converts an annual requirement into a quarterly hiring schedule. Lead-time optimism is the most common reason driver-based plans fail on paper while their totals still look right — the year-end number is achievable, the in-year trajectory is not.
The modelling lesson is unglamorous: get these five inputs reviewed, ranged, and evidenced, and a simple model outperforms an elaborate one. Complexity beyond this set buys perceived rigour at the price of auditability — more assumptions, each individually less examined.
Publish the assumptions with the plan
A workforce plan without its assumptions is a conclusion without a derivation — unverifiable in the moment and unlearnable in retrospect. The instrument that fixes this is an assumptions register, published alongside the plan, with one row per material assumption:
| Field | Contents |
|---|---|
assumption | The input and its value (e.g., attrition rate per role family) |
owner | The named person accountable for the estimate |
evidence | What the value is based on — trailing twelve-month actuals, external benchmark, or judgement |
sensitivity | Direction and rough magnitude of plan impact if wrong |
review_trigger | The observed condition that forces re-examination |
The register does three jobs. It makes the plan falsifiable — next quarter’s actuals can be compared against stated expectations rather than vibes. It distributes accountability — an attrition assumption owned by finance and a demand assumption owned by the business unit can be challenged by their owners, not just by the analytics team. And it turns planning into a learning loop: the register is where forecast error gets decomposed into which assumption missed, which is the only version of “our plan was wrong” that improves the next plan.
One practice we consider non-negotiable: separate the assumption from its advocate’s incentive. The business unit that benefits from a larger plan should not be the sole author of the demand and productivity assumptions that generate it. This is not an accusation; it is the same incentive-separation principle applied to survey design and mobility metrics. Inputs authored under incentive are data with a known distortion direction.
What scenario planning cannot do
Driver-based scenarios quantify sensitivity; they do not assign probabilities, and we caution against presenting scenario outputs as prediction intervals. Downside scenarios are typically chosen for narrative plausibility, not calibrated likelihood — the set of scenarios is a stress test, not a distribution. The model also inherits every limitation of its flow accounting: productivity gains from automation, role redesign, and demand-mix shifts appear in these models only as tuned parameters, and treating them as exogenous constants is a modelling choice that should appear in the register like any other.
The argument for driver-based planning is not that it forecasts better. On point accuracy, the literature gives no reason for confidence either way. The argument is that it fails better: wrong in documented places, at documented magnitudes, with an owner for every miss. Budget arithmetic fails silently and is renegotiated; a driver model fails audibly and is revised. The data always wins over the narrative — but only for organisations that wrote their assumptions down before the data arrived.