I am a proponent of change management (CM). I value the function, even if I sometimes despise the bureaucracy found in typical implementations.
At $work, we follow fairly well established CM process. It’s not perfect and it has bureaucratic elements but it’s well understood and mostly respected. Regular thinking about process improvement has led to critique of the individual elements of the process. Deadlines. Approvals. Communication plans. Success criteria. Change windows.
Let’s talk about change windows. We have a “regular” change window that happens once a month on a particular weekend. This was an IT decision. We decided on a particular schedule and called it the “regular” change window and asked everyone to schedule their changes within that window unless they had justification and approval from management for doing otherwise. The problem is, by the numbers, it is hardly our “regular” change window.
The Numbers
In 2014, just over 89% of our changes were performed outside of the “regular” change window. The trend for 2015 remain nearly identical.
Those numbers mean that we’re (re)negotiating change windows with stakeholders 9 out of 10 times. We’re creating justifications and requiring “off-cycle” approvals 9 out of 10 times. Talk about overhead!
The key to this process failure and resulting overhead is that we haven’t tied change windows to the actual business. We didn’t engage stakeholders to determine when is a good time to make changes for the business. However, in our complex environment doing so isn’t straight forward. We have a multitude of different clients, stakeholders and services. Boundaries often overlap.
Reducing the Friction
We can consider focusing in on major services, identifying stakeholders and establishing regular change windows on a per-service basis. This probably makes sense for the major services but what about the smaller, less visible services? What about services with a single stakeholder? How do we document each change window? How do we enforce changes to a particular service within that service’s specific change window? I don’t know…. but my short-term recommendation is to simply ditch the idea of regular change windows unless we can do them right. Why are we bothering with rubber stamp approvals for scheduling on 90% of changes when we’re going to talk about schedule in CAB anyways? What are we gaining from this?