PM Articles > Alan S. Koch > Little ITIL®, Big Results

Little ITIL®, Big Results

Steps 3 of 10: Know the Score

by Alan S. Koch, PMP

In our last article, "Talk About Getting Started," we discussed the second of our 10 steps to starting an ITIL effort in a small IT shop. (Listen to our webinar on this 10-step process!)

Talking is all well and good, but we are not in this to hear ourselves talk! We need to do something, so let's get to work! But before we make any changes in our IT shop, we must lay some important groundwork. So, we continue in this article with Step 3, "Know the Score."

Step 3. Know the Score

What gets measured gets rewarded. And what gets rewarded gets done.

Having begun dialogs that will continue in all of the even-numbered steps, you now need to turn inward. You have heard about problems and opportunities for improvement from all sides. But before you can begin taking steps to improve the score, you need to know the score. It is said that, "all players know the score," so if you're going to be a player, you had better know the score. To carry the sports metaphor one more step, every player knows his or her own stats as well of the stats of the players they play with and against.

When there are many problems to address, it's tempting to dispense with the quaint idea of metrics and jump right into the important work of changing things. This impulse is foolhardy. Without baseline metrics, you lack an objective basis that will allow you to do four very important things:

  1. Prioritize problems and opportunities to decide on the order of attack
  2. Compare your IT shop with others to understand what they may be doing that you could capitalize upon
  3. Judge the effectiveness of the supposed improvements you make to determine if they should be retained
  4. Demonstrate that things are indeed improving to gain support from others for your continued efforts

Good baseline metrics (objective measures of how things are before you begin making changes) will enable all of those things as well as being useful in a host of other ways as your IT processes and practices become more mature.

But of all the things we could measure, which are the ones we should measure? Devising metrics, collecting measurements, then doing something with them all take time and effort. There is only so much time we can devote to metrics, so we must focus on those few things that will be valuable to us. The metrics you will need fall into two broad categories:

  • Internal technical metrics
  • External customer-oriented metrics

Internal technical metrics

These are the metrics we normally think of in IT: Utilization of CPU, disk and network; numbers of users, components, incidents, and requests; average effort to stand up a PC, resolve an incident, or fulfill a request; and many, many others. These sorts of metrics enable us to gain an objective understanding of our IT shop's current capabilities and performance, which will help us to recognize our opportunities for improvement.

The valuable internal metrics start with those that come for free. Our devices, systems, and software are capable of measuring and reporting on a variety of things. Those capabilities should be enabled and the data stored even if you have no immediate intention of using it. You will need some of it to diagnose problems at some point in the future, and having that data available to comb through sure beats beginning to collect it after it is needed.

Then there are the metrics that you will have to invest time and effort in defining, collecting, and using. How do we identify which of all those metrics are worth worrying about? Start with the concerns that are common in most IT shops (especially the small ones).

  1. What chews up all the money? Capital purchases are obvious, but the other parts of TCO (Total Cost of Ownership) are also important. Service contracts, parts and supplies, training, consulting, and support or other help can add up.

    The good news is that this data should be readily available from your bean counters. Whether you have budgetary responsibility or not, you should take it upon yourself to understand where the dollars go so you can make smart decisions or recommendations about future investments.
  2. What chews up all of our time? Employee costs often are among the biggest IT costs, and they are certainly among the most controllable. Insight into where the time goes -- both your staff's and your own -- can help you to distinguish between the mere annoyances and the true time wasters.

    But this data is difficult to collect. Most technical workers find it difficult to log where their time goes, and many have a downright negative reaction to the idea, fearing that the data will be used against them. Appropriate tools and processes can address the difficulty issue, but the fears must be handled with finesse. Lay the groundwork by making it clear that the data will be used to defend and support their jobs, not to threaten them, and demonstrate the behavior by logging your own time.

    Then back those words with actions. Key among them: never, ever discipline an employee on the basis of the time data they log. This will be a difficult for you when the time log data shows a clear problem. But remember this: the moment you use data against those who collect it, it will cease to be real data, and will simply be manufactured to make them look good. (And the reality is that there will be other symptoms of the problem that you can use for disciplinary purposes.)
  3. What causes our pain? This is where the information you gained in Step 2 comes in. The complaints you have heard, both from your customers and users and from your IT staff, often will point to things that should be measured. The first step in determining the legitimacy and priority of complaints is to measure them.

    Of course, we can't give specific advice without knowing precisely the nature of the complaints. (We will address these topics in other articles on specific topics.) But some generic advice is still useful here.

    For example, suppose that one of the complaints we are hearing from users is that problems or requests require multiple calls to the service desk before they are resolved. How shall we go about measuring this problem?
    • First, capitalize on what you already measure. Often you can gain indirect insight into a problem through metrics you already have at hand. Better to capitalize on those than to invent something new.

      In our example, see what data the service desk already collects. Gross number of calls may be helpful if there is other data we can use with it. If each incident record includes the name of the person who called, you may be able to identify series of calls from the same users. And if there is a category or call-type attached to each incident, you may be able to see how often this multiple-call problem is actually happening.
    • If you don't measure anything that is relevant, ask around. Someone else in IT or in some other part of the enterprise might have some usable data. The obvious place to start in this search is with the source of the complaint. But don't stop there. Be creative in your search, and you may be rewarded.<

      In our example, we would ask those who have made these complaints to give as many specific examples as they can recall. (We must be careful to ask in a way that does not sound like we are challenging the allegation. We must make it clear that we are seeking data to diagnose and fix the cause of the problem.)
    • Finally, keep it simple. We technology people tend to want to do things rigorously and completely, and the costs involved in doing so are often not justified. For many kinds of problems there is a simple, easily available metric that will give you good enough insight. It may not capture all variables involved or quantify all aspects of the problem, but it will provide what you need to get started on improvements.

      In our example, it will be tempting to institute new procedures to ask callers if they are calling back about something they called about previously, and to collect specific data about the original call. Although this approach might give us precisely the data we want, we must consider the impact it will have on the callers as well as the productivity of our Service Desk personnel. A simpler approach (especially one that uses data you already collect) is likely to be good enough.

