You Don't Get a Mulligan: How to Choose the Firm That Will Implement Your ERP

Most companies spend months evaluating ERP software and a few weeks evaluating the firm that will implement it.

Then they are surprised when the implementation goes sideways.

I have sat on every side of this one. I led the NetSuite selection and implementation as the Controller of a SaaS business preparing to go public — we were cranking out more than 20,000 invoices a month in QuickBooks and the system was breaking under the weight. After that company was acquired, I helped lead an SAP S/4HANA Cloud implementation inside a very large enterprise, where we paid premium hourly rates for consultants from a Big Four firm, most of them fresh out of college with no real-world experience in complex business operations. I sat there thinking: there has got to be a better way.

Now I run the kind of firm that gets hired to do this work. So I also know exactly what the sales side sounds like.

The software is not the variable

I get called in after things have gone wrong, and it is almost never because the software could not do the thing.

It is because a poorly designed workflow got carried forward unchanged, and the client is now locked into the same inefficiency on a more expensive platform. It is because reporting still requires spreadsheet gymnastics, so finance keeps a shadow version of the books in Excel. It is because nobody designed the handoff from quoting to billing, so people are still swiveling between systems, retyping the same order three times.

Those are design decisions. Design decisions are made by people, not by software.

Which is why the evaluation you should be running longest is the one most buyers run shortest.

Did the people who sold it also deliver it?

Take references seriously, and do not accept the reference call as a satisfaction survey.

Talk to their clients. Ask how they actually worked together. Ask whether the team that sold the project was the team that delivered it — this is the single most useful question in the entire process, and almost nobody asks it. Ask whether they felt like a partner or a number. And ask how supported they were once the system was live and the real work began.

Then ask the reference for the name of the consultant who did the work. Then ask the firm whether that person is available for you.

The answer to that second question tells you more than the proposal does.

Who is actually on your team

Big consulting firms will sell you junior consultants at senior rates. That is not a slur, it is a business model: leverage. The partner sells, the analyst delivers, and the rate card is set so the arithmetic works out.

Sometimes that is fine. On a complex ERP implementation, it usually isn’t.

So ask for names, years, and specifics. How many people on this proposed team have fifteen-plus years of ERP implementation experience? Has anyone on this team ever closed a month-end? Has anyone lived through an audit on the receiving end? Are they going to design a solution around my business, or force my business to conform to their preferred methodology?

Here is what that experience actually buys you. We worked with a company whose internal team had spent months building an integration between their operational system and NetSuite. At go-live, everything failed. They were sending vendor bills before the vendors existed in NetSuite — and the ERP rejected every single transaction, because it could not match a vendor reference. Master data is the relatively static reference data a transaction depends on: customers, vendors, items, the chart of accounts. If the master record isn’t there, the transaction has nothing to attach to.

Months of work, dead on arrival, because the steps were done in the wrong order.

Sync the vendors. Run the approvals. Then sync the vendor bills, with the GL segments populated. Set up monitors so you catch drift before finance does.

Nobody who has done this twice makes that mistake. That is what you are buying.

What assumptions is this quote built on?

Years ago I walked an incoming executive through the SAP program I was leading. I told him what we were building, what the system would do, how it would transform the business. His advice was three words: don’t over-promise.

I brushed it off at the time. He was right.

Some firms sell simplicity to win the deal, and the buyer pays for that fiction in change requests — a change order being the formal amendment to your statement of work that adds scope, adds hours, and adds cost after you have already signed. The pattern is completely predictable. The cheapest plan is rarely the most predictable one.

So read the quote for what is written down, not for the number at the bottom.

A serious proposal spells out its assumptions explicitly: this assumes X, this is contingent on Y, if Z changes the scope changes. It gives you a range of expected hours rather than a single confident figure, because nobody truly knows the full effort required until design is complete — and plenty of companies keep refining requirements right up until go-live, sometimes against our best advice. It says out loud who is responsible for data cleanup, who writes the test scripts, and how many entities and integrations are in scope.

Ask a contractor to quote a renovation on an old building and the honest ones price the unknown, because no one knows what is behind the wall until it is opened. The dishonest ones quote the visible work and invoice the rest.

You don’t control cost by believing the quote — you control it by understanding the risk.

The most overlooked phase is the one after go-live

Ask what happens the Monday after launch.

Because the launch is not the hard part. A company goes live on time and on budget, everyone celebrates, and then real life kicks in. Where’s the report I used to pull? How do I track a mid-term contract change? Why is this invoice showing the wrong term? That week is where adoption is won or lost, and it is the week that never appears in the sales deck.

So get specific. Who supports us after go-live? Is it the same people, or are we handed to a queue? Is the relationship nothing but tickets and time-and-materials, or does someone proactively look at our system and tell us what to fix next?

Clients hate set-it-and-forget-it vendors — the ones who finish the build and drop into maintenance mode. Vendors coast. Partners lean in.

And be suspicious of anyone selling you a finish line. Six months and done is how transformations get oversold to a CEO. Six months becomes a year, the system still needs care afterward, and nobody budgeted for that much change management.

Can we start small?

You do not have to go all in on day one.

Phase it. Build the core first — a clean data model, the foundational processes, solid integrations between the systems that actually matter — and get the debits and credits right before layering on advanced billing logic and custom reporting. Trying to do it all at once is how projects run over budget and clients end up frustrated.

That sequencing is good project design. It is also a test. A firm that is confident in its people will happily say: start with a focused engagement, evaluate the results, expand when you’re ready. A firm that needs the whole contract signed on day one is telling you something about its pipeline, not about your project.

Are you the kind of client this firm is built for?

The last question is the one no firm will volunteer.

Boutique firms chase white whales — big projects outside their usual industry or scope that look incredible on paper. I have done it. We lost most of them, and in hindsight losing was usually a blessing, because those pursuits pulled our focus off the clients who built the business. My mother’s advice on this is better than anything I have read: dance with the one who brung ya.

The reason it matters to you as a buyer is simple. When a firm takes on a project well outside its range, it has to staff that project by pulling people from somewhere. That somewhere is its existing clients. You do not want to be the white whale, and you do not want to be the account that got quietly deprioritized to feed one.

The flip side is what a good firm owes you before you sign: the truth. I have told a prospect to go look at a different billing tool than the one he had already done weeks of prep work to adopt, because it was not going to meet his needs. I have told companies they were not ready. One called us wanting to overhaul their ERP — two executives pushing hard, the rest of the leadership team unable to agree on whether to spend the money or where to start. Six months later that disagreement still has them frozen.

Wanting a new system and being ready for one are two different things. A firm that will not say that to you before the contract is signed will not say the hard things afterward either.

No redo

In golf you can call a mulligan. On an ERP you cannot. There is no restart, no let’s-just-try-that-again — once you are live, you are living in whatever you built, and the cost of unwinding it dwarfs the cost of choosing well.

So spend the time where the risk actually is.

Evaluate the software until you are satisfied it fits. Then evaluate the firm harder than you evaluated the software. Ask who sold it and who will deliver it. Ask what the quote assumes. Ask what happens after go-live. Ask to start small.

Make them answer in writing.