What is change management? Simple–it’s managing change. The change that needs to be managed could be a company culture, a significant policy change or a simple procedural change brought about by the installation of a new enterprise application. A great example of a culture change can be seen anytime an independent hotel makes the decision to flag its hotel for the very first time after being in operation for decades. The chain has a transition plan for the hotel that is heavy in change management.
This article isn’t about managing a culture change and it isn’t even about a managing the change brought on by a significant shift in a long established policy. This article focuses on the small stuff that is so often overlooked.
If you ever read “Who Moved My Cheese?,” by Spencer Johnson, M.D., then you know what I mean. For those of you who haven’t read this 94-page, large print parable then head right to your human resources department. They probably have a case in the closet.
The reality is that anyone involved in selecting or implementing a new software application had better learn quickly about the importance of change management. You could almost say that change management is critical to a successful project plan.
Many of us have been around since the dark ages and still recall what “On change” means on the flip side of a cardboard room rack card. We recall working the front desk when all the keys were metal and had the room number stamped on them. Remember carbon paper transaction logs to record long distance time and charges dictated to you by an operator after a guest made a long distance call?
Thankfully technology automated procedures like this over the years, but did the human element of change keep up with the technology? Did we make sure all of this technology served to improve a process that had worked effectively before technology? Did we get sold a solution to a problem we didn’t know we had? Don’t laugh–it happens more than you think.
Did you ever have a general manager complain to you that we probably don’t even use 50 percent of the features in the PMS, POS, S&C, etc.? Soon complaints set in about what the application can’t do compared to the latest competition in the market. And if you decided that a full re-training on the current application is needed then prepare yourself to learn that many of the features everyone is looking for have been there from the very start.
So who’s at fault when this happens? Is it the software developer? Do you have too much faith in train the trainer that is now in its 7th generation of staff trainers? Maybe it’s your IT department’s fault?
There could be a simple answer at work here. Maybe these applications offer so much complexity, at the request of so many customers, that it’s just impossible to use it all and still be effective in running your operation. Has any vendor been able to give you the name of a customer that uses 100 percent of the software’s features? Didn’t think so.
As you begin to develop a plan to deploy a software package take quality time to document every process, work flow or policy that might be impacted. Get the stakeholders engaged early. Rely heavily on your managers and supervisors; but don’t forget to include front line staff in these discussions. Get everyone thinking about change. Then prepare to manage that change.
Vendors welcome the opportunity to show all of the unique features their applications have that will generate millions of dollars within the first hours of being implemented. And it will only require 2 hours of training for each user, and it integrates to every other application known in the industry! Great! Let’s do it!
Not so fast. Remember the stakeholders. Did they ask for all these features? Did the vendor even show everyone how the application works in doing what you need it to do now? Are there features you take for granted today that will not exist in the new application?
This is where change management comes in. If your vendor can demonstrate to the group that everything we need today will be there tomorrow, then you will begin to diminish some of the anxiety brought on by change. The group can then focus on the sexy new features, understand what they do, and if they are a good fit for the operation.
Don’t be afraid to say no to certain modules until a later date, especially if they don’t replace something already in use. Wait until a later date when the affected departments can look at tweaking a process or procedure so this feature can be implemented. But don’t forget those features.
So the next time you get ready to put a project plan together for a new enterprise application make sure you include room for change management. Determine at the beginning how much change management you and the team are willing to bite off, chew and swallow at one time. Quick, pass the antacids.
Ron Strecker, CHAE, CHTP, is the chief financial officer for the Al J Schneider Company.
