Every WMS proposal I've read is precise about money and vague about time. It gives you the license to the dollar and the consulting estimate in hours, and somewhere in the assumptions there's a line about client resources being available as needed.

That line is the biggest number in the document, and nobody prices it.

The hours

For one small-to-midsize site on a modern system, a straightforward implementation takes 400 to 700 hours of your people's time over six to nine months. Multiple buildings, heavy customization, a parallel ERP upgrade or first-time lot tracking will push it past a thousand. A very clean project with good data and a vendor who's done your industry fifty times can come in under 300.

Roughly where they go:

  • Requirements and selection: 60 to 120 hours
  • Data cleanup (item master, units of measure, dimensions, location names, open orders): 80 to 200 hours
  • Design and configuration reviews: 60 to 100 hours
  • Testing with your data and your weird orders: 80 to 150 hours
  • Training, plus your people's time in it: 40 to 100 hours
  • Go-live and stabilization, mostly in about three weeks: 60 to 120 hours

Data cleanup is the one that surprises people. It's also the one that gets deferred, and deferring it just moves the hours to a worse week. Add it all up and it's most of a full-time position for most of a year, spread across people who already have jobs.

It lands on the same three people

If those hours were spread evenly, you could absorb them. They aren't. Every project needs someone who knows why the process is the way it is. Not the org-chart answer. The person who knows the West rack holds returns because the returns desk used to be over there, and that customer 3300 gets their labels a certain way because of an argument in 2019.

That's usually your best supervisor or your inventory control lead, the person you can least spare. They take the project on top of a full week, and around month four it slows down and the vendor's status report starts saying "awaiting client input" every week. I've seen that stall kill more implementations than any missing feature.

What I'd do about it

Name the internal lead and take work off their plate in writing. Not "as needed." A specific share of their week and a list of what they stop doing. A quarter of their time for most of the project and close to full time for the six weeks around go-live is a realistic shape.

Backfill one level down. You can't hire a temp to be your inventory control lead. You can hire one to cover receiving, so the person who normally covers receiving steps up and frees your lead. It works, and it costs a fraction of what people expect.

Start data cleanup during selection. It doesn't depend on the vendor. Clean units of measure and consistent location names are good whatever you buy, so give cleanup its own owner and start date. It's the best schedule move you have.

Block testing on the calendar. Testing is the first thing cut when a project runs late, and it's why go-lives go badly. If it isn't an appointment on someone's calendar, it happens in the last week as a formality.

Plan on slower output after go-live. Everyone's slower on a new system. Plan for about eighty percent of normal for two to four weeks, and don't go live within six weeks of a seasonal peak.

What to ask the vendor

Ask how many hours of your team's time their estimate assumes, by phase and by role. A vendor who's run real projects has that number and won't mind sharing it. One who says it varies by client and moves on is telling you something.

Ask what happens when your team falls behind. Some vendors will take on more of the data work for a fee, often money well spent. Others just wait, billing nothing and delivering nothing, while the schedule stretches. And ask what support looks like after go-live. A week on site is very different from two days of remote availability, and the gap shows up on the worst possible Monday.

Most WMS projects that fail didn't pick the wrong system. Feature gaps show up in a demo and get negotiated in a contract. They fail because nobody budgeted the internal hours, so three people already at capacity absorbed them, and by month five nobody had time to make good decisions. The system went live half configured on dirty data, and the warehouse decided the software was bad.

The software was fine. The staffing plan was the thing nobody wrote down.