Every WMS proposal I have read is precise about money and vague about time. It will tell you the license cost to the dollar and the consulting estimate in hours, and then somewhere in the assumptions there is a line about client resources being available as needed.
That line is the largest number in the document. Nobody prices it.
Roughly what it takes
For a single site, small to mid sized warehouse, a straightforward implementation on a modern system, the internal effort I plan for is 400 to 700 hours across six to nine months.
That number moves. Multiple buildings, heavy customization, a parallel ERP upgrade, or serial and lot tracking you have never done before will push it well past a thousand. A very clean project with good data and a vendor who has done your industry fifty times can come in under 300.
Where the hours go, roughly:
- Requirements and selection, 60 to 120 hours. Site walks, writing down how you actually work, demos, reference calls, scoring.
- Data cleanup, 80 to 200 hours. Item master, units of measure, dimensions, location naming, open orders. This is the one that surprises people. It is also the one that gets deferred, and deferring it just moves the hours to a worse week.
- Design and configuration reviews, 60 to 100 hours. The vendor configures, you decide. Every decision needs somebody who knows why you do it that way.
- Testing, 80 to 150 hours. Real testing, with your data, running your weird orders, not a scripted demo.
- Training, 40 to 100 hours of delivery plus the time your people spend in it.
- Go live and stabilization, 60 to 120 hours, concentrated into about three weeks where a couple of people will not be doing their normal jobs at all.
Add them up and it is most of a full time position for most of a year, spread across people who already have jobs.
The problem is not the total, it is the distribution
If those hours were spread evenly you could absorb them. They are not. They land on a small number of people, and they are the same people who keep the warehouse running.
Every project needs someone who knows why the process is the way it is. Not the org chart answer. The person who knows that the West rack holds returns because the returns desk used to be over there, and that customer 3300 gets their labels a specific way because of an argument in 2019.
That person is usually your best supervisor or your inventory control lead. They are also the person you cannot spare. So they take the project on top of a full week, and around month four the project slows down, and the vendor's status report starts saying "awaiting client input" every week.
I have seen that stall kill more implementations than any software shortcoming.
What to do about it
Name the internal lead, then take work off their plate in writing. Not "as needed" involvement. A specific percentage, and a specific list of what they stop doing. Twenty five percent for most of the project and closer to full time for the six weeks around go live is a realistic shape.
Backfill at the bottom, not the top. You cannot hire a temp to be your inventory control lead. You can hire a temp to cover receiving so the person who normally covers receiving can step up and free your lead. Backfilling one level down works and costs a fraction of what people expect.
Give data cleanup its own owner and its own start date. It is not project work in the sense that it depends on the vendor. You can start it before you have even chosen a system, because clean units of measure and consistent location names are good regardless of what you buy. Starting cleanup during selection is the single best schedule move available to you.
Put testing in the calendar as blocked time. Testing is the first thing sacrificed when the project runs late, and it is the reason go lives go badly. If it is not on someone's calendar as an appointment, it will happen in the last week as a formality.
Assume reduced throughput for two to four weeks after go live. Everyone is slower on a new system. Plan for eighty percent of normal output, tell sales, and if you have a seasonal peak do not go live within six weeks of it. Warehouses that skip this step end up firefighting a shipping backlog while also learning new software, and the software gets blamed.
Questions worth asking a vendor
Ask them, in the sales cycle, how many hours of your team's time their estimate assumes. Ask for it by phase and by role. A vendor who has run real projects will have a number and will not mind giving it. One who says it varies by client and moves on is telling you something.
Then ask what happens when your team falls behind. Some vendors will do more of the data work for a fee, which is often money well spent. Others will simply wait, billing nothing and delivering nothing, while the schedule stretches.
Ask about a stabilization period after go live too. A week of on site support is a very different thing from two days of remote availability, and the gap between those shows up on the worst possible Monday.
The version I actually believe
Most WMS projects that fail do not fail because someone bought the wrong system. Feature gaps are visible in a demo and negotiable in a contract.
They fail because the internal cost was never budgeted, so it got absorbed by three people who were already at capacity, and by month five nobody had the hours to make good decisions. The software then went live half configured against dirty data, and the warehouse concluded the system was bad.
The system was fine. The staffing plan was the thing nobody wrote down.