The Change Management Process
3 min read
You only need to visit the Wayback Machine internet archive to remember how much change has occurred on the internet since its inception. But what exactly should an organisation consider to effectively manage change for their website?
It shouldn’t come as a surprise that change should be owned and considered by the whole organisation. Just because the server (wherever it is!) has a plug on it, doesn’t make it an IT problem. That said, it is important for IT to manage an overarching change process, but the whole organisation must feed into it.
A typical IT change process will focus on the risk and impact of change, and also on security. This normally takes the form of a Change Advisory Board (CAB) who will meet monthly, agree on system changes, and contingency/rollback plans.
Common changes feeding into this type of plan will no doubt be known as system releases and software patches. Microsoft users will already be familiar with ‘Patch Tuesday’, but what happens with other changes outside of this?
For many websites, there are constant changes, so it’s key to define a release period that allows changes to be developed, tested, and signed off by an internal owner before an eventual release. The CAB may also want assurances that code has been tested for security issues in order to minimise risk. If your team is using Agile, then you will most likely be running fortnightly sprints.
So now you have a Board to approve change, and a defined release schedule for updates, that’s it right? [Checks notes]
Umm, what about our users?!
While the multitude of changes may be minimal in scale and may simply be obvious enhancements, some, that impact the dials of the organisations (such as revenue, sign-ups, or lead generation) will require a review of analytics and user testing to inform what to change. A great example is an online music store. Their key aim will be to sell the latest Beyoncé ditties. But, if the website itself is slow, or the buying process is cumbersome this will just cause users to go elsewhere.
Multiple analytics tools exist that enable a website or product team to test a conversion funnel, such as Google Analytics. If you want a more visual understanding of how users interact with the components on the page, then a tool like Hotjar or CrazyEgg will let you see change.
What is important here is the volume of visitors or time itself. To properly test a funnel, you need data for at least a month, or 1,000 visitors to spot problems that will help increase your conversion rates.
So, while lots of change requests will come in, it’s important to stand by your Customer Experience strategy and balance this with the Change process. Without doing this, you’ll be working with quick fixes rather than making decisions based on user data.
For example, you could build a period for testing change hypotheses around key events within the organisation. For instance, some sectors will have a main annual conference, so it would be wise to collect data and test the funnel on smaller events in the lead-up, so changes can be made before registration opens for the main event. Then you can use that booking window to collect more data for the next iteration.
So, remember that there are multiple types of changes that affect websites, and it is key to ensure that system updates, bugs, and enhancements are managed effectively, but also that all of these require input from different parts of an organisation, and of course, your users.
If you’d like to find out more about how Cantarus could help you with your digital needs, please get in touch via our contact form or email us at [email protected]