A Communication Strategy for Change Management

People don’t like change. Understanding that truth is the first step to crafting a change management strategy — and over-communicating your strategy is the best way to make things stick.

For example, at a previous company I embarked on a strategy to clean up a very sloppy project management delivery system, with consistent reporting and management oversight of where various project teams were spending their time and resources. What I got from my peers and management was strong push-back. And so my team re-tooled and tried again. We stopped talking about reporting, stopped pushing people back to a SharePoint site where all of the project stats were being collected, and opted for daily status meetings, almost daily email communications, and more face-time with leadership to articulate (again) what had been shared in the daily status updates, the weekly rollups, and the bi-monthly 4-blockers.

Our strategy did not change — but our communication increased. Suddenly everyone loved what we were doing, even though what we were doing really didn’t change at all. Communication was the key to our change management success.

There is a natural progression in the growth and development of a software development team or start-up. As the problems and your solutions get more and more complex, the tools you require to manage these solutions needs to be able to handle these changes. What would software development be without change management? The two are inseparable. To successfully develop and deliver your solution, you must put in place the tools and processes and knowledge required to successfully perform change management.

When people talk about change management in high-tech, they are usually referring to the tools that manage source code. However, this is just one aspect of the solution. What works for software teams can be applied more liberally to the rest of your organization. If you step back and look at all of the components, change management consists of many different pieces, including:

• Identifying components, structure
• Controlling releases, visibility and changes
• Ability to report status, changes, and their impacts
• Ability to validate completeness and track changes
• Ability to trace the process from the individual developer making a change through the release of the software
• Ensuring that changes go through a particular life-cycle
• Ability to control team interactions at multiple levels
• No matter how complex and messy things seem now, just get started

Change management is all about managing the increasing complexity of a project, plain and simple. Your team must understand how to manage the complexities of an ever growing, always expanding list of customer demands, enhancements, and features.

To successfully build and deploy a change management platform, you need to understand how it fits into your company. What are you current processes? How strictly are they adhered to? Who needs access to this information, and where are they located? You may all be centrally located in one office now, but what are your company’s plans for growth? The actors (roles) will tell who will use your change management system, and help you to model out the flow of communication necessary for a successful system.

At the end of the day, a poorly communicated change management strategy will fail. If you find that people are resisting change (and assuming that the changes themselves are the right ones), take a look at your communication methods. Mix it up. Err on the side of over-communication. People will not support what they do not understand.