While reviewing the level of readership of our blogs, we couldn’t help but notice that certain blogs never lost their popularity over the years. This is one of them – with thousands of unique views every month. We thank Stuart Rance for his words of wisdom that clearly sustain longevity (the advice is as relevant today as it was when it was original published). So, ICYMI, we’re pleased to republish this blog for your convenience.
I was working with a customer recently and they asked me what key performance indicators (KPIs) they should use to measure IT change management. After thinking about this for a while I offered them some suggestions, and I’m going to share them here, because the ideas may be useful to other people. Please don’t just copy the KPIs that I suggested for this customer, but look at the way we derived them and think about what you need to measure.
The first thing to do when you are thinking about KPIs is to decide what they are for. Who are the stakeholders for any reports that you will generate? In this case we wanted to measure the effect of process improvements that we were planning. The reports will be used by the change manager, the IT operations manager, the project management office (PMO) and the service level managers.
We spoke to the various stakeholders, to understand what was important to them and identified four critical success factors (CSFs) for change management. These CSFs were:
Your critical success factors may be very different to these, but you should be able to come up with a list that works for your stakeholders. Another good starting place to help you think about CSFs is the examples in the ITIL Service Transition book (but don’t copy these either).
The CSFs don’t have to be directly measurable, it is more important that they are words that the stakeholders agree with, and that summarize the outcomes they want from the IT change management process.
The next step is to identify up to 3 KPIs that could help to demonstrate that you have achieved each CSF. The KPIs won’t “prove” that you achieved the CSF, but they will help to indicate how well you are doing against that CSF. It’s quite acceptable to have the same KPI for multiple CSFs, and it’s important not to define too many.
While we were thinking about change management KPIs we realized that we needed better data about change success. Every change was being marked as successful unless it had been backed out, but this didn’t give us the information we were going to need to establish our CSFs. We decided to evaluate each change based on:
This resulted in us defining a number of change closure codes, to distinguish between changes that fully succeeded and those that had one or more issues. We also added a new incident closure code to indicate when an incident was caused by a change.
We could now define KPIs to support our CSFs.
CSF1 - Protect the business from the adverse impact of IT change
CSF2 - Facilitate the rate of change that the business needs
CSF3 - Provide knowledge and information about new and changed services needed by IT and business staff
CSF4 - Make efficient use of IT resources
This resulted in a fairly small number of KPIs to measure and report, which were focused on what the stakeholders cared about, and could be used to help us understand the effect of process improvements that we were planning.
When did you last review the KPIs you use for change management? Why not review your change management KPIs and reporting and make them more valuable for you and your stakeholders?
Update: Since writing this blog, Stuart has helped to write the publication ITIL Practitioner Guidance, which includes lots of helpful suggestions on how to define CSFs and KPIs.