Get problem management working
This is the game changer that most organizations still struggle with. It requires the right person more than a good process.
Why is the right person required? Read on:
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 its 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 practise. The result of successful problem management is the removal and eradication of issues, not just the speedy resolution of faults. So its 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 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 its fundamentally a business process, not an operational one.
Yes. Its 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 its about clarifying the business impact of ‘problems’ to the right people in 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 its hidden as a IT admin issue.
The test of whether an IT organisation is actually using PM successfully is simply to ask ‘what are out 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 prioritised. When problems are visible across a wider team there is also a greater chance that they can be resolved resolved quickly through basic ‘crowdsourcing’.
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 ore 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 practise the proactive role is often ignored and 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 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 which 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 common sense, which is stilll a rare commodity. It also needs good management to make it successful