“People hate change!” This is a pretty well-accepted statement for those of us who work in the technology industry. Most of us involved in driving change in large organizations have the battle scars from those that were less than successful.
But I’m here to take issue with this truism. Like most generalizations, there may be truth there, but it’s not universal. Some people don’t like change, some people embrace it. Most people take exception to change when it is thrust upon them unexpectedly, not well planned, or when it doesn’t take their individual or collective needs into account. And almost all of us resist when we’re told to do something without being told why.
Any change to a tool, process, or organization makes fundamental changes in the way people do their jobs. Even when the change is better than what they have now, people fear the unknown. Specifically, they fear that they are not up to the change. The more we can do to prepare them and involve them, the better the experience will be for all concerned.
So, instead of strapping on your Kevlar and raising the shields, plan for success. Here are six things you can do to make changes less painful. These tips won’t remove all the resistance, but they will make things easier for everyone.
- Identify and involve your stakeholders early. Take a 360-degree look around the change. Who will be using the system? What will change upstream, downstream, or in support functions? What’s the impact to internal and external customers? Describe the change to leaders in departments and groups that you may not think will be affected, and ask them what they think. Even in organizations that have formal, well documented business architectures, there are often informal connections that aren’t considered when changes are made. And when you talk to them, listen closely to their answers for their assumptions and concerns. Make sure these find their way into the documented requirements.
- Over communicate. Use company newsletters, direct e-mails, chair-drops and company intranet sites. Craft and send top-down e-mails from executives. Send join communications from the sponsor and his or her counterparts in all the organizations. Describe how the change will affect everyone involved, even when it’s minimal. Tell people when, where, how, who, and – most importantly – why. Give a cohesive and consistent message. Begin months before the change will be rolled out, and make the communications frequent. Consider the feedback and questions you receive yet another opportunity to sanity check your requirements and assumptions.
- Build a network of champions. Involve people from the requirements team, end users who concerned about the change, managers who believe in the change and nay-sayers that will tell you all the reasons it can’t work. Use those involved in the requirements efforts, the design, and in UAT. Show them demos and design specs. Educate them on the benefits of the change, as well as the downside. All of these people will bring disparate and valuable perspectives to the change. The only qualification is that they care about what the change might mean to them, their group, and the organization as a whole.
- Iterate. Create multiple cycles of requirements, design, communication, testing, user acceptance, and planning. Involve the test team in the requirements. Get the stakeholders to validate the design and planning. While sign-off and exit criteria are important to move to the next phase, build in flexibility and iteration in the planning phase to provide sanity checks and accommodate changes along the path.
- Stay involved. The sponsor of the change is not allowed to throw requirements over the wall to the delivery or implementation team and walk away. They must stay involved with every phase and every change, verifying and validating that what they thought they wanted is really what they want, and that what they really want is what they’re going to get. Ask questions. Keep asking questions until there is no ambiguity. Micromanagement may make some enemies, but attention to detail will result in a successful change.
- Provide exceptional post-implementation support. Once the change is implemented, whether over a period of time or overnight, make sure there is a person, a phone number, a department, a webpage, an e-mail address, a trouble-ticketing system, a command center – any avenues that exist – where people can ask questions and report problems.
One tip that will go a long way towards support is to make sure you pay close attention to how this change will impact the executives in the organization. The perception of success by the leadership of the organization is an important measure of success. If they are inconvenienced, annoyed, or prevented from getting on with the business of running the company, their opinions will carry weight about the success of the change no matter what the true metrics say.
Large-scale change efforts can be difficult, or they can be rewarding and appreciated. The difference between disgruntled victims of change and eager participants is the level of preparation, involvement, and support that they are given before, during, and after the change.
