The value of IT Incident Management is not restoring service. You heard me right. If you’re focusing on how quickly you resolve Incidents, you’re missing the point. Don’t believe me? Read to find the real value of Incident Management.
Goal of Incident Management
If you’ve been in IT for more than a few minutes, you’ve heard the goal of Incident Management – the prime directive – is to rapidly restore service to the customer.
It’s true, and a good start, but it’s a reactive treadmill that has no real value to customers. If all you do is restore service, regardless how quickly, you’re missing the point.
Why?
Because what your customers really want is services that never go down in the first place!
Incident Management Does Not Create Business Value
Incidents are not happy moments for customers.
Think of it like this:
Let’s say you discover your bank account is several hundred dollars short. Heck, its a made up example; let’s say its several thousand short. You call the bank and they take your name and account information. They verify that you are who you say you are, and begin researching your problem.
After putting you on hold several times, they discover an error has occurred, and they need the manager’s approval to correct.
Another bout with the funky hold music, and your customer representative announces that he’s corrected the problem.
“Sorry for the inconvenience. Is there anything else I can help you with today?”
Let me ask you; is this valuable to you? In dollars, I mean. Has this interaction with the bank been valuable to you? Has your bank balance gone up as a result of the time you spent with Customer Support?
Answer: No. The net net is back to normal. No positive value.
But wait. Let’s say you’re the owner of a small business. You work nights and weekends to keep your business growing. You work all these hours because if you don’t, the business won’t be profitable. Your time is valuable.
Every minute you spend on the phone with the bank is time that you’re not working your business and making a profit. (Loss of real value).
Good Customer Service can make the experience more pleasant. Good tools and processes can make it quicker. But nothing changes the fact that an Incident is a value reducing experience. Good Incident Management minimizes the loss, but don’t buy the lie that Incident Management has value to the business.
It doesn’t.
Get over yourself, and look at IT the way the business does.
What’s the Real Value of IT Incident Management?
While Incident Management quickly restores services, the goal of Service Management, more broadly, is to increase business value.
If you’re doing even Basic IT Incident Management, the data you collect in the process of restoring service is purchased at a 
price. It’s an asset. (Staff and customer time, opportunity cost, training, tools, etc). If we’re going to make the investment, we should at least get some (positive) value out of it.
The real value of Incident Management is how we leverage it to:
- Reduce the number of Incidents
- Improve recovery time.
- Identify service improvements
In the era of Big Data, it’s inexcusable to sit on piles of data and not use it!
Reducing Incidents
If you asked your business if they could use an extra 10% in staff time to do their jobs, they’d say “oh, heck yeah”. That would definitely be a value-add.
Well, forget about call volumes, average call times, and first call resolution. These do nothing to add value. Go back to the bank example and tell me if the business owner gives a rip.
Here’s some things he will care about:
- How much unproductive time did I have last month,
- How much less unproductive time did I have this month, and
- What are you doing to continue improving my staff’s productivity?
Now these have real value.
So how do we do that?
Incident data is a valuable source of quantified information about what’s actually failing and why.
Analyze it to :
- Establish relationships in the data (who/what/when/where; what’s the context?)
- Uncover patterns (why are things happening; what does it mean?)
- Determine best opportunities to improve
Process it to determine:
- Top categories by volume
- Top categories by customer impact (downtime, number of users impacted)
- Top categories by business impact (lost revenue, opportunity cost)
Use the knowledge of Incident responders to identify potential changes that can reduce or eliminate sources of Incidents. Work with the business to prioritize these improvement opportunities, and drive through Continual Service 
Improvement. Monitor Incident reduction, and adjust improvement efforts accordingly.
Improving Recovery Time
Customer perspective – if you’re going to take my time fixing things that shouldn’t have broken, you can at least do it quickly.
The ability to quickly identify symptoms with likely causes can greatly reduce Incident recovery time. While having the ability to search previous Incident resolution information can help, bigger gains can be had through basic Knowledge Management – proactive analysis of Incidents and resolutions, and creating a collection of authoritative knowledge articles describing the failure symptoms and how to restore.
Nearly all Incident Management tools include some form of Knowledge Management. Use it. Well trained Service Desk staff with ready access to this kind of information can greatly reduce recovery time.
Self service has become pretty common as well. This allows customers to walk though an automated troubleshooting tree, and if their problem qualifies, a “click here to fix” button can automate the restoration of service.
This requires a heavy investment in building troubleshooting trees, creating corrective packages, and thorough testing. But the improvement to recovery time can be significant.
Identify Service Improvements
As you’re analyzing Incident Management data, be on the lookout for opportunities to improve services and satisfy unmet needs.
Some things to look for include:
- What new or changed services could improve customer effectiveness?
- Where and how could new technologies or services relieve pain points for customers?
- Are there areas where additional user training could help? Can the training cost be justified by increase in user effectiveness and less time with the Service Desk?
- What features of services cause the most questions and frustrations to customers, and what could be changed to make it less confusing and frustrating?
- How are customers using services in unexpected/creative ways that might indicate unmet needs?
- What workarounds are customers using to compensate for shortcomings in services?
- Where could one customer group benefit from leveraging what other customer groups are doing?
- What “why can’t I…” questions could be resolved by new or changed services?
- What needs do customers face for which IT does not (yet) offer a service?
- How could customers benefit from use of technology that other companies are using?
- When customer questions are answered with “because of policy…” there’s an important learning opportunity. What is it? How can it be changed to better serve the customer?
- When IT staff think “this would be so much easier if we could just…”, there’s an opportunity.
In the Real World
I know, some of you are thinking – that’s all great and everything, but out here in the real world….I barely have enough staff to just respond to every incident, let alone do more.
I get that. I’ve lived it.
But here’s the deal. You can either continue to be a necessary evil, a net-zero function. Or you can be a respected value-added organization.
It’s your choice.
The real value of IT Incident Management is how you use the valuable information you (and only you) possess to improve IT Services.
- Start small. Identify one big call generator, and champion an effort to reduce.
- Use your star Service Desk staff to do the analysis. Reward high performers with offline time to do analysis and propose improvements
- Talk with staff about the real value of Incident Management, and get them engaged in proactive Incident reduction.
- Tell customer-impact stories. Walk a mile in the customers’ shoes. (remember the bank incident!)
- Reduce focus on traditional metrics (call volume, average call length, first call resolution)
- Increase focus on Incident and customer impact reduction
How have you created real value for your customers with Excellent Incident Management?
This hypothesis has many misconceptions. If you ask the question ‘what is the purpose of a post incident review’ & ‘what is the purpose of problem management’?
It is to:
– Reduce the number of Incidents
– Improve recovery time.
– Identify service improvements
WRT the comment ‘While Incident Management quickly restores services, the goal of ITSM is to increase business value.’ I fully agree – Incident Management is only 1/26th of ITIL’s ITSM processes. That is why there are 26 plus processes p address the full scope of IT.
WRT ‘The real value of Incident Management is how we leverage it to:
– Reduce the number of Incidents
– Improve recovery time.
– Identify service improvements’
That sounds like the real value of Problem Management.
In summary if Incident Management was the only IT ‘end-to-end’ process then the goals have to include: Reducing Incidents, Improving recovery time & Identifying m service improvements
But smart people from many different organizations disagree.
Larry – you are so right about the interrelation of the ITSM processes. Nearly all organizations are doing some form of Incident Management, fewer are doing effective Problem Management and formal CSI.
A lot of Help/Support/Service Desks have a strong legacy of reactive-only thinking. Many see their role as “when a problem comes along; you must whip it”. They see their role end when they hang up the phone.
A surprising number of organizations don’t include Service Desk input as they consider service enhancements and improvements. Part of the reason is because Service Desks themselves often report Call Center type metrics, and don’t leverage what I consider to be the single largest underutilized asset in the company – Incident Management data, and the real business value it contains!
Fully agree but this will only happen with those areas that look at Incident management and Problem management and then throw away the ITIL or COBIT books. Problem management is a subset of Incident management. A problem is when you do not know how to get things back to normal or when an incident has occurred that you feel should never occur or be dealt with in this manner again.
You do not need separate teams to do this. let the people who do this everyday own both processes and improve both processes, the people involved and where necessary, the tools used. Celebrate the success! Thanks for this excellent article!
Celebrate success. Yes, spot on! Thanks Daniel.
Sorry Daniel – Problem Management is not a subset of Incident Management – these are separate and different disciplines. In ITIL terms, Incident is primarily concerned with the recovery of service, while Problem is concerned with Root Cause identification and Root Cause Fix.
As Larry and Greg comment below … some of the topics that Greg covers fall into Incident Management – e.g. timeburn identification and reduction – while others are part of Pro-active Problem Management – e.g. Incident Trending, and Data Mining. Yet others can – and should! – be part of both these disciplines and others in the ITIL stable – e.g. Service Improvement identification, which can be part of IM, PM and CSI.
The problem I see with people trying to conform to ITIL is that you force the separation of what people do into all of the various processes. All the customer cares about is Resolution which used to be a process set comprised of Incident for when things are not right and Problem for when no one knows how to get right.
In which case it is end to end for that aspect. So do you really practice proactive PM? Or is this where you empower the people doing Incident Management to say ” can we not stop this and let’s figure out how in which case you use standard problem-solving techniques but the process of Change says whether you can Release the new way of doing things.
It is all a matter of interpretation and it begins with the view of the customer; not what IT has created as disparate processes with overly complex metrics that are not key but a waste to use or measure.
I would agree with Larry, we can not treat Problem management as a subset of Incident management. While Incident management is targeted at providing a resolution to the customer and getting the ticket queue cleared, problem management has a lot more involved. It is Problem management that gives actual value to the organization. Day to day Incident management is a routine activity and involves a lot of repetitive and dollar eating activities but Problem Management should concentrate on the recovery of this loss. Problem management should focus on improving ITSM as a whole and reducing the number of Incidents.
Analyses of Reports and data from Incident Management helps us to identify the areas and processes that need additional efforts and focus but again that does not mean that this is a subset of Incident management.