Service Support Metrics

In Malcolm Fry's book (that is being hosted by NextSLM.ORG), he reviews each ITIL metric individually by quoting the ITIL definition, describing it in clear and concise terms, and making recommendations on how to best leverage the data for both IT managers and business managers. By focusing on these key metrics, one can help illustrate the value of ITIL best practices to those who have responsibility for related functional areas within IT.

He also adds to ITIL recommended metrics and introduce Business Alignment Indicators. These key metrics expand the ITIL best practices to highlight information that helps align IT goals and objectives with business priorities.

Please read on to know more about the same -

Introduction

Information Technology (IT) groups are generally adept at gathering vast amounts of data. The data collected is not always used successfully for analysis and decision-making, however. Very often, the opposite is true. The processing of raw data is sometimes a distraction, rather than a useful activity. For example, many IT departments measure and monitor every event on a Service Desk, yet they may fail to notice that a key server is getting close to capacity. Why? Service desk technologies automatically collect and collate vast amounts of data regarding Service Desk performance, whereas measuring the growth of a server relative to its capacity requires a different effort and intervention.

Let’s look at how we can best leverage data to provide both IT Managers and business managers with useful tools that help them keep IT services closely aligned with business goals.

The benefits of ITIL are often obvious to those who have received ITIL education, read the ITIL books or attended and ITIL conference or training. The first two books in this series focused on advanced ITIL concepts that help ITIL experts build commitment from non-ITIL experts within an organization, by selling what’s important to various constituents, and by better communication the goals outlined in ITIL Service Delivery and Service Support.

In this, the third book in the series, we’re going to continue developing advanced ITIL concepts by focusing on the monitoring and measuring best practices describe in the ITIL Service Support book including:

1) Incident Management

2) Problem Management

3) Change Management

4) Release Management

5) Configuration Management

Each section of the ITIL Service Support book details a list of metrics that should be considered for those managing that functional area. In total, the book lists about 80 suggested measurements to use for monitoring and measuring performance across these processes.

In this book, we’ll review each ITIL metric individually by quoting the ITIL definition, describing it in clear and concise terms, and making recommendations on how to best leverage the data for both IT managers and business managers. By focusing on these key metrics, you can help illustrate the value of ITIL best practices to those who have responsibility for related functional areas within IT.

We’ll also add to ITIL recommended metrics and introduce Business Alignment Indicators. These key metrics expand the ITIL best practices to highlight information that helps align IT goals and objectives with business priorities.

Driving Factors

There should always be reasons for monitoring or measuring. You should continually ask, “Why are we measuring?” or “Why are we collating this data?” Basically, there are four reasons to monitor and measure:

To direct: This includes monitoring and measuring to set direction for activities in order to meet set targets. It is the most prevalent reason for monitoring and measuring. For example, Service Level Agreements (SLAs) set target metrics and the IT department is measured against these targets. These targets set the direction for the IT department.

To intervene: This includes monitoring and measuring to identify a point of intervention including subsequent changes and corrective actions. For example, a network may monitored and identified to be slow. As a result, IT undertakes an investigation that will result in changes implemented to accelerate network performance. Special monitoring may be installed for the investigation to track the effects of the changes. Again, these metrics are usually monitored only for the duration of the changes. However, ongoing measurement may be necessary to direct and ensure that performance does not deteriorate in the future.

To justify: This includes monitoring and measuring to justify, with factual evidence or proof, that a course of action is required. For example, return on investment projections may be required to make a major purchase. Justification often requires forecast trending, financial projections, and/or modelling. In a typical scenario we first justify a project and then validate the deliverables.

To validate: This includes monitoring and measuring to validate previous decisions. For example, the justification to implement configuration (asset) management may be to reduce the costs of asset spending by 10 percent. This requires the implementation of a measurement tool to track and monitor the savings resulting from the project to validate that 10 percent savings goal has indeed been met. Once the project has been completed, it is no longer necessary to measure for validation.

The four basic reasons to monitor and measure lead to two key questions: “Why are we monitoring and measuring?” and “When do we stop?” To answer these questions, you must identify which of the above reasons is driving the effort. Too often, we continue to measure long after the need has passed. Every time you produce a report you should ask, “Do we still need this?”

Definitive Measuring Process
Whether you are measuring to direct, intervene, or justify, or validate you should follow the same simple process:
The process may be simple, but the activities may be time-consuming and difficult. Let’s look at the process in more detail:

