Change Management Matters

The producer, her face pale, rushed up to me when the cameras stopped rolling and said, “You shouldn’t say that!”  I was being interviewed for a segment on Bloomberg and was wracking my brain to remember what kind of word bomb I may have dropped.  The offending phrase? I had said, “You must consider change management.”   She had interpreted it to mean that I was recommending a change of management team. I had to explain the definition of change management. And it reminded me that no one is born knowing this stuff.  Sometimes we have to learn the hard way.

At the young age of 24, I led an implementation of ERP software at a location of a Fortune 50. The technology, systems, and processes for the entire manufacturing facility – from contracts to purchasing to production to shipping and invoicing – were completed and the system was up and running on-time and on-budget.  The President of the facility presented me with the company’s coveted Annual Outstanding Achievement Award for my efforts. I have chosen to say “for my efforts” because I can’t honestly say that I achieved results.  

I couldn’t articulate the problem at the time as I knew nothing of change management. Now I know that the implementation problem I sensed is called “resistance to change.”  I had never before considered the people side of the equation when deploying new systems and processes.  As an engineer born with a systems-thinking mindset, it didn’t naturally occur to me that a human would refuse to cooperate with improved methods, rules and systems. In spite of repeated trainings we provided and my daily offers to assist the users, I saw the old-timers finding workarounds to the new software system.  I would see them throw away reports without glancing at them, ignore their new computers which were gathering a deep layer of dust, and go back to their old manual methods of running the production facility. They would come in every morning with their clipboards and pencils, shouting and jockeying for the attention of the foreman to get their products made ahead of others in queue. They ran the plant at full capacity at all times.  

The problem was, because I knew how to use the software system, I now had an overview of the big picture. I knew the demand, the open contracts, and what the customers expected and when. I could see the ever-increasing inventory levels of finished product.  And I could see the shipping schedules that showed these products weren’t due to ship for years. The plant was overproducing at an alarming rate.  They were completing six years’ worth contracted parts and components in under six months. And I could see that few new orders were coming in nor did we have the ability to directly influence more orders/sales as this plant was a supplier to parent entities that were producing the final product (aircraft and weapons systems – products with very long sales cycles). At this rate, our plant risked running out of work. I tried to show the key managers the data but was shooed away as a nuisance who didn’t understand “how we do things around here”.   

Twenty-four months later, as I had predicted, the parent company closed the plant. I had heeded the writing on the wall and made my exit long before the plant was shuttered. The saddest part is that a small town lost one of its biggest employers. And I still believe that had I understood the principles of change management and user acceptance had been achieved, the managers may have made different decisions and all those people (almost 1,000) would still have their jobs. That’s a lesson I never forgot. 

Read Part 1 of The Four Things I Wish I’d Known here.  Read Part 3 here.