Choose where to start.
Choose where you end up .

Directors were no longer debating a number. They were manually reconstructing the maths themselves to work out what the cost plan should say, because they could no longer trust the version the process produced. Underneath that, two waves of turnover had taken business and system knowledge with them, and the legacy planning tool had received limited support while a replacement was being built. People filled the gaps with manual workarounds, and each workaround buried its logic inside one person’s file, introduced a few more errors, and made the team more dependent on whoever had written it.

Wait for the replacement platform and live with a plan nobody fully trusted until it arrived. Or pull engineering effort back into a tool everyone had already agreed was on its way out. Neither addressed the actual problem: the organisation could no longer explain its own planning logic, and a new system built on top of that same gap in understanding would carry the same uncertainty forward.

The team was too busy explaining and correcting this week’s errors to recover the underlying logic, ease the manual burden, or prepare properly for the replacement. The long-term platform was still the right answer, but only once the business could explain what the current logic actually did and define what the new system needed to do instead. The first move was to check whether an approach already trusted in Europe could transfer here, which showed the North American system ran on comparable underlying logic. A lightweight AI interface then let business experts interrogate the existing code directly, without reading thousands of lines of code. Plan assumptions, outputs, and actual cost drivers were brought together in one new database table they could all see.

Business experts could see for themselves where the logic diverged from how the operation actually worked, without waiting on an engineer to translate it for them. Engineers knew where to target fixes to implement revised business logic. That cut the team’s dependence on individual spreadsheet authors and freed capacity to prepare the replacement properly rather than firefight around it. Within about three months, forecast variance fell from 8% to under 0.5%, the next planning cycle landed on time, and the team could move the replacement forward from a clearer shared understanding.

The network was growing, but every warehouse still produced its own weekly labour cost forecast, one of the business’s largest and most volatile cost lines. Standard tools were already in place; the problem was that each warehouse used them in its own non-standard way, adding inconsistent human judgement. That produced numbers that would not add up across the network and cost each warehouse 10 to 15 hours of manual work a week to produce.

Keep the network growing, and grow finance headcount alongside it, warehouse by warehouse. Or centralise data production for consistency and lose the local insight that made the numbers useful in the first place. One made finance headcount rise with every new warehouse. The other appeared to remove the local judgement that made the numbers useful.

The operating environment had already changed underneath the process. Newer operational systems now produced richer, more standard data: attendance and labour-planning outputs detailed enough to support a costed rolling forecast built centrally. The opportunity was no longer a tooling gap. The finance operating model had not adjusted to use what those systems could now do. The first move was to split the work by value: centralise the repeatable production of numbers from standard sources, and keep local finance focused on the one thing only they could do, explaining why results differed from plan through the operational drivers on the ground.

Local finance was not removed from the process. It moved away from producing numbers by hand and towards explaining what those numbers meant, the higher-value part of the job. The result was a model that could support network growth without growing finance headcount at the same rate, while preserving, and improving, the quality of local operational insight.

Full-year cost planning that normally took around four months now had to be delivered in six weeks. The deadline was fixed, and the level of detail the business needed from the plan wasn’t reduced. The plan set the cost budgets the network would be managed against all year, and the previous cycle had already shown how much manual effort the existing process demanded to produce it.

Two paths looked realistic. Produce a fast, high-level plan the team could turn around inside six weeks, or attempt to run the existing rigorous process and miss the deadline. The fast option wasn’t a harmless shortcut. A plan that couldn’t be properly explained or managed against would need constant manual patching for the year that followed: weekly reconciliation, fragile workarounds, and dependence on the few people who understood how the shortcuts worked. Neither path was free.

A tool that preserved the detail finance needed, without the existing process’s burden, had already been identified as the right answer. It was proposed after the previous cycle and turned down for a sound reason: planning ran only a handful of times a year, so the investment couldn’t be justified. The six-week deadline changed that arithmetic. A simplified plan meant a year of manual patching to run the business against it, and the existing process couldn’t finish in time. There was no longer a middle ground worth choosing. And the capability to deliver already existed: the team knew exactly what needed to be built, could build it quickly, and was confident it would land inside the time remaining. So the build came first. Not boldness for its own sake: the circumstances had removed the value of compromise, and the capability made the apparently risky option the lower-risk one.

