Article first published 22nd May 2017
Process re-engineering is never an easy thing. Studies have been carried out which map peoples reaction when subjected to significant life changing events and this is no more apparent in the work place when reviewing some of the core ITSM processes. A key one I have observed having the most significant people impact is Change Management.
Since starting out as a contractor in 2014, I have had the opportunity to reshape the ITSM process on a few occasions. They resulted in a significant shift in the approach towards change management, the underpinning processes and use of the toolset.
Lets be honest, Change Management as a process is very well defined. The common text books have it documented to a good level of maturity and as a framework the key pillars such as the presence of the CAB, the easily recognised change types of normal, standard and emergency and a logical process flow allow a maturity review to be carried out quite easily.
But this article is not about that, its introduces the key observations which I have found to be common in a number of reviews and they are based around people not process.
I am going to start this short example list with “Lead Time” as from an emotional viewpoint it tends to be up there at the top. The Change Manager (in administering the process) tends to want the maximum length and it is not uncommon for this to be between 7 to 14 days. This allows a good review of the change record to ensure it has been written to a good standard, a period of time to allow the change to progress through a technical approval cycle (and where end user or client approval is needed, this also to be sought) then in the event of it needing a CAB, a number of days to prepare and execute prior to the required implementation date.
Unfortunately this extended lead time tends to push against the needs of the developers and project managers who as an average I have found seem to sit in the 3 – 4 days camp. In a large number of cases the requirement for a shortened lead time can be clearly tracked back to a level of poor planning but with project timeliness, the risk of escalation and “the change process” being cited as reason for late delivery, any transformation of the Change Management process should really approach any communication of pushing the lead time out with a clear communication plan being able to clearly state the reason why the lead time is as it is, the benefits and most importantly have a clear process for expedited changes which does not become the norm but gives a level of reassurance that where a shortened lead time is required, the process can accommodate it without adding risk into the deployment.
The second issue that has been common in the transformations has been to approve or not to approve before cab. Let me explain. With the general lifecycle for a normal change following some form a peer review and then a decision gate based on a criteria to create the requirement to be presented to a CAB or to immediately go to Change Manager for final approval, one debate I regularly find myself facilitating is that of pre-CAB approval. Now in this case there are generally two routes if the approver has a query and wants the matter discussed in detail at the CAB.
Option 1 is to refine the process to allow the change to progress to CAB “part approved”. In this model, if a change had for example 5 pre CAB approvers and only 3 approved it, there may be a pre-defined CAB date in the change record which automatically progresses the change into the CAB but provides clear visibility that the change record has not completed its approval cycle and a level of questioning would take place. The problem I find with this model is that the CAB can become log jammed and extended with part approved changes, especially if the discussion is quite in-depth. On a people note, it is also a convenient way to defer the decision making process and can become the norm making the Change Manager role much more complex.
The second option is to have a criteria that all changes must be approved by the peer review cycle before presentation at the CAB. This creates accountability on the approvers to really own the action of approving the change and ensuring that any issues they have are resolved prior to the CAB. In this scenario I regularly get challenges with “well if we have all approved it what is the purpose of the CAB?”. My reply to this is fairly standard in that I see the CAB as a collaborative review process which moves past what tends to be a silo’d approval process in the peer review stage to a more collective review of the change, its back out, the testing evidence etc. By forcing the individual peer reviewers to get down to the detail of their level of accountability prior to the CAB it also has had a tendency to drive up the quality of the change approval.
You will probably get a feel for the fact that the second approach is my preferred one although this tends to need more people input in achieving buy-in when compared to the first option.
Where the nature of the application and infrastructure drives a regular need to engage with the end users or clients to seek approval, the decision to include any back out time in or out of change window is an interesting debate. Take a simple change that will take 3 hours to execute excluding back out and then a 1 hour window to back out. The question is whether the last hour to back out should be included in the change window. If you do it appears that you are planning to fail and in some cases can extend the change window significantly and not give a true picture of the “happy path” service handover point. By excluding the back out, you give a more realistic point of service handover but if the change fails and needs to be rolled back you may breach the SLA.
The people element here for me, really does come down to the approach and mindset towards failure. I have found where the consensus falls in including the regression time, there can be an underlying culture that finds failed changes acceptable. By forcing the change to be approved without the regression time included (and the penalty being an imposed SLA breach), the senses are sharpened and accountability for the rigor around the change is elevated.
The approach in the three examples above ultimately come down to engagement. Any process review and certainly where Change Management is concerned can only succeed with a strong engagement plan that gives early visibility of the options available and creates an environment where the options can be debated to a satisfactory conclusion. The days of reviewing the process and then presenting a “fait accompli” are long gone but I would close by stating that this is not process design by committee. Ultimately someone has to take the lead and carry the accountability of the final process but by recognising the people triggers and considering item such as the three highlighted above, a smoother approach can be achieved.