My WMS implementation is failing. What do I do?

The triage questions are immediate and reasonable. Escalate to the vendor. Get an outside review. Pull in the implementation team's leadership. Document everything. Prepare for the possibility of a renegotiation, a contract dispute, or a write-off. Each of those has a place. But the question they all skip is the one that determines whether any of them is the right move: what kind of failure is this?

Most failing WMS implementations look similar from inside the failure. Timelines slip. Scope shifts. The vendor's explanations get less confident. The team's frustration builds. The founder is asked to make decisions about things — configuration trade-offs, customization scope, go-live readiness — that the founder doesn't have the context to decide well. The surface is roughly the same regardless of root cause. Underneath, three different failures tend to be running, and they require different responses.

The first is a configuration failure. The system that was selected can support the operation, but it has been configured against the wrong picture of what the operation needs. The workflows have been built around an inaccurate operational baseline. The integrations have been scoped against requirements that don't reflect the floor reality. This kind of failure is usually fixable — the system is the right system; what got built on it is wrong. The path forward involves rescoping configuration against an accurate operational picture, which usually means going back to the work that should have been done before the system was selected and doing it now, mid-implementation, under significantly worse conditions.

The second is a process failure. The system is right, the configuration is closer to right than wrong, but the operation hasn't done the people, process, and data work that implementation requires. The team isn't ready. The data isn't clean. The workflows haven't been updated to take advantage of what the new system does. The system is doing its job; the operation hasn't caught up to it. This is also usually fixable, but the fix isn't a system fix — it's an operational fix that the implementation team isn't structurally set up to drive. The founder usually has to lead it, and usually doesn't recognize that distinction in time.

The third is a selection failure. The system itself is wrong for the operation, and no amount of configuration or process work will close the gap. This is the failure that doesn't get better with more effort, because effort is being applied to a foundation that can't carry the operation regardless. Selection failures showing up downstream are the failure mode the implementation phase wasn't built to surface or solve — they originated upstream, in a process that produced a selection against an inaccurate operational picture or through a buyer-only frame that didn't expose the fit problems that are now visible at full cost. The path forward in this case is structurally different from the other two: more effort on the current system is good money after bad, and the real question becomes whether the implementation can be paused, whether the contract can be unwound, and whether the next selection — if there is one — gets done differently.

Which failure the implementation is in determines almost everything about what to do next. Configuration failures get rescoped. Process failures get operationally led. Selection failures get exited, on the best terms available. The triage moves — escalation, outside review, documentation — are useful in all three cases, but they don't substitute for the diagnosis. The diagnosis is what tells the founder whether they're trying to fix the right thing.

Most founders living a failing implementation are in the middle of it without having yet asked the diagnostic question. The failure itself is consuming the attention that the question requires.