Most of the ERP projects I have been brought into mid-flight were not failing for technical reasons. The software worked. The servers were fine. What had broken down was something harder to put in a status report: the connection between what the business thought it was getting and what was actually being built.

That gap rarely announces itself early. It shows up at user acceptance testing, when someone from finance opens a screen and says the words that stop a project cold — "this isn't how we do it." By then the budget is largely spent and the go-live date is close enough to be political.

Failure is usually late, not sudden

A troubled implementation almost never goes wrong in the week it becomes obvious. The decisions that caused the trouble were made months earlier, and they were usually reasonable-looking at the time.

The most common pattern I see: requirements were gathered from managers rather than from the people who actually do the work. Managers describe the process as it is documented. The people doing it describe the process as it exists, complete with the workarounds, the exceptions, and the one customer who gets invoiced differently for historical reasons nobody remembers. Build to the documented process and you produce a system that is technically correct and operationally useless.

The second pattern is scope that was never really agreed to — only deferred. Every hard question gets pushed to "phase two," and phase two quietly accumulates everything that makes the system actually work for the business.

The first move is not technical

When I come into a project that is in trouble, the instinct from the team is usually to start listing defects. That list matters, but it is not where recovery starts.

Recovery starts with an honest assessment of where the project actually is, delivered to the people paying for it in plain language. Not a red-yellow-green dashboard. An actual accounting: what is built and working, what is built and wrong, what was never started, and what it will take to close each gap.

This conversation is uncomfortable, and it is the one thing that cannot be skipped. Projects stay in trouble largely because nobody wants to be the person who says the date is not achievable. Until someone does, every subsequent decision is made against a plan everyone privately knows is fiction.

Then: separate the essential from the accumulated

Once there is an honest baseline, the work becomes triage. In my experience the requirements list on a troubled project contains three distinct things:

  • What the business genuinely cannot operate without. Usually a much shorter list than anyone expects — order to cash, procure to pay, the close, and whatever is specific to how this company makes money.
  • What people asked for because the old system did it that way. Some of this is legitimate. A lot of it is preserved habit, and rebuilding it faithfully in a new system is how organizations spend a modernization budget to end up exactly where they started.
  • What got added because the project was already open. Every long implementation attracts adjacent requests. They are rarely unreasonable individually and they are almost always the difference between a project that lands and one that does not.

Cutting the third category is straightforward. Cutting the second requires someone senior enough to say no and credible enough that the business accepts it.

Rebuilding trust is part of the work

The part that gets underestimated is the human one. By the time a project is visibly troubled, the business has usually stopped believing the project team. Users have been asked to test something that was not ready. Finance has been told a date that moved. That skepticism does not reset because a new plan was published.

The only thing I have found that repairs it is a short cycle of small, visible commitments that get met. Not a revised master schedule — a two-week promise, delivered. Then another. Trust rebuilds at roughly the rate you demonstrate that your word is good, and that pace cannot be accelerated by a steering committee.

What prevents the next one

Recovery work is expensive, disruptive, and largely avoidable. Nearly every troubled project I have seen shared two conditions: the people who understood the actual business process were not in the room during design, and there was no one on the engagement senior enough to say an uncomfortable thing to an executive.

Those are not technology problems, which is precisely why they survive so many technology-focused project reviews. Solve for them at the start and the implementation itself becomes a far more ordinary exercise.

Across more than 50 NetSuite implementations, the projects that went smoothly were not the ones with the best tooling. They were the ones where somebody experienced stayed close enough to the work to notice a problem while it was still small.