Is your organization considering a move to O365 or looking to adopt more features in the O365 platform? As IT people, we are often consumed by the technical aspects of migrations and rollouts. Sometimes the success of a project is not just about the technical execution but also the user experience, especially in productivity platforms used daily by the employees of the organization.
In this post I’m going to highlight some of the things I’ve learned over the years to help soften the edges of disruption and get everyone to embrace the change instead of pushing against it. This will drive an increase in feature adoption, make IT a business enabler, and help to solve problems across the organization.
The key is setting the correct expectations. With any significant change, there are often disruptions, confusion, and things that go wrong; however, platforms such as O365 can offer immense benefits to employees, their teams, and the organization as a whole. Everyone needs to know how the changes can be beneficial to them and how it can make their lives easier, even if it comes with a little pain at first.
Drive excitement in the organization
Build a team of internal champions, non-IT power users, the folk who others can reach out to within the organization. These individuals can better relate to the various departments processes, constraints, or other concerns. An invitation to become a champion should be exactly that: an invitation. If people are nominated or volunteered for the role, it might not create the positive team of champions that this group should be representing. They can be early adopters / pilot users, likely already excited and understanding of the benefits of the change. Empower them to be subject matter experts in their corner of the organization, cheerleaders scattered among the masses to build excitement, answer questions, and show off the capabilities of the platform. Consider them first responders for others, likely already known and trusted, able to offer immediate assistance without having to formally engage with IT. Continue to involve and empower them so you may solicit their feedback as the project progresses.
Build a steering group consisting of senior leaders in the organization. Help them understand the business benefits of the change: how the change could improve efficiency, increase collaboration, or whatever are the appropriate drivers for your organization. These are the leader voices you can use to drive adoption, excitement, and understanding. Avoid factors such as “We are closing a data center,” “The Exchange environment needs replacing,” “Microsoft is dropping support for X.” These may be true but are largely irrelevant points to the majority of the organization.
Managing the message
Communication with everyone is critical to setting the right expectations. There are many ways to engage with people, and the methods used will be dependent on your organization’s culture and structure. Emails, town halls, posters, and lunch and learns are just some examples of ways to get the right message out. But what should that message be, and who should deliver it? Business benefits should be delivered by the steering group members or by the champions. Technical elements should be delivered by IT.
Let’s look at a couple of examples:
- O365 will help us collaborate and work on proposal documents in real time. That’s a message for non-IT to deliver.
- O365 will change how you log in to web-based email. That’s a message for IT to deliver.
Benefits should be communicated first to help with understanding why the changes are being made. Technical communications should come second, closer to the actual migration, to guide everyone through the change.
Technical communication and disruption types
Written, technical messages should always be run through a non-technical member of the organization. Sometimes it is hard to step away from the jargon and lay things out in ways everyone can understand. Ask them to explain, in different words, what the message is conveying. If they can’t, the message will likely not be well understood and should be recrafted.
When it comes to user impacting disruptions, there are three types, and each require some form of messaging. These are known knowns, known unknowns, and unknown unknowns. The first two are the simplest to communicate.
Let’s have a look at some examples for the first two types:
- Perhaps the icon for Outlook will change as the newer version is rolled out. This is a known known, and communication can be straightforward for changes like these.
- When will the user be migrated? This is another known known and straightforward to communicate.
- When Outlook first attaches to the Exchange Online mailbox, it will display as empty. The time it takes to fully populate the mailbox will depend on several things outside our immediate control. How big is the mailbox? How much bandwidth is available for download? This is a known unknown. We know that the mailbox will be empty when first opened. We know it will take time to download. The unknown here is how long will it take. That’s OK; the message should be to set the expectation of the known while reassuring the user about the unknown. The first reaction from people presented with an empty mailbox is that it all got deleted! Give them a heads-up on what to expect, request patience, and mix in reassurance.
Unknown unknowns are unpredictable by their very nature. They could be unforeseen complications in the migration process, identification of a new bug, etc. They could halt migrations, change timeframes, or otherwise alter that carefully laid-out plan. This is the hardest to communicate and sometimes the hardest to identify. Clear lines of communication need to be opened, allowing anyone to inject concerns, things they have noticed, etc. The actual communication can only occur once it becomes known, and that must be captured by open communication. You can still prepare for the scenario in the event that something is identified. Break-glass processes can be created to get the message built and delivered ASAP, to reset the expectations or offer other guidance to anyone impacted.
Final considerations
In the end, this is about building those relationships across the organization, enabling everyone to gain value from the change, and helping to make everyone feel as though they are a positive part of the change, not just experiencing it, or worse—feeling as if they are being subjected to it.
Hopefully this blog post has helped to stimulate thoughts on how to better manage the message of change in your organization. These concepts are not unique to O365 and can apply to any large user-facing project.
Doing well here can help put you on a good path for other future changes. You’ll have built those relationships and built that trust to execute in a collaborative way, engaging with and understanding the business, showing greater value.
Here at Converge we have helped a number of organizations, from small to large, with their moves to O365 and other large IT projects. Our experience can bring to light many of the known knowns, known unknowns, and even change unknown unknowns to one of the other types, just because we’ve already seen them. We have experienced an array of scenarios, helping projects be successful, not just to IT, but to your customers, the end users, and the consumers of your services as well.
