A board meets and asks finance a narrow question. Can we delay one delivery hire by six weeks?
It is a reasonable question, and often where a planning software conversation begins. That is the wrong order. The answer depends on three things being written down first. Once they are, the system question becomes answerable.
Start with the decision, not the shortlist
The decision required. Not better visibility. One choice against a named alternative: delay the start date by six weeks, or recruit now. Something the board can settle in the meeting.
The assumption and its owner. Which driver moves the answer, and who owns it. Billable capacity, backlog and start-date slippage sit with the delivery director. Finance models the number; somebody outside finance approves the assumption.
The output and the deadline. Margin and cash effect across the plan horizon, on the desk two working days before the board meets.
Written out, it reads like this: we need [owner] to decide [action] by [date], using [driver] and [margin and cash consequence].
That sentence is the specification. Everything after it is procurement.
Reporting requirements and planning requirements are not the same
A reporting problem and a planning problem need different things. A shortlist that blurs them produces a system that displays the past well and struggles to change the future.
| Reporting requirements | Planning requirements | |
| Output | Reconcile actuals | Connect drivers to consequences |
| Inputs | Refresh source data | Collect named assumptions |
| Approval | Sign off definitions | Approve changes |
| Scenarios | Compare reported periods | Compare changed drivers |
| Versions | Retain published outputs | Retain baseline and approved scenarios |
These are requirements, not categorical product limitations. Several products span both columns. The table is a specification to test against, not a statement about any platform’s limits.
The distinction is simple. Reporting makes the past defensible. Planning makes the future changeable, with a record of who changed it and what it was before.
The worked example
Illustrative example. The figures show the mechanism. They are not benchmarks and not a client result.
One delivery hire. Six weeks is 30 working days. Six billable hours a day at £150 an hour, against a fully loaded employment cost of £350 a day.
| Measure | Working | Effect in the period |
| Billable capacity | 30 days × 6 hours | 180 hours deferred |
| Revenue | 180 hours × £150 | £27,000 deferred |
| Employment cost | 30 days × £350 | £10,500 avoided |
| Contribution | £27,000 less £10,500 | £16,500 lower than hiring now |
The payroll line improves. Contribution falls by more.
The assumptions carry that answer, and they belong on the page rather than in a model: immediate full productivity if hired, enough demand to fill the time, no cover and no redeployment, no catch-up inside the comparison period, revenue recognised as work is delivered, and all other costs unchanged. Move any one of them and the number moves. Allow partial cover from existing staff and the gap narrows; assume the work returns next quarter and the picture changes again.
Two points matter more than the £16,500.
Deferred is not permanently lost. This is a single-period comparison. Those hours may be recovered later, and where they are recovered belongs in the plan rather than the headline.
Contribution is not cash. It is also not EBITDA. Cash needs its own schedule, built from invoice dates and collection terms, because revenue recognised as work is delivered and cash received are separated by however long the business takes to get paid. A model that implies a cash benefit from a contribution effect has skipped the step the board cares about most.
Run the acceptance test
Ask any supplier to demonstrate this with your numbers, not their demonstration data.
Change one start date.
Capacity, revenue and employment cost should all move from that single input, without anybody rebuilding a model or keeping a second spreadsheet. The cash schedule should move too, on its own timing assumptions, visibly separate from the contribution effect rather than derived from it.
The system should then show where the assumption came from and who approved it. A start date owned by nobody is a number, not a decision.
Finally, recover the approved baseline and put the two side by side. If the board approved a plan in March, that plan must still exist as approved, and the difference must be explainable.
Pass that test and the board can settle the hiring question in the meeting, with the consequence attached and an owner named, instead of commissioning another paper. That connected chain, from source system to driver to approved assumption to the decision, is what I mean by decision infrastructure. It is not a product. It is what the products are bought to support.
Scale the controls to the decision
Not every assumption needs a formal approval step. Put a sign-off gate on every driver and you produce a planning process nobody uses, which is worse than the spreadsheet it replaced.
Separate two activities. Data preparation should be automated where it sensibly can be, because trusted data is a foundation rather than an achievement, and nobody should spend the week reconciling extracts. Accountable judgement should not be automated at all. A named person approving a start-date assumption is doing something a tool cannot do for them, and modelling speed does not compensate for an assumption nobody owns.
That is where the first use case should be scoped. One decision, defined tightly enough to test from input through to approved decision, beats a platform-wide rollout that answers no real question.
Five checks to run on your own next planning decision
1. The decision. What choice is being made, by when, against what named alternative.
2. The driver and its source. Which input moves the answer, and which system it comes from.
3. The owner and the approval. Who owns the assumption, and who approves a change to it.
4. Linked margin and cash timing. Whether the margin effect and the separately modelled cash schedule both move from the same input.
5. The retained baseline and refresh trigger. Which version the board approved, and what causes the plan to be refreshed.
If four of the five are in place, you have a scoping exercise. If two are, the platform is not your immediate problem.
A closing judgement
I have watched a good many planning investments decided the wrong way round, starting with a shortlist and working backwards to a purpose. Businesses that get value from a planning platform tend to be the ones that could describe, before the first demonstration, which recurring decision they wanted to make faster and who was accountable for the assumption behind it. Those that struggle tend to have bought capability hoping the purpose would emerge once the system was live.
The tool matters. It is simply the last decision rather than the first, and the work that makes it the right one happens before anybody opens a demonstration.