Gathering: Gathering concentrates on collecting the raw data required for monitoring and measuring IT services and components. At first glance, it may appear that gathering the necessary data is easy, because IT automatically collects huge amounts of data. However, this is not always true. For example, a Service Desk tool primarily collects data entered by the Service Desk agents, but if a key field is not on the Incident record, then no data can be gathered for that parameter. You should ensure that you have the correct data collection methodology in place.
In addition, it is often necessary to collect more information than is required, so that, in the event of a poor measurement, a base of data is available for further investigation. One thing is certain—to be successful, you must collect the correct data. To do so, you must know why you’re gathering the data—is it to direct, intervene, validate, or justify?

Processing: Once you have gathered the data, the next step is to process the data into the required format. For example, you may have 3,000 Incidents a week, but only want to see the hourly totals to determine staff loading. You use report-generating technologies at this stage. Normally, this means taking huge amounts of data and condensing it into information for use in the succeeding stages.

Analyzing: Once the data is processed into information, you can then analyze the results, looking for answers to questions such as:

· Are there any trends?

· Are changes required?

· Are we operating according to plan?

· Are we meeting targets?

· Are corrective actions required?

· Are there underlying structural Problems?

Here you apply knowledge to your information. Without this, you have nothing more than a string of numbers showing metrics that are meaningless. It is not enough to simply look at this month’s figures and accept them without question, even if they meet SLA targets. You should analyze the figures to stay ahead of the game. Without analysis you merely have information. With analysis you have knowledge. If you find anomalies or poor results, then look for ways to improve.

Presenting or Using: The final stage is to take our knowledge and present it, that is, turn it into wisdom by utilizing:

· Reports

· Monitors

· Action plans

· Reviews

· Evaluations

· Requests For Changes

· New opportunities

As you can see, measuring and monitoring allows you to make informed decisions, taking IT forward in a constructive and structured manner.

This process defines a logical approach to follow, but how can you be sure that you are monitoring and measuring effectively? You need to have in place driving factors to ensure that you will produce effective metrics.

The driving factors affect the data that you collect as well as all the other stages in the process. There is no point in gathering huge amounts of data unless you are going to use it constructively. First, decide why you are going to monitor a parameter. Armed with this information, you can determine what data is required and where you can obtain that data. From here you can follow the process, but remember that success lies in identifying the driving factors at the outset.

360° Feedback

When I think about 360° evaluations I am reminded of a classic body image exercise where you are told to stand naked in front of a mirror and make an honest assessment of yourself. It’s a frightening task to say the least. However, once you open your eyes and take an honest look, you can relatively easily scrutinize your front and sides; it’s the rear that takes some work!

The same is true for work performance – yours or your employees’. There are aspects of it that you can readily identify as needing work and others parts that you know are working really well. However, with normal performance reviews, you rarely see a full picture: Your judgment is necessarily clouded by your perspective and biases. With a 360° evaluation you get others to fill in the “rear view” and help you see what you couldn’t quite picture before.

With 360° feedback you gather information from the main people working with, or affected by, the person being evaluated (as well as his or her managers.) This is then amalgamated it into one full and complete image. One person can have a limited and sometimes biased view, whereas many people should provide a more accurate and more complete picture.

Not only foes this create a clearer picture of areas of improvement, it also encourages teamwork. After all, there’s no point in someone "sucking up to the boss" if everyone else is going to point out arrogance, unhelpfulness, and political behavior!

However it’s at about this point in the explanation of 360° feedback that many managers gasp and raise the following types of objections:

"You want my staff to evaluate me? I don’t think so!”
"It'll weaken discipline and compromise respect for authority."
"It'll crystallize feelings that are better left vague and undefined.”
"It'll cause problems where none exist."
"The bureaucracy created by the process of each team member rating each other team member is far too time consuming for the amount of extra benefit we’d get over the usual appraisal method.”
"People will rate their friends high and take the opportunity to criticize others they don’t like or get along with.”

Is 360° Feedback Really For You?
Arguably, therefore, 360° feedback is not for the faint of heart. It takes a very confident management group to implement it – one that is clear about the value in hearing the good and the bad from a whole bunch of different perspectives. The whole point of 360° feedback is to get the topic of performance out in the open.

In traditional workplaces performance is discussed in private, once a year (if you’re lucky!), and is simply one person’s assessment of how another is doing. However, think about how rich a performance review could be if the results were based on information received from everyone a person interacts with!

Goals of ITIL

INCIDENT MANAGEMENT GOALS

Here is the goal for ITIL Incident Management as quoted in the ITIL publication Service Support:

The primary goal of the Incident Management process is to restore normal service operation as quickly as possible and minimize the adverse impact on business operations, thus ensuring that the best possible levels of service quality and availability are maintained. 'Normal service operation' is defined here as service operation within Service Level Agreement (SLA) limits.