These internal, technical metrics are critical to your ability to gain control of what is happening in your IT shop. You can't manage what you don't measure.

External customer-oriented metrics

But you must manage more than the technical infrastructure and your IT staff. The other thing that is critical for us to manage is our relationship with our customers and users.

The metrics that enable us to manage what goes on within IT are not generally useful for managing these relationships, because for the most part they measure things that those people do not care about. (For example, they don't care how many person-hours the average request eats up; but they do care how long it takes to get what they requested.)

Your starting point for this is the list of services you provide for them. For purposes of communicating with your customer, you must be careful to define each service in the customer's terms.

For example, when your marketing department refers to CRM (Customer Relationship Management), they mean much more than the CRM application. We know that when a user clicks the CRM icon, many parts spring into action: their PC, the client side of the CRM application, the network, the server, the backend of the CRM application, the database server, the DBMS …. Those are the things we must manage. But they are mostly invisible to that end user, who only sees that either the CRM system works or it doesn't.

With this customer orientation in mind, it becomes clear why some of the services we routinely talk about within IT (like network services) and the metrics we use to manage them have little or no meaning to our customers and end users. But what can we measure that is relevant to them? Let's look at our services from the customer's perspective.

In the CRM example above, the marketing department cares about things like these:

  • Availability. By this, we don't mean the availability of the server or the network, or the DBMS, or any other individual component. The Marketing department cares about how often the CRM system is available to them, which is only true when all of the underlying components are working. We don't want to talk with them about the availability of the components that enable the CRM system. We must talk about the availability that the end users actually experience. Which means that we must find a way to measure that. (Not a simple feat!)
  • Performance. And just as above, we don't mean the performance of individual components, but the performance levels that the end user experiences. Again, we must find a way to measure from the customer's perspective.
  • Support. When things go wrong, or when they need something, how long must they wait? We must manage call pickup time, investigation time, escalation, and resolution. But, similarly to Availability and Performance, we must find a way to measure the customer's total downtime (the total elapsed time from when their ability to work is blocked to when they can get back to work).

It will take a while to understand your customers well enough to know which metrics will speak most loudly to them. (We will look more at this in Step 6.) But you already have enough information to begin rudimentary measurements that will be relevant to them. This is your start on metrics. You can't afford to measure everything to the nth degree, so don't try.

Putting Internal and External Metrics Together

The external, customer-oriented metrics give us a way to quantify and understand the service we are providing to our customers and to understand the impact they experience from problems with our services.

When the external metrics point us to a problem we need to address, we must turn to our internal technical metrics to understand how all of the pieces and parts contribute to the problem. This will give us the insight we need to know what to fix, as well as a way to understand the efficacy of any fixes we attempt.

When we believe that the problem has been resolved, we must return to the external customer-oriented metrics to confirm that the resolution had the desired impact on the service from our customer's perspective. Only after we have confirmed that the problem is resolved from the customer's perspective can we claim success!

Without these metrics, we may cast about blindly trying to solve problems, or we may even blame the customer. With these metrics, we will know precisely what is happening and what to do about it. There is no better basis for beginning to improve things than to know the score!




Comments
Not all comments are posted. Posted comments are subject to editing for clarity and length.

Post a comment




(Not displayed with comment.)









©Copyright 2000-2017 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail info@projectconnections.com
Terms of Service and Privacy Policy

Stay Connected
Get our latest content delivered to your inbox, every other week. New case studies, articles, templates, online courses, and more. Check out our Newsletter Archive for past issues. Sign Up Now

Got a Question?
Drop us an email or call us toll free:
888-722-5235
7am-5pm Pacific
Monday - Friday
We'd love to talk to you.

Learn more about ProjectConnections and who writes our content. Want to learn more? Compare our membership levels.