Why incidents are bad for business and doing something about them...

Is your organisation suffering from high incident volumes?

This article explains the impact of and reasons for having too many incidents and what can be done to help reduce them.

What’s an incident??There are many definitions of an incident, for the sake of simplicity, and at the highest level, an incident represents something that isn’t working as expected or, put another way, something that is broken.?

Why are incidents “bad” for business? Incidents bring with them a reduction in employee or customer experience, cost associated with loss of productivity, costs associated with handling them or, in some cases, brand and reputation?damage. In addition, and something not often considered, repeat (“churn”) incidents give support agents less opportunities to work on areas that may develop the business and their own learning and careers. In short, having less incidents is better for an organisation on many levels and can save them a considerable amount of money.

It is often the case that organisations invest significant resources finding ways of resolving incidents quicker or to reduce the impact of them. Whilst these are worthwhile activities, investing resources to stop them happening in the first place makes a lot of sense.

Why are they not being reduced? There are many reasons why incident reduction is not a focal point for organisations including:

• Awareness?– “what incidents?”
• Cost?– “that’s going to cost too much”, “we will be replacing that service soon”, etc
• Ability?– “we don’t have the skills to stop this happening!”
• Job security?– “If I’m busy fixing incidents, I’ll have a job for life!” – I know this is a cynical view but…

Making things better! So, let’s consider how we might go about reducing incidents and making things better for employees, customers, support team members and organisations overall!

Gather data - Going to wherever the incident data is stored is the obvious place to start. Some organisations may use tools to analyse the data but there are other ways to do so including exporting the incident data into a spreadsheet where analysis can then be carried out. Some of the common “fields” to analyse include:

• Incident description?– what happened
• Incident status?– open, cancelled or closed (don’t forget that cancelled incidents are also a cost to your business!)
• Service?– the business/technology service impacted by the incident, e.g. email, VPN, etc?and the one that caused the incident
• Start Day - when the incident started
• Assignment Group?– group who are handling or who handled the incident
• Assignee?– person who is handling or handled the incident
• Opened by?– person who opened the incident record
• Opened by location?– the country and city where the caller is located?

Talk!?Yes, talk! It is amazing how much can be learned from talking to the people who use and support the service having incidents raised against it. The creation of working groups including users and support personnel can bring many other benefits, including employee/customer happiness as the feeling of being in it together is built.??

Analyse data - Analyse the incident data and create information to make decisions from.?Themes can be found in the data – filters and pivot tables within a spreadsheet are useful in this space. Some common areas to focus on include:

• Common words or text from the incident description – for example “Login issue…”, “Password issue”, “Locked out”, “Disk space low”, etc
• Frequency of services impacted
• Frequency of the service causing the incidents
• Day / Time of the incidents - higher volume of incidents on some days and times compared to others
• Caller – are some employees or customers raising more incidents than others
• Location – are more incidents being raised in some locations than others?

Categorising?the incidents at this stage will help as you decide the action to take to reduce incidents and the pain they cause. Some organisations chose to raise problem records at this point and allocate the incident records to the problem records so they can more clearly and consistently articulate the categories of incidents.

What might you find? Some of the common categories you may find include:

• Software issues - may need development time, engagement with the service provider to resolve and funding
• Hardware issues – failed hard drives for example
• Should have been a request?– nothing was broken the caller just wanted something. It is common for the terms incident and request to be used interchangeably (frameworks, processes and tools sometimes don’t make it easy!), this is the reason why some case management systems just call any employee or customer interaction a “case”, “contact”, “interaction”, etc. Some organisations decide to take action such as education programs to ensure that employees and support agents use the correct record type as the action taken to reduce incidents may be different to that needed to improve the volume or handling of requests?
• Knowledge gaps?- The caller didn’t know how the system/process works and thought it was broken. An example maybe that a transaction between two system needs human interaction, such as an audit or approval action, and the person who raised the incident didn’t know this. Some organisations look at education and ways of improving the system/application to make it more intuitive or informative to the user?
• Incorrect categorisation?- The wrong service was selected by either the person who raised the incident or by the support agent. This is often handled by education or improving the route (form, etc) the caller used to raise the incident

Once you have categorised the incidents, it is time to seek a decision on what to do about them!?

Decision time - Ultimately, a decision to tackle or not tackle should be made. By meeting with those accountable for the service to share findings these decisions can be made. Go armed with data and information to help decisions be made.?

Not all incidents will need heavy or costly remediation actions, incident reduction is possible through communication and user/support agent education.?

Repeat - By continuously gathering data, analysing data and talking about the findings with decision makers, momentum and continual improvement can be made. It may be that an earlier decision not to tackle something may change over time.?

Final thought – Aiming high in your reduction efforts will encourage innovation and will bring better results. Consider where you would rather be in these two scenarios:

• Scenario 1: 10% incident reduction target in 1 year - achieve 12%
• Scenario 2: 70% incident reduction target 1 year - achieve 50%

Yes, the reports would shine red as 70% wasn't hit in scenario 2, but the outcome and value to the business is much better than in scenario 1.?