Change management for happier ITSM
I’ve worked at a few companies throughout my career, from large retail chains, to smaller companies who still have the “start up” mentality. At businesses that operate Waterfall and Agile working methodologies, from businesses who deploy changes daily, to those who deploy monthly (even quarterly).
Here are some of my thoughts on how I’ve seen successful change management work and the frequency at which I think software changes should be made, and the impact these things have on ITSM.
Firstly, we have to accept two things.
- Changes are inevitable — We have to make changes to move forwards. Whether we’re fixing bugs, developing new features or simply paying off some technical debt (lol). We have to make changes to achieve all of these things. Not making changes means not improving, and you should always be looking to improve.
- Incidents are impossible to stop — Sorry guys. It’s bad news. There are more certainties in life than death and taxes. The third is incidents. Something will go wrong. Something will have been missed in testing. Human error will always happen. No matter how much automation, testing, continuous delivery and resilience you build in. Incidents. Will. Happen.
Now that we’ve established these two principal laws of the universe, here are some things I think are important in creating a modern and lean change management process, which keeps engineers happy and excellence in service.
- Get the basics right
Any change management methodology, needs to do some basic things before it’s “OK” in my books.
They are… Create and share your change management process, ensure all of changes follow the change management process (Lab > Staging > Production) (No changes deployed straight to live please) and record all of your changes (I like JIRA) with appropriate information (who made the change, what the change was and how to roll back that change). These things create a great basis for change management.
- Make small, iterative changes often.
This isn’t a new idea. But, despite that, some schools of thought think that changes should be bundled and deployed on regular (or sometimes irregular) scheduled intervals.
The problem with grouping changes in this manner, is that those changes are often large pieces of work to deploy, they’re often not tested against other changes, and are often breaking changes. Some companies will even carry out scheduled maintenance to conduct these changes, which often mean downtime (ewww). Also, how can you tell which of the deployed changes caused the incident?
In my experience, we should be making small, iterative changes often. Why? We can test these very easily. They are very predictable. They are way less disruptive to both the business and customers. Ultimately, the smaller the change, the smaller the risk, and smaller the impact. Also, you’ll probably find more changes possible when making them iteratively.
- Smaller changes make your engineers happier
Engineers aren’t as difficult to please as most companies seem to think. They want to be well paid, they want to feel empowered and want to feel like they can make a difference. The ability to deploy changes quickly and safely means that the “gratification loop” for making changes is a lot shorter. There is a lot of satisfaction in fixing a bug and being able to deploy that fix quickly.
The longer it takes to get changes into production for your engineers, the less they’ll feel like they have the ability to make a difference within your business, and more likely they are to leave your company.
- Monitor the changes you’re making
When you’re making changes, any request for change should have acceptance criteria defined. What behaviour should the Ops Team be looking for after the change has been made? If there aren’t adequate metrics or monitoring, get them added. You should be able to explain and demonstrate how a change has improved your software/hardware/whatever.
- Good incident management supports good change management
As covered in my previous blogposts, good incident management processes are there because of the inevitability of incidents. We accept that incidents will occur and have measures in place to deal with things when they do go wrong.
What I’m saying here is give your engineers the freedom to make mistakes. Don’t blame. Learn how to stop making the same mistakes and move on.
- Continuously improve change management
Review your change management process regularly. Use reporting from your change management software to report on statistics like…
* How many changes are made
* How many were rolled back (%)
* How many production defects introduced
* What was the most common reason for production defects
* How many changes caused issues due to human error
* Flight Time
* And many more…
The point here is, whilst accepting that incidents will happen, we must also look to do everything we can to stop them happening whilst maintaining a healthy cadence for change management. Similarly, make sure your change management process is working for you.
Retrospectively looking at metrics, KPIs and CSFs will help make change management better.
- BONUS BULLET— Communicate with the support team/service-desk
Hey guys, if you’re making some fairly risky or large changes to your service or platform, please let your support team know. They are going to be the ones receiving questions from customers once the changes are made. It’s good manners to give those guys a heads up. You’ll be doing them a huge favour.
In conclusion, a great change management process, in my experience, is built on the ability to plan and implement changes at a very fast pace, supported by a business who are communicated with often, and understand that when things do go wrong, we’re still a team who both support and challenge each other appropriately.
Does some of this ring true to you? If so, drop me a comment underneath!