The Human Side of WMS Implementations

Catherine L. Cooper

Too many WMS implementations struggle and fail, not because of the system’s weak technical performance, but because of a poorly handled project and people management problems. The many tasks associated with implementing a WMS can make the responsibilities of a project manager seem intimidating. Regardless of which system you select and how much support you expect from the vendor, there is a body of knowledge that you must have as a project manager in order to lead your team through a successful WMS implementation.

Your first mandate is to utilize technical resources for assistance with WMS specific issues, such as the selection of both system and vendor, development of test plans and interfaces, and the hardware setup. You are the manager, and that means that you should not try to be an expert in every area of the project.

Your second mandate is to understand that, despite your best efforts, your WMS project may fail. It is a serious mistake to assume that you will never need to return to the system that you had before (the legacy system). Therefore, be prepared with a clear back-out plan. The days before a new system goes "live" are stressful. Chaos could ensue if the system fails and you are not fully prepared to recover quickly. Before you begin the installation, establish a back-out team, define its responsibilities, and describe step-by-step procedures for returning to the legacy system. The team should review this contingency plan several times before start-up.

There are some project management issues common to most WMS installations, and several basic do’s and don’ts for leading a cohesive project team, developing a positive communication plan, establishing effective communications channels, and identifying essential training activities. Each of these stages is fraught with pitfalls. Some common traps are described below, along with suggestions for managing or, in the best case, avoiding them.

Project Team

Don’t underestimate the importance of project team development. Allowing your corporate organization chart to evolve over time by assigning responsibilities to people, rather than people to functional responsibilities, can result in a dysfunctional team shaped by relationships, personalities, and low morale.

Do take the time to assemble a group with clearly defined roles and responsibilities, and one that is capable of maintaining motivation and commitment throughout the duration of the project. No matter how large or capable your crew is in the beginning, it needs to be properly sized so that momentum and energy can be sustained to the finish line. It is difficult to do this with a large group of loosely knit people, so designate both a core and support team based on functional responsibilities. A sample organization chart is shown in Figure 1.

Project Team Development

Don’t assume that your team possesses all needed skills and that it will not require additional training.

Do assess the team’s capability for achieving a successful implementation. The four main assessment categories are project administration, functional concepts, software modules, and hardware components. To manage a project effectively, the team needs working knowledge in each of these areas. At the very minimum, the team should perform a self-evaluation, but it may be more helpful to have an industry expert conduct the assessment. Based on the assessment results, develop a team education plan outlining the steps required to master the skills needed by the team.

While communication is vital, do not schedule meetings so frequently that you raise the risk of team burnout before the project is completed. Participation and overall project morale wane when people feel that they are not contributing or benefiting from project meetings.

Do schedule full-team meetings monthly or bi-weekly, depending on the project’s requirements. These meetings should focus on status updates and discussions of interest to all the participants, including support team members. Core team members, however, should be in constant communication, getting together several times a week in order to handle functional issues that may not always pertain to the entire group. An additional reason for adopting the team structure is that it helps control people’s time and the company’s resources.

Positive Communication

Don’t forget to name your project or it will be done for you. As with all nicknames, once it sticks – it is yours. No one wants to be known for managing Project Hopeless or a name derived from a deliberate mispronunciation of the WMS package name.

Do proactively name your project, preferably with a short, catchy title that imparts a positive message.

It is a mistake to let the project slowly ramp up as activities are initiated. Instead, be sure to kick off the WMS implementation correctly, an essential step in managing a positive project communication campaign. First, hold an executive briefing to introduce the project’s name, team, objectives, and benefits. Present the schedule, budget, issues, and risks at the same time. Second, introduce the project to your "customers" – the system’s users in the warehouse. A warehouse project kickoff, held during normal shift hours, is very effective. The goal is to announce the reasons for, and the benefits of the project in an upbeat manner. The presentation should include the implementation plans along with the explanation that future updates will be posted on company bulletin boards.

Don’t keep project status information secret or attempt to hide problem issues. No news is not necessarily good news when it comes to corporate activities. Perfect projects rarely exist. You will gain respect by facing difficult issues rather than concealing them.

Do provide continued project updates following the kickoff. Informing people of the project status helps mitigate gossip such as "I heard the project has been put on hold …." People are much more positive and understanding when they are informed. By sharing issues with management, you avoid surprises and may be fortunate enough to receive an unexpected solution. When problems are discovered you need to get pre-approval of contingency plans.

