When Your Planning Process Can't Keep Up With Growth
You doubled revenue in two years. Your planning process didn't scale with you. Now budget takes 14 weeks, nobody trusts the forecast, and your FP&A team is drowning in spreadsheets. Here's what actually happens when fast-growing companies outgrow their planning tools.
At 30 people and GBP 5M revenue, budget season was a two-week job. The FD built the model, the ops lead plugged in headcount numbers, and the board got a pack that made sense. It wasn't pretty, but it worked.
At 120 people and GBP 25M revenue, that same process takes 14 weeks. The model has six linked spreadsheets. Three people touch it, but only one actually understands how the formulas connect. Half the budget cycle is spent copy-pasting actuals from the ERP into Excel, reconciling numbers that don't match, and chasing department heads who haven't submitted their inputs.
The forecast? It's a snapshot from three weeks ago. By the time it reaches the board pack, the numbers are already stale.
This is what growth does to planning. Not all at once. Gradually, then suddenly.
What Actually Breaks
Growth doesn't break your planning process in one dramatic failure. It erodes it. Each new cost centre, each acquisition, each product line adds weight to a system that was never built to carry it.
Here's what we see across well over 200 EPM projects: the breaking points are remarkably consistent.
The budget cycle stretches. What took four weeks now takes ten or twelve. Every new business unit adds another round of consolidation. Another set of assumptions to check. Another version to reconcile. Month-end close drags because the same people building the forecast are also producing management accounts.
One person holds the keys. There's always someone. The financial analyst who built the original model three years ago. The one who knows why column AJ references a hidden sheet. When that person goes on holiday, the reforecast stalls. When they leave, you're in real trouble.
Nobody trusts the numbers. Different departments run their own side models. Sales has a revenue forecast in one spreadsheet. Finance has another. Operations has a third. The board sees whichever version got finished first. In the steering meeting, half the time is spent arguing about whose numbers are right instead of making decisions.
The manual process can't flex. The CEO asks "what happens if we delay the new hire plan by a quarter?" The honest answer is: "Give me two days." Because re-running a scenario means manually adjusting inputs across multiple files, checking every downstream formula, and rebuilding the output. So you stop running scenarios. You plan once and hope for the best.
Signs You've Outgrown Your Process
These aren't abstract warning signs. They're Tuesday morning realities for growing finance teams.
Your FP&A analyst spends 70% of their time on data preparation and 30% on actual analysis. That ratio should be reversed.
You've missed a board pack deadline in the last 12 months, or it went out with numbers you weren't fully confident in.
Your budget assumptions live in someone's head, not in a documented model. Ask them to explain the revenue build and you'll get a walkthrough of a spreadsheet, not a description of a process.
Reforecasting takes so long that you only do it quarterly when you should be doing it monthly.
You've hired good finance people who spend their days copy-pasting instead of thinking. They won't stay long.
What an EPM Platform Actually Fixes
A proper planning platform (Anaplan, Pigment, Planful, IBM Planning Analytics, among others) solves specific problems. It gives you one model that multiple people can work in at the same time. It connects to your source systems so actuals flow in without manual extraction. It lets you run scenarios in minutes instead of days. It produces a board pack from live data, not a static export from last week.
But here's what it doesn't fix.
It doesn't fix a planning process that nobody has actually designed. If your current approach is "everyone does their bit and we stitch it together at the end," putting that into Anaplan gives you the same mess on a more expensive platform.
It doesn't fix bad data. If your chart of accounts is inconsistent across entities or your cost centre structure doesn't match how the business actually operates, the platform will surface those problems. It won't solve them.
It doesn't fix ownership. Someone still needs to own the model, maintain it, and evolve it as the business changes. The platform makes that job easier, not unnecessary.
Why Most Growing Companies Get This Wrong
The typical sequence goes like this: Finance team is drowning. CFO sees a demo. The demo looks brilliant, clean data flowing into perfect dashboards. CFO signs a contract. Implementation starts. Three months in, the project stalls because nobody defined what the planning process should actually look like.
They bought software before fixing the process. It's like buying a CRM when you don't have a defined sales process. The tool amplifies whatever you put into it, good or bad.
The other common mistake is over-scoping. The platform can do budgeting, forecasting, workforce planning, sales ops, and consolidation. So the project tries to do all of it at once. Eight months later, nothing is fully working and the finance team is running the old spreadsheets alongside the half-built platform. Double the work, half the trust.
The Right Sequence
After well over 200 projects across our combined careers, the pattern is clear. Companies that get this right follow a specific order.
First, fix the process. Before you touch any platform, define how planning should work. Who owns which inputs. What the timeline looks like. How assumptions flow from revenue through to cash. How scenarios get approved. This takes two to three weeks of focused work, not months.
Then, pick the platform. With a clear process defined, platform selection becomes straightforward. You're matching capabilities to specific requirements, not evaluating features in the abstract.
Then, build in phases. Start with the thing that hurts most. Usually that's the budget or the monthly reforecast. Get that working properly, with 8-12 weeks for a focused build. Then expand to the next area once the team has confidence in the new way of working.
This isn't slower. It's actually faster, because you avoid the six-month stall that comes from trying to do everything at once and ending up with nothing that works.