Change is arguably one of the riskiest behaviors within IT. Whenever we make a change, things tend to break. It is in no way coincidental that one of the foci of change management is post-change incidents, i.e. the errors introduced by the changes we make. I would go so far as to say that the only thing associated with higher risk than change is not changing.
One of my many roles at work is that of change coordinator for a large subset of our customers. I have learned a lot in this capacity, and have come to feel that, while Incident Management is the natural first step in ITIL implementation, until you start implementing Change Management, the majority of your effort is largely spent firing fires.
When I wrote my blog post about important features of a service management tool, I wrote “I am increasingly coming to believe that the change management process is perhaps the most important one for success in ITIL – not to mention DevOps – adoption” – and I stand by that assessment. Not because change management is such a revolutionary idea in and of itself, but because of what true management of change means for a business.
This was originally written before I read chapter 18 of the DevOps handbook. I feel strongly that peer review has greater legitimacy and chances of success than a system where a change manager is solely responsible for changes that may or may not fall within their area of expertise. It further grants employees more agency and autonomy in performing their jobs. While not directly addressed below, peer review is compatible with my views on change management.