Nearly all of the emphasis on implementation of warehouse management systems (WMS) and other software is directed toward functionality and technical aspects. Often overlooked — or discovered too late — is human resistance to change.

Any banker can tell you that there are still customers, admittedly fewer every year, who will not use an automatic teller machine. Many others cannot or will not use a computer.

I am reminded of a short training project held at a public warehouse in Moscow. The company was owned by two Americans, but the remainder of the staff was local people. When the presenter described the importance of using a computer to maintain a warehouse locator system, one of the line supervisors slammed his fist on the table and exclaimed: "We are clever people! We don't need those computers!"

You don't have to go as far as Moscow to find similar attitudes.

The implementation of a new system should begin with the development of the project team. That team should include hourly workers as well as risers and managers. It should include folks from the warehouse as well as office people. It certainly should include the mad Russian just described.

The project team should meet on a fixed schedule, not so often as to raise the risk of team burnout. Members should be visiting with their colleagues in between meetings in order to get feedback on the implementation process. Keeping all your people informed of progress is important for the project team.

The project team should develop, or at least endorse, the objectives and benefits of the new system. They should present and monitor the implementation budget and schedule. They should discuss the best ways to introduce the project to the system users.

Before the new system is launched, users must be thoroughly trained. The training program requires planning, and that is part of the job to be addressed by the project team. The training project should include explanation of how the new system will change each person's current job. It should address the "why" as well as the "how."

Never underplay the issue of system reliability. Never forget that there is no guarantee that the new system will not fail. In other words, overconfidence can be fatal.

Maintenance of technical support during both training and start up will prevent the possibility that some of the users will express a fear that the system will never work.

It is important to make tracks and keep them. Documentation of the project is essential, and each document should be readily accessible. Electronic versions should be backed up with printed versions as well as a backup data file.

There will be bumps in the road, and a troubleshooting guide will explain how each of the bumps occurred. The result of these notes should be a manual that describes things that could go wrong and proven ways to fix them. This document is never complete, and it should be revised and added to as the implementation is completed and the system has gone live.

In summary, introduction of a new system is too important to be delegated to the technical experts. Without the support of most, if not all, of the people who use the system, there is a risk that it will not perform in the anticipated manner.