Training

Never underestimate the planning required to develop an effective training program. Weak training programs are a major cause of troubled implementations. Next to having a system that works, a well-trained user group is the most essential component in a successful WMS implementation.

You must develop a training plan that covers the format, approach, course structure and requirements, administration, scheduling, and resources (hardware, software, and trainers). Training can be paper- or computer-based, in a classroom or on the job. It is essential to promptly determine the correct approach for your situation.

Don’t Miss The Benefits Of Getting Supervisors Involved Early

Do conduct supervisor training. This training provides the opportunity to pilot the training materials and operational concepts. Even though acceptance testing may prove that the system works, it may not identify functional problems that supervisors could uncover during training. Also, users are more receptive when the terminology and examples are correctly tailored for their own facility. When you teach supervisors how to handle exceptions and troubleshoot problems, such as RF communication lapses, you enable them to provide assistance with end user training. This becomes useful if the trainer is a vendor or consultant, because your people are more inclined to ask questions of their supervisor than an outsider. As an added bonus, when your supervisor is in a leadership position, you increase user acceptance.

Don’t Limit Training To Only Functions That Users Need To Know

Do explain how the WMS relates to the each person’s current job and the impact of his or her actions on the overall operation. It is important to discuss why some activities are no longer required, especially if they are replaced by a new WMS function. A step-by-step correlation between the old and new system and procedures confirms the importance of each part of the user’s activities, reduces confusion, and makes any unfortunate return to the old system easier.

Don’t Be Too Confident In The System’s Reliability During Training

System installation can be tricky, and having a much-touted new system go down during training sends a negative message to users.

Do keep technical support available during hands-on training. Problems will occur, but fixing them immediately keeps the dreaded "it is never going to work" attitude to a minimum.

Don’t Rely Completely On Classroom-Based Activities

Do consider building a Mock Warehouse. A "simulation lab" may require time and resources to construct, but the investment is well worth it. Training in a simulated warehouse with actual RF equipment, bar-coded pallet props, and fake storage and staging locations is enormously helpful in relating the classroom instruction to the physical activity on the floor. The mock warehouse should use a training database populated with a sample of the real inventory and locations. Locate the setup in a section of your facility to avoid replicating the RF network, and design receiving, put-away, picking and shipping flows so that they resemble actual operational flows.

Don’t Forget To Evaluate And Reward The Participants.

Do certify the participants. Verify that the users have learned how to execute those WMS transactions required to perform their job. This will highlight, prior to implementation, areas or workers requiring additional attention. A certification program promotes a sense of achievement. For example, you might try giving each user a card that lists all the classes that he or she attended and reward-completed cards with a token of accomplishment.

Project Documentation

Don’t lose track of critical project information or take on the burden of managing a full project library. Project managers begin to lose control when project documentation is spread throughout the company or become overwhelmed by attempting to manage a complete project library. Establishing a balance may seem difficult.
Do develop an electronic project library guide – a fairly easy task if begun early. Create and maintain a spreadsheet that does three things:

For documents such as status reports, list both current and historical items. Minimal effort is required to keep a spreadsheet like this up to date. With this tool, everyone can find all the project’s documents, and the project team is not encumbered with trying to assemble the material in one place and managing a library.

Don’t rely solely on what the vendor provides. Documents supplied with the system tend to be encyclopedic, organized by function rather than topic and not handy for a quick reference.

Do create a troubleshooting guide. This time saver can be a struggling user’s biggest help on the floor. Customized for your operation, the guide should offer simple diagnostic tests and fast fixes for common problems with barcode scanners, terminals, printers, software, and so forth. At the beginning of the project, designate a spiral notebook as your troubleshooting manual. Encourage team members to record, in simple language, frequently encountered problems and how they were resolved. Before the crunch time of implementation, organize this guidebook by subject, set it in type, and place it in an accessible location on the warehouse floor. It then continues as a living document, with new problems and solutions added on an ongoing basis.

These Do’s and Don’ts emphasize the serious attention required for planning implementation activities. Too many WMS implementations struggle and fail, not because of the system’s technical performance, but due to poorly handled project management and people issues. Project activities, carefully planned at the start, eliminate wasted time, money, and effort. Your attention to these basics will facilitate a smooth implementation from beginning to end.

IDII thanks Catherine Cooper of The Progress Group
for permission to use their white paper.

Catherine Cooper is President/CEO of The Progress Group.