Ever seen the Tom Hanks film The Money Pit? There’s a scene that strikes fear into anyone who has ever paid for building work. Hanks, standing in the smoking ruins of a house that’s slowly destroying his life, asks his contractor how long the work will take.

“Two weeks.” It’s always two weeks. The staircase just collapsed: two weeks. The bath fell through the floor: two weeks. By the end of the film, “two weeks” has stopped meaning anything at all. It’s become an over-confident, oddly specific, completely fictional concept delivered with a grin and a clipboard. And it’s painfully funny because it’s true. We all know someone who’s been quoted “two weeks”, fallen for it, and paid for the mistake in cold dinners and even colder showers.

So when someone asks us how long a WMS implementation will take, we know what they’re braced for: the warehouse-project equivalent of “two weeks”. A random number invented on the spot by someone who’s never seen inside their warehouse, looked at their data, or considered their diary. If you’re weighing up a WMS project and you’d rather that didn’t happen to you, read on. We’ll walk through where the time actually goes, phase by phase, so that next time someone flashes you a neat number, you’ll know which questions make them sweat.

This is the final part of our look at what a WMS really costs. If you haven’t read them, here are Part One and Part Two.

A WMS project has two costs: the one on the invoice and the one in your calendar. “Two weeks” is what people say when they haven’t looked closely enough to give you a sensible answer. The real answer is “it depends”. Stay with us, though, because while the length of each phase moves around with scope, the order of the phases almost never does. Every implementation we’ve seen passes through the same phases in the same sequence. So while you can’t always know how long yours will take, you can know exactly where the time goes, and where it tends to sneak off to before you notice.

Job one: discovery and design

You, us, a room, a lot of coffee, hopefully some good biscuits, and an ever-growing list of questions about how stock actually moves through your operation. Note the word “actually”. There’s how your warehouse works in the Ops manual, and then… there’s how it works at 4pm on the Friday before a Bank Holiday when the returns cage is buried under a mountain of boxes. Those two things are frequently mutually exclusive.

This phase slows down because the answers often don’t exist yet. Ask three people how returns get processed and you’ll get four answers, two shrugs, and a story about a crusty pallet that’s been there since 2019. Please know, this is not a dig. Every operation runs on undocumented knowledge. But that knowledge has to be uncovered and written down before anyone can configure a system around it, and that always takes longer than anyone expects.

Job two: the system gets built and configured

Usually the most predictable part of the project, because it’s our side of things. If we’ve reached this point, scope is agreed, and barring nasty surprises your configured system tends to arrive roughly when we said it would.

Job three: other people’s stuff

Integration. Your ERP, your carriers, your customer systems, maybe some automation. All of it needs connecting, and most of it belongs to somebody else. This is where a clean project plan starts misbehaving, because now you’re dependent on third parties answering emails, and third parties answer emails on their own schedule, which can sometimes appear to follow a biodynamic lunar cycle. You’ll wait a fortnight for an API spec, and when it arrives it’ll cheerfully document a system that’s two versions older than the one you’re running. Your critical path runs straight through other people’s inboxes, so someone needs to be chasing everything from the start.

Job four: the skeletons in your spreadsheet

Master data. Product dimensions, weights, locations, barcodes, units of measure. Nearly every implementation uncovers data problems, and only a few customers knew about theirs beforehand. Nobody wants to open the padlocked cupboard of master data in case a bowling ball falls out, because somewhere in the item master there’s usually a product that weighs 4,000kg and fits in a shoebox, and it’s been on the list a while.

This is where the “two weeks” people give themselves away. Anyone quoting a timeline before they’ve seen your item master is the WMS equivalent of those Money Pit contractors. Cleaning data is nearly always the longest customer-side job in the project, and usually the one started last.

Top tip: start on your data before you’ve even picked a system. It’s never wasted work, and it buys back more time than anything else you can do.

Job five: testing

Everyone’s busy running the warehouse. We know. But you have to test, specifically user acceptance testing, where your best people put the new system through its paces before any real orders go near it. The catch is that your best people are your best people because they’re busy running the warehouse, so testing gets squeezed into shrinking gaps and a fortnight of planned UAT becomes six scattered afternoons.

Incomplete testing won’t make your project shorter. It will just push the discovery of problems to a point where they’re far more exciting and far more expensive to fix. Protect your testing time like annual leave: book it, ring-fence it, backfill the day jobs your people can’t do while they test. (It’s worth remembering that when implementations go wrong, it’s rarely the software that fails.)

Job six: before peak? Which peak?

This is probably why you’re still reading. People rarely ask for a timeline out of curiosity. There’s usually a date looming, and that date is usually peak. Can you go live before peak? Sometimes, yes. But you have to reverse-engineer the dates first. A sensible go-live needs clear space either side: time for the system to bed in, get tuned, and let the team find their feet before volumes climb.

Nobody sane flips the switch on a new WMS the same week the Christmas stock arrives. So “before peak” doesn’t mean the week before peak. It means a good stretch before then, plus every phase above, plus the slippage. If someone promises a pre-peak go-live without doing the sums in front of you, congratulations: you’ve just been Two-Weeksed.

If the maths works, brilliant, we’ll get moving. If it doesn’t, forcing it is how go-live horror stories start. The strongest alternative to implementing before peak, when you don’t have time to implement before peak, is to aim for the quiet season on the far side of it, and spend the run-up doing the data and design work properly. That way you still get your sparkly new system, with your peak left intact.

So how long will it take?

Waiting to start doesn’t shorten anything. Starting now beats starting “after peak”, “after the audit”, or “after things calm down”, because things never calm down. You know this. And slippage almost always hides in the same three places: in decisions, in your data, and in other people’s diaries. Those cause far more problems than the software ever does, which is oddly good news, because you can start dealing with all three today, for free, before you’ve signed anything with anyone.

The Money Pit contractors could say “two weeks” with a straight face because they didn’t care. Anyone who’s actually looked at your warehouse should take longer to answer “how long will it take?”, and that’s a good thing. So if there’s a date on your horizon, book an obligation-free discovery call. Bring your deadlines, especially the scary ones. We’ll tell you how long we think it’ll take, and we can guarantee it won’t be two weeks.