Don’t Think You Can Make Up Schedule Slippage

Schedule slippage is schedule slippage – in the vast majority of cases, if time is lost in the original schedule due to various factors, it cannot be made up, and the entire schedule must be moved back.

This is something that executives obviously don’t like to hear, and so managers and vendors often come up with plans to recapture lost time – but they rarely work, and in the end usually cause even longer delays. It is always better to have a go-live delayed for two weeks than to rush a deployment that isn’t ready and have months of issues to deal with as a result.

Keep Internal Resource Commitments

If you ask WMS vendors, one of the chief implementation problems they cite is resources promised by the customer for a project that never really materialize. This is especially true when a resource is scheduled for “half time” – 50 percent of his or her time on the WMS project, 50% on their day job.

No surprise, the urgency of the day job almost always means the 50 percent effort on the WMS project never materializes, putting the schedule and the entire deployment success at risk.

Perhaps the most important job of the executive champion of the WMS project is to ensure the right level of internal staffing and to monitor that those resources are being utilized as planned. Dedicating full-time resources is good practice.

Get the Right Vendor Project Manager

Over and over again, internal analyses by WMS vendors themselves demonstrate that the number 1 factor in terms of system deployment success is the experience and capabilities of their own project leader.

The clear point: do the right due diligence on the project leader you are being assigned to ensure you are getting a good one with a track record of success.

Ensure You Really Need the Mods

Most companies know making modifications to WMS software increases the risk of implementation issues and also total costs. What many don’t realize is that many modifications are never even used by the companies authorizing them.

First, too many WMS modifications are used not to add real operational value but to simply pave over “cow paths” – the way a company has always done something. This is especially likely to happen when users get together for the “conference room pilot,” and executives don’t set guidelines in terms of what is a value-added mod and what isn’t.

But companies should also be aware that even modifications that do make operational sense often don’t get used when the system goes live.

The key message: rigorously analyze each proposed modification to ensure it has an ROI and that it will really be used upon go live.

Over-Focus on Training

It’s almost a cliché, but after a WMS implementation virtually every company says it wished it had done more training. One of the challenges (again) is that often operators are so busy with current work that there is insufficient time for training them.

There are no magic bullets here, but some proven success tactics have been identified.

• Make sure you include in the project budget the time needed to take existing operators off the job for training or to train on an off-shift.
• Consider “competency-based” training, in which for each role in the DC (supervisors, operators) a set of necessary capabilities for using the system are defined. Employees are not considered trained until they can demonstrate they have mastered these skills.
• Build a high quality manual – many companies have successfully put considerable effort into building a high quality training document, often using the vendor’s manual as a starting point but then modifying the relevant portions to company-specific processes and in a style appropriate for floor-level employees.’

It is hard to overstate the difference in WMS implementations between those with a well-trained staff prior to go live and those with a poorly trained operators.

Make Testing Meaningful

It goes without saying that more testing is better, but the quality of the testing is just as important as the quantity. Common problems in testing for WMS implementations include:

• Placing too much focus on testing individual pieces of functionality rather than integrated flows. Well test entire processes.
• Failure in both WMS and integration testing to test for mistakes and exceptions; for example, don’t just test if the software works say when an order picker does everything correctly – test what happens if they make mistakes, like scanning the wrong bar codes, or turning off an RF terminal.
• Testing is frequently compromised because of lack of available product to use in the testing scripts. This is especially true if material handling system integration is involved. Adequate testing is often not performed because of difficulty obtaining physical product with which to test. Plan ahead to avoid this problem.

What would you add to our list of WMS deployment tips? Let us know your thoughts at the Feedback button below.