Published February 1, 2022
Many warehouse management system (WMS) implementations underperform. They overrun budgets, blow out schedules, fail to deliver promised results and inflict excessive go-live pain. In all fairness to WMS deployments, other business system implementations can fall short too. But as an operations-centric execution system, a WMS deployment is very susceptible to a wide variety of pitfalls that can result in poor project results and potentially a failed implementation.
The shape and magnitude of these pitfalls vary according to each WMS implementation’s size, complexity, business requirements and drivers. While implementations backed by strong project management functions are generally well equipped to deal with these potential hazards, they are not immune to underperforming because of them. Understanding how to avoid or mitigate the potential landmines can make or break a WMS implementation.
Implementation pitfalls can be categorized and analyzed a variety of ways. Below are four planning challenges that can negatively impact your WMS implementation, as well as solutions for dealing with each pitfall.
- The Job is Bigger than Expected – This is probably the most common reason that WMS implementation projects flounder. The schedule, resource requirements and budget set when the project was approved turn out to be inadequate. This can be due to a variety of factors. First, the participants in a WMS selection and approval process (operations, IT, software vendor, integrator, etc.) may have been overly optimistic when determining resource requirements and the timeline. Since they probably wanted the project to proceed, they consciously or subconsciously tried to accommodate perceived budgetary thresholds and schedule goals. Also, a WMS design process is typically an iterative proposition. You need to peel back the layers during the detailed design process to determine what actually needs to be done. Selection requirements typically only represent the first layer. There still may be a lot of unknowns buried in the underlying layers that impact schedule, budget and resource requirements.
Obviously, the best approach for dealing with this pitfall is to avoid it by doing your due diligence during the selection and approval process. This should include a critical review of each bidder’s proposed project plan and resource estimates. This should not only cover completeness but also include a direct discussion on contingencies the vendor or integrator has included to cover the unknowns. Any vendor or integrator with a successful deployment track record will have a standard implementation approach or methodology, therefore the only tasks they should miss are the unknown requirements (see the next pitfall). It is far more likely that they will underestimate the complexity of the requirements gathered during the selection.
The vendor is not the only one that can miss or underestimate tasks. When compiling your budgetary request, you need to ensure that the tasks you are responsible for are adequately defined with appropriate contingencies. This is especially true for the resource requirements that you will have to provide to support setup, facility preparation and testing.
All of this won’t entirely eliminate the possibility of ending up with an insufficient budget. Of course, no one wants to go back to executive management asking for more money and/or communicating a schedule pushback when this occurs, but bad news will not improve over time. The cost of addressing any resource gaps and the impact of any schedule slippage tends to grow over time.
Unfortunately, the established schedule and budget may be relatively inflexible. If you must play the resource and timeline hand originally dealt, then you need to look at what functionality and features can be deferred or off-loaded to a subsequent phase. Continuing without directly addressing the shortfall will not turn out well.
- Misaligned and Hidden Requirements – Most WMS implementations depend on a detailed design process to deliver the required functionality and features. During the process, the WMS vendor or systems integrator develops design documentation and specifications that drive configuration and any software extensions that must be developed. This is generally done through a mixture of observations, workshops and reviews with key client stakeholders and subject matter experts (SMEs).
The challenge here is that team members can always see things differently especially given different personal perspectives and project roles. It is easy to assume that everyone involved in designing a particular process is on the same page when actually there is significant misalignment on how the system should work. Words-even when backed up by flow diagrams-can always be interpreted differently by the people involved in the design. This tendency is compounded when a distribution operation has a lot of requirements that exist outside of documented standard operating procedures. These hidden requirements may not be fully articulated to the vendor or integrator by the SMEs because they seem obvious, or they get lost in the shuffle.
The best remedy to avoid this hazard is frequent playback sessions where relevant processes and features are reviewed end to end, covering everything from design approval all the way through delivery. These sessions will enable you to discover any misalignment between the vendor or integrator and client stakeholders and SMEs so it can be addressed in a timely and effective manner.
- Too Little or Too Much Thinking Outside of the Box – Hopefully key business and operational requirements were defined and vetted during the selection process, but as we already have discussed, there is generally a vendor or integrator led detailed design process that drives solution configuration and any extension development. This process relies on client stakeholders and SMEs to provide the input on what the system truly needs to do. When it comes to the details, client stakeholders and SMEs have a natural tendency to view functionality and feature requirements through the prism of how things work today. This can result in missed opportunities to increase operational efficiencies and improve service levels.
The flip side to this situation is when client stakeholders have what they think is a really great idea to improve operational performance. The problem is that the idea may also drive a lot of complexity and effort into the deployment that can jeopardize the schedule and budget. Furthermore, there may be other alternatives that are closer to base WMS functionality that can provide 85%+ of the benefits at a fraction of the risk and cost. The stakeholders don’t want to give up on the nifty idea, and the software vendor or integrator is too hesitant to push back. This reluctance can be due to a natural desire to please or an ego that won’t admit there are some risks that are better not taken for the particular WMS package.
Additionally, there is a natural tendency for stakeholders involved in the WMS design process to push to include every piece of functionality that they think may eventually be useful. The implicit thought process here is that if they don’t get it now, they never will. This can lead to a detailed design that far exceeds the original budget.
Open, direct communications are the best avenue to avoid these pitfalls. Client stakeholders and SMEs should be constantly challenged to consider better ways of doing things. Vendors and integrators need to be encouraged to push back whenever they believe a specific process is heading down a path that will add unwarranted implementation complexity and risk. Project management needs to make sure that all parties feel comfortable speaking their respective minds.
- Project Plans that Fail to Deliver Value – Behind every WMS implementation there is some form of project plan. These plans vary in structure and detail as well as the effort required to develop and maintain them. While necessary, they do not always live up to their potential. For some implementations, they become an unwieldy tool that consumes too much effort for the value produced.
Many implementations approach the project plan as a glorified activities list. An exhaustive list of tasks is compiled with little consideration given to resource requirements. The list with its task dependencies is typically defined based on a pre-detailed design perspective with individual task durations shoehorned into the overall desired project timeline. Tasks are viewed as strictly linear when they may need to reflect a more iterative process.
All of this can result in a project plan that delivers diminishing value over the project life cycle with too much time spent inventorying the individual trees on a weekly basis instead of assessing the overall health of the forest. Developing a well-structured plan is key to avoiding this pitfall. When appropriate, summarize instead of detailing. Many detailed activities are better managed through punch lists by the responsible workstream than buried within a massive plan. The plan structure should be adaptable to fit changing conditions and insights that impact the original assumptions used to develop the plan.
The plan structure should support an earned value measurement mechanism for monitoring budgetary performance. This mechanism needs to go beyond a fixation on perceived duration and critically evaluate when value is earned. Finally, avoid walking through project plan details during weekly project status meetings. These valuable meetings should focus on the health of the various sections that make up the forest rather than a time-consuming discussion on the status of individual trees.
This is the first post in a two-part series dedicated to helping supply chain executives navigate the common pitfalls of a WMS implementation. Learn more about how to ensure a successful WMS implementation in the related articles below and be sure to visit our newsroom to stay up to date on our latest news.