By Jon Bergman and Lonnie Sanders III, CIOPS Associates
The store manager arrived at work at 9:30 am, just as she did every workday, and she immediately started readying the store to open at 10:00. She turned on the lights, straightened out the merchandise, powered up the computers, turned on the registers and addressed some paperwork.
Everything seemed fine…until 45 minutes later when she went to ring up the day’s first customer and discovered that something was screwy with the register. While she vaguely remembered getting an email the week before saying that corporate was going to be downloading some new software, she was certain that email had appeared pretty routine. After all, if they had announced that on a specific day and time they were going to be downloading software to change how the registers worked, she certainly would have taken notice!
Needless to say, what started out as a “normal” day quickly became quite frustrating—for her, her staff, the employees at the organization’s hundreds of other store locations, and the hardworking folks at the company’s help desk. No one was happy.
Why weren’t the store managers informed about what to expect?
We’ve seen this happen far too many times. IT goes through a lengthy process to make changes, but then fails to communicate these changes to the people who will be impacted. Or, the notice that IT does send out is so vague or technical that the key points of how users are affected are not communicated clearly.
Change management is a fundamental tenet of any IT Service Management (ITSM) process; and there are many things to address. As we’ve written before, ITSM basics include Incident Management, Change and Problem Management, Knowledge Management and Asset Management. An important and often-overlooked aspect of this change is communication. Leading ITSM practices include a change communication strategy for effectively communicating changes to the user community.
Putting a change communication strategy in place
As with most initiatives, a good approach is to start small and grow incrementally based on experience.
Ideally, as part of your ITSM process you will have put a CAB (Change Advisory Board) in place. The CAB is a cross-disciplinary team of members who meet weekly to approve “normal” (i.e., anticipated and planned) changes. Typically, a CAB includes those requesting the change and those performing the change. However, those who are most affected by the change—the user community—are often not part of the CAB process.
The CAB should be responsible for ensuring the changes they approve are appropriately communicated as part of the implementation process.
The goal of your change communication strategy should be to ensure a policy of “no surprises.” Surprises, such as that store manager’s experience, tend to cause confusion and conflict. If you want everyone to get on board with a change, you need to provide the information and education that will enable them to do so.
Tips for a successful change communication strategy
- Take a broad view of “change.” Keep in mind that “change” includes user experience, system, process, and organizational changes.
- Talk to everybody. Because of the inter-dependent nature of system and operational environments, changes can affect systems, functions and departments that were never considered to be impacted by the change.
For example, that register change doesn’t just need to be communicated to the store managers. The change may impact credit card acceptance, which impacts PCI (payment card industry) compliance. Which means that compliance and finance also need to be in the loop. - Communicate significant changes before the change occurs. “Significant changes” are those that will have wide-ranging impact to a business function, such as changing the way that the registers operate. All stakeholders need to be told what is happening, when it is happening, how it will impact them and what action, if any, they will have to take. In fact, for significant changes, the affected stakeholders and users should ideally accept and approve the change before it is implemented.
- Communicate significant changes again when the change occurs. It doesn’t hurt to communicate that this change was implemented and provide a link to the instructions regarding what the end user must now do or see differently.
- Err on the side of over-communicating. It’s always better to over-communicate change than to under-communicate it, as this helps ensure that the word really does get out. You are on the right path when users start complaining that they are receiving too many emails about changes!?
- Use both “push” and “pull” notifications. “Push” notifications are notifications that are sent to a list of recipients, often through defined email distribution lists. “Pull” notifications are posted to a central repository of change notices that users can access to review changes that might affect them.
Ultimately you should have both. When you are just getting started it’s often best to start with pull notifications, since it sometimes takes some time to identify which business processes, functions and departments will potentially be impacted by different categories of change.
Use different communication mediums for communicating change, such as regular user group meetings, group-wide voicemails or texts, and postings on wikis or intranet sites. Adopt media consistent with the company culture, not what the IT organization finds easiest. - Create standard templates for change notifications. The more standardized the communication process is, the easier it is for users to quickly review and understand the impact of change. Your template should include items such as type of change, time of change, change completion status, point of contact for gaining more information on the change and, most importantly, how the user is impacted. This communication should be short and have the key take-way as part of the headline.
Ultimately, software applications such as ServiceNow should be able to discern which users should be notified of a change and when. However, it takes time for your ITSM processes to mature to the point where this is the case. - Don’t communicate in technospeak. The previous seven points on this list will all be for naught if you fail to communicate the change in a way that is meaningful to the communication’s recipients. This means that you need to think in terms of the practical impacts of the change for the end users and the overall business impact of the change (i.e., the business benefit that explains why you are making this change).
If, for instance, you send out an announcement that you are “upgrading the Oracle RMS environment,” your announcement will be pretty much meaningless to everyone outside of the IT Department. If you say, “we are making software upgrades that will significantly change how all of the registers in the stores operate, and this is why we are doing this,” then people will take notice.
Of course, a communication like that should always be accompanied by instructions regarding how to do things after the change has taken place. Essentially saying, “Surprise! Nothing works the way it used to, but you’ll have to figure it all out for yourself” is not a winning approach.
Establish a regular cadence for deployments
When you are consistent regarding your deployments for specific business functions, such as only making store changes on Thursday evenings at 10:00 pm EST, then those end users will know what to expect. We’ll dive more deeply into this issue in our next blog post.
In the meantime, if you need help getting ITSM in place, give us a call. This is one of our areas of expertise.
Contact CIO Professional Services
About Jon Bergman
Jon is a business-driven executive focused on near-term results and positive outcomes for his clients and customers. Jon has over 40 years of diverse experience as a CIO, management consultant and business owner. He has been with CIOPS for a year.
About Lonnie Sanders III
Lonnie Sanders is a program/project leader with exceptional leadership skills and technical knowledge. Clients appreciate his extensive experience leading cross-functional and multi-site teams to produce successful project results in diverse industries and domains. Lonnie has been with CIOPS since 2018.
About CIO Professional Services
Based in the San Francisco Bay area, CIO Professional Services LLC (CIOPS) is a top-rated Information Technology (IT) consulting firm focused on integrating Business and Information Technology. Our consultants are all hands-on executives who are veteran CIOs and Partners of Big 4 consulting firms. Companies come to us seeking assistance with their information technology strategy as well as for interim or fractional CIO / CTOs, and negotiation and program management/project rescue assistance.
