Why do technically sound ERP projects still fail with their users?

Before the shortlist, not at go-live. The stakeholder and impact analysis belongs in the selection phase: it shapes requirements, surfaces resistance early and identifies the key users who will later carry the system. From our experience, programmes that bolt change work on after contract signing pay for it twice — once in the delay, once in the adoption.

Often, partly — and we encourage it. Internal people know the culture, the informal networks and the history. What an external partner adds is pattern recognition from comparable programmes, a mandate that does not depend on internal hierarchies, and the discipline of measurement. In practice, the strongest set-up is a joint one: your people carry the messages, we carry the method.

Against criteria agreed before go-live, not by gut feel afterwards. Typical measures: system usage on defined core transactions, data quality at the points where daily work meets the new processes, key-user readiness per department, and structured acceptance feedback at fixed intervals. The read-out goes to the steering committee — adoption is a programme metric, not an HR side note.

It depends on the depth of the process change, the number of affected roles and locations, and how much of the work your own team carries. We scope the change workstream in the first conversation and work in fixed stages with explicit go/no-go gates — you always know the effort of the next stage before committing to it.

Training is one instrument inside change management, not a substitute for it. A training plan teaches people how the new system works; the change workstream makes sure roles, responsibilities and daily routines are redesigned so the training lands on prepared ground. Key users sit at the centre of both: we build the key-user programme first, and the training plan follows from it.

The productivity dip after go-live gets deeper and lasts longer — that is the consistent pattern in our projects, and it rarely shows up in the project plan. Without early stakeholder work, the same issues surface later as support tickets, workarounds and data-quality problems, and they are harder to fix once routines have hardened around them. The system can be technically sound and the business case still slips, because the benefit sits in changed daily work, not in the software.

Training transfers system knowledge — necessary, but it is one artifact of five. Change management manages what happens around it: who is affected and how deeply, what is communicated when, where resistance builds, and whether adoption actually happens against agreed criteria. A training provider delivers courses; the change workstream decides who needs which course, when it lands, and measures whether it worked.