Two causes account for half of the 41 stalled implementations in our sample: requirements that never settled (31%) and no internal owner with the authority to decide (19%). The sample and its bias are described on the failure-modes page — it is small and skewed toward severe cases. What follows is not a finding from it, it is what we changed in how we run engagements because of it.
Both causes get described, afterwards, as a people problem. The sponsor was too busy. The department heads could not agree. Someone kept reopening settled questions. That description is comfortable because it implies the next project will be fine with better people, and it is almost always wrong. Most of what looks like a people problem is actually a gap in project governance — nobody assigned the decision a deadline.
The actual mechanism
A stalled decision is rarely a decision someone refused to make. It is a decision nobody knew they owned, arriving without a deadline, in a form that made "let us discuss it next week" the only safe answer. Left alone, that gap compounds; a functioning decision log is the cheapest fix in ERP implementation governance.
Watch what a reopened requirement actually looks like. Someone in week fourteen says the returns process cannot work the way it was designed. They are usually right. The design was agreed in week five by people who had not yet seen a returned item flow through a screen, and the agreement was recorded as a tick in a document rather than as a choice between named alternatives with a stated cost.
A requirement that was never framed as a choice cannot be reopened, because it was never closed. It was only written down.
Three things that changed for us
None of these are novel. They are the ones that survived contact with projects that were already going badly.
- Every open question carries a name, a date and a default. The default is what happens if the date passes with no answer, it is written down in advance, and it is usually the standard behaviour of the software. This converts an indefinite stall into a decision someone has to actively prevent.
- Decisions are recorded as the option chosen and the options rejected. One paragraph each. When the returns process comes back in week fourteen, the conversation starts from what was already known and rejected rather than from nothing, and the reopening is either quick or justified.
- One person can say yes without convening anybody. Not a steering committee — a person. Where the organisation genuinely cannot appoint one, the project should not start, and saying so out loud early is cheaper than discovering it in month five.
Where this argument is weak
It is downstream of the thing that actually matters, which is whether the sponsor has real authority. A decision log with dates and defaults will not manufacture authority that does not exist; it will only make its absence visible faster. In the projects in our sample where ownership was the primary cause, the escalation path existed on a slide and had never been used. No amount of change management process substitutes for a sponsor who can actually say yes.
It also assumes the defaults are safe. A default of "standard behaviour" is only reasonable if someone has checked what the standard behaviour does to the month-end close, which is a real piece of work and not a formality.
The uncomfortable version
Most of the schedule risk in an implementation is not in the software and not in the data. It is in a queue of unmade decisions that no one is measuring, and it is invisible until it is expressed as a date slipping.
If you want a single instrument, count the open questions weekly and plot the count. A project where that number is flat or rising after the design phase is a project that is going to be late, and it is going to be late for reasons that have nothing to do with the product anyone selected.
Our own view of what a small delivery team changes about this — including the parts that are worse — is on the team page. Track the open-question count the way you would track any other source of ERP project delays, and the schedule stops being a surprise.
Decision paralysis is one failure mode from the same 41-project sample; bad data discovered during the load is another, and it fails on the identical clock — too late to absorb. Once a system is live, the discipline question shifts to what an agent can be trusted to decide unsupervised inside a ledger, and whether closing faster is a staffing problem or a reconciliation one. And before any of it, the reference calls that would have told you which of these problems a given vendor’s customers actually hit.
Some of the biggest undecided items we see are structural rather than personal: whether the chart of accounts gets redesigned or just copied over, what happens at cutover if the numbers do not reconcile, who is allowed to add a custom field without anyone signing off on it, and how a group close gets designed before the first subsidiary is even migrated. Each one is a decision hiding as a task.