What was delivered in three weeks was not a shortcut: around 200 database objects behind an Excel front-end built from scratch, running a full-year calculation in about 30 seconds instead of 10 minutes. The plan arrived inside the six-week deadline and could still be understood, challenged, and managed against all year. Then the payoff outgrew the deadline. Planning effort per cycle fell from roughly 48 person-weeks to 12. Within six months, the tool let cost planning be centralised for the UK, removing the need for each local team to build its own.

A shared tool was being built for three EU regions. Each region spoke directly to engineers and requested changes on its own. Engineers would build and deploy a change for one region, then hear from the other two: it didn’t help them, it conflicted with what they needed, or it broke something that already worked. The same work kept being done, removed, and redone.

The trade-off looked like speed versus standardisation. Let each region keep working directly with engineering and optimise for its own needs, which felt fast but meant the tool would drift into three regional variants. Or hold one standard product by aligning requirements across regions before engineering started, which meant agreement had to come first and looked slower. Under the way work was flowing, those genuinely were the only options. To keep the speed, give up the standard. To keep the standard, accept the delay. And neither, by itself, resolved the problem. The apparent speed came from postponing the cost rather than avoiding it: every change built for one region was being undone or rebuilt when it reached the other two. And negotiating agreement, with no agreed way to decide whose requirements should win, would have stalled without resolving the conflict. The trade-off held only as long as the way work entered engineering stayed fixed.

The constraint wasn’t engineering effort, and it would not have been solved by tracking requests more carefully or adding engineers. Direct region-to-engineer requests had worked when the tool served one region with one set of needs. Extended to three regions, the same model put three unreconciled sets of requirements straight onto engineers, with no agreed way to decide whose should win. The first move was to stop that uncontrolled flow of features and introduce a product-management layer: a place where the regions aligned on shared requirements and decision rights before anything entered engineering. That removed the trade-off rather than picking a side of it: the business could keep one standard product and get its speed back.

Work reaching engineering had already been agreed across the three regions, so it stopped being rebuilt. Ownership became clear: regions knew where their requirements got decided, engineers knew what they were building and why. The tool stayed one standard product rather than splitting into three regional variants, and the team could move faster over time because it was no longer spending its speed on rework.

Quarterly resource planning existed so leadership could see the whole portfolio at once: where projects overlapped, and where capacity should move before work began. The knowledge to build that view already existed with the product managers and engineers speaking directly to customers. But the process didn’t draw on that knowledge directly. TPMs gathered and restated it, and in translation, context was lost: genuinely different projects could look alike, and duplicated work could look unrelated. So leadership reviews became exercises in correcting and rebuilding the planning information rather than deciding anything with it. And because the cycle took four to six weeks, by the time a consolidated view arrived, customers and delivery teams had often already discussed, agreed, or started the work it described.

Two fixes looked obvious. Build a faster planning tool, so the consolidation stopped taking weeks. Or start planning earlier, so the answers arrived before the quarter did. Neither touched the real problem: a faster tool would process the same distorted information more quickly, and starting earlier would ask customers to commit to priorities before they were ready, baking in assumptions that would need revisiting anyway.

The constraint wasn’t speed or timing. It was ownership: the people running the planning process were not the people who understood the customer problems most deeply, so every cycle reconstructed second-hand information that already existed first-hand. The sequence mattered. Ownership moved first, to the people already closest to customers and delivery teams, because that changed where reliable information entered the process. Only once information originated with the people who understood it could the process itself be redesigned into a clear sequence. And only once that operating flow existed was it worth building a tool, one that enforced the redesigned way of working rather than automating the old one.

The planning reviews changed character. Instead of correcting and challenging unreliable planning data, leadership spent them making deliberate trade-offs about where finite capacity would create the most value. The consolidated view was accurate, it covered the whole portfolio, and planning took around two weeks instead of four to six, so leadership could set the direction before the work set it for them.