The 7 Habits of Highly Effective Incident Managers
Incident management plays a key part in the IT service management ecosystem and in keeping businesses running. But what are the key things that need to be considered when optimizing your incident management capability?
Incident management, like Maverick’s need in “Top Gun,” is often all about speed (but not always).
Put simply, incident management is usually a break-fix capability, run as quickly as humanly possible to mitigate impact (or to restore services with as little adverse impact as possible). It’s an IT process, or capability, that’s very visible to the organization and is so business critical that it needs a highly-organized ecosystem of people, practices, and technology to underpin it.
Here are my seven top tips for optimally running your incident management process – what I like to think of as the seven habits of a highly-effective incident manager.
Tip 1: Have a Plan
As the legendary A-Team saying goes “I love it when a plan comes together.” Incident management is fast and furious (albeit more Rock than Vin Diesel), and service desk analysts often have mere minutes to log, categorize, prioritize, triage, and attempt to fix issues – so plan for this.
Plan for the most common issues. Then plan for what to do when an unexpected issue is presented, as you can’t plan for all eventualities. Train your people to the best of your ability, and to the best of theirs, and set up easy-to-use scripts to aid the speed of resolution for common issues and generic types of uncommon issues.
Tip 2: Structure Your Service Desk’s Work
Make your incident data-capture forms work for you. Incident management is all about getting the people back up and running as quickly as possible, so make it as easy as possible to document the facts and to then get to the resolution. Focus on capturing any customer details not already held in the IT service management (ITSM) tool and a description of the issue by asking about:
- Customer details, including a number to call them back on if they get cut off
- Service affected
- Business impact
- Priority
- Times and dates – when did this start happening?
- Recurrence information – has this happened before?
- Whether anything has changed recently – for example, a technology refresh program, hardware upgrade, or new applications installed
The quality of stored and newly-captured information is important to the different IT support teams, who might need different views of tickets. For example:
- Service desk – by ticket age
- Desktop support – by hardware or software affected
- Networks team – by location or site
- Development – by application
- Capacity management – by resource usage
- Service delivery managers – by service level agreement (SLA) status
- Change management – by date/time to compare with the change schedule
So, make it easy for your analysts to capture the right information, at the right time, and to prevent the need for further contacts/rework later on, by building contextual prompts into your capture forms such that key information isn’t missed on the first pass.
Tip 3: Timebox Everything
Different service desks will have different time limits for each call, sometimes by call type, but a typical industry limit is 10-12 minutes per call to achieve a work rate of circa 10 tickets dealt with per hour. It prevents service desk agents being too focused on first contact resolution (FCR), which does no one any favors if the customer is kept on the phone for 45 minutes just so an agent can hit their FCR target.
Whatever your time limit is, also consider having a shorter version for emergencies so that you have greater flexibility when you have a high volume of calls. It ultimately means that you can ensure that everyone who needs to contact the service desk can get through at a time when they really want and need to get help (or at least assurance that help is imminent).
Tip 4: Get Your Priorities Straight
Make sure your service desk has a way of assigning appropriate priority levels to each incident. Priority should be based on impact and urgency – in other words, how much pain the issue is causing and how quickly it needs to be resolved.
Have an incident priority matrix in place (either something that’s ITSM toolset based or a standalone matrix or standard set of questions) such that analysts can assign a tangible priority score rather than going down one of either the “If in doubt just select medium” or “Who is shouting loudest?” routes.
Tip 5: Make Handoffs and Escalations Seamless
With the best will in the world, no matter how amazing your service desk agents are (are you looking at me?), you’ll always need the ability to escalate incidents. So ensure that the handover process is as easy as possible.
Escalation varies depending on the situation. It can be to any of the following, for example:
- The next level of internal support for access to greater expertise with a given IT service or technology (this is known as a functional escalation)
- A vendor or third-party supplier
- A team leader or manager in the event of unusual time pressures, a complaint, or any additional resources being needed (this is also known as a hierarchical escalation)
Also make sure that you have the way(s) for managing handoffs written into your incident management processes, including how to contact the right people/support team/vendor as well as notifying the customer to keep them updated.
Tip 6: Have a Plan for Major Incidents
Major incidents, AKA the serious stuff, are always going to be stressful. So, having a tried-and-tested way of dealing with them will make them slightly less of a nightmare.
One of the best pieces of advice I can give when dealing with a major incident is to stay calm (yes, I know it’s easy for me to say this when stuff isn’t hitting the fan). It sounds obvious but please hear me out.
The chances are that, if you flap, panic, or start shouting at people, then not only will you completely disengage your team but you also run the risk of stressing them out so much that they miss things or make mistakes. If you remain calm, it will help to take the sense of panic out of the equation and it’s more likely that everyone else will calm down too.
The final thing I’d like to say about major incidents, well almost, is to template everything and have a checklist. This way, even when the pressure is well and truly on, you’ll know that all the key tasks have been covered.
I also recommend you read The IT Skeptic’s advice on major incidents in his blog What is an ITSM Major Incident? ITIL doesn’t say.
Tip 7: Always Remember the Customer
There’s two important things to bear in mind here. Firstly, incident management is one of the most visible processes in ITIL, the popular ITSM best practice, framework.
Secondly, employees are increasingly bringing their personal life (consumer-world) experiences and expectations of service and support into the workplace – such that the bar continues to rise for internal support.
So, put the customer at the center of everything, remembering that incident management is really about business and people support, not IT support. One way of doing this is to use the Voice of Customer (VoC) concept from Six Sigma, which is all about capturing customer expectations, preferences, and comments about a product or service such that you have the very best possible chance of delivering value.
So that’s my seven top tips for effective incident management. What would you add? Please let me know in the comments section below.