The board asks a reasonable question. Can we take this contract on without hiring? Finance says it will come back next week.
Nobody in the room says the quiet part, which is that the week is not modelling time. It is the time it takes to find out who knows the answer.
My first question is never about the model. It is where the driver actually lives, and who is allowed to change it. That single question usually sorts a forecast problem into one of four layers, and the four need very different work.
The four layers, in the order they should be checked
Data. Does the number exist anywhere?
Process. Does anybody update it when the business changes?
Model. Does the forecast carry it as a driver at all?
Technology. Is the platform genuinely the limit?
Most planning conversations start at the fourth layer. In my experience the answer is usually at the first or second, and the fix there costs a conversation rather than a project.
A worked example
Illustrative example. A delivery business with twelve consultants. Six billable hours a day each, twenty working days in the month. That is 1,440 hours of capacity.
Committed work already absorbs 1,200 hours, so 240 hours are free. The new contract needs 400 hours a month.
A shortfall of 160 hours a month. That is the answer the board wanted, and it took one line of arithmetic.
The reason it took a week is that no part of that calculation lived anywhere a forecast could reach. Costs are deliberately not calculated here, because no cost assumptions have been specified, and the hiring decision does not turn on the hours alone.
Why the week happens
Trace that shortfall backwards and you can watch each layer fail in turn.
Capacity was not recorded, so there was no data. Nobody updated it when work was won, so there was no process. The forecast had no capacity line, so the model could not flex even once somebody supplied the hours. By the time the question reached the planning platform, the platform was not the constraint.
The data layer is where this most often starts, and it is rarely anybody's fault. In one of this year's research interviews, an Associate FP&A Director at a business with just under £500 million of revenue described the inheritance plainly: "we've got lots of legacy data from different systems when people migrated, and then there's been different consolidation in different parts of the business."
That is a data-layer problem, and no amount of model work resolves it. A separate conversation, with a Group FP&A Manager in a multi-site venues business, pointed at the layer above: complexity across data and scenario planning, with relationships between records that make a single driver hard to isolate. That one is real design work.
Both are the interviewees' observations. The four-layer sequence that follows is mine.
The smallest useful intervention at each layer
The instinct when a forecast cannot flex is to scope a rebuild. The better instinct is to ask what the smallest change is that would let you answer this one question next time.
Data. Capture booked hours by team, weekly. One sheet, one owner in operations, no system required to start.
Process. Add one field to the work-won handover: hours committed, by month. Commercial owns it, because commercial creates the commitment.
Model. Add capacity as a driver. One line, sourced from the data above. This is an addition, not a rebuild, and it is where finance earns its place in the conversation.
Technology. Only once the first three hold and still will not scale. If capacity is captured, updated and modelled, and the process still takes a week, you have a genuine platform case and the evidence to make it.
That order matters commercially. Three of the four start with something other than software, and a business that reaches for the fourth first tends to buy capability it cannot yet feed.
The trade-off worth naming out loud
Every control you add makes the answer more defensible and slower to produce.
Faster answers come from fewer approvals. Traceable answers come from more. There is no setting that gives you both, and the mistake is to choose once, for the whole model.
Choose per driver instead. A capacity assumption that moves a hiring decision deserves a named approver and a recorded change. A minor phasing correction does not. Decide the threshold in advance, when nobody is under pressure, rather than in the week the board is waiting.
That is the design judgement in a sentence: match the weight of the control to the weight of the decision, driver by driver.
What this makes possible
Run the four layers on one driver and the board question changes shape. Instead of a forecast that will come back next week, you have a shortfall of 160 hours, a named owner for the capacity assumption, and a decision that can be taken in the meeting: take the work and resource it, take it and subcontract the gap, or decline it.
Then record what was decided, and what happened. That outcome is the input to the next review of the same assumption, and it is the step most teams skip. Without it, the same question arrives next quarter and takes another week.
This is also where the connection becomes visible: source data feeding a driver, a driver feeding a decision, and the decision feeding back into the assumption. That connected chain is what I mean by decision infrastructure, and it is what trusted data and responsive planning are for. Neither is a product you buy.
One proportionate next step
Take the single driver your board has asked about most often this year. Run it through the four layers and write down, in one line each, where it is recorded, who updates it, whether the forecast carries it, and who approves a change.
If the first two are blank, you have an ownership problem and a fortnight of work. If all four hold and the answer still takes a week, you have earned the right to look at the platform.
For more on how we approach responsive planning and scenarios, or on why the tool is the last decision, both are worth ten minutes before your next planning conversation.