WMS Project Team: Who You Really Need and How to Size It

The WMS project team roles at a glance

6 seats matter on a WMS project.

Florian maps their load across the project phases in a single table. The one to fill in for your own project:

Occupancy by phase is left blank on purpose. A “standard rate” is hard to pin down. It depends on project length, parallel initiatives, decommissioning work and the skills already in the room. Fill it with your project lead.

What each seat is really for:

• Executive sponsor: decides when the project can’t. Keep them out of the daily detail.
• Client project manager: holds the tempo and the vendor relationship. A conductor.
• Logistics / business lead: the voice of the floor.
• Key users: define, test, validate, train others. Your make-or-break people.
• IT / SI: keeps interfaces and security honest while operations owns the system.
• Operations & support: inherits go-live and keeps the promise to customers. The go-live is the moment every seat converges at once. More on that below.

A WMS project team is an organizational decision

The table is the easy part. The useful question is who you actually mobilize, and when.

A WMS project runs as a ramp-up, built phase by phase. The real variable is who you put in the room, and when, far more than how long it takes.

Start with the trio you can’t skip: a project manager who steers, one or two key users who get their hands in the system and a sponsor who decides.

Why two key users?

Florian is blunt about it:

“If one key user is on holiday the week you need a fix, you won’t wait.”

Two people back each other up. The only exception is a project manager who can absorb that backup role.

Now the sponsor. The instinct is to hand the decisions to your most operational manager. That’s exactly the person who’s too close to still ask “why are we doing this?” instead of being carried by the day-to-day. A sponsor works best sitting outside the daily project.

The data agrees. Prosci’s change management research found that projects with highly effective sponsors hit their objectives 79% of the time, against 27% when sponsorship is weak.

The sponsor swings the outcome more than any org chart suggests.

The people the project changes most

There’s a group the org chart underweights: your middle managers.

They’re the relay to the teams:

• When a shift supervisor or a floor manager is confident about the new system, that confidence travels down.
• When they’re anxious, that travels too. So they have to be reassured before they can reassure anyone else.

And it’s often them who live the biggest change. Operators learn a new screen. Middle managers watch their routines, their control points and sometimes their role get redrawn. Budget real time to bring them along.

Start from the autonomy you want

Here’s the question almost no buyer asks early enough:

How autonomous do you want to be?

Picture a line.

At one end, you run the WMS yourself. You build your flows and adjust without calling anyone. At the other, the vendor does most of the work and you validate.

Neither end is “better.” The right spot depends on your context: how fast your business changes, how much skill you want in-house, what your team can take on alongside operations.

Size your team from the autonomy you want. Before you commit to a spot on that line, check you’re set up to deliver it:

• Am I organized to meet my own stakes before the project even starts?
• Will the team I need actually be available when the heavy phases hit?
• Is this the right moment, or can I shift the schedule earlier or later?
• Do I need to adjust my ambition instead — aiming for autonomy in a step 2, not at go-live?

Decide this early and the project falls into place: it tells you which roles you need, how heavy they are, and what help to ask for.

Decide it late and you’re staffing blind. You’ve missed the moment to start the people side of the project, well before go-live. Prosci again: organizations that define success well and measure against it are up to 5× more likely to hit their objectives.

Estimate your test load to size the team

The part buyers underestimate most is testing. So here’s a concrete way to size it.

List your nominal flows and their variants. Put a time value on each.

In one of Florian’s examples, a site lands at roughly 150 flows to test. A nominal flow takes about two hours. A variant, fifteen to twenty minutes.

Run the math and you get around 70 hours of testing. Close to 10 full days.

Now you have a number to staff against, not a guess.

That feeds the real load. On a typical project: about two full-time-equivalents at 70% for your key users, plus one person around 80% to steer, on top of teams who still have their day jobs.

The cheapest way to pressure-test all this before you commit? Ask for a WMS demo built on your own flows rather than a generic script, and watch where your team struggles.

Size by context: single site, 3PL, lean teams

Context changes the shape of the team.

A single logistics site (~50 users, genuinely articulated flows): a logistics project manager plus one lead wearing an IT or business hat. Two people cover it.

A 3PL is a different animal. It keeps absorbing new activities, so it needs a design authority: reusable system and process models that integrate the next client fast. We’ve seen a 3PL use that setup to take over the flows of several sister brands inside its own group, one activity at a time. The team is built to evolve, and the trade-offs there are specific enough that the best WMS for a 3PL deserves its own read.

