Assumption Ledgers and the Continuous Annual Plan

Assumption ledgers and the continuous annual plan describes how an annual workforce plan can be kept current without being re-signed: by holding the plan as a ledger of named assumptions, each a stock with a tolerance band, and recomputing the plan from the ledger whenever an assumption moves. The annual plan then stops being an event and becomes a horizon. Signature is reserved for the moment an assumption leaves its band, which is a decision, rather than for the calendar, which is not.

The page belongs to the series that begins at Workforce Planning as a Control System, where the ledger is coupling L2.

The problem the ledger solves

A conventional annual plan is a number with a history. The number was built from assumptions: a volume forecast, a channel mix, a handle time per channel, a shrinkage rate, an attrition rate, a ramp curve, a productivity path. The assumptions were argued over, agreed, and then compiled into headcount and cost, and the compiled number was signed. From that moment the assumptions are invisible. When the world moves, the discussion is about the number, "we are forty over plan", and not about the assumption that moved, "handle time on the email channel is twenty percent above what we assumed and has been for a quarter".

Three things follow. The plan cannot be partially wrong; it is defended or abandoned whole. The variance explanation has to reconstruct, every month, which assumption moved, and does so inconsistently. And the organization cannot learn, because the assumption that was wrong is never revised in the place it lives; it is overridden in next year's plan by someone who remembers.

The idea that a plan is a set of assumptions to be tested rather than a number to be met was formalised in strategy as discovery-driven planning: write the assumptions down, rank them by how much the plan depends on them, and check them at milestones. The ledger applies that discipline to workforce planning and makes the checking continuous.

The ledger

The ledger holds one row per assumption the plan depends on. Each row carries:

Field	What it holds	Example
Assumption	the named quantity, with its definition from the definitions register	handle time, email channel, hours per item
Planned value	the value the plan was compiled from, with the date it was set	as set at the last re-base
Current estimate	the value the learning loops currently hold, with its vintage	the thirteen-week trailing measure, updated weekly
Tolerance band	how far the estimate may drift before a decision is opened	plus or minus eight percent (illustrative), or whatever the plan's sensitivity to the assumption justifies
Owner	the role that answers when the band is breached	the channel's planning lead
Persistence	how long the estimate has been outside the band	weeks, from the variance-routing test
Dependents	which plan outputs move when this assumption moves	headcount for the channel, the training plan, the envelope

The plan of record is a function of the ledger. Headcount by pool and week, the training plan, the envelope and the cost are compiled from the rows, and recompiled whenever a row's planned value changes. The compiled plan therefore has a lineage: every number in it can be traced to the assumptions it came from and the dates they were set.

The tolerance bands are the ledger's design decision. A band too narrow makes every assumption a decision every week; one too wide is the annual plan again. The right width comes from the plan's sensitivity to the assumption and the cost of being wrong about it, which is the same logic as the frozen zone and the change cost in Planning Nervousness and Frozen Zones: the band is the assumption's frozen zone.

How the plan moves

Three kinds of movement, with different governance.

• Inside the band, nothing. The current estimate drifts, the plan does not. The drift is visible in the ledger and in the variance routing, and the fast loops carry it.
• Across the band, a decision. When an estimate has been outside its band for longer than the persistence test allows, the owner is asked one question: is the planned value wrong, or is the operation? If the planned value is wrong, it is re-set, the plan recompiles, and the envelope moves with it through the finance loop. If the operation is wrong, a corrective action is opened and the planned value stays. Either way the decision is recorded against the row, which is what makes the ledger an audit trail.
• At the re-base, a review. Once a year, or at a defined event, every row is reviewed, the planned values are re-set to the current estimates where no decision has been taken, and the lineage restarts from the re-based values. This is what the annual planning cycle becomes: a review of a ledger that has been current all year, rather than the construction of a number from scratch.

The forecast and commitment ledgers of The Annual Plan as an Open-Loop Controller are two views of the same rows: the current estimate is the forecast view, and the planned value is the commitment view, since it is what the envelope was compiled from. The target ledger is a third column, where leadership wants something other than the forecast, and the gap between the two is visible rather than hidden inside one number.

A breach, worked

One application of the method, in indices [estimated]. The email handle-time row was planned at 100. The current estimate, a thirteen-week trailing measure, has read 109, 111, 112 and 113 over the last four weeks against a band of plus or minus eight. Persistence is four weeks, which passes the window. The owner, the channel's planning lead, is asked the one question. The finding is that a new case type arrived with the quarter and takes longer by design, so the planned value is wrong: it is re-set to 109, the smallest excursion in the window, which is the same rule the routing method uses so that a re-set never chases the latest reading; the plan recompiles, the channel's workload dependents move by nine percent and its headcount by somewhat less, the training plan picks up the new case type, and the envelope request goes to the finance loop with the row's lineage attached. Had the finding been that agents were taking longer on the same work, the planned value would have stayed at 100 and a coaching action would have been opened against the row instead, with the excess carried by the hours band until it closed.

What it needs

The ledger reads from the definitions register, one definition and one source for every measure it holds; without that the current estimate and the planned value are not comparable. It needs a version on every forecast, so that the current estimate has a vintage and the learning loop can tune it; see Forecast Vintages. It needs the variance decomposition, so that a breach is attributed to the assumption that moved and not to the headcount that resulted; see Variance Routing by Horizon. And it needs a compiler, the model that turns rows into headcount and cost, that is run by machine rather than by workbook, because a plan that is recompiled monthly by hand will not be.

Where a planning platform already holds drivers, the ledger can be its driver layer with bands and owners added, and the platform's forecast-to-plan variance becomes the breach test. Where it does not, the ledger is a table in the planning function's own data layer with the compiler reading from it, which is the subject of Long-Term Planning Agents and the Plan of Record.

Limitations

The ledger does not make the assumptions right; it makes them visible and dated. The tolerance bands are judgement, and an organization that sets them to avoid decisions has rebuilt the annual plan with more rows. The compiler is a model, and its lineage is only as good as the definitions it reads. And the ledger moves the argument from the number to the assumption, which is progress, but an assumption can be argued about too; the persistence test and the owner column are what keep the argument short.

Maturity Model Position

A ledger of assumptions with owners exists informally at every level of the WFM Labs Maturity Model™, in the planning lead's notes. It becomes a data object with bands and a compiler at Level 4: Planning in Distributions, where the plan is a range and every forecast carries a version; at Level 5: Adaptive Orchestration, where the operation is run as a loop that learns, the current estimates update as part of that loop and the owner is asked only when a band is breached.

See Also

• Workforce Planning as a Control System
• Feedback Loops in Workforce Planning
• The Annual Plan as an Open-Loop Controller
• Variance Routing by Horizon
• Planning Nervousness and Frozen Zones
• Forecast Vintages
• Long-Term Planning Agents and the Plan of Record
• Labor Budgeting and Financial Planning
• Workforce Data Definitions Framework