IT departments often stumble at the first hurdle with ITIL/ITSM style Problem Management. This can be for a variety of reasons, including:
- Lack of a Problem Management module in their ITSM/Service Desk toolset.
- Lack of ownership.
- Lack of faith in the value of Problem Management.
- Biting off more than they can chew.
- Not knowing where to start.
Not every IT department has the resources to go 100% at Problem Management from the outset. But there are ways to address all of the above and start down the path of Problem Management without having to do vast amounts of work. Read on to find out how.
Where do you start with Problem Management?
So, where do you start, and how can it be broken down so it is not so huge?
When implementing Problem Management, begin with these simple starting points and introduce them one by one:
- Implement PIRs. You can start by implementing Post Incident Reviews for your Critical/Major/Priority 1 incidents, and make Root Cause Analysis an integral part of the PIR process. This is applying the 80/20 rule to Problem Management, as these incidents tend to be the ones that most impact IT’s customers, and thus are likely to be the best ones to avoid in future.
- Use existing knowledge. There’s often a lot of knowledge on trends and root causes among your IT staff, but no-one ever asks them. In the early days of Problem Management get a group of smart IT support staff together and simply ask them. You’ll probably identify some quick wins and start to really engage some of the IT staff in Problem Management. They may even start to be evangelists for Problem Management.
- Start trend analysis. You can also make a start on trend analysis without a dedicated tool, and without taking it to the nth degree. While you don’t need a Problem Management tool to do this, you do need to be able to report on the types of incidents you are getting. The foundation here is getting the incident categories right (those by which your Service Desk categorises the incident), and getting your incident resolution codes/categories right, then establishing the right reports from there. Pick some easy wins, tackle them, and ignore the rest for now.
Addressing lack of ownership and buy-in
You may initially suffer from lack of ownership and buy-in. At Silversix we’ve seen this happen multiple times, and it is vital to address this. Here are some examples of how you can begin to address this before you even start doing Problem Management:
- Make somebody accountable for the Problem Management process, ideally a leader from Level 2 Support. Their KPIs should be updated to include Problem Management so that their accountabilities and the desired outcomes are clear.
- Don’t limit responsibility to that one person. Include shared Problem Management KPIs on performance plans of all Level 2 IT leaders and their staff, so that they’re encouraged to share in the ownership for the success of Problem Management.
- Communicate to all of IT (and especially IT support staff) what you are doing and why. Share examples where Problem Management has helped customers, reduced cost, and/or increased IT efficiency. Point out that reducing incidents can free up IT staff to spend more time on projects that can progress the business and their own development. Use multiple communication mechanisms for this (just sending an email is not enough), and ensure that the immediate leaders of IT support staff are communicating the message in team meetings.
- Measure success. Ensure you have some measures in place for Problem Management’s overall impact (e.g. reduction in incidents, improved servie availability). Also consider specifically measuring the impact of Problem Management on a particular type of incident that you’ve targeted. This way you can show what progress you’ve made from the outset, and use that to gain more momentum for Problem Management ongoing. Present this to senior leaders in IT on a regular basis, and share it with the rest of IT via email or a noticeboard.
No Problem Management module? No excuse!
Now, in an ideal world you would like to have an ITSM toolset in place with an integrated Problem Management module (so that you can keep Problem Records separate from Incident Records), but, and I must stress this, it is not an absolute pre-requisite and shouldn’t be an excuse. Workarounds exist.
For example, you may be able to track Problems in your Incident Management module. Log problems as new Incident Records, include the prior Incident Record number in the title and have a naming convention so that the title always makes it clear that this is a ‘Problem Record’. You’d ideally then look to mitigate the impact on your Incident Management reporting by doing things like using a special incident category that can then be used as a filter to remove the Problem Records from your incident data set, and/or putting the ‘Problem Record’ on hold (no SLA clock ticking) for the duration, thus not breaching incident response and resolution targets.
You could also track Problem Records in a separate system, but remember to keep it simple. Once you’ve proved the value of Problem Management by achieving some early wins, you’re then positioned to argue a case to invest in the Problem Management module of your existing toolset (if it has one), or contributing to a case to switch to a new ITSM toolset that includes integrated Problem Management.
So get started
Initially the job of the Problem Manager (your accountable Problem Management lead) could just be to communicate and get buy-in, and then ensure that all IT support staff are supported and encouraged to conduct tasks entailed by 1, 2, and 3 above. Don’t over engineer it, don’t bite off more than you can chew, pick some quick ways to start, and get on with it.