Thinking of the larger change initiatives that I have been involved in over the years, I recently wondered: What was the easiest, and why? Without question, it was the implementation of a Materials Requirements Planning (MRP) system, used to track inventory, schedule production, purchase materials, and track costs at Solo Cup Company.
Our task was fairly straightforward. We needed to replace the existing mainframe system with a new server-based system. While the project was complicated in terms of setup and timing, it was not difficult by change management standards. For example, we encountered little resistance. When it came to rolling the boulder uphill, the slope was not very steep.
I attribute the relative ease of implementation to the following factors:
Clear sense of urgency
The reason for the replacement and upgrade of the system was the so-called Y2K bug. If we didn’t replace the old system, it would cease to function properly at the stroke of midnight at the dawn of the millennium. The system was essential to the operation of the company; it was clear to everyone that the change needed to happen.
While the new system replaced the functionality of the old system, the features of the new system were miles ahead. The user interface was easier to use and learn. The database structure allowed reports with more and better information. Since we were starting from scratch with a new database, we were able to fix any lingering issues before loading the new system. No doubt, it would help people do their jobs more efficiently and effectively.
Plenty of resources
Although the ultimate deadline was December 31, 1999, the project was started in early 1997. We were given enough time to do things right and not rush. Also, we had a capable full-time project team of four, plus dedicated IT resources. No one ever complained about budget constraints. There is something to be said for having the capacity to do the job right!
Since we had people and time, we were able to provide each user of the system with on-the-job, one-on-one training on the system. Each person learned how to perform his own job with the new system over the course of three weeks. The users had enough time to get comfortable with the new system, prove to themselves that it worked, and have any questions answered in person.
Minimized extra work
During the three-week implementation, the data needed to be entered into both the old system and the new system. This duplication was necessary to prove that the system was working properly before going live. Instead of burdening the users with twice the work, the trainer would enter the data into the old system for them. Not forcing them to add extra work during the implementation reduced any animosity for the change and allowed the users to focus on learning the new system.
Useful reporting structure
Although each of the users worked at a distant manufacturing plant, most reported to either the corporate logistics or purchasing departments, and their bosses were the same directors who were sponsoring the new software. The reporting structure was useful for making centralized decisions and standardizing processes. The lines of authority, and our ability to standardize across plants, were somewhat trickier in instances where the users reported to the individual plant managers instead.
No culture change required
As a straightforward software upgrade, there was not much of a culture change involved in the implementation. The organization with the old system was generally the same as the organization with the new system. While increased accessibility to information might have provided the opportunity to create a culture change, it was outside the scope of the project. A change in culture was not required to successfully implement the software.
Not all change initiatives are difficult, and resistance is not always a struggle to overcome. With the right combination of factors, change can seem downright easy.