WMS Implementation Failure: The Real Causes | Socius24
The WMS Implementation Graveyard: How to Stay Out of It
Somewhere, one of your competitors is running a WMS that everyone in their warehouse hates.
It went in a couple of years ago: late, incomplete and totally over budget.
Half of the features that were demoed during the sales process were never actually switched on. The team have only ever worked around it (rather than with it), and most of the people who championed it in the first place have since moved on. Possibly because of the above-mentioned WMS.
Nobody actually says the word ‘failure’ out loud, because doing that would mean having to explain what happened to all of the money. So, it just limps along, and no one bothers to mention it anymore. It just IS.
And WMS implementation failure happens more often than a lot of providers would like to acknowledge.
WMS projects do have a failure rate, and only a very few providers feel comfortable talking about it. And that’s partly because failures like this don’t often reveal themselves with big, dramatic collapses. They just sort of… settle down with a groan, into a puddle of disappointment. The system works. Technically. But it never quite became the ‘thing’ that it was supposed to be, and instead, the business has slowly reshaped itself around the gap where the ‘thing’ should have been.
And the people who deployed it on their behalf have most likely scarpered off to their next ‘not quite right’ implementation.
If you’re the person who has to sign off on the next WMS, you’ll probably already know what we’re talking about. It’s exactly why you’re so nervous about doing it again.
And you’re right to be.
Why WMS projects fall over
The interesting part about problems like this is that when implementations fall over, the cause is rarely the software itself.
We know this because we’ve been called in to rescue and replace enough of them over the years to have a pretty clear view of what is actually going wrong. And the same handful of things come up over and over again.
Typically, the rot starts with a scope that was never properly agreed.
The project gets sold as a sort of vision, it’s bought on a wing and a prayer, and the difficult conversations about what’s actually in scope and what’s actually out of scope are kicked down the road, because nobody wants to look like the Bad Guy, at least while everyone’s still getting along.
Then, almost inevitably, those conversations happen anyway, about six months later. Except now they’re happening as arguments about change requests and about whose budget the changes are going to come out of. The actual scope of the project was always going to come to the surface eventually and ignoring it just meant that the problems that were going to happen anyway blew up later, and louder.
Then there’s the assumption that the warehouse will simply mould itself around the new system.
Every operation has its quirks: the arrangements, the exceptions, the “oh, we always do it this way for that particular client” rules that have built up over years of negotiations, like a kind of emotional patina.
Plenty of implementations treat those things as nuisances that need to be standardised out of existence. And sometimes that’s OK. But quite often it isn’t, because some of those quirks aren’t quirks at all: they’re actually the whole business.
They’re the things keeping specific customers from going elsewhere. They’re the features, not the bugs.
And when your new system can no longer handle those features, your team is going to build workarounds to accommodate them. And a warehouse that’s full of workarounds is just all your original problems, but now they’ve cost you a lot of money.
Then there’s the question of what happens to business knowledge during the project itself.
The people who genuinely, properly, really understand how your warehouse runs are usually the busiest people in the building. And that makes them the hardest people to get any time with, especially while you’re trying to configure a system. So, unless you’re aware of this, and willing to take the time required to get it right, your sparkly new system is going to get built on a partial picture. And then, it’ll be signed off by people who aren’t quite close enough to the action to spot what’s missing (or just wrong). Which means that those gaps are going to stay invisible… right up until the thing goes live, at which point they’ll stop being cheap(er) to fix.
But in our experience, the single ONE thing that does the most damage is treating the whole thing as an IT project, rather than an Operations one.
IT can install software, brilliantly. But IT can’t make your warehouse want to use it.
And when your Operations people don’t feel any ownership of the thing, when they don’t believe that it was built for them, when they don’t trust that it actually understands what they do on a daily basis, they’ll skirt around it with exactly the same level of determination that your best people have always applied to everything else.
The messy middle
And there’s one cost that almost never makes it onto the first project plan: the cost of the transition itself.
Not the cost of the licence, and not the cost of the implementation fees, either. The productivity dip that will predictably happen while your team gets to grips with a new system:
- The errors that will happen during changeover.
- The temporary slowdown that, because sometimes badly organised projects can have a habit of running long, tends to arrive at the worst possible moment… and then collide head-on with Peak.
This is all perfectly survivable if you’ve planned for it, budgeted for it, and set expectations with the people upstairs (who’ll be staring at numbers rather than the warehouse floor the whole time that it’s happening). And, obviously, it’s ideal that you work with people who know what they’re doing.
But it’s a catastrophe if you haven’t done any of the above, because then that predictable dip will be translated as proof that your pet project has failed. At which point, any confidence that has been built up will start to pour down the drain. And a transition that you could easily have recovered from turns into the thing everyone points at later, while they’re explaining why they never trusted that new system in the first place.
The boring bits
In our (really rather extensive) experience, the implementations that go the most smoothly are not the ones that have the most features or the biggest budgets. They’re the ones where people have taken the boring stuff that we ask them to do seriously:
- Scope, which has been properly agreed, awkward bits included, before anyone signs anything.
- Ops leaders are brought in early so that they can contribute in a meaningful way and not just shown the decisions that have been made on their behalf, when it’s too late to make changes.
- Quirks that matter to the business are kept, while the ones that don’t matter are dropped deliberately, rather than by accident.
- A transition that is recognised as an actual project phase, with actual costs and actual time required to do a good job.
- And somebody on the Operations side who owns the whole thing, who wanted it in the first place, and who’ll stand up for it on the floor when the wobble comes. Because there’s always a wobble.
None of this is particularly exciting. None of it demos exceptionally well. And all of it is the difference between a WMS that becomes part of how the warehouse runs, and a system that the warehouse just runs around.
Where we come in
We’ve been implementing Dispatcher WMS for more than thirty years, and a significant chunk of that time has been spent tidying up after implementations that went wrong before we got involved.
And the one, single thing that we keep coming back to is that the technology was rarely the deciding factor when it came to success or failure.
By the time somebody rings us to deal with a system that’s problematic, the conversation is almost never about features. It’s about everything that was going on around the features and that got neglected during the original implementation: the scoping, the ownership, the security. The brutal truth about what the operation really needed. The plan for the messy middle, where everything feels worse before it gets better. Eggs, omelette, etc.
If you can get those things right, then your WMS has got a fighting chance to revolutionise your business the way it could. But, if you get them wrong, the best software in the world can still end up in the implementation graveyard, along with everything else.
So, if you’re at the start of one of these projects, or if you’re already staring down one that’s starting to wander off course, come and have a conversation with us before you commit to anything else.
We’re happy to talk through what you’re trying to do and help you to pinpoint where the real risks are. At the very least, you’ll go away knowing more than you did before we talked. Book an obligation-free discovery call now.
FAQ: WMS implementation failure
Rarely because of the software. The usual suspects are a scope that was never properly agreed, an assumption that the warehouse will mould itself around the new system, crucial business knowledge that never made it into the configuration, and, most damaging of all, running the whole thing as an IT project rather than an Operations one.
Less dramatic thank you’d think. The system technically works, but half the demoed features were never switched on, the team works around it rather than with it, and the business slowly reshapes itself around the gap where it should have been. Nobody calls it a failure out loud, because that would mean explaining what happened to the money.
Operations. IT can install software brilliantly, but it can’t make the warehouse want to use it. The implementations that succeed have somebody on the Operations side who owns the project, wanted it in the first place, and will stand up for it on the floor when the (almost inevitable) wobble comes.
Treat the transition as a project phase in its own right, with its own costs and time. Budget for a temporary productivity dip and increased errors during the changeover, keep the timeline well clear of Peak, and set expectations with senior stakeholders well in advance so that a predictable dip isn’t interpreted as proof of failure.
Request a Demo Now
If you’ve enjoyed this article, claim your free subscription to our LinkedIn weekly Newsletter
– The World of WMS –
for more of the same great information!
