The expensive parts of a first WMS project are almost never technical. They're decisions about people that cost nothing to make early and get billed at implementation rates once they're late.

Jason Bader re-ran our Distribution Talk conversation in November 2025 as episode 191. It's the same recording as episode 159 from June 2024, sponsor reads aside. I've written up the systems half of that conversation separately, in what to know before you buy: where vendor incentives bend, the gap between what an ERP records and what a warehouse runs on, and where the return actually shows up. This is the other half, the one about people. It's the half that decides what the project costs.

Every quote block below is me, on the episode, condensed for reading.

It Was Never a Technology Project

They viewed this technology as a technology project. And if I can say anything in terms of just looking at patterns, that's almost never the case. Technology plays a part. It's an important part, but it comes last. If you don't have people across different teams, and that's not just the four walls, that's sales, purchasing, customer service. If you don't have them all aligned, it doesn't matter how good the technology is. It's just going to amplify your problems if you have ineffective processes.

The word I'd underline there is amplify. A bad process doesn't survive a system implementation unchanged and it doesn't quietly get fixed either. It gets encoded. A workaround somebody performs by hand forty times a day costs whatever it costs today. Written into a system, it becomes configuration, then training, then the thing you pay a change order to undo.

If you get the people talking, that will inform your processes. And then once you have your processes, now you can use the technology to get the mileage out of your operation that you're looking for.

A system industrializes whatever process it finds, which is why the same inefficiency costs more after go-live than it did before.

It's also the honest answer to whether to customize the system or change the process. That question is much cheaper before you own the system.

Whoever Owns It Decides Who Opts In

For the very big companies that I worked with early on, it was very much an IT project. And I think that was part of the reason why so many of them struggled, because if it's technology, you have IT, they're the ones with the final say. And then you have operations and IT fighting each other because something's pushed at them versus them opting into it.

I'll take my share of that:

I didn't necessarily appreciate that because early on, I was on the IT side. I was the software vendor. That was the role I had to play.

Pushed at, versus opted into. Same software, same budget, same timeline, and two entirely different projects. One of them spends its first three months building agreement it could have had for free. The other spends them building the system.

Where the project sits on the org chart decides whether the warehouse opts into the system or has it handed to them, and that gets settled long before a requirement is ever written down.

It's one of the more reliable predictors of how these things fail, and it's visible from the outside on day one.

What Fear Costs You at Go-Live

A big part of the fear of technology is the basic question of why do I have to change? This works for me. I'm very happy in what I do today and I've optimized around it. I know what I'm doing when I come in. I don't have to guess. I don't have to relearn.

That's an accurate description of someone's own position. They have optimized around it, often for years, and nobody has told them what they're being asked to trade it for.

There's an old adage. When you think you're communicating too much, you're barely meeting the minimum threshold for communication.

That matters to a budget, not only to morale, because of what comes next:

When you scare people, they're less likely to participate in general. Opt out completely. There's the adversarial notion there, but there's also, if they're checked out, they're not sharing those critical tidbits that would be huge when it comes to day one, go live. You hit a corner case that they could have been sharing information about, maybe helping you flesh out the process and the whole workflow in general, and you get blindsided.

Those tidbits are the exceptions. The customer whose orders are staged differently. The product that can't go on the top rack. The Friday routine nobody wrote down. None of it is in a document anywhere, because it lives in the heads of the people who handle it.

The exceptions that break a go-live are held by the people your rollout just frightened, and they cost nothing to collect in advance and a great deal to discover on day one.

Quiet during an implementation is not the reassuring signal it looks like.

The Seat Nobody Fills

Someone's already wearing a bunch of hats. They either volunteer or they're told to put on another hat, and their day job takes priority. So trying to push this thing forward part time, never done it before. Things always fall off. That's where time kind of kicks you hard.

A day job taking priority is what a day job is. The alternative is worse:

Sometimes it's just not filled at all. The vendor is supposed to do it. And that's where a lot of these go off the rails.

A vendor's project manager is real and often good, but they are managing the vendor's scope, which is the deployment of their software. Nobody on that side is accountable for whether purchasing changed how it receives, or whether the second shift was trained, or whether the master data got cleaned.

A program manager assigned part time to someone who already has a full job buys you a longer project, and on work billed by the month, length is the price.

The difference between what a vendor's project manager owns and what nobody owns is worth understanding before the contract is signed rather than after.

Why the Question Lands Differently From Outside

If you get someone that's independent and external, they can do things that the folks inside can't necessarily, or they get very uncomfortable with. Because you know what? They're going to be working with everybody else for a very long time. I can come in and out. I can have objectively productive conversations, ask hard questions and get the business moving.

The internal person who doesn't push on a colleague's process has good reasons. They have to stand next to that person at the time clock tomorrow, and the year after that. Asking costs them something real, and weighing that cost is reasonable behavior.

They can see the hard question perfectly well. They're paying a price for asking it that never appears on a project budget, and an outsider's only genuine advantage is not having to pay that price.

It's also why the outsider asking it shouldn't be selling you the implementation afterward. An advantage that only lasts until someone has a deployment to protect isn't much of an advantage, and it's a large part of what separates an independent assessment from a vendor's discovery process.

Listen to the full episode, or read the systems half of the same conversation.