Let us break this down into its fundamental components and see what we can identify to help justify ITIL:

1. Restore normal service operation
2. Quickly and efficiently as possible
3. Minimizing the adverse impact on the business and operations
4. Ensuring best levels of service quality and availability are maintained
5. Business alignment indicator

PROBLEM MANAGEMENT GOALS

Here is the goal for ITIL Problem Management as quoted in the ITIL publication Service Support:

The goal of Problem Management is to minimize the adverse impact of Incidents and Problems on the business that are caused by errors within the IT Infrastructure, and to prevent recurrence of Incidents related to these errors. In order to achieve this goal, Problem Management seeks to get to the root cause of Incidents and then initiate actions to improve or correct the situation.

The Problem Management process has both reactive and proactive aspects. The reactive aspect is concerned with solving Problems in response to one or more Incidents. Proactive Problem Management is concerned with identifying and solving Problems and Known Errors before Incidents occur in the first place.

Let us break this down into its fundamental components and see what we can identify to help justify ITIL:

1. Minimize the frequency and impact of IT problems on the business
2. Initiate actions to correct each situation
3. Find the root cause of Incidents
4. Prevent the recurrence of Incidents
5. Both reactive and proactive

CHANGE MANAGEMENT GOALS

If you are not familiar with ITIL Change Management then you should understand the difference between Change Management and Change Control under ITIL if you want to maximize your chances of producing a strong argument to justify ITIL Change Management.

ITIL defines Change Control as:
"The procedure to ensure that all changes are controlled, including the submission, analysis, decision making, approval, implementation and post implementation of the change."

Whereas ITIL describes Change Management as:
"The process of controlling changes to the infrastructure, or any aspect of services, in a controlled manner thus enabling approved changes to be implemented with minimum disruption."

Change Control is a procedure whereas Change Management is a process.

In other words there may be many changes being controlled under the Change Management process. Each change needs good Change Control but the Change Management process oversees all of the changes. It is possible to have good Change Control but failures because there is no Change Management.

With Change Management the fact that two teams were going to change the status of the same server would have been noticed and those teams would have been asked to liaise and communicate with each other and therefore eliminate the change failure. So in any way you could say that Change Management simultaneously manages the life cycle and status of many controlled changes because Change Control is a component of Change Management.

It is particularly important that Change Management processes have high visibility and open channels of communication in order to promote smooth transitions when Changes take place.


CONFIGURATION MANAGEMENT GOALS

Many ITIL experts argue that Configuration Management is the ITIL sun around which the other ITIL planets revolve. Certainly this is a strong argument because all of the other ITIL processes do come into regular contact with Configuration Management. Therefore meeting the goals for Configuration Management is critical for success when implementing ITIL but are you currently meeting those goals?

Let us have a look at the ITIL Configuration Management goals:

Configuration Management provides a logical model of the infrastructure or a service by identifying, controlling, maintaining and verifying the versions of Configuration Items (CIs) in existence.

The goals of Configuration Management are to:
1). Account for all the IT assets and configurations within the organization and its services
2). Provide accurate information on configurations and their documentation to support all the other Service Management processes
3). Provide a sound basis for Incident Management, Problem Management, Change Management and Release Management
4). Verify the configuration records against the infrastructure and correct any exceptions.

Let us break the goal for Configuration Management down into its fundamental components and see what we can identify to help justify ITIL:

1. Configuration Management provides a logical model of the infrastructure or a service by identifying, controlling, maintaining and verifying the versions of Configuration Items (CIs) in existence
2. Account for all the IT assets and configurations within the organization and its services
3. Provide accurate information on configurations and their documentation to support all the other Service Management processes
4. Provide a sound basis for Incident Management, Problem Management, Change Management and Release Management
5. Verify the configuration records against the infrastructure and correct any exceptions
6. Business alignment indicator

RELEASE MANAGEMENT GOALS
Release Management is often seen as a subset of Change Management but in reality is an important ITIL element because it is often the release of a change that fails rather than the change itself.

The ITIL goals are comprehensive but very precise:

1) To plan and oversee the successful rollout of software and related hardware
2) To design and implement efficient procedures for the distribution and installation of Changes to IT systems
3) To ensure that hardware and software being changed is traceable, secure and that only correct, authorized and tested versions are installed
4) To communicate and manage expectations of the Customer during the planning and rollout of new Releases
5) To agree the exact content and rollout plan for the Release, through liaison with change management
6) To implement new software Releases or hardware into the operational environment using the controlling processes of configurations management and Change Management - a Release should be under Change Management and may consist of any combination of hardware, software, firmware and document CIs.
7) To ensure that master copies of all software are secured in the Definitive Software Library (DSL) and that the Configuration Management DataBase (CMDB) is updated
8) To ensure that all hardware being rolled out or changed is secure and traceable, using the services of Configuration Management.


