Introducing New Warehouse Management Systems
Why Projects Fail – and How to Do Better
WMS IMPLEMENTATIONPeople do not like to talk about it – and yet it happens again and again: large-scale IT projects, such as the introduction of a new Warehouse Management System (WMS), are terminated prematurely because the problems seem impossible to overcome. In almost all cases, the causes do not lie primarily in the software, but in the project approach, the organization, the management, and the expectations.
One of the best-known disasters is Lidl’s failed migration of its ERP and WMS systems to SAP and SAP EWM. The discounter restarted and restructured the project several times before eventually discontinuing it to a large extent. The damage is said to have amounted to several hundred million euros in project costs.
Conflicts Between IT Logic and Operational Reality
The example of Lidl already reveals several typical factors that contribute to the failure of a WMS implementation. In this specific case, an attempt was made to adapt the software heavily to Lidl-specific processes. This resulted in extensive customization effort in order to map complex, historically grown processes. Conflicts arose between IT logic and operational reality.
The lesson to be learned is that a WMS or ERP system should not become a digital replica of decades of special processes. Before introducing the system, processes should therefore be simplified as much as possible.
Unlike Lidl, however, many inadequate WMS projects lack a clear cut-off point. Instead, companies often settle in practice for only limited usage depth, Excel lists that continue to be maintained in parallel, permanent special processes, and a high level of manual control effort.
Be Careful With the Following Statements:
❌ “The system has to be able to do this because we have always
done it this way.”
❌ “We’ll fix that later.”
❌ “It’s not standard, but we can quickly build it for you.”
❌ “We have to go live – we can test afterwards.”
❌“So far, we are on schedule – but only on paper.”
Main Causes of WMS Project Failure
A significant proportion of WMS projects exceed the planned budget and timeline or are accepted only reluctantly by users. Such developments and outcomes can sustainably reduce financial success, jeopardize the company’s business foundation and, not least, negatively affect the working atmosphere.
The best prevention strategy starts with a systematic look at the main causes. These can be divided into eight key categories.
Similar to the typical mistakes, there are also a number of typical symptoms and early indicators that may appear during an ongoing WMS project. These indicators point to deviations from the planned course. The more warning signs occur at the same time, the higher the risk of delays, additional costs or failure in day-to-day operations.
The Main Causes:
1. Unclear objectives and lack of strategic alignment
2. Inadequate project organization
3. Insufficient process analysis
4. Overestimated individualization
5. Poor data and master data quality
6. Too few tests, trainings and go-live preparations
7. Lack of change management and insufficient involvement of specialist departments
8. Mistakes in time, budget and risk management
pLG Warehouse Management System
Benefit from pLG solutionsReduce inventory discrepancies sustainably: With real-time postings, guided processes, and transparent inventory management, the pLG WMS ensures reliable stock levels – enabling higher delivery reliability, less rework, and predictable operations.
Unclear Objectives and Lack of Strategic Alignment
A common mistake at the beginning of a WMS project is an unclear or purely technology-driven definition of objectives. Statements such as “We need a modern WMS” or “Our old system is no longer up to date” do not replace a clear strategic objective. Often, it remains unanswered which specific problems are supposed to be solved:
- Should picking performance be increased?
- Is the goal to achieve higher inventory accuracy?
- Are new business models or automation technologies being prepared?
- Should transparency and controllability be improved?
Without this clarity, the WMS becomes an end in itself. Project decisions — for example regarding process design or customization — are then made opportunistically rather than in a targeted way. As the project progresses, the following indicators often appear quickly:
- There are no clearly defined, measurable project goals (KPIs)
- The WMS is introduced “because it is needed”, not because of specific problems
- The logistics strategy is not clearly documented or not known
- Automation or growth scenarios are not taken into account
- Project success is not measured against business KPIs
Typical symptom: Discussions revolve around functions — not benefits.
How to do better: A WMS project should always be derived from the logistics and corporate strategy. Measurable goals (KPIs) such as throughput, error rates, service level or scalability provide orientation and later serve as a benchmark for project success.
Inadequate Project Organization
Every WMS project must be clearly structured and tightly managed. The following mistakes occur again and again:
- The project is primarily managed as an IT project
- Responsibility within the specialist departments is unclear or weakly assigned
- There is no real product owner / process owner
- The steering committee makes decisions late or not at all
- External consultants permanently replace internal know-how
Typical symptom: Decisions are postponed or “solved technically”, even though they are organizational issues.
How to do better: The responsibilities within the project must be clearly defined. A partnership-based cooperation with external consultants should ensure knowledge transfer in order to avoid dependencies.
Typical symptom: “The system has to be able to do this because we have always done it this way.”
How to do better: Before system selection and configuration, a structured process analysis is essential. The goal should be a clearly defined target process model that is based on best practices and deliberately simplified. A WMS project is always also an organizational project — this opportunity for process improvement should be actively used.
Insufficient Process Analysis – Digitalization of Inefficiency
Another core problem is the inadequate examination of existing warehouse processes. In many projects, current processes are transferred into the new system without critical reflection — including all media discontinuities, special rules and historically grown workarounds.
The result: A modern WMS merely maps inefficient processes digitally. The expected productivity gains fail to materialize, while complexity increases.
- Current processes are transferred 1:1 into the WMS
- There is no clean target process model
- Special cases and exceptions dominate the discussion
- Processes are strongly dependent on individual people (“Stefan always does that”)
- An end-to-end view, from goods receipt to dispatch, is missing
Overestimated Individualization and Customizing
Many companies tend to adapt a WMS heavily to their individual processes. At first glance, this seems reasonable — after all, their own processes are often considered “special” or “competitively differentiating”.
In practice, however, excessive customizing leads to high implementation and maintenance costs, longer project timelines, limited update capability and increased dependency on the provider or integrator.
- High proportion of customer-specific developments
- Standard functions are ruled out at an early stage
- Updates and release capability play no role
- Dependency on individual developers or service providers emerges
- WMS, WCS and ERP are not clearly separated in terms of functionality
Typical symptom: “It’s not standard, but we can quickly build it for you.”
How to do better: Modern WMS offer a broad functional standard that is sufficient in many cases. The guiding question should be: Can our process be adapted to the standard — and not the other way around? Individual developments should remain the exception and only be used where they create genuine added value.
Typical symptom: Problems are played down during testing: “We’ll fix that later.”
How to do better: Data migration and master data quality must be treated from the very beginning as a dedicated work package with clear responsibility. Test runs with realistic data are essential in order to identify problems early.
Poor Data and Master
Data Quality
A WMS is only as good as the data it works with. Article master data, packaging hierarchies, storage location parameters and movement data form the foundation for functioning processes and intelligent control logic.
Nevertheless, the preparation of this data is often underestimated or postponed. Incorrect or incomplete data then leads to chaos, manual intervention and frustration during live operation.
- Article and packaging data is incomplete or inconsistent
- Storage locations are not logically structured
- There is no clear responsibility for master data
- Data migration is regarded as a purely technical issue
- Tests are carried out with “cleaned-up” or dummy data
Too Few Tests, Trainings and Go-Live Preparation
Go-live preparations are sometimes taken too lightly. This classic mistake can be observed in various forms:
- Test phases are shortened due to time constraints
- Integration tests across system boundaries are missing
- Key users are overloaded with day-to-day business
- Trainings take place shortly before go-live
- Emergency and fallback concepts do not exist
Typical symptom: “We have to go live — we can test afterwards.”
How to do better: The go-live is naturally one of the most critical phases of a WMS project. Test phases should be planned with sufficient time. Emergency and fallback concepts must also be created.
Typical symptom: The WMS is running — but employees work around it.
How to do better: A successful WMS project requires the active involvement of logistics departments — from requirements definition through to go-live. Key users who understand both the processes and the system are crucial for quality, acceptance and sustainability. Change management is not a “nice-to-have”, but a central success factor.
Lack of Change Management and Involvement of Specialist Departments
WMS implementations are often managed as IT projects. Responsibility lies primarily with the IT department or external service providers, while operational departments are involved late or only selectively.
The consequences are serious: requirements are described incompletely or incorrectly, acceptance problems arise among users, training efforts increase significantly and workaround solutions or “shadow processes” become established.
- Users were involved late or not at all
- There is resistance that is not openly addressed
- The benefits are not known to employees
- Managers do not visibly support the project
- Excel lists and parallel processes already emerge during the project
Mistakes in Time, Budget and Risk Management
The pressure to become productive quickly is high — especially when construction, automation or transformation projects are running in parallel. Timelines are often planned too optimistically and risks are ignored.
When delays occur, pressure on the project team increases, which leads to compromises in testing, training or stabilization. The consequences often only become visible after go-live.
- The timeline is extremely ambitious or politically driven
- Buffer times are completely missing
- Risks are known but not assessed
- Budget overruns are glossed over
- Problems are only raised in the steering committee when the situation has become critical
Typical symptom: “So far, we are on schedule — but only on paper.”
How to do better: Realistic planning, clear milestones and active risk management are essential. A phased rollout or pilot operation can help limit risks and gather experience in a controlled way.
Typical Symptoms as Early Indicators in Ongoing WMS Projects:
- Discussions revolve around functions — not benefits.
- Decisions are postponed or “solved technically”, even though they are organizational issues.
- Problems are played down during testing.
- The WMS is running — but employees work around it.
A single mistake and one early indicator will not cause a WMS project to fail. It becomes dangerous when several points occur at the same time and are not actively addressed. Successful WMS projects are characterized by making problems visible early — not by avoiding them altogether. A WMS project rarely fails suddenly — it fails gradually.
Conclusion
WMS projects are a management task that involves much more than the introduction of new software. The failure of many WMS projects is not due to a lack of system performance, but to false expectations, insufficient preparation and a lack of organizational anchoring. Anyone who wants to successfully introduce a Warehouse Management System must take technology, processes and people into account equally.
With clear goals, a well-thought-out methodology and consistent change management, a new WMS becomes a central enabler of modern, high-performance logistics.
We will be happy to advise you on our products
We are here for you.Give us a call or send us a message. We look forward to welcoming you.
proLogistik Holding GmbH
Fallgatter 1
44369 Dortmund
Tel.: +49 (0) 231 5194-0
Tel.: +41 (0) 44 200 40-00
Tél.: +33 (0) 251 81 85 85