Failed WMS Project? Why It’s Your Superpower | Socius24

If a WMS go-live has gone badly on your watch before now (a failed WMS project, if we’re being blunt)… well, you’ve seen things, man.

You know things that most WMS buyers don’t.

You’ve felt them, viscerally.

You’ve experienced things that other people haven’t.

And they’ve probably kept you up at night.

So, while I’m not suggesting that you celebrate them, you do need to acknowledge these things, to embody them, and then use them for the Superpower that they TRULY are.

If you’ve lived through a WMS implementation that went badly, you’ve probably spent a fair amount of your personal, private, quiet time since then wishing that you hadn’t: the late nights, the trailers backing up, the phone that wouldn’t stop ringing… stopping production during third shift because the WMS came to a grinding halt, accidentally wiping off all of the inventory a day before go-live, and maybe that moment when you realised the only things you’d eaten during the previous 48 hours had come from the vending machine in the common room. And then, there was the tough self-examination, post-implementation, where you questioned everything, but very specifically your own career choices.

Nobody puts a failed WMS project on their CV. Although, when you think about it rationally, living through something like the above probably taught you more than most of the rest of what’s on there, combined.

So, if nobody’s said it to you already, it probably wasn’t your fault. Because these things very rarely are.

All this to say, trigger warning, that I’m going to gently suggest that having experienced a catastrophic go-live might be the most useful thing that you could bring to your next WMS selection.

It doesn’t very much matter whether it happened at your current job, and there’s a set of board minutes somewhere with “never again” scrawled across them (in jagged red letters), or whether it happened at your last job and you’ve been carrying the emotional scars of it with you ever since. Either way, you’ve seen exactly how WMS projects can fall apart. And that’s your superpower, because it’s important to understand that most of the people sitting around the table with you during the selection process don’t know what you know.

While they’re working from the brochures and presentations, you’re working from experience, and maybe, just, perhaps… the occasional, white-knuckled flashback.

Where failed WMS projects usually go wrong

The good news, if you’ll permit me to call it that, is that most bad implementations tend to go wrong in the same handful of ways. Which means that if you know what to look for (and let’s face it, you do), you can usually spot the warning signs long before anyone else.

The go-live date was a non-negotiable

A lot of painful go-lives have one thing in common: the go-live date was decided before anybody knew if the project would be ready by then, or not. Maybe it was tied to a lease ending, or a big new client starting, or perhaps it was tied to the end of the financial year. Maybe it was just the date that happened to be in the contract. Maybe everyone had already booked their holidays off. Whatever it was, as soon as that date was set, it was carved in stone, and your project was then mutated into whatever shape would vaguely fit around it.

So, this time, ask how the date would move, if it had to. Not whether it could (because everybody will say yes), but what would actually have to happen if it did. Would there be a go/no-go meeting? What criteria would go into that decision? And, most importantly, who would have the authority to stand up and say, “not yet”, and if they did, would anybody ACTUALLY listen?

Now, we know that Socius24 has a reputation for being rather <cough> ‘straightforward’ in our communications. Which is totally fair, because we refuse to tell anyone that something’s fine if it isn’t. So, our unsolicited opinion would be that if your WMS partner cheerfully agrees to any date you give them, they’re not necessarily being as helpful as you think they are, however nice it might feel in the moment. And that’s because as uncomfortable as pregnant silences in a meeting can be, genuinely, you want a vendor who’ll tell you when your date looks overly optimistic… and then explain why.

If you don’t get this, push back.

The data was (even) worse than expected

Almost every implementation discovers, at some point, that the data is in a worse state than everybody assumed. Product dimensions that were last measured in 2014. Locations that exist in the system but not in the building, which makes for a very confusing walk around the warehouse (or the other way around, which is significantly worse). Places that can’t be accessed by the new forklifts, containing locations that have been earmarked for SKUs that need to be moved using exactly that and only that MHE. Perhaps even customer records that have three slightly different spellings of the same address.

None of it is anybody’s fault, particularly. It just builds up over time, sort of like things do in a junk drawer, eventually jamming it closed and causing an attack with the nearest spatula when you have to get that one, very specific thing, that you know is in there, out.

The trouble starts if this particular bombshell is only uncovered three weeks before go-live, rather than three months (when you could easily and cheaply have done something about it). Because suddenly there’s a mountain of data-cleaning that nobody planned for and, just like a cartoon anvil, it’s going to land on someone’s head, and usually that someone or those someones are already working to capacity.

