Your WMS Implementation Slipped Again. Everyone Says That's Normal.

Month Four

The go-live date has moved twice. Nobody has used the word failing.

What you have instead is a feeling. The questions coming from the vendor are getting more basic rather than less. Your own team is answering the same question differently depending on who gets asked. Somebody said "we'll handle that in a workaround for now" and nobody wrote down what the workaround was.

So the question you actually want answered isn't whether this is failing. It's whether this is normal.

Every implementation has a stretch that feels exactly like this, which is precisely what makes the question impossible to answer from inside one.

Everyone You Can Ask Is Answering a Different Question

You ask the vendor. They tell you this is normal at this stage, and they are not lying to you. Slippage at this stage really is normal.

But notice what answering otherwise would cost them. "No, this isn't normal" reopens scope, and reopening scope starts a conversation about who pays for the difference. They are giving you an honest answer to a question that has a price attached.

You ask your internal sponsor, the person who championed the purchase. They hear the question as a referendum on their judgment, because it partly is.

You don't ask the floor, and the floor doesn't volunteer. A team struggling with an unfamiliar system generally assumes the struggle is their own fault.

Each of them gives you a straight answer to a question you didn't ask, and none of them is positioned to answer the one you did.

The Delivery Side Usually Knows First

There is one more seat in the room, and it has the clearest early view of any of them.

On the delivery side of these projects the shape of a problem shows up early, often in the first few weeks. Not as a missed milestone. As a pattern: a straightforward question that keeps not producing a straightforward answer, and a scope document that turns out to describe an operation nobody has actually observed.

The incentives around that seat all point away from saying so. The scoping conversation already happened. The statement of work is signed. Raising it isn't a status update, it's a claim that the scope was wrong, and that is a commercial conversation rather than a project one. So it gets logged as a risk, managed, and worked around.

The people with the earliest clear view of the problem have the least standing to name it, which is why it reaches you as a schedule item instead of a verdict.

The Signal Isn't the Slipped Date

Dates slip on healthy projects. Watching the timeline tells you less than it seems to.

The signal worth watching is the one that looks like a communication problem. A simple question from the vendor produces no answer, or produces two answers from two people who both know the operation well.

Those questions are requirements. They are being asked now because they were never answered earlier, and the reason nobody can answer them consistently is that the answer was never a documented fact. It was tribal knowledge, and tribal knowledge disagrees with itself the moment you write it down.

If you arrived here from an ERP warehouse module that was presumed adequate because it was already paid for, there may have been no evaluation to leave undone in the first place. All of the discovery is arriving at once, during configuration, priced as change orders.

A missed date tells you the plan was optimistic. Contradictory answers tell you the plan was built against a picture of your operation that nobody had ever written down.

Which Failure This Is

Once you stop asking whether this is normal, a better question replaces it: which kind of problem is this? There are three, and from month four they look identical.

→ A configuration gap. The system is right, and it was configured against an inaccurate picture of the operation.
→ A readiness gap. The system is right, and the operation cannot yet receive what it delivers.
→ A fit gap. The system structurally cannot do what the operation needs, and no amount of configuration reaches that.

They share a set of symptoms and almost nothing else. What each one costs, who has to do the work, and whether that work happens inside the implementation or inside the operation differ completely. The FAQ takes both of those apart: whether a failed implementation can be saved, and how to tell which kind of failure you're looking at.

The instinct in month four is to push harder, and pushing harder is the one response that works for none of the three.

What separated the recoveries from the write-offs, in the ones I watched, was when somebody stopped asking whether the vendor was performing and started asking whether anyone had ever written down what the system was supposed to encode.

That question was answerable before any of this started. It stays answerable now. It just costs more.

If it turns out to be the third one, what follows is a selection, and the only thing that matters then is not running the same process that produced this one. Fullstride doesn't rescue implementations. The System Fit Sprint is built for the decision after this one.