ERP projects rarely succeed or fail on the software. The same system runs beautifully at one company and is abandoned for spreadsheets at another within three months. The difference is rarely features — it is whether "the human side" is managed as part of the project. Stage by stage:
Diagnose: hear the silent objection
The most dangerous signal in discovery interviews is not open opposition — it is polite silence: "all good", "whatever the experts say". Once the system changes daily work, silence turns into passive use.
- Symptom: one role always "has no opinion" and never joins the discussion;
- How we work: ask about operating detail, not conclusions — "that order last week: from receiving it to finishing it, how many people and how many forms did it pass through?" Detail cannot bluff, and the real pain surfaces on its own. Walking through each role's "ordinary day" beats asking "what do you need".
Design: get the business owner to sign
The judge of a design is not the consultant — it is the business owner. The biggest risk here is the illusion of consensus: the consultant writes what they understood, the business nods without reading closely.
- Symptom: nobody asks anything in the review; after go-live, "this is not what we agreed" everywhere;
- How we work: review line by line — especially the exceptions (how returns land, who approves beyond limits, how legacy data counts). What gets confirmed is not "is the design good" but "this is what we will do from now on". Consensus goes on paper, attached to a person.
Build: grow your key users
Before the system is configured, someone needs to stand on the business side while understanding the system side. Key users are the translators between those worlds — without them, every question lands on the consultant: slow, and distorted in transit.
- Symptom: every small question waits for the consultant; key users relay but cannot judge;
- How we work: each major department appoints one or two key users who join configuration and testing hands-on — not observing, but running the cases themselves. By go-live they can answer eighty percent of their team's questions, and "everything stops when the consultant is away" never happens.
Go live: keep the dual-run short and watched
Switches usually come with a period where old and new run in parallel. That parallelism is a safety net — and itself the biggest risk: two sets of books diverge over time, and everyone drifts back to the more familiar one.
- Symptom: the parallel period stretches; "check in the new system, work in the old way" becomes normal;
- How we work: the plan fixes the exit condition (say, two consecutive closing cycles reconciling), and the switch happens on schedule; the cut-over week has dedicated staff on site or online, triaging same-day — unfamiliarity, data mismatch or a process gap, each handled as itself. No problem spends a night unresolved.
Operate: treat workarounds as signals
Go-live is not the finish line. The moment the team starts bypassing the system with offline patches is the signal that matters most.
- Symptom: one process quietly runs offline; the system only receives back-fill;
- How we work: reviews ask directly "where are we still offline", then classify each: the system genuinely missed it (add scope), it is too clunky (improve it), or the process itself should go (rework the process). Workarounds are not employee failure — they are evidence the system or the process has not arrived yet.
Takeaways
Manage people as part of the project — hear the silent objection in discovery, sign real consensus in design, grow your own key users, give the dual-run a deadline, and track workarounds in operations — and the software side becomes the easy part. Systems land not through feature lists but by making every person involved able to answer: why is this changing, what will it look like, and what does it mean for my ordinary day.