As the CTO for an organization, you are charged with not only solving the problems, but also delivering, which means getting what you and your team have accomplished into the hands of the users. Now the real problem begins.

The thing to appreciate is most users are not technologists. We are comfortable upgrading our tools regularly, we welcome change, and embrace it. If you are anything like me, you don’t need any specific training, as you love to explore yourself. Normal business users are not like this, any change that gets in their way of them doing their role, is friction.

Small incremental changes are usually welcomed, especially if it fixes an annoying bug or a long winded feature. These generally don’t need anything more than an email/release-notes type of communication. Anything large, that has a significant change in the way they interact or manage their workflow, will require a change management plan.

The Plan

First thing you need to do is to create a project plan. This project plan outlines everything that needs to change, when, who, and how. The plan should be very detailed, in terms of knowing exactly what the steps are, including the criteria for success.

Usually this involves how data is going to move around, the exporting/importing and validation. Nothing worse than delivering a new solution to users only for their data to be left behind in the older system.

The plan should assign who is responsible for each step including execution and confirmation.

The plan defines the overall success criteria, alongside a timeline. This gives complete visibility into the process, and no step should be too small. Simply saying “Migrate email accounts from GSuite to O365 this weekend” is neither a step, plan or directive.

Communication

Once the plan has been set, the next thing is to make sure everyone who is involved with the plan, including those the plan effects, is fully informed and educated.

Make sure the plan is communicated well in advance, setting out the why. Bringing people along in the journey as to why something is changing, makes any wrinkles/issues while implementing so much easier as they will feel in the boat with you.

Be as detailed as possible, particular for users that are outside of your group, making sure they understand when certain systems (if) will be unavailable and for how long. Detail what they can and can’t do. Do not leave it to the user to figure this out for themselves.

Remind well in advance, including a daily emails leading up to the start. Considering holding a few meetings, with department heads, or those that can then distill the message on down.

Once execution of the plan starts – give regular updates. Let people know things have started, and give periodic updates, even if there is no update, that things are still progressing. If you are updating a public site, then consider setting up a status page that will users updated on progress.

https://health.aws.amazon.com/health/status

Once completed, good or bad, communicate to the users, thanking them for their patience and offering a specific support channel to ask any follow up questions.

In short – you cannot over communicate.

Training

Finally, make sure your users know what they are receiving. This is not communications, but training them on how the new system is going to work. How is it different, what can they do before they couldn’t do prior (and vice versa).

Outline a whole training schedule, including videos, articles, meetings, anything that will help prepare the user for the new system. If it is an internal tool, then consider letting users play with the staging environment (clearly noting it is dummy data) while they wait for the new launch.

We often assume users will figure it out for themselves – and for times when Facebook, Google change something, then they will. The reason is that the stress/pressure is off. Making changes to tools that someone relies on for their professional career, the luxury of self-discovery is not there.

Change Management is hard – it is a whole discipline by itself. With some forward planning, solid communication it can be a successful transition.