Change is not scary

How robust is your change control process? How many incidents are as a result of change? When a significant change goes in to live do you worry about what's going to happen? A robust change process is often seen as a business blocker, but when implemented correctly, it will provide a return on investment.

Since my team implemented a robust change process and actually got buy-in from all affected parties, the volume of incidents associated with releases and significant system changes has all but gone to zero. The ITIL based process is the underlying reason why we've seen this step-change, but just as important is that it's a process that meets the business need and is seen by all to enhance the chances of success so adoption became a no-brainer. Recently, we even managed to get a 3rd party to use the process and they had one of their most successful version upgrades ever.

Often change processes stumble around the need for a change advisory board (CAB) which typically runs once a week or some set time period. This is never timely and most people find incredibly dull and therefore don't attend. A non-working CAB will always kill any attempt to maintain a successful change process so there is no CAB, instead all changes are signed off electronically with the Change Manager maintaining a forward schedule of change and making intelligent scheduling decisions. All the required documentation and information is associated with the change ticket and is therefore available for review by the relevant stakeholders. Workflow and the Change Manager ensures the ticket is only available for sign-off once it's ready and only those who are interested in the change are notified making review and sign-off as fast as possible.

By removing the CAB obstacle, stakeholders outside IT are willing participants knowing that they will only be involved when it is pertinent and their opinion really means something; "No" really does mean "No". Negotiation is obviously possible, but the only way the workflow will allow a change to go ahead is when all checks and sign-offs are completed.

Two to three incidents per release used to be the norm, but in the last 6 months, the norm has shrunk to no incidents per release, having an incident post release is quite odd now and it's reduced our incident workload considerably meaning we can put further time in to the quality of releases.

I thoroughly recommend a change process, but to make it work, make sure you have a strong change manager who is a great communicator and who lives and breaths successful change.