Why do WMS implementations run late?

The steering committee wants to know why. A WMS implementation overrun becomes visible in the test phase, but it does not originate there. It originates months earlier, in a meeting where someone said: we will pick that up during testing. Nobody flinched. It was not on the risk list. It was just a sentence.

And we all know that start. The design is sound. The business case holds. Green light. But green in a test environment means the system agrees with itself. Not with the floor.

What I see in practice: an implementation does not run late because the work takes longer than estimated. It runs late because decisions that belonged early get made late. And late is more expensive. Much more expensive.

In the concept and requirements phase you establish what the customer actually needs, and where that deviates from your standard. Every deviation is a gap. A gap you name is a choice: build it, configure around it, or decline it. A gap you do not name is not a choice. It is a surprise with a date attached, and that date falls in the test phase. Almost always.

The Customer Concept Document is the most important gate in the whole implementation. It is also the gate most easily made soft.

You recognise it immediately. The CCD is signed subject to final detailing. A discussion about labels is still open. Two order types are not worked out. The billing rules will follow. That is not a sign-off. That is a list of open decisions with a signature laid over it. And then configuration starts, on a foundation that is still moving.

Master data is almost everywhere the work that lands on someone without mandate and without time. Item master, customer master, shelf-life and allocation rules, labels, SSCC registration. It is a lot, it is dull, and it is exactly the kind of work that only proves wrong once you test against it. Test with incomplete data and you are not testing. You are confirming that the system starts up.

The same applies to the test plan itself. Most plans prove that one order runs cleanly through the process. Fine, that is day one. What you need to know is what happens at volume, at peaks, with a wrong sequence, a rejected pallet, an interface that stalls for twenty minutes. Capacity and sequencing tests belong in there, and interface tests with real message structures, not with a tidy sample file supplied by the vendor.

FAT proves the system meets the specification in a controlled environment. SIT proves the interfaces talk to each other. UAT proves users can execute the agreed process flows. Each phase is necessary. None of them automatically proves that the installed system agrees with the physical warehouse. That is what SAT, site acceptance, is meant to expose. A green UAT is not a proven SAT.

The classic example: the physical rack labels do not resolve cleanly to the locations in the WMS configuration. A small formatting mismatch. UAT never caught it, because UAT tested the system side, and the gap only shows when a real scanner reads a real label on go-live morning. A missing or mis-formatted location rule then stops being a data issue and becomes a queue of pallets at receiving.

Four things have to line up: the label on the rack, the scanner in the hand, the location in the WMS, and the actual slot on the floor. When they do not, pickers get errors, pallets wait, supervisors build workarounds, and consultants get pulled back in. The weeks that follow are called hypercare, even though part of that work is really acceptance testing that happened too late.

This is the quietest cause of overrun, and the most structural. IT, the MHE supplier and the operation are all working hard. All three assume someone else is pulling the interface. There is no name attached to it. There is a vendor name attached to it, and that is a different thing. At NewCold I learned that interface management is a role, not a document. Someone has to keep IT, MHE and the operation at the table until the messages are right. Not as a technical specialist, but as the person who places the ownership and does not let go of it.

The same void sits on the acceptance side. A WMS project has a project manager, key users, and a supplier. What is often missing is one operational owner who brings the standard process, the customer commitment, and the reality on the floor together, and who owns the physical acceptance, not just the functional sign-off.

Before go-live, one question is worth more than another green test report: who physically confirmed that the rack label resolves to the right WMS location, in the building, with the scanner, against the actual configuration? If there is no name attached to that check, you do not have acceptance. You have an assumption.

The go-live date is usually fixed. Contractually, commercially, or simply politically. So when time runs short, the date does not move. What moves is whatever still looks compressible. That is never the build. It is testing, training and transition: exactly the three things that decide whether your operation can run on day one. So you hit the date and lose the first quarter. The overrun does not disappear, it relocates. From the project plan into the operation, where it is no longer called overrun but teething problems.

On top of that sits a curve most plans ignore. They assume the productivity of an experienced team on a familiar system, from day one. It does not work that way. Pickers search. Planners doubt what the screen tells them. Every exception costs a conversation instead of a movement. Model that ramp-up before you enter it, and align your volume commitments, staffing and customer communication to it. If you do not, you hit the go-live date and then miss your service agreements. To the customer that is the same problem.

The best go-lives I have been part of were not exciting. There was a cutover runbook. There were names against WMS, WCS, controls, maintenance, operations, customer and escalation to the integrator. There was a hypercare roster with real people in it, not a mailbox. And a dry run had been done with production-like order profiles, so the team had already done it once. Heroics around a go-live are not a good sign. They usually mean something was not finished.

Are you in the middle of an implementation and can feel it starting to slip? Do not look at the schedule first. Look at your gap register. How many items are still open there that should have been decided before design freeze? And how many of those are waiting on a decision from someone who is not even in the project structure? That number is your real schedule.