A lean, mid-size company? Here’s the reality for a small team.

You won’t field 25 people. You don’t have to.

One person can hold several roles: a business lead who’s also the project manager. And bringing in a consultancy or external project management reads as maturity, not weakness. Project skills move you from one state to another. They aren’t a permanent fixture you must own to run good operations.

How this shapes your WMS selection

Keep this in mind during selection.

The autonomy you want is a weighting criterion in your selection grid.

Don’t know what you want? Your reading of the offers tilts toward price and number of days, and you pick the cheapest. Know what you want and what you can provide? You compare on fit.

A good vendor then proposes the right setup. In one version, what Florian calls a Shift Go, the integrator does more of the build and you validate the testing. In another, you take a more autonomous path and drive it yourself. When you reach that comparison stage, the WMS selection guide lays out the options.

One caution from the field: don’t pad your requirements with use cases you don’t have. Dangerous goods you’ll never handle, quality controls you’ll never run. Open the door to a likely future need, but never invent one.

Also, bring IT in early.

Two things pull your IT department into the project sooner than most buyers expect and getting them right early is what keeps the timeline honest.

• Data. Do this work upstream: know what data you already hold and what the WMS will actually need. That inventory is what lets you anticipate both the workload and the change ahead, instead of discovering gaps mid-project. Ask early whether there’s a data owner. A new IT project usually triggers the question, but data is really a company-wide job.
• Integration strategy. How the WMS connects to the rest of your systems shapes how much your teams are pulled in. One platform carrying every brick, for easy integration but at the risk of passing up a sharper best-of-breed tool for a given business need? Point-to-point links between systems? An ETL layer? One interface format, or several? This phase is genuinely hard to estimate, because it depends on each company’s IT map and the trajectory it wants.

What a good partner does, and life after go-live

Strategic software calls for a partner rather than a supplier.

In practice, the vendor sizes its own team to your resources. Little internal time to spare? A good editor flexes up, from roughly two days a week of support to three or four, to protect your timeline. Already have people who know the system? It scales down.

The accountability stays with you, because you know your business best. But you’re supported, never left alone with it.

The go-live moment. This is when every team is mobilized at once. It’s also the reason each role has to be crystal-clear about what it owns. It’s why key users are 100% dedicated to the start-up: no day job competing for their attention while the system goes live.

Go-live is the handover point, the moment the project team passes the running warehouse to the people who’ll operate it.

Then plan for the day after.

Someone keeps the WMS running and evolving. Your RUN team, like your project team, depends on what you actually want from it. So decide two things:

• What level of autonomy do you want to keep in-house?
• How fast does your business change, which tells you how much of a standing team to maintain versus how much to delegate to an integrator or the editor?

Often the key users from the project carry that knowledge forward, adjusting flows and training newcomers. Some companies would rather not hold that skill in-house and call the editor back when a new flow comes up. Both are fine.

Stable for years? A standing team may not be worth it. The day things shift, you run a small project and adjust.

Organize before the RFP

A WMS project is demanding. It also becomes very manageable with a clear organization, owned roles and honest anticipation. A well-prepared WMS, as Florian puts it, is already half a success.

“The best moment to get organized isn’t once the project kicks off. It’s before you write the RFP, when asking the right questions still shapes the outcome.”

Starting now? Put a name against each role, decide the autonomy you want, and project your team into the heavy phases. Our WMS RFP template builds those questions in, so you walk into selection knowing what you need.

FAQ

How many people do you need for a WMS project?

At a minimum, three: a project manager, one to two key users, and a sponsor. It scales from there with project size and the autonomy you want. A single articulated site around 50 users often runs on two well-chosen people plus a sponsor.

Which roles are essential on a WMS project team?

A project manager, key users, and an executive sponsor are the non-negotiable core. Logistics, IT and operations roles join depending on scope.

Can one person hold several roles?

Yes, and in mid-size companies they often should. A business lead can also be the project manager, and external project management can cover gaps.

Do you need IT on a WMS project?

Yes, and earlier than most buyers plan for. Two topics bring them in up front: data (knowing what you hold and what the WMS needs, ideally with a data owner) and integration strategy (platform, point-to-point or ETL). Both are hard to estimate late, so a good partner helps map the scenarios early.

Who maintains the WMS after go-live?

Usually the key users from the project, who keep adjusting flows and training newcomers. Some companies prefer to call the editor back as needs arise. The right choice depends on how quickly your flows evolve.