MI/HPI caused by Change

Tue, 21 Sep 2021 08:42:03 GMT

Hello All - Hoping someone can advise. There is a focus on driving down the impact of changes in my organisation (major retail) where changes result in an MI or HPI. Is there a widely accepted % to use as a benchmark relating to % of change that results in an MI or HPI?

Thankyou

Tue, 21 Sep 2021 09:33:33 GMT

Hi Abby,

I'm not sure giving you a figure to aim for as a target will be too useful as like with most things it will depend on the objectives of your organisation and where you sit today with that metric.

For example, it would be easy for me to say that the obviously goal is to have 0% MIs or HPIs as a result of change, but that's likely not realistic.

I think a more practical application of that metric is to establish it, and use that as a baseline moving forwards, using your post change reviews and CSI practices to identify ways you can continually drive down the number of incidents.

Chris

Tue, 21 Sep 2021 09:46:03 GMT

So the short answer is "no" there is not a widely acceptable benchmark. However, my guidance would be that you need to take a risk based approach.
So for a less important IT Service, you may not even offer major incident management, and whilst an outage caused by change is definitely an irritation (and to be avoided), it would not be the end of the world. However, for a critical IT Service, you should have zero tolerance of major incidents caused by change. This is actually a resilience question rather than just change or incident. A critical IT Service should be designed in such a way that changes are possible without having to take the IT Service down. My advice is to go that extra step and add "no P1s caused by a change" as an SLA in any contracts. How you manage this subject with other levels of criticality will depend on your risk appetite. Hope this helps.

Tue, 21 Sep 2021 14:07:24 GMT

Hi Abby, whilst I agree with the advice given by both Chris and Karen, I just need to chip in here as well. I have worked with many companies that measure %age of failed changes, meaning any change that has gone in and not worked, caused an incident, MI, HPI etc with the aim to get that value to zero. As Chris and Karen have said there is no real measure and in my opinion no change should go live if there is a risk of failure. Going on past experience, I have found that the majority of failed changes come from a failure in the process such as changes being rushed through for operational reasons etc.

Having said that I believe you should be aiming to put changes in that do not cause issues, therefore, I would suggest that comparing the amount of failed changes you have against other industries will not help (any failed change is one too many), the aim as Chris said should be to drive down the number of incidents of failed changes. I would propose that you look at your change process of how the change is being, impact assessed (what system / applications will be affected by this change), designed, built, tested and released to identify areas of possible weakness, with the aim of improving the process and therefore you should have a high degree of confidence that it will not fail of worse still cause a MI or HPI. That way over time as the process improves the %age of failed changes can be monitored to confirm it is reducing.