When conversations turn to measurements, key process indicators (KPIs) always get raised as a mandatory requirement for anyone running a process. KPIs really are a “must have” if you want to see how your process is performing, and to improve effectiveness, efficiency, and compliance to it.
But what are the real goals of any process, and can KPIs help us ensure that we achieve these goals? Well, yes they can – however, in the case of problem management, the key measure for our senior management at Nationwide is not how many problem cases are open, how many root causes are yet to be uncovered, or the percentage of incidents associated to a problem record. What most concerns them is whether a priority 1 (P1) incident has a real likelihood of recurring.
Identifying and Managing Risks
So for us, at the highest level, key risk indicators (KRIs) are more important than KPIs. Our KRIs give our senior management a snapshot of our exposure to being headline news. And then having to respond to additional information requests from regulators in addition to our staff being unable to help our members in a branch, and to our members being unable to open a new mortgage or pay a bill.
Our Problem Management Journey
At the start of our problem management journey we had simple KPIs to track our process. Knowing that we generally did not complete actions agreed at the post implementation review as quickly as we should, we focussed on how long it took people to complete their tasks.
However, as it became clear that our senior business stakeholders viewed each unaddressed P1 incident as a risk to service, we knew that we needed to really focus on the actual risk to IT services.
To address this we introduced very simple KRIs (for example, volume of P1 incidents where root cause is not found and volume of P1 incidents where all activities have not been completed). In fact, they weren’t really indicators of actual risk but, as our process was immature, they gave us a basic indication of exposure to recurring P1 incidents.
Then, as the process has matured, and we really started to understand where we needed to focus our resources (“I need to know you’re addressing the things that keep me up at night” is a statement from the Head of IT Service Delivery that we keep reminding ourselves of), those two KRIs became KPIs, and two new KRIs came to the fore – the volume of P1 incidents with a material risk of recurrence and the volume of critical problem tasks outstanding.
Reporting KRIs and KPIs
These simple KRIs now get the headlines at our regular forums and on balanced scorecards – whilst KPIs help us internally ensure that the process is moving as quickly and efficiently as possible, these two KRIs are the first measures we cover when we’re talking to any senior stakeholder about the problem management process.
Because they’re ultimately concerned about a P1 incident happening again, rather than whether we’ve reached the “green” threshold on any particular KPI report.
Want to Know More?
If you’d like to know more about reporting KRIs and KPIs then please join me at the upcoming itSMF UK conference (ITSM17) in November, where I’ll be presenting with my colleague Ian Porter on “Solving your Customers Problems at the PUB”.
We’ll be discussing the overhaul of our problem management process and how focusing on our internal and external customers helped us to: focus on what was materially important; change perception of the process as quickly as possible; use scarce resources most effectively; ensure our stakeholders were aware of the investigation progress (and its achievements); implement measures to ensure progress was made; and ensure senior management didn’t lose sight of exposure to recurring incidents.
It will be a very practical session covering our service management journey, mistakes we’ve made, things we’ve learned, what’s worked well, and how you can use these learnings to kick start or improve your own problem management process. I hope to see you there.
Peter Norris
Peter Norris is a Principal Teaching Fellow in Cyber Security with WMG at the University of Warwick. His background is in general engineering with industrial automation experience in the steel industry. This was followed by several years working in the non-conventional machine tool sector (laser, EDM and ECM) designing post-manufacture machine-vision inspection systems for jet engine components.
For the more than 25 years, Peter has worked in academia, leading a range of undergraduate and postgraduate courses, focusing on identifying emerging technologies for inclusion in the curriculum, and devising ways to get students fully engaged with this new material. His interests include the join (or fracture) between the different technological subsystems within the cyber domain. Peter's breadth of experience across the entire digital spectrum has enabled him to design and deliver a wide variety of bespoke cyber courses for a range of significant commercial and public sector clients.
