Three Reasons Your EPM Implementation Will Fail (and How to Avoid Them)

We've been involved in well over 200 EPM projects across our combined careers. The ones that went wrong almost always went wrong for the same three reasons. Not because the software was bad. Not because the vendor oversold it. Because something more basic broke down before anyone touched a configuration screen.

If you're about to spend six figures on an EPM platform, these are the three things most likely to sink you.

1. You bought the platform before defining what you actually need it to do

This is the most common pattern. Someone on the leadership team sees a vendor demo. The demo looks incredible. Dashboards refresh in real time. Scenarios update with a click. The board pack practically builds itself. So the decision gets made: we're buying this.

Then reality hits. Your actual data is messier than the demo data. Your processes have edge cases the vendor's pre-built templates don't cover. And nobody sat down before kickoff and agreed on what "good" looks like. What does the monthly close process actually need from this system? What does the FD want in the board pack? What does the FP&A team need for the forecast? These questions didn't get answered because everyone assumed the platform would sort it out.

Scope is the other killer here. The project starts as FP&A: budgeting, forecasting, management reporting. Reasonable enough. Then someone says "while we're at it, can we add workforce planning?" Then sales wants their pipeline forecast in the same tool. Then operations wants capacity planning. Each addition seems logical on its own. Collectively, the project doubles in size, the timeline stretches from 8 weeks to 8 months, and the budget conversation gets awkward.

We've seen a GBP 80,000 project turn into a GBP 300,000 project this way. Not because anyone did anything wrong. Because nobody drew a line at the start and said: this is what we're building first, and this is what comes later.

2. Dirty data will find you mid-project

There's a joke that does the rounds on LinkedIn: "People at businesses with good data... what do you do all day?" It's funny because it's true. Almost nobody has clean data. They just don't know how bad it is until they try to put it somewhere structured.

EPM platforms need data from your ERP, your HR system, your CRM, sometimes your payroll. When you start pulling that data together, surprises appear. Multiple charts of accounts that don't map cleanly. Historical gaps where someone changed a cost centre structure three years ago and nobody updated the old records. Master data that doesn't match across systems because finance calls it one thing and operations call it another.

Garbage in, garbage out applies to EPM exactly as much as it applies to the spreadsheets you're trying to replace. The difference is that in a spreadsheet, one person knows where the workarounds are. In an EPM platform, dirty data breaks the whole model and everyone sees it.

This surfaces mid-project. Always mid-project. And it causes weeks of rework that nobody budgeted for because the original scoping assumed the data was in better shape than it actually was. We now tell every client: assume your data needs work. Budget time and money for it. If it turns out to be fine, you'll be pleasantly surprised. It almost never turns out to be fine.

3. You underestimated how much daily work needs to change

Your finance team has been running the budget cycle in Excel for years. They know their models inside out. They know which tabs to update, which formulas to check, which cells to copy-paste into the board pack. It's a manual process and it's slow, but it works and they trust it.

Now you're asking them to do all of that in a new system. Different logic, different layout, different workflow. The person who built the original Excel model left two years ago, but everyone else has memorised the process. That muscle memory doesn't transfer to a new platform overnight.

Training typically gets squeezed. The project is running behind (see points 1 and 2), so instead of proper hands-on sessions spread over a few weeks, the team gets one training day right before go-live. They nod along, take some notes, and then the system goes live and everyone breathes a sigh of relief.

That's when the real problems begin. Users don't trust the numbers coming out of the new platform because they haven't had time to understand how it calculates things. So they do what any sensible person would do: they run the old spreadsheets alongside the new system. Now your team is doing double the work. The month-end close takes longer than it did before. The forecast is late because people are reconciling two sets of numbers. The CFO starts asking why they spent all that money.

This isn't a technology problem. It's a people problem, and it's fixable. But only if you plan for it from the start rather than treating it as a box to tick at the end.

What actually reduces these risks

Do proper discovery before you buy software. Spend two to three weeks mapping your processes, your data, and your team's actual requirements. Not what you think you need based on a demo. What you actually need based on how your finance function works today and where the pain points are. We call this the Bolt Blueprint. It costs GBP 5,000 and gets credited against implementation if you go ahead. It's the single most effective thing you can do to avoid a failed project.

Deliver in phases, not all at once. Start with management reporting. Get the board pack automated. Get the monthly close running smoothly. Then add budgeting and forecasting. Then, if it makes sense, add operational planning. Each phase should take 8-12 weeks for a focused build. Each phase delivers something usable. And each phase gives your team time to learn the system before more complexity gets added.

Build internal capability so you're not dependent on consultants forever. Your team should be able to run the month-end close, update the forecast, and make minor model changes without calling anyone. That means proper training, not a one-day session. It means documentation your team actually wrote, not a consultant's handover pack that sits in SharePoint unopened. The goal is that six months after go-live, you don't need us. That's what success looks like.