Requirements never settled
The largest cause at 31%. Scope kept moving because nobody could decide, and each new discovery reopened decisions that had been treated as closed. This is a governance failure, not an analysis failure.
Research · updated August 2026
We are called into stalled ERP implementations regularly, which gives us an unusual view: not of projects that succeeded, but of the ones that did not, with enough access to establish why rather than to accept the explanation already agreed on.
Tell us where the project is and what has slipped. We will tell you honestly whether it is recoverable.
Primary cause only. Most projects had several contributing factors; this counts the one without which the project would not have stalled.
What we found
The distribution is stable across company sizes and across vendors, which suggests these are properties of how ERP projects are run rather than of any particular product.
The largest cause at 31%. Scope kept moving because nobody could decide, and each new discovery reopened decisions that had been treated as closed. This is a governance failure, not an analysis failure.
24%, and almost always discovered during load rather than during diagnostic. Nobody looked properly before committing, because looking properly is unglamorous and takes a week.
19%. A project sponsor who cannot decide is a bottleneck with a title. Decisions escalated, stalled, and were eventually made by whoever had least context.
14%. Every gap closed with a script rather than a decision. Each individual customisation was defensible and the accumulation made the system unmaintainable.
8%. The team that sold the project was not the team that delivered it, or rotated mid-way. Usually visible in advance if anyone asks who specifically will be assigned.
4%. The rarest cause and the most commonly blamed after the fact, because it is the explanation that assigns responsibility outside the building. It is also nearly always knowable in week one.
Add the first three causes together and you get 74% of stalled projects failing for reasons that existed before any software was configured: unsettled requirements, unexamined data, and no one with authority to decide.
That is uncomfortable because it means the implementation partner is rarely the primary cause, and it means changing vendors after a failure addresses about a quarter of the actual risk. Restarting the same motion with a different logo is the most common response we see and the least effective.
Requirements do not fail because nobody wrote them. They fail because they were written from interviews rather than derived from transactions, so they describe what people believe they do rather than what the data shows they do.
The divergence surfaces during configuration, as a series of small surprises that each reopen a settled decision. By the fourth or fifth of those, the schedule has absorbed all its slack and the project is in the pattern that ends in a stall.
Every implementation methodology includes a data assessment phase. In practice it is frequently a questionnaire rather than an examination, because examining the data properly requires access, a week, and somebody willing to report bad news before a contract is signed.
The specific findings recur: duplicate rates above eight percent in customers or vendors, historical transactions with no dimension data, periods that do not balance, and a chart of accounts with several hundred accounts that have not been used in three years. None of these are exotic and all of them are cheap to find in advance.
The 19% failing on internal ownership is not about disengaged executives. It is about sponsors who attend every steering meeting and cannot unilaterally decide whether the approval threshold should be $10,000 or $25,000, because that decision touches three departments.
A project needs someone who can make cross-departmental decisions in a day rather than in a fortnight. Where that person does not exist, the decisions queue, and the queue is what eventually stops the project.
Of the 41, we recovered 27 to a working state. In almost all of them the recovery started the same way: stop configuration entirely, fix the data, settle the requirements against actual transactions, and name a decision-maker with real authority. Only then resume.
The average recovery took eleven weeks. The ones that took longest were those where the organisation wanted to resume configuration immediately, because it feels like progress and it rebuilds on the same foundation that failed.
Forty-one stalled or failed deployments we were brought into between January 2024 and June 2026. Stalled is defined as a project that missed its go-live by more than 100% of the original schedule, or was abandoned.
Primary cause is our assessment after access to the project record, the data, and interviews with the internal team — not the cause recorded in the project post-mortem, which in our experience differs substantially and skews toward the software and the partner.
The sample is self-selecting in an obvious way: these are projects that went badly enough that somebody called an outside party. It over-represents severe failures and tells you nothing about the base rate of success. It is also small, and covers a range of vendors rather than any one.
The 70% business-case figure quoted in our stats is from published industry research rather than from this sample, and it measures a different thing — missing the business case rather than stalling.
Questions
Data examined, requirements derived from transactions, and a decision-maker named. That is the whole prescription.