For so many years in IT service management (ITSM) we have been working to better resolve and even prevent incidents, but it really doesn’t matter how much you prepare, you cannot completely eradicate them.
However, that doesn’t mean you skip the preparation entirely.
My own ITSM journey started with an implementation of change management, which is all about preventing and resolving outages caused by system changes, both planned and unplanned. I recall the incident storms that would hit after a weekend software release, where the service desk would answer one call after another from a user community who was experiencing service degradation or unavailability. These incidents were disrupting business, but without good insight into underlying system changes, there was little we could do to prevent resulting outages. And we could never restore services quickly enough.
Change management’s purpose is to deliver change
Change management was implemented to give us insight into change, to assure the business that an effective process was in place to alleviate damage, and plans were in place to manage the circumstances should failure occur.
Change management today for many organizations is a very structured and rigorous process that includes risk assessment of the change, effective review of operational preparedness for the change and even an allowance for user education. Changes are reviewed by a Change Advisory Board (CAB) before being approved for implementation.
He who screams loudest gets the change
Now this all sounds good, but what if your process takes days or more and the business needs the change today? Administrators may escalate and implement your change, and when the change fails, they will tell you, “we told you so!” That said, with the emergence of cloud computing, “citizen developers” who write their own code, and an accelerated change culture, we now have a situation where the change process is no longer a “one size fits all” matter.
CDO and the business change dilemma
The chief digital officer (CDO) of a large financial organization recently shared with me their approach to change. To keep competitive and rapidly differentiate, their organization is delivering new mobile solutions through lightweight apps that are rolled out on a continual basis. The accelerated app delivery program is on a different cadence from their traditional solutions. The solutions have longer development cycles and higher reputational risk in the case of failure, and in some instances compliance requirements must be satisfied.
Different change cadences require different approaches. This financial organization’s approach is quite simple. They have what is described internally as systems of innovation – change that leverages a DevOps approach, where their systems of record, such as their SAP implementation, follow a more traditional waterfall approach.
The approach for the service catalog identified the low hanging fruit, calling out 10 different change processes that previously would have been run through a more complete and very structured change process. These were typically always approved, and their implementation rarely, if ever, led to system outage.
After an initial review, these 10 identified changes were moved to the service catalog as request items with their delivery automated, including auditing.
One of the benefits was that resources that were previously occupied doing “busy work” such as repeated manual activities were released to automate additional repeated manual activities.
Proof is in the pudding!
My CDO colleague says his success has been measured not only by the business, but also by customers who are taking advantage of their mobile environment.
Interestingly, within their systems of record, where a longer more structured process is used for change, the application of the software development lifecycle with more emphasis on testing has resulted in more quality in the change process with a deeper focus on testing prior to production.
But back to where we started – with incidents.
Yes, they still happen. Recent analysis identified that a large percentage of them are related due to lack of knowledge in using applications. Their response is to focus more on user design to make the solutions more intuitive and easier to use. And better self-help and similar knowledge sharing raise the rate of resolution before a ticket is even placed.
That said, major incidents will happen, even to critical services. And like a good sportsperson, it’s all about being prepared. More on that in the near future!
Article source: CA ITGovernance Blog