12 Tips For Getting Started With Incident Management – Part 2

Last week I posted a blog offering my thoughts and advice on getting started with incident management, based on the premise that involves more than just adopting a best practice IT service management (ITSM) process. Today, I want to continue with even more:

7. Don’t blindly follow incident management best practices.

Good or best practices are ideally things that have worked at a number of other organizations. But those other organizations aren’t your organization. And ITSM tool vendors have most-likely created UIs, templates, workflows, alerts, and reporting based on these best practices and/or what an average customer needs.

These might fit your organization or they might not. So don’t blindly adopt either best practice or ITSM tool out-of-the-box ways-of-working if they go against what your company (and its people) want, need, and expect from incident management. Hopefully the best practice will fit but it’s best to check before trying to change IT operations in a way that ultimately won’t work for your organization.

For instance, cultural norms or industry regulation might necessitate that things are done differently. Or the size of your organization might require ITIL best practices to be down-sized to fit a smaller number of people and roles.

8. But, conversely, don’t act as though your incident management needs are totally unique.

Yes, it might sound like I’m Joe the Flip-Flop Guy here (maybe I have a future in politics?), but much of what needs to be achieved through incident management will be similar across organizations, so much of the best practices will be applicable. As is often quoted about ITIL – its guidance is designed for an “adopt and adapt” approach, so take only what you need and change it to suit your circumstances.

The important thing is to understand what can be used to meet desired outcomes while not adding unnecessary bureaucracy or conflicting with those aforementioned norms or regulations. The important word being “outcomes,” in that one has to look at how the process will support or impede the desired, and required, outcomes.

9. Don’t forget to think “people first”.

Maybe I should have had this higher in my list? Maybe it’s why I don’t have line management responsibilities? Come to think of it, I often struggle to manage myself.

Sadly when people talk of incident management it’s easy for then to get bogged down in the process and with enabling technology. For instance, ITIL is often considered as a bunch of ITSM processes. But it’s not. It’s actually a way of delivering IT services that can be helped by using a selection of best practice processes. Likewise, incident management should be thought of as people helping other people, with the support of process and technology.

So don’t build a grand incident management Taj Mahal out of processes and technology without thinking about, and then recruiting against, the right type of people qualities. Good people can make bad processes or technology work but sadly the best processes and technology will struggle in the hands of the wrong people. I’ll return to these people qualities in a later blog.

10. Understand the wider implications and connectivity of incident management.

Incident management isn’t an (information) island. Not only will it need to pull information from other ITSM activities – such as event, problem, change and release, or configuration management – it also pushes information out too. So cater for these future connections at the outset even if these processes are to be later additions.

And it’s not just about information exchange. It also involves getting disparate people to work together – many resolution groups (or roles) will be outside the control of the service desk. Thus the complexities of ensuring that relevant people are committed to hitting agreed resolution targets, and provided with the availability to do it, should be addressed upfront.

This might also relate to mindsets as per tip 3 – are involved parties fixing technology or helping people and business operations return to business as usual? And are they fixing technology components, or restoring IT or business services?

11. Don’t make metrics and reporting an afterthought.

Designing, and agreeing on, metrics and reporting early on has multiple benefits that go beyond fit-for-purpose metrics and reporting. A big one is that it can act as a sense check to incident management design and implementation.

This can relate to ensuring that incident management is delivering against requirements (when you consider how metrics, KPIs, and critical success factors stack up). Or to UI design. For instance, if you consider what the data captured during the incident logging process (whether by IT or via self-service) is used for, are you using a particular system field just because it’s there or because there’s a legitimate need to capture the information?

12. Remember that incident management and service desk activities are probably the most visible things that IT does.

When you stop to think about an IT department’s visibility within a company, it’s often limited, except for field support visits and interactions with the service desk. So rather than thinking of the service desk as a cost of quality, merely dealing with IT failures and service requests, think of it as the business’ window into IT.

If the IT department is imagined as a hotel, then the service desk would be its lobby. And how many hotels don’t realize that they’re judged by the quality of their lobby facilities and services before a visitor gets to their hotel room?

Thus the service desk and incident management activity has two important roles, not only reducing downtime and improving productivity, but also a subconscious internal marketing role for IT. So please don’t forget this when designing and delivering service desk and incident management capabilities.

And this is all before addressing the more-operational aspects of incident management such as: creating a prioritization matrix, designing incident classifications, agreeing escalation routes, and providing a self-serviceand self-help facility that people will actually use. There’s so much more to consider beyond the incident management best practices you commonly find available on the internet.

My list is not definitive; it’s just a start. So what would you add?

Image Credit