How to Avoid 10 Common Mistakes in WMS Implementations: Part 1

The implementation of any WMS application is a complex undertaking. However, it does not mean that your project must fail, or even struggle. Bridge Solutions Group has extensive experience in managing the implementation of complex WMS applications, and we are committed to providing customers, partners, and interested parties with our expertise in every way possible. In a series of articles, we will present, how to avoid the 10 most common mistakes made during WMS implementations.  First, we’ll share the list of topics (below), and then jump right into the first topic: Inadequate Business Review.

1. Inadequate Business Review – Many business reviews are inadequate and contain only the business process definitions. To be effective, the business review document must contain adequately defined objectives, realistic schedules, required resources and roles and responsibilities.
2. Failure to Set Realistic Expectations – WMS implementations often ignore or fail to set proper expectations at all levels of the organization.  Realistic expectations can only be set by having an adequate understanding of all of the major technologies and processes involved.
3. Lack of Risk Planning – Incorporating a Risk Plan within the overall implementation plan is vital. Many WMS implementations exclude risk planning and as a result, fail to meet implementation schedules due to the fact that they fail to predict the “what if” aspects.
4. Insufficient Resources – Many implementations underestimate the resources required for success. Both human and financial resources are often insufficient or are not deployed in the most efficient manner.  Most often underestimated is the required availability of functional and business users.
5.  Unrealistic Implementation Schedule – One of the most common mistakes found in almost implementation schedules is the setting of an unrealistic schedule. In many cases, the end date is picked before the schedule is developed. Thus, when the plan or project schedule is developed, it must fit within a predefined timeline. This is the equivalent to fitting the “square peg on the round hole.”  Working out to an end date based on work estimates will help provide you with more accurate estimates, and inherently cannot be done until you know what the work is!’
6. Inadequate Training – Adequate training is vital. Training is often too short, too broad or improperly conducted.  This leads to higher support, maintenance, and opportunity costs. Proper training is as important as any other aspect of the implementation.
7.  Insufficient Testing – All implementations contain some degree of testing. However, a common mistake often made is to reduce the testing cycle to meet schedule restrictions. The development of adequate testing plans is a vital aspect.
8.  Inadequate Data Collection and Conversion Plans – The collection and conversion of data from existing systems is often started too late and lacks any plan to ensure the accuracy of the data. The plan must be developed early and there must be a focus on accuracy.
9. Poorly Planned Integration – The integration of the WMS with other applications or systems is often poorly planned. The lack of a detailed integration plan typically results in implementation delays and unexpected technical issues.
10. Insufficient Support – Too little too late is often the theme of many implementations. Only when a major issue is encountered are the support resources put in place. Better to plan for the worst and expect the best.

Each of the above 10 most common implementation issues will be discussed in greater detail in our series of articles to be published every few weeks over the coming months. Check back regularly to ensure you have an opportunity to review the article and gain insight and feel free to send us more topics, comments, or other discussion points as well!. So let’s get started:

Topic 1:  Inadequate Business Review

We have all heard and seen examples of groups and companies that operate within various degrees of managing, technical, and functional silos.  Too often, decisions made in isolation have much broader effects that can be felt within your company, and arguably more importantly, can be felt by your suppliers, carriers, and customers.  Fortunately there is a ready solution: the Business Review Document (BRD).  In this article we will explain the BRD, and define some of the more important components of a good BRD.  By creating, utilizing, and integrating the BRD into your plan, you will align yourself with the leading Enterprise Architecture Frameworks (NIST, Zachman, and others), and more importantly you will align your internal initiatives better by creating cross-functional ownership at the appropriate levels.

The Business Review Document (BRD):

An insufficient or inadequate BRD is one of the most common mistakes made during many WMS implementations. The BRD must be developed and completed at the very beginning. Sometimes referred to as a “specification” (and viewed as such), it often lacks key components. The business review in addition to defining the process flows, gaps analysis and systems architecture, should also contain the following modules that are often excluded or simply ignored.

• Quantifiable Objectives – Defining “quantifiable” objectives for each process is a fundamental strategy that sets expectations. The old saying “If it can’t be measured, it can’t be managed” holds true. If everyone is focused on the same results, then everyone’s expectations will be met. In a later article, we’ll present a specific model that can be used to define the objectives, critical success factors, obstacles, implications and solutions that will focus teams on delivering “results.”
• Requirement Mapping – Quantifiable objectives (above) should be mapped and tracked to their corresponding requirements.  This provides visibility, and prevents misunderstanding and oversights of requirements in implementation.
• Risk Analysis – The BRD should contain a Risk Analysis derived from the identification of the obstacles and implications. If everyone is aware of the risks then everyone can work to eliminate or reduce the impact. Additionally, it provides yet another method to set expectations at all levels.
• Resources – The BRD must clearly define the resources required during the entire WMS implementation. Resources must include people, systems, infrastructure, software, furniture, equipment and any other item that is necessary for success. In a future article, we’ll provide insights into defining what resources are often overlooked yet vital to success.
• Schedule – The BRD must contain the complete implementation schedule. Properly referred to as the “Project Plan”, it must be derived from the components of the process flows, resource requirements and objectives. It must also be the basis upon which milestones and final implementation dates are derived. In other words, the Project Plan determines the dates for deliverables and not the other way around. We’ll present some techniques for the development of a solid Project Plan.
• Integration – The BRD must clearly define any integration requirements. The complete integration architecture should be presented. Look for our future article that addresses how to incorporate a solid integration section within the BRD.

Ultimately, a BRD as part of a cogent and coherent Enterprise Architecture strategy, can increase your enterprise alignment, align disparate groups of people in your company around a given initiative, and improve visibility throughout your business. We’re sure you’ll agree that a comprehensive Business Review Document (BRD) is vital to every WMS implementation (yes, even the small ones!).

Please let us know what you think, and how you have or have not used a BRD, and what the results are!  Also, check back soon for the next installment of Bridge Solutions’  How to avoid 10 Common Mistakes in WMS Implementations