Getting the basics right
This process is greatly under-used and under-achieved in many organisations, particularly if or when they believe that they have ‘cracked’ incident management and so, therefore, are ‘doing’ ITIL. Why is this? – mostly because it’s under-estimated and generally misunderstood – certainly in practical terms of how to make it work successfully.
The value of effective problem management however cannot be over-stressed. This is the process that ‘changes the game’ and starts to improve service quality – not just IT efficiency, or incident management practice. The result of successful problem management is the removal and eradication of issues, not just the speedy resolution of faults. So it’s about actually delivering on being ‘proactive’ and removing underlying causes and issues – this has been talked about in IT for some time but rarely achieved consistently and successfully.
The reason for this and the real ‘problem’ with problem management is a basic misunderstanding of what it involves and how to make it work. The expectation is that it’s another process that can be systematically implemented, like an incident, and which can be defined and administered at a technical or administrative level. There are significant technical and admin components and inputs to problem management, but it’s fundamentally a business process, not an operational one.
A business process?
Yes. It’s about classifying opportunity and risk, clarifying priority and impact, and escalating necessary decision-making to the appropriate levels of management in the appropriate language and context. Then, getting resolution and closure and actioning or communicating this back to the relevant people involved.
Whilst this might involve some technical skills and decision making, often it’s about clarifying the business impact of ‘problems’ to the right people in the language they understand – and then getting action and resolution.
In simple terms and as an example, a basic problem that requires a financial decision to spend some money (e.g. improving resilience to reduce downtime), may never be actioned because the people who can make that decision are not presented with the options in terms of risk and value to the business – or the issue just never is presented to them at all as it’s hidden as an IT admin issue.
The test of whether an IT organisation is actually using PM successfully is simply to ask ‘what are our current top 5 or 10 problems?’ This should be known across the team and not just the preserve of one or two service management people. Problems should be visible underlying issues that are defined and perhaps understood or not but are certainly quantified and prioritized. When problems are visible across a wider team there is also a greater chance that they can be resolved quickly through basic ‘crowdsourcing’.
So how do we make this work?
The simple answer is to think person and capability rather than process and function. The right person with the right sort of skills and approach will be far more successful than setting up some processes and expecting them to deliver results by themselves. Of course, processes are needed – particularly with larger organisations – but essentially every organisation needs someone with a particular profile and skill-set to grasp this and make it work.
These skills and attributes are:
- Strong communications and influencing skills
- EIQ (emotional Intelligence) and project management skills
- Klout and respect in the organisation
- Completer/finisher profile – rather than technical
Trend analysis is of course required and this is the technical and admin part of the role, although that can be done as a component within the Problem Management team or from other technical groups. The point here is that the technical/admin profile people aren’t usually suited to carrying out the resolution/completion tasks – this usually requires a more senior profile and skill-set.
- Problem management is not just a technical or admin function
- There is a reactive element – the analysis and research – plus a strong proactive element – i.e. the action to resolve. This distinction has always been defined in ITIL, although in practice the proactive role is often ignored and the assumption seems to be that the same person will do both.
- Get started and get agreement and visibility around what the problems are.
- The problem role is distinct from the service desk and incident management, and it shouldn’t be assumed that a successful service desk manager will automatically be successful in the PM role.
- Set some (small) targets for problems logged and then reduced. Shift the focus from successful incident management to issue removal.
- Problem management is more about ownership than just process – give the right person the job
- The Problem Manager is part analyst, part investigator, but mostly project manager completer-finisher
- In IT we like to build models, tools + processes rather than just managing people + issues
- Metrics in isolation are dangerously misleading – its an eco-system that needs balance
- Processes don’t happen or work by themselves – if there’s no governance then they’re a waste of time
- Documentation is good – but engagement, empowerment, and attitude are even better
- Visibility helps to get problems solved – so publicise your top 10 problems across IT
- Problem Management is a game changer to stop firefighting and start adding value
- ITSM is documented in common sense, which is still a rare commodity. It also needs good management to make it successful