Wanting a New System and Being Ready for One Are Different Things
Three signals tell me whether a company will actually finish an ERP implementation. Missing one is the reason most projects stall, not the software.
A company called us last year, ready to overhaul their ERP.
Two executives were pushing hard for it. But in our first few discovery calls, the rest of the leadership team couldn’t agree on whether to spend the money or where to start.
Six months later, that internal disagreement still had them frozen. They never moved forward.
Nothing was wrong with the software they were looking at. Nothing was wrong with their business case. What they didn’t have was a decision.
So now I ask one question before I ask anything else: why now?
I’m aware that publishing this costs me deals. I’d rather tell you that you aren’t ready than take your money and watch the project die in month four.
Why “why now?” is the first question I ask
I hear “we need a new system” constantly. If someone is calling us, that’s already a good sign — something hurts enough to pick up the phone.
But wanting a new system is a feeling. Being ready for one is a set of facts.
The single biggest misread I see is treating an implementation as a software purchase. It isn’t. It’s an organizational initiative that happens to involve software. It requires buy-in, effort, and sustained commitment from people who do not work in finance and did not ask for any of this.
That’s why the three signals matter. They aren’t about your software. They’re about whether your organization can carry the disruption.
Signal one: a specific goal, not a general complaint
Here’s what it sounds like when it’s genuinely present. “One of our goals this year is to transform our finance operations.” “We’re launching a new product line and our current system can’t support it.” There’s a driver underneath the request. The system is in service of something.
Here’s what it sounds like when it’s being claimed. “Our system is old.” “We’ve outgrown QuickBooks.” “Finance is drowning.” All true, probably. None of them is a goal. They’re symptoms, and symptoms don’t survive contact with a steering committee in month five when someone asks why the project is worth another quarter of everyone’s attention.
A lot of companies come to us saying they need a new ERP, a tool replacement, an integration platform. Once we start walking through the details, we frequently uncover that the root issue is process-related. Not a system requirement whatsoever. And it is much harder to undo a poor application of the wrong tool than it is to figure out what the right tool should have been in the first place.
The self-test: write one sentence describing what will be true twelve months after go-live that isn’t true today, and make it a sentence your head of sales would understand. If the only answer you can produce is “we’ll be on a new system,” you don’t have a goal. You have a purchase.
Signal two: a forcing function with a date on it
Something has to be forcing your hand. Maybe you’ve got an audit coming and your current processes won’t hold up. Maybe you’re scaling fast and the old system can’t keep up. Whatever it is, there’s urgency, and you’re ready to do something about it.
I know this one from the inside. Before I started this firm, I was the Controller of a fast-growing SaaS business preparing to go public. We were producing more than twenty thousand invoices a month in QuickBooks. It took a small army of AR specialists just to keep things moving, and the system was constantly on the edge of collapse. Nobody had to be persuaded that we needed NetSuite. The IPO calendar and the invoice volume made the argument for us.
A claimed forcing function sounds like this: “we’d like to be live by end of fiscal.” “Sometime next year.” “Once things calm down.”
Things do not calm down.
The self-test: name the person who has a real problem on the day you miss the date, and name what it costs them. If you can’t, you have a preference on a calendar, not a constraint. Preferences lose to quarter-end every single time.
Signal three: leadership has already agreed to spend the money
I can’t tell you how many times I’ve walked into a company that’s “ready to scale” only to find leadership that can’t make a decision. They’ve got the technology. They’ve got the budget. What they don’t have is alignment, or the conviction to make the tough calls.
Scaling requires alignment and authority — everyone rowing in the same direction, and someone empowered to make the call when there’s disagreement. Without both, you’re just adding complexity to chaos.
“We have budget approved” is the claim. Here’s what the real version includes:
A named executive sponsor who will still be in the room in month seven. Not a champion. A sponsor — someone whose own objectives are tied to this landing.
A number with a buffer in it. For time, for cost, and for team capacity. ERP budgets don’t implode on their own. The scope expands, resources get pulled back to their day jobs, “Phase 2” suddenly can’t wait, integrations unravel. Budgets don’t implode. Teams do.
An honest read on where “done” is. So many leaders get stuck on the six-months-and-done mindset, and then oversell that timeline to the CEO. Six months becomes a year. Even once the system is live, it needs ongoing care. The CEO feels misled, the team is exhausted, and nobody budgeted for that much change management. Set the expectation correctly at the start and you keep your sponsor. Oversell it and you lose him exactly when you need him.
What to do when one of the three is missing
Fix the missing one before you sign. Not after. After is a change order.
No specific goal? Buy a diagnostic, not an implementation. Walk your order-to-cash, purchase-to-pay, and record-to-report processes end to end and find out where the friction actually originates. Separate symptoms from root causes. Sometimes the honest outcome of that work is that you don’t need a new system yet. That’s a good outcome. It’s certainly cheaper than the alternative.
No forcing function? Don’t manufacture a fake one — your organization can smell it. Either find the real one, or wait and spend the interim on your data. The devil is in the data, and clean master data is the one investment that pays off no matter which system you eventually choose.
No leadership alignment? This is the hard one, and it’s the only input you cannot outsource. Fix your leadership dynamics before you touch your operations, or you’re building on quicksand. We can build the system, manage the implementation, and train your users. We cannot make your people believe that change matters. Only you can do that.
A real deadline doesn’t buy you permission to skip steps
Readiness cuts the other way too. Urgency is a signal, not a license.
We had a client who wanted to go live even though we hadn’t finished validation testing. They had a hard date, and missing it was a risk they were willing to take. I understood the pressure. I still don’t recommend it, and I said so at the time.
There are three kinds of testing you can’t skip. Process testing, where you walk every workflow end to end. Historical data testing, where you migrate your data and then prove it’s clean rather than hoping it is. And integration testing, where you confirm your systems can actually talk to each other using scenarios they’ll hit in real life. Companies skip these because they feel behind schedule or because they’re confident the system will work regardless. Then they spend roughly three times as long fixing problems after launch as they would have spent catching them before it.
An ERP go-live is not golf. There’s no mulligan. Once you’re live, you’re in it.
So when the date is real and the work isn’t finished, you don’t compress testing. You shrink scope. We phase every project for this reason: core ERP first, with a clean data model, foundational processes, and solid integrations between the critical systems. Layering advanced billing logic and custom reporting on top of a core model that hasn’t been fully tested is exactly how projects run over budget and clients end up frustrated. Then a short pause, deliberately, to avoid project fatigue. Then automation, tailored reporting, and workflow changes in the next phase.
Moving quickly and building well are not opposing goals. Getting both requires the discipline to do fewer things, better, and in the right order. You do not have to boil the ocean to go live on time.
The ruling
Score yourself honestly. A goal you can say in one sentence. A date somebody will be held to. A leadership team that has already stopped debating the money.
Three out of three, and I want the call. Two out of three, and the third one is your project — not the ERP.
Fix the missing signal first. Then sign.
Questions people ask
- How do I know if my company is ready for an ERP implementation?
- Check three things. Can you name a specific business goal the new system serves, in a sentence someone outside finance would understand? Is something forcing your hand on a date you'd be embarrassed to miss? Has your leadership team already agreed to spend the money, with someone empowered to break ties? Two out of three isn't ready. It's a project that stalls in month four.
- What counts as a real forcing function for an ERP project?
- An audit your current processes won't survive. Growth your system can't absorb. A product line or geography you can't launch on what you have. A financing or reporting event with a date attached. The test isn't whether the date exists. It's whether someone specific has a problem the day you miss it, and whether that problem costs something.
- Our leadership team isn't aligned. Should we start the implementation anyway?
- No. Alignment is the one input you cannot buy from a consultant. I've watched a company sit frozen for six months because two executives wanted a new ERP and the rest of the team couldn't agree on whether to spend the money or where to start. We can build the system, run the project, and train your users. We can't make your people believe the change matters.
- What should we do if our go-live date arrives and validation testing isn't finished?
- Cut scope, not testing. Process testing, historical data testing, and integration testing are the three you can't skip. Teams that skip them because they feel behind spend roughly three times as long fixing problems after launch as they'd have spent catching them before. Move the non-essential work to a later phase and go live on a smaller, tested footprint.