n an effort to continue your journey to improve the delivery of services your IT organization has decided that it needs to “do” problem management. The first question I would ask is what does “doing problem management” really mean? If you were to go by many standard definitions for the term it would suggest that we are working towards determining root cause of incidents to prevent any recurrence of some particular issue.
For most service management practitioners it is clear why IT would want to implement a problem process. The benefits speak and frankly can pay for themselves including:
- Increased productivity
- Through fewer incident escalations to support
- A reduction in incident volume and durations to business
- Reduction of Costs
- Less handling of re-work issues by support teams
- Improved customer experience
- Business sees less of the repeatable issues (the “oh not this again”)
These are a few of the really obvious examples, however the challenge then becomes whether we are in a position to be able to “do” (as was suggested earlier) problem management properly? There are several pieces that integrate with a successful problem process.
Leadership buy-in
Always big on my list. You really need to have the backing of leadership for this to be as effective as possible. Almost all organizations will be behind fixing issues as a result of the incident process but there seems to be challenges with regards to fixing something that isn’t broken….yet. Despite the directive to “do” the process it should be understood what is involved in making this happen from a day to day perspective. The results will speak for themselves but seeing that value can take some time. Some patience will be required.
Integrating processes
You may have very efficient incident process, in that the resolution of issues is quick and effective. The challenge for problem management will be the gaps in the integration between incident and problem. For me the challenge is always the level of information that is in the incident knowledge record. After all, these “tickets” are effectively knowledge articles which the problem process can leverage to dig into the root cause analysis. The old saying goes “garbage in – garbage out”. For example if the incident impact was “application slow” and resolution was “fixed issue” we are going to need to take a closer look at the information that is collected during the incident and ways to ensure that it is captured consistently.
Another key process to consider is Change management. After all this is the vehicle to implement the fixes to our issues in a controlled fashion. However if your change process is “fire, ready, aim” you may also have challenges that will prevent effective problem management. For example if we are performing several changes which are documented but not really reviewed or discussed across the broader audience where it might apply we may also be setting ourselves up for problems down the road where there were so many changes that we are unable to pinpoint the areas for diagnosis.
If we are seeing process gaps in either incident or change we may not need to even talk about configuration management. See “The Configuration Management System (CMS) – The Service Management Linchpin”
These are only a few examples… remember you need to walk before you can run. Take a closer look at how your service management processes work with your organization as a whole to allow your business to operate.