This time around, ask who’ll do the data work, ask when they’ll do it, and ask how long they’ll be allocated (and left in peace) to get it right. And then ask if there’ll be a trial load of real data early on, so that everybody can see exactly what state it’s in – while there’s still enough time to fix any problems.

If the answer you get is something along the lines of “meh, we’ll sort the data nearer the time”, push back.

The incredible disappearing project team

… and we all know what happens next. The project team gets picked, everybody’s very enthusiastic about the new WMS implementation, and then slowly (but sometimes not quite so slowly) they’re pulled back onto their normal jobs. And that’s because, well, the warehouse still needs running.

The problem with this is that when user acceptance testing time comes around, the people who had been carefully selected for their expertise and deep knowledge of your operation, and who had been pencilled in to do said testing – are covering a shift, chasing a delivery, or on holiday. Because they booked their holiday back in March, before any of this was planned, and frankly, my dear, they’ve earned it.

Again… nobody’s fault. People are doing the best they can with two jobs and one pair of hands. But this exact thing is a very common cause of problems that should have been caught during testing making it all the way to go-live day instead.

So, this time, ask which of your people this project actually needs, and for how many days a week. Then be honest with yourself about whether you can spare them, and who is going to cover their normal work while they’re working on the project.

If the plan assumes, without anybody overtly saying so, that your team can do both jobs at once… push back.

The people who sold it to you weren’t the same people who ended up building it

If you’ve been burned before, there’s a decent chance that you met a lovely, knowledgeable team during the last sales process and then a completely different set of people turned up to do the work. Some of them were brilliant. Some of them were there, learning about your business on expenses, one freelance consulting day rate at a time.

This time, ask to meet the delivery team. Not just the project manager, but whoever’s going to be configuring the system and sitting with your team during testing. Ask what they’ve done before that looks like your operation.

And if your potential WMS provider doesn’t offer you the opportunity to speak to a reference customer, push back.

What did “done” look like?

Then, there’s scope. A surprising number of the difficult projects that we’ve been brought in to triage over the years never had a clear, agreed, written-down picture of what the system would do on day one post go-live. So “done” just kept on moving. Things got added, things got pushed into phase two, and, by the end of the project, everybody had a slightly different memory of what had been promised.

In fact, about the only thing that everyone agreed on was that whatever that was, it wasn’t what they ended up with.

So, this time, get it all written down, in plain language, before anything starts. And get everyone involved to agree it. Also in writing.

What goes live on day one, and what doesn’t. What “working” means for each part of the operation. And what happens when somebody (inevitably) asks for something that’s not on the list. It’s not the most exciting document you’ll ever read, but it’s probably the one you’ll be most glad that you had.

So, if you aren’t offered such a document (or given the opportunity to create one yourself), push back.

You do you, Boo

All of which is to say that, if you’ve been burned before, you’ve earned the right to be the one asking awkward questions during a selection. You’re allowed to ask the questions that nobody else is asking, because you know what they are. Push back on the answers that sound a bit too smooth. And, if you’re comfortable doing so, say (out loud and everything): “The last time we did this, it went badly, and here’s why.” Any WMS partner worth their salt will take that seriously and want to hear more, because it’ll tell them exactly what you need from them this time around.

It’s also completely fine if the whole topic still makes your stomach drop a bit when you think about it. That sensation does tend to fade in time, but until it does, know that it makes for a surprisingly good early-warning system.

A small word of caution, though. It’s very easy for one failed WMS project to turn into a general suspicion of everything, and that can lead to some odd decisions: ruling out a system because it’s the one that went wrong last time, when the real problem was the way it was put in, or picking whoever feels safest rather than whoever fits best.

The scars that you bear are useful because they tell you where to look. They’re less useful if past experience starts making decisions for you, in different circumstances, today.

By the way, if you’ve got this far despite never having lived through a ‘burned before’ experience, and you’d like to read up a bit more on where implementations tend to go wrong, our blogs on common WMS implementation mistakes and the good, the bad and the ugly of WMS implementation go into it all in more detail.

This is just the way we work

At Socius24 Limited, we operate a “No Surprises” policy, and part of that is being upfront that our projects sometimes have bumps too. Every implementation does. What we’d rather do is talk about where those bumps are likely to be before we start, so that nobody has to find out about them the hard way.

So, if you’ve been burned by a failed WMS project before and you’re thinking about trying again, we’d be very happy to have a no-obligation chat, including about what went wrong last time, if you’d like to tell us. No judgement, and we promise we’ve heard worse.

You can get in touch with us here.