At a recent event I was asked about the way the incident and problem management processes were managed. Should they be managed simultaneously with the same people or should they be operated separately. Like a true throwback Thursday, this question still gets asked and likely will for some time.
To get to the root of the question I would ask “What is the real reason that you need to have these processes run in that manner?”
Generally people will say we can’t get addition people or time to do problem management effectively so how can we get around that?
My answer is that it is all about marketing…
You are probably wondering how I got to marketing from incident and problem, but its really something that IT as a whole hasn’t been particularly good with for some time so it’s a skill we need to really work on. Quite often the service management team and some of your operations folks will see the value in having a formalized problem process in an effort to reduce incidents which likely have resources attached. So selling the idea to them is easy, but they may not be the one you need to convince.
The real challenge is that we are always looking at this from the incident perspective, hence the marketing. For example if we were able to apply the same effort to permanently reducing incidents rather than having people fixing them with regularity we may not need additional people at all. To clarify, if we spent 6 hours on a weekly basis to restore functionality to a service, what would happen if we allocated those 6 hours to problem investigation. Doing the math, instead of 468 hours of service impact per year we may be able to spend a fraction of that determining a fix or a workaround or potentially even a way to replace the service to improve perception. This is the way we need to market reactive problem management.
Assuming we can clear that hurdle and allocate resources accordingly, the next challenge is managing the incident and problem activities at the same time. In my opinion these are two different processes which have two different objectives and should be managed as such, and this can get tricky. Without some real focus most often the incident side will bully problem into the shadows and you could be right back where you started without doing any real problem investigation. This slide back into the shadows creates its own negative marketing (there’s that word again) that problem is not as valuable as incident, which is not the case.
Remember that despite keeping the two processes separate by focusing on what they aim to achieve, you still need to connect them together with regularity. This will ensure you are getting a big picture view of where services need improvement and can adjust accordingly.
You might ask me next, “Well that’s great, but what if we don’t have people to do this in the first place?”
Again I come back to marketing and suggest that in the end we are looking to achieve some business outcome. As such we want to ensure that these supporting services enable the business to achieve their goals. If we market the processes based on their merit and what specific value that they add, is it possible that your operations teams could leverage the process to perform incident and problem activities. The touch point may be a regular operations meeting to review the state of services as they relate to incidents and problems.
In summary we need to keep these activities separate, but they cannot exist in isolation. That we market the value of them not only within your service management teams but also to your IT department to ensure that we are all working to the same goal – excellent service delivery
