Failed implementations rarely fail for exotic reasons. The same handful of causes appear again and again, and each has a known countermeasure.
Cause 1 — Data was treated as a task
Countermeasure: make data a workstream with an owner, a schedule and a validation method before configuration begins.
Cause 2 — No defined planning process
Software was configured to mirror an undocumented, inconsistent process. Countermeasure: define the intended process first and configure to it.
Cause 3 — Scope expanded during the project
Countermeasure: freeze scope at kickoff, log every request as phase two, and hold the line publicly.
Cause 4 — Training taught screens, not logic
Planners who do not understand netting, lead-time offsets and order policy cannot judge an exception message. Countermeasure: teach the logic, then the software.
Cause 5 — Nobody owned it after go-live
Countermeasure: name a system owner with authority over data standards and a standing exception review before cutover, not after.
Cause 6 — Shadow spreadsheets survived
If the old workbook still runs the plant a month after go-live, the implementation has already failed quietly. Countermeasure: retire specific spreadsheets by name, with dates.