12 Tips For Getting Started With Incident Management – Part 1

There’s a lot of documented good or best practices out there on how to do incident management – or so my good friend Stuart Rance tells me – whether that be what’s contained within the ITIL books, information provided by IT service management (ITSM) tool vendors to support the use of their software, training materials, the IP of professional advisors, or the wealth of free information available on the internet.

But I want to take a step (on the good days I skip) back from the more operational aspects we often see within incident management advice, such as “follow this best practice incident management activity.” Instead, I’d like to offer more fundamental thoughts and advice that will hopefully help you to start, or to formalize or improve, incident management based on the premise that it involves more than just adopting a best-practice ITSM process. In fact, this is my first point:

1. Don’t blindly start with incident management because you’re told to or because it “seems a good thing to do”.

Instead, start because you need to – with an understanding that the real need is external, rather than internal, to the IT department. Starting incident management purely because you’re told to or because it “seems a good thing to do” will probably result in little more than the adoption of a new (or now formalized) process.

Think of this  “doing incident management because we have to” process as the equivalent of being served by a waiter or waitress who seems to be doing just enough. You get to place an order, you get your food, and you get to pay the check (maybe after a long wait), but you’ll probably not want to visit the restaurant again no matter how tasty the food was. In the same way that the restaurant failed you on service, incident management should be more than a process – it’s a service. I’ll come back to this.

2. Appreciate that you’re probably already doing some form of incident management.

Even if done informally, the people that provide your company’s IT will already be delivering some form of IT support service. You might call it something else – I’ve heard some “interesting” terms, many of which I can’t repeat in polite circles – but it will be likely that you’re already dealing with a flow of IT-related issues – from password resets, through hardware faults, to system outages.

And don’t automatically ditch what you currently do in a rip-and-replace manner as the new incident management process appears from the ITIL books. Much of the current activity can probably still be used to support a formalized incident management capability.

3. Consider why you are doing, or wanting to do, incident management.

If your answer is “to fix the IT when it breaks” then I urge you to think a little longer, and harder, about the question. Surely incidents are more than faulty technology or unavailable IT services?

Instead look beyond the technology to appreciate that incident management ultimately supports people and business operations; that incident management is about people supporting people. In some ways the term “IT support” is a misnomer that can reinforce that misconception that IT support people are just supporting the IT.

4. Look beyond the process to see the service.

Ask yourself: “Is incident management a capability (or service), or is it a process?” For me it’s a service, provided by my IT colleagues and yours truly, which is supported by a process. Unfortunately, it’s too easy to just see incident management as a process, especially after undertaking rushed and process-based ITIL training, and then to consequently take an internally focused view of IT support.

Instead, if you consider incident management as a service, then it can open up a number of avenues of thinking; avenues that are easy to miss if you’re merely adopting (or adopting and adapting) a best practice process. And it’s these avenues that will ultimately make a difference between your IT department operating a support process, providing a support service, or providing a support service with customer service.

5. Watch your terminology.

Yes, it’s great that ITIL wants us to use a standard lexicon – yes it’s a fancy word for me I know – to describe what we do in IT, but consider what the word “incident” means to your users or customers. For instance, could it conjure up images of motor vehicle accidents, retail store robberies, or killer virus outbreaks? Outside of IT, incidents are usually things that cause worry and that people want to avoid.

Instead, people who don’t work in IT will probably state that they have an IT issue or can’t work because of an IT failure, so don’t force the word incident on them through any of the available access channels and communications.

6. Consider whether you’re taking a supply-side or demand-side view of incident management.

ITIL includes user or customer-focused ITSM capabilities such as service level management (SLM) and business relationship management (BRM). But these are often adopted much later than incident management, if at all. Thus, it’s easy for incident management activities and service to be designed based on what IT thinks is right for users/customers, and business operations, rather than what might really be needed – there is often little user/customer input.

Of course business stakeholders might want more from IT support than they’re prepared to pay for, but that shouldn’t prevent conversations around what’s needed before deciding on what’s acceptable from a cost perspective.

Thus, variables such as access channels, service desk opening hours, and incident management response and resolution targets should be based on demand-driven requirements rather than on supply-side assumptions (which can include what other companies do or best practices) and capabilities.

Is that all?

No, but start giving some thought to these first 6 tips, and next week I’ll bring you 6 more.

Image Credit