Define Measure Acheive. Repeat

Archive

Posts Tagged ‘Add new tag’

Do you measure your incident backlog?

May 5th, 2010

Incident backlog provides an informative KPI that you should consider adding to your reporting repertoire. The KPI should measure the number of incidents outstanding that have missed an SLO or SLA. The KPI should be trended over time and should either be stable or decreasing.

In the example chart below, we can see the backlog rising over the last three months.

Incident Backlog

In this example we see the backlog increase by 50% over 3 months and should be investigated. To determine how urgent the issue is the first thing to explore is to breakdown the  backlog by incident priority.

Open Incidents

It would be highly unlikely that a backlog with high priority issues would persist over a period of time and the chart above now shows that a majority of the back log are priority 3 and 4. This is fairly common and is often systemically ignored. However, it is worthwhile to examine further. 

The reasons for the rising trend could include:

- Second line support personnel are not closing tickets in your ITSM tool.

- Resourcing level may not reflect the current volume of tickets being received on the Service Desk.

- The organizations Change and/or Release practice is causing unscheduled spikes in incident volume

- Are their particular workgroups with particularly high backlogs that could indicate a bottleneck?

  • Share/Bookmark

Charles Cyna Uncategorized , , , , , , , , , , , , , ,

Anatomy of a KPI – Mean Time to Restore Service (MTRS)

March 3rd, 2010

Mean Time to Restore Service is an important KPI that most help desks measure (or at least should). MTRS tells us about the average customer experience a user has when a service interruption is identified.

To calculate the MTRS you take the total amount of time of open incidents divided by the total number of incidents logged in a given time period (normally a month). I would recommend that the KPI only show the top 2 tiers of classification as performance on lower classification would probably reduce the usefulness of the KPI based on how most organization service their lower priority issues.

Now the usefulness of KPI is just that, ‘an indicator’. If it is going in the wrong direction (i.e. up) there is no reason to panic – the most important thing is to identify whether there really is an issue and if so then be in a position to address it as soon as possible.

practice-indicators1

The first thing to look at in regard to MTRS is to see whether Incident volume has spiked. When incident volume changes unexpectedly, the help desk doesn’t have a chance to change resourcing so the average time to restore service will often rise.

analyze-your-mtrs1

The second thing Read more…

  • Share/Bookmark

Charles Cyna Uncategorized , , , , , , , , , ,

Keeping IT Real– risks of low maturity in incident, problem & change.

October 22nd, 2009

Risks for Organizations with Maturity less then Level 3

There are risks for organizations that operate in the Level 1-2 maturity range. If there is a plan to develop and mature the practice(s) to level 3 or higher the risks are somewhat mitigated. However, while at a level 0-2 some of the key risks to consider are:

Service Desk and Incident Management

  • Perception of IT as a whole is lowered and considered not customer focused
  • There is a danger of negatively impacting external customers and their perception of the business
  • There are costs (financial, reputational) when the business is interrupted while users and major services are down
  • There is an inefficient use of skilled IT technical resources
  • There is little incident reporting data because most of it is inaccurate and consequently little basis for improvement
  • Many of the same incidents are resolved repeatedly (re-inventing the wheel)
  • There will be a risk of high Staff burnout and high turnover of support staff

Change Management

  • The infrastructure is very unstable and has long term performance issues
  • There are frequent outages following unauthorized changes
  • Project implementations are delayed because changes cannot be coordinated
  • There are many failed changes that cause incidents
  • The requirement for changes outstrips the capacity to implement them
  • Support for third party applications expires due to inability to stay current

Problem Management

  • Common incidents are resolved repeatedly, lowering customer satisfaction and inflating support costs unnecessarily
  • Re-inventing the wheel when sporadic incidents occur over longer periods of time
  • Frequent interruptions or degradation of service
  • It is difficult to introduce new services when unknown errors may jeopardize the implementation.
  • The change practice gets bogged down due to higher rates of failed changes
  • Due to a lack of work around information the Service Desk regresses to a call dispatch function.
  • Share/Bookmark

Maria Ritchie Uncategorized , , , , , , ,

ITIL maturity - where do you want to be and why.

October 6th, 2009

As a rule, a practice is not considered mature unless it is at a level 3 or higher. This means that the single practice is mature enough to be working as designed and is being used by all relevant stakeholders. It also means that the data it is generating is mature and can be trusted for decision-making.

At Level 3 the practice has control points that provide management indication when and if intervention is required. The practice is end-to- end and collaboration across departments has been optimized. For many organizations reaching Level 3 seems to be the end of the journey.

However, the value proposition of an integrated ITSM practice approach is that when practices reach Level 4 they begin to interact with each other. This provides the ability to share common data and provide insight that is not available at Level 3.

By working cooperatively the practices become more efficient and effective and whole becomes greater than the sum of the parts. Level 4 is the desired target state for the practices in scope for most organizations.

A maturity of Level 5 is often seen in single departments but rarely across all departments. The effort required to get to this level of maturity is high and costly.

Many organizations do not have the ability or desire to reach Level 5. That is ok and not all organizations will have business need for this level of maturity.

  • Share/Bookmark

Maria Ritchie Uncategorized , , , , ,