SERVICE LEVEL MANAGEMENT GOALS
SLM is a key process within the ITIL framework because it defines the levels of service that the rest of the processes have to strive to deliver. It is primarily concerned with setting the goals for Service Management in conjunction with the customer community. The goals for SLM as stated by ITIL are:

The goal for SLM is to maintain and improve IT Service quality, through a constant cycle of agreeing, monitoring and reporting upon IT Service achievements and instigation of actions to eradicate poor service - in line with business or Cost justification. Through these methods, a better relationship between IT and its Customers can be developed.

Not a huge goal but every word is loaded with meaning. Often the expectations and aspirations of the business community regarding IT performance is their perception of the quality Service and Support rather than the scope of technology solutions available to them. To leave expectations as the yardstick is very dangerous. It is important to convert those expectations into realities and this is really what these goals are all about. Let us have a look at a breakdown of the goals.

SLM is to maintain IT Service quality -

Complacency is the enemy of us all especially when it comes to maintaining quality, true winners are never complacent. Before we can begin to improve the quality of IT services we must make sure that we have in place processes, working practices and metrics that will ensure that we continue to maintain the levels of service that we have agreed with our customers. That is what this element is stating.
1) Do you communicate regularly with your customers to check whether you are maintaining your levels of services?
2) Do you set service targets that are challenging?
3) Do you survey your customers often?

SLM is to improve IT Service quality -
Note that this element is not talking about new technologies but current technologies. So we maintain and improve not stay stagnant. Too often IT sets targets that are easy to hit and then congratulates itself every month when those targets are met. However if those targets are not 100% then those congratulations are not deserved. Even worse is that the figures have been hit so often that nobody cares any more they just go through the motions of producing and issuing the metrics. You must have a clear policy statement to improve the levels of quality if you want top meet this goal element.

Through a constant cycle of agreeing, monitoring and reporting upon IT Service achievements –
Agreeing, monitoring and reporting this element could not be clearer nor could it be much simpler. It is about constant communication with your customers to understand their technology requirements required to meet their business objectives. Too often the only communication between IT and its customers is when things go wrong, which is why so much conflict exists in many organizations. A relationship based on confrontation will always fail which is why this element is so important.

You cannot manage expectations but you can manage realities so it is important that the agreeing, monitoring and reporting be formalized to remove any confusion and provide a concrete base for future relationships.

Can you answer these three simple questions successfully?
1) Are you meeting regularly with your customers to agree, and document, service levels?
2) Do you then implement the necessary monitoring to measure those agreed service levels?
3) Do you then issue reports with recommendations and suggestions to ensure that any failures to the agreed levels of services are eliminated?

If you cannot a resounding yes to each of these questions then you’re not meeting these elements. Remember this should be a constant cycle of events not just a once a year visit. It is through this constant cycle that we create the information that drives the final two elements of these SLM goals so failure here is not acceptable.

Instigation of actions to eradicate poor service in line with business or Cost justification –
This element relates to the actions that we take as a result of agreeing, monitoring and reporting. To meet this element you will need a Service Improvement Program (SIP), normally run in conjunction with problem and availability management.

SIP components must also be in line with business or cost justification.

1) Are you meeting this goal element?
2) Do you make sure that you are constantly improving service in line with business or cost justification?
3) Do you have an active Service Improvement Program? Or do you only react when all else fails?

Through these methods, a better relationship between IT and its Customers can be developed –
This element is more of conclusion than anything else. If you are meeting all of the other elements in this goal then this last element will the natural result. When you have a good relationship between IT and its customers then you will have more contented staff and more interesting challenges. This element is the litmus test for all of the others in the SLM goals if you are meeting it then you are most likely to be meeting all the others.

Business alignment indicator –
The prime focus for SLM is business alignment but there is one point of alignment that needs to be discussed here to meet the SLM goals and that is Customer responsibility. Many of the items in an SLA or a Service Catalog can only succeed if the Customers fulfill their roles and responsibilities.

For example:
1) How can ITSM meet their Release plan commitments if the customer is not available as agreed in the plan?
2) How can ITSM solve Incidents if they are not reported? How can ITSM keep an accurate CMDB if customers do not report upgrades to their assets?