The basics of CRM change control

July 25, 2018 Mark Payne

Following on from my previous blog post which, unashamedly, focused on user adoption and making sure it happens, I thought it might be useful to take a look at the other great post go-live challenge; change control.

For clarity, in this instance I am not talking about managing the organisational change that goes with running a new CRM system. Instead I am referring to the management of system tweaks and enhancements that, for those that were paying attention to my last blog piece, are a necessary part of a successful CRM system.

In the interests of full disclosure, I am also not intending to get into a deep discussion about the various different change management methods out there. Every consultant I know has their own opinion on this subject and there are loads of resources available if you want to get deeper into the subject as it relates to your own specific scenario.

Instead, what I am aiming to do in this blog is to look at some basic principles that should be easy to implement to start your change control process off on the right foot.

Before we start, why should you care about change control? Quite simply, change control is there to reduce operational risk and to ensure that all system changes are implemented in a controlled manner. Without it you run the risk of introducing change that nobody wants, in the wrong order and also introducing bugs to your system. You don’t need me to tell you that this scenario is not good for your user adoption!

There are 5 simple principles that I would like to briefly discuss:

1. Always have a test system.
2. Implement a change log.
3. Agree a release schedule.
4. Test, test and test again.
5. Communicate change to your users.

Always have a test system

This may seem the most obvious point but, without a test system, it is impossible to rollout system changes in a controlled manner. If you only have your live instance then developers will need to work directly on that and the risk of breaking your production system is significant. With a test system in place, changes can be developed and tested in isolation before being deployed to live. If you are expecting a significant pace of change with periods of testing overlapping ongoing development then you may want to consider having a 3^rd instance (1 for development, 1 for user acceptance testing and 1 for live).

The good news is that (depending on the number of licences you have) a lot of cloud-based CRM systems now come with an additional test environment at no extra cost. In addition, if you have an on-premise deployment and an on-going support relationship with an implementation partner then it is likely that they will maintain a copy of your system in-house.

Implement a change log

You can’t implement changes unless you know what they are! A change log helps you to note what requests users have made and, more importantly, track where they are in the change process lifecycle. A change log can be as simple as a spreadsheet that records, at a minimum:

• Details of the change.
• Who requested it (so you know who to ask for further detail).
• Its current status (New, Under Consideration, In Development etc.).
• Which release it is due to be included in (see the next section).
• The expected date it will be available to users.
• If it is not going to be implemented, why not (so when you get asked for the same change again you can refer back to your notes).

Agree a release schedule

Having a defined release schedule is an easy way of controlling change and ensuring a constant stream of improvements reach the users. This maintains momentum for the system and helps users to realise that their requests are not simply falling into some big black hole never again to see the light of day.

There are multiple ways to implement a release schedule but a very simple scheme that I have seen work effectively is to have several maintenance releases containing small changes throughout the year (maybe one per month if the amount of change requests coming through from users is large enough). This can be followed by 1 or 2 major release per year in which you implement more significant changes. Clearly you will also need to allow for “hot fixes” that should only address bugs or changes to functionality that are stopping people using the system at all.

Test, test and test again

The title of this one says it all. Introducing errors with a release of new functionality is guaranteed to reduce the confidence that users have in the system. It is important to remember that you should not only test the change that has been made but, preferably, everything else as well (regression testing).

Communicate changes to your users

All the good work achieved by responding to users’ requests will be undone if you don’t tell them you are going to do so or already have done so! Communication of your release schedule is a must. A simple “What’s new” bulletin at every release is also an easy way of communicating change to them.

As I mentioned at the start of this article, change control is a huge topic, but I hope that this piece has given you some simple things to think about that will help de-risk the implementation of system changes on your CRM implementation.