When to walk away from an ERP project mid-implementation.

Most failed ERP projects keep going. Not because they should. Because nobody in the room has the authority to stop them.

I’ve sat in rooms where everybody knew. The CIO knew. The CFO knew. The project sponsor knew. The implementation lead absolutely knew. And the project kept going for another nine months, then another six, then another quarter, until the company finally rolled back to the old system or limped into a half-broken go-live that took two more years to recover from.

Stopping a failing ERP project is one of the hardest organizational moves there is. Continuing one is one of the most expensive.

Why projects fail to fail

The economics of stopping a project should be straightforward. If continuing costs more than recovering, stop. Most companies can’t actually run that math, because the political weight on each side of the calculation isn’t equal.

Sunk-cost reasoning. “We’ve already spent $X.” Money already spent is irrelevant to the decision in front of you. Everyone knows this. Almost nobody acts on it when their own budget is the X.

Career risk. The executive who approved the project doesn’t want to be the executive who killed it. Killing it is harder than continuing it, even if continuing it is more expensive. The cost of continuing is paid in budget. The cost of stopping is paid in career.

Vendor and partner incentive. The vendor is billing license. The implementation partner is billing hours. Neither one benefits from stopping. Both will explain, with charts, why the next milestone is the corner.

Internal team identity. The project team has been on this for a year. Their identity is tied to delivery. Asking them whether the project is failing is asking them whether they’re failing. Most won’t answer that question honestly, even to themselves.

The bag-holding question. “Who explains this to the board?” The honest answer is the same person who would have to explain a 14-month overrun anyway, except now it’s a smaller number with a clearer story. The political instinct is to wait, hope it improves, and explain less.

Warning signs that mean stop

The hard distinction is between stuck and failing. Every project gets stuck. Most stuck projects recover. Failing projects are recognizable, if you’re willing to recognize them.

• Three consecutive go-live date slips. Once is normal. Twice is a worry. Three times means the people setting dates can’t see the work clearly.
• Power users opting out. The people who know the business best are quietly shifting back to the old system, the spreadsheets, the workaround. They’re not arguing. They’re just doing their jobs in spite of you.
• Implementation partner changing senior leads twice in six months. The partner sees what you see. They’re trying to get a senior in who can fix it. Each replacement loses the context the previous one built. Two replacements is the partner running out of options.
• Critical processes still in workaround at 80 percent configuration. If your close process still requires three Excel exports and a manual journal at the point where the system is supposed to be 80 percent done, the system is not 80 percent done.
• Custom code volume exceeding initial scope by 3x or more. Custom code is debt. The original scope estimated how much you could carry. 3x means you’re past that estimate, you’re still adding, and nobody’s revisited what it costs to maintain.
• Daily standups that have stopped surfacing real issues. Standups that turn into status reports are standups where the team has decided that surfacing problems isn’t safe.
• Loss of the original sponsor. The executive who championed the project got promoted, left, or moved to another role. Nobody stepped into the role with the same authority. The project is now organizationally orphaned, which means there’s nobody with the standing to make the hard calls.

One or two of these can be managed. Three or four together is a project in failure mode, regardless of what the dashboards say.

The economics of stopping

The math nobody runs: every additional month inside a failing project costs more than the recovery alternative. Not always. But often enough that the question deserves an honest look.

Continuing means: more partner hours, more internal team time, more opportunity cost on day jobs, more shadow systems entrenching, more workarounds calcifying into “how we do it,” more goodwill burned with users who’ve been promised three go-live dates that didn’t happen.

Recovering means: writing off the partner contract, swallowing the schedule loss, salvaging what you can (cleansed data, mapped accounts, documented gaps), and either restarting with a different partner or rolling back to the legacy system while you regroup.

Recovery is a known cost. Continuing is an unknown one. People prefer the unknown because the known feels worse, even when the unknown is bigger.

How to actually stop

Stopping doesn’t happen by announcement. It happens by structured pause.

Frame it as “pause and reassess,” not “kill.” The political room for a 30-day pause is much larger than the room for a permanent stop. Most pauses end in restart with a different plan, a different partner, or a different scope. Some end in graceful retirement. Either way, you bought time to make the decision properly.

Get a third party to write the recovery memo. The vendor can’t. The implementation partner can’t. The internal team can’t. Somebody who has nothing to lose by being honest needs to write down the current state, the realistic options, and the cost of each one.

Identify what to keep. Not everything is wasted. Cleansed data, mapped chart of accounts, documented gap list, change-control discipline, integration architecture decisions. Catalog what survives the pause so the restart isn’t starting over.

Plan the rollback. If the legacy system is still running, what does it take to keep it running for six more months? If it’s already partially decommissioned, what does it take to bring it back? You need this plan whether or not you actually use it. Having it removes the “but we have nowhere to go” argument.

Time-box the decision. 30 days. At the end of 30 days, you either resume with a new plan that addresses the recovery memo, or you formally close the project and start fresh. Open-ended pauses become open-ended drift.

What you preserve, even when stopping

The point of stopping isn’t the satisfaction of stopping. It’s what you keep that you couldn’t keep by continuing.

• Real cost of the current state, knowable now instead of in another nine months
• An honest gap list, the real one, not the kickoff one
• Lessons that the next selection round can use
• Trust with the team, who would rather be told the truth than asked to keep pretending
• A finance team that hasn’t spent another two quarters reconciling between two systems
• Selection lessons for next time. See The ERP demo is theater and The integration tax for what the next round should look like.

Stopping a failing project is a leadership move. Continuing one to save face is the actual failure.