ITSM Evolution – Practical Steps to Stay Current

Using ITSM Tools can be like rummaging through a garage full of old tools that you rarely use in order to find one or two tools that you do
Using ITSM solutions can be like rummaging through a garage full of old tools that you rarely use in order to find one or two tools that you do

ITSM Evolution – Practical Steps to Stay Current is a guest post contributed by Dirk Anderson, Head of Product at RedPixie

 

With the growth in BYOD and the consumerisation of devices, more and more enterprises are adapting the way that they use technology to service the business effectively.   However, many ITSM tools have been designed to give traditional IT teams a way to manage traditional services and processes at a component level only, whether that’s processing tickets or responding to an individual end-user request.  The challenge, however, is whether or not ITSM evolution is possible and demands of the business can be met using the current tools at our disposal.

Today, firms need to ask themselves if this type of service level approach, using legacy methods, can flourish, or even survive in the future. This article will look at the practical steps that we’d recommend IT Service Managers consider, to deliver services that address the needs of the internal ‘business customers’ in a dynamic business environment, where user expectations are more demanding than ever.

 

Step 1: Know your customers

As a matter of course, you should already be undergoing customer satisfaction surveys or have appropriate forums for regular dialogue with your internal business customers. Use these forums to gain an appreciation of how your customers do business today, what IT services they use and what may change in the future. It is likely that:

  • Your business will be using more personal devices and business customers will expect to access corporate applications and data securely from those devices
  • Your business customers will be embarrassed if their business partners and guests cannot easily use your enterprise guest wireless whilst they’re visiting
  • Your business customers will expect to work effectively from wherever they are
  • They will expect to walk to another desk or meeting room and instantly access the IT services, applications and data at those locations

Expectations are changing. It’s important to explore these areas, and never shy away from hearing frustrations. Canvas their views on new service capabilities that would improve their experience and help them be more productive.

 

Step 2: Pay attention to your IT service portfolio

Look at the IT consumer services that you provide, and break them into categories. There is high chance that you will have one category (and call it what you prefer), has a large percentage helpdesk tickets that are similar. This means that “your consumers” repeatedly need to consume these same critical services. These include: resetting passwords or removing software on end user devices. It is important that you automate these services and allow the business to self-serve. This will free your team up to focus on the emerging services that need to become part of your service portfolio. As you add those new services, some may fall into this same category. Consider how automation and self-service capability is applied to those emerging services.

 

Step 3: Evolve ITSM Toolkit to Meet IT Service Goals

As you evolve your service portfolio, how well does your current ITSM toolset fit your strategic needs? It is important to evolve your ITSM toolkit to meet your longer term IT service objectives. Can you easily add common cloud services and can you automate and allow your consumers to self-serve?

In larger enterprises, you should think like a public cloud provider. You provide the capacity and the technologies and your customers help themselves to the most common services, without the IT team’s involvement. You should focus on managing areas such as, overall service capacity, the software license position and the development of your service portfolio. Commonly used or repeatable IT services should be available to your customers to help themselves, in the way customers consume Microsoft cloud services, for example, without the need to involve Microsoft’s Cloud IT support team. If your ITSM toolkit does not support that strategy, then you need to consider replacing or adding to those tools, to support a more strategic focus. That may mean looking at new ITSM capabilities that augment existing processes and tools to deliver “new world” capability within your service portfolio.

 

Step 4: Review and measure

As your service evolves, make sure that you have a continuous review cycle in place with an internal business customer group.  It’s important to measure not only how the service portfolio fits the changing needs of the business but also whether your ITSM “toolkit” allows you to shape your service around your changing business. The following are critical:

  • Know your service portfolio – To measure the services that you provide as an enterprise IT team, be clear on the portfolio of services provided. It starts with a list of those services, typically on a web portal explaining clearly what the services are (and are not). The portfolio needs an overall owner, typically a senior IT head, and the individual services require service owners, such as IT line managers. This list of the services requires ongoing maintenance.
  • Manage the service portfolio – Work with business representatives and senior IT stakeholder to ensure that the portfolio remains manageable. As new services are used, you need to be able to remove other services, unless the business is willing to fund you to support an ever-growing and unsustainable portfolio.
  • Measure the service portfolio – Develop a way to measure your portfolio. This needs to include which services are used by whom, and the level of consumption. Undertake a Service Review, and work with the business to get feedback on the quality of those services. Understand the cost of providing those services, relative to their business value.
  • Build a Governance Function – Be open and discuss the importance of not creating a technical debt because of a “bloated” portfolio. You only have so much capacity as an IT function. Consider building a senior governance function to support the integration of new technology capabilities whilst removing non-strategic services and technologies.

In summary do everything you can to know your customers, understand your changing service portfolio, be aware of current limitations in your ITSM toolkit and evolve it for emerging demands, and lastly, proactively review and measure.

 

Image Credit

A five step framework for business oriented metrics

A practical look at why some metrics programs fail while others are successful, along with some tips you can use to kick your metrics up a notch.

Introduction

I was math-challenged as a child and hatred of anything having to do with numbers followed me into adulthood. This hatred remained with me until I became a manager and needed to begin proving the work my team was doing or understanding where we were failing. Actually, the turning point may have been the now-overused adage “you can’t move what you don’t measure,” a powerful concept that has a lot to do with the metrics programs I’ve created over the years. I’ve worked hard at this, mainly because of my math aversion. While Excel certainly helps, it’s all still “funny math” and through practice I’ve learned how to justify any story I want to tell using the numbers available from the IT Management tools my organizations have used.

Ultimately, if you can a story with metrics, how do you decide what is the right story? That’s the focus of this blog: determining the story to tell and to whom. 

Building a Business Oriented Metrics Framework 

Ultimately, if you turn to ITIL for help with metrics, you can be led astray pretty easily unless you read all of the books (or at least Service Strategy (SS) and Continual Service Improvement (CSI)). This is because at the end of each process described, there is a list of Critical Success Factors (CSF’s) and Key Performance Indicators (KPI’s). These are great sample metrics for the process you might be implementing and are critical for measuring that process’ success, however providing them to business partners will have you producing the same type of metrics IT’s been producing for years, the type that are not of real interest to the business. You’ll also be led into a false set of security because they came from ITIL, didn’t they? YES!

While these process metrics are one of the three types of metrics ITIL recommends you produce (Process, Service and Technology) and while they are important metrics to produce, they’re of little or no interest to business partners outside of IT because they don’t tell you how well IT is doing at delivering on the key strategic initiatives of the business.

To craft a metrics program that is of interest to the business, you need to start with the business. To help you get started, you can use the informal framework for building business-based dashboards and scorecards presented here (If it seems familiar, it is. It’s based on ITIL’s Continual Service Improvement approach):

Linium-Metrics

This framework is very simple:

  • Know the vision of the organization or line of business
  • Document the goals that support this vision
  • Discover those Critical Success Factors (CSF’s) the organization feels are needed to be successful
  • Create Key Performance Indicators (KPI’s) or measurable indicators of the Critical Success Factors. Include target levels for these, so success is clearly shown.
  • Organize them into dashboard views for each audience that may be viewed live (on-line).
  • Develop scorecards that may be used for trending, historical reporting.

Three Steps to Using this Framework

This framework can be delivered using five basic sets of activities or steps, which are described below.

In addition to these steps however, some of this can only be demonstrating using examples. For these, let’s use a sample organization that is expanding into web-based sales to demonstrate the concepts. In this organization, the new Web Sales department and the Audit/Control group are tasked with delivering on three goals that support the organization’s vision of “providing the best shopping experience on the web.”

These goals include:

  • Providing Customers with an Excellent Web Shopping Experience
  • Giving Customers the ability to do shop any time of day (or night)
  • Guaranteeing credit card security

With this in mind, let’s look at the five steps:

Step 1Create a Focus Group

To ensure alignment, create a focus group consisting of key stakeholders from several lines of business and a few IT Managers. For the organization in the example, this would include managers from Web Sales, Audit/Control and the IT teams tasked to develop and deliver the website.

Step 2: Understand the vision, goals of the organization

With the focus group, take a look at the organization’s strategic plan. Typically the strategic plan includes a set of initiatives designed to support the organization’s vision, similar to the web sales initiative. These are often stated as goals so review the business goals associated with the initiatives and define the ways in which IT supports these goals.  Think of the goals as the pillars that support the organization.  This will ensure your program aligns with these goals and the strategic initiatives.

To move to the next step you will need the vision and goals, similar to the ones provided for the sample organization.

Step 3: Identify your audiences and their contribution

Next, working with the focus group, create a matrix to document the goals and critical success factors for each of the organizations to which you’ll be reporting. This matrix will be used to plan the dashboards and scorecard measures you need. Using the sample organization, the matrix would look like the one that follows.

Audience

Goals

CSF

KPI

(with target)

Web Sales department (1) Excellent Web Experience(2) Ability to do shop anytime
Audit/Control (1) Confidence when using credit cards
IT (1)    Service Operations Excellence(2)    “Fort Knox” security

Step 4: Make the goals measurable

To quantify the goals, you’ll need to work with your focus group to determine the Critical Success Factors that will demonstrate the fulfillment of their goals. The best Critical Success Factors (CSF’s) will be: “SMART”: Specific, Measurable, Attainable, Realistic and Timely.

Once your and the focus group have agreed on the CSF’s, you’ll be able to develop Key Performance Indicators, or measures that support the CSF. It’s extremely beneficial to develop KPI’s along with targets, so you and your business partners are clear on whether you’re successful in delivering on each of the goals. The best part about this approach is that when IT and the business agree on measures and targets, it’s easy to tell when IT has delivered or when IT is not meeting the needs identified by the business.

The ITIL books demonstrate this process clearly at the end of each process documented. The last section of the process description includes a list of Critical Success Factors for the process and Key Performance Indicators that support them.

For example, the Incident Management process (ITIL Service Operation 2011, p. 109) has a Critical Success Factor to “minimize the impact to the business of incidents that cannot be prevented.”

This is not measurable by itself, but four Key Performance Indicators follow it:

  1. The number of known errors added to the Known Error Data Base (KEDB)
  2. The percentage of accuracy of the KEDB
  3. Percentage of incidents closed by the service desk without reference to other levels of support and
  4. Average incident resolution time for those incidents linked to problem records

At the end of this stage, your matrix will be complete, similar to the one which follows for the sample organization:

Audience

Goals

CSF

KPI

(with target)

Web Sales department (1) Excellent Web Experience(2) Ability to do shop anytime (1)    Customers are satisfied with the website design and functionality(2)    Web site is available 24×7 (1) 85% of customers give the site a 5-star rating on exit(2) Web site is 100% available
Audit/Control (1) Confidence when using credit cards (1)    Web site is PCI compliant(2)    Security patches are up to date (1) 100% PCI Audit pass rate(2) 90% of patches applied within 24 hours
IT (3)    Service Operations Excellence(4)    “Fort Knox” security (1)    Web site is available 24×7(2)    Web site is PCI compliant(3)    Security patches are up to date (1)    100% site availability SLA(2)    99% performance SLA(3)    100% PCI Audit SLA(4)    No Security Breach SLA(5)    90% on-time patch SLA

You might notice several things when reading this list:

  • A qualitative measure (5-star rating by customers) is used to determine the customer’s view of the website. This is a critical measure as the CSF points to the customer’s experience.
  • The quantitative measures that sound like IT performance measures are translated to SLA’s for reporting purposes under the IT list of KPI’s. When creating the dashboards and scorecards in the IT Service Management tool, these SLA’s may be configured to demonstrate IT’s achievements against the business KPI’s.
  • Most of them sound like technology metrics. While this is true, these are a short list of technology metrics that these audiences care about. Notice some frequently reported, but missing measures: average speed of answer at the service desk, mean time to restore service etc. These would be IT metrics that support teams would need, but not IT management or the business, unless IT is failing to deliver on the metrics listed in the matrix and management wants to dig down to discover the reasons.

Step 5: Build the dashboards and scorecards

Once the matrix is agreed on and the method of measuring each KPI is defined, documented and agreed on by the focus group, the final step is to design dashboards and scorecards that represent these KPI’s. These are both graphical views of the Key Performance Indicators listed above, showing the result in comparison to the target. The main difference between the two is in the delivery:

  • Dashboards are dynamic: live representations of the data, often provided via a web portal that is integrated either to a measurement tool or directly into an ITSM tool.
  • Scorecards are static: they provide a historical look at the data including trending over a period of time.

Sustaining Success 

There are two final aspects of using this framework:

  • Continual improvement
  • Measurement retirement

As these dashboards and scorecards are used by the business, it’s important to come back to the focus group to evaluate the results. This may lead to creating new KPI’s or tweaking the ways in which they are measured, depending upon the focus group’s satisfaction with performance. In the case of the sample organization, it’s possible that the business is not meeting their objectives and may initiate changes to their critical success factors that will drive a need to change the measures. The point here is that you should not build the dashboards and scorecards then forget about them. Rather, you should meet with the focus group quarterly to review the metrics programs and IT’s achievements. This is a great opportunity to talk about service improvements that the business might need to support the initiatives as well.

Knowing when to stop delivering a dashboard or scorecard report is the last critical piece to a successful program. Once IT is reliably meeting the targets set by the business for a particular goal, it’s a good idea to discuss this result with the focus group during the quarterly review.  In this case, you’re not looking at changing CSF’s and KPI’s to address a business need, but rather you’re reviewing the KPI’s to see if the business still needs to see them continually and if any of the targets need adjustment.

Bear in mind that once you are achieving targets reliably, the business might want to work with IT to “up the game.” So in the sample organization, once the security patches and PCI audit result SLA’s are being met consistently, the business might want an shorter SLA for deployments of new features to the website. Thus, the matrix would be adjusted and the appropriate changes made to the dashboards and scorecards.

Benefits of the program

Providing metrics that are responsive to your business’ needs rather than the same stale set of IT metrics they don’t really care about will have a significant impact on the relationship between you and the rest of the business. Looking back at the reasons to measure, you can expect the following results:

  1. Direct: Live dashboards also provide the ability to determine the activities needed to drive success of an initiative and whether these activities are providing the expected result,
  2. Validate: You and your stakeholders are able to use the metrics you provide to validate whether IT’s performance is contributing to the business’ ability to meet their goals and objectives,
  3. Justify: IT is able to produce metrics that support a business case for infrastructure or development projects related to the delivery of a service,
  4. Intervene: Live dashboards provide IT and the Business to know when there is a performance issue and they can intervene immediately to turn the problem around.

This helps an organization move from a purely reactive mode to a more proactive approach that is integrated with the success of the business’ initiatives in mind.

Linium’s 5 Box Model – You Cannot Manage What You Cannot Measure from Linium on Vimeo.

Balance your productivity books

What did you achieve in 2013?
What did you achieve in 2013?

The end of the year is coming and if you are anything like me you find time to reflect and ponder over the year that has passed. This year I had a chance to show myself that I have actually made a difference to my organization and that my work has been valuable.

I recently had the good fortune to speak at the itSMF Sweden Expo 2013 in Gothenburg. It was actually the first presentation I have given in this line of business so I didn’t already have a presentation to just whip out and deliver. I had to create one.

Someone presumably knew that I had been working as a Configuration Manager for the same company for almost three years and they probably assumed that I would have some valuable insights to share with my peers by now.

So when I was asked to present what I and my colleagues had accomplished over the last three years my first reaction was:

“What a great honour, I’d be delighted! But… I haven’t anything to tell, we haven’t accomplished anything yet…”

Having said that to myself I quite rapidly asked myself:

Really? Not a single accomplishment during three years worth sharing? I must really suck at my job!”

I don’t believe that I suck at my job so I set out to balance my productivity books to get an idea of what we had accomplished and what results we had achieved.

Finding the records

Looking into the past can be both dreadful and uplifting. It’s so easy to judge choices and decisions in retrospect when you have all the answers at hand. But you can also find forgotten gems of good stuff that will remind you of things that mattered but had lost its place in yours and others minds.

At the same time you might find that you don’t keep your records in good enough order to know whether or not you’ve been valuable by the end of the year. I had to wade through a lot of documents, blogs, posts and tweets, and talk to quite a few people to find the good bits and pieces that I had left behind as imprints of accomplishments over the years. Many things were still in my head of course but when it came to details and hard facts, I had to dig deep and look far to find them.

To my surprise there was quite a lot of things to be found that showed my accomplishments. Not only in form of project reports and management presentations but also in actual effects in my organization. Effects that weren’t directly connected to what I had done but at least started with my doings.

One of the lessons learned here is to keep a better record of my own accomplishments. Starting 2014, I’ll track things I do in some kind of ledger so that I can find records of my activities more easily.

Doing the math

It’s a good thing to measure. I think most people in the ITSM industry can agree to that. And we have all heard, read and talked about the necessity of measuring in the smartest possible ways to gain results.

When it came to measurable results in my records, there was close to none, and the few metrics I had were not really comparable. And all that aside, I wasn’t even sure what I wanted to show or to whom.

It’s tricky measuring ones value or the value of ones accomplishments. I was pondering over one aspect of this in another article some time ago and I did come up with some interesting findings.

The value of metrics and what they tell you is probably not the most important aspect to consider if you want to balance your productivity books (a completely different story if you are balancing the financial records of your company, I’d presume). But if you are interested in numbers, do the math and see what you get. The result may surprise you.

Presenting the report

Even if you don’t have the opportunity to tell your peers in the community the results of your work with a presentation at a conference, you would gain from summarizing it in some way. This will force you to select what was important and what was not.

Use the result as a compilation of the work-year to keep in your personal archive. Use it to tell your boss what a great asset you are to the company. Use it to share your success with your peers, your spouse or even to explain to your mother what it is that you actually do at work.

But most importantly, use it to empower yourself with the knowledge that you have accomplished many important things this year and that you are your own fortune.

 Image Credit

What makes for a compelling metrics story?

reading1In my first article “Do your metrics tell a story?” I discussed the “traditional” approach to reporting metrics, and why that approach is ineffective at driving action or decisions.

Personal observations are far more effective. Personal observations appearing to conflict with the data presented can actually strengthen opposition to whatever decision or action the data suggests. Presenting data as part of a story reboots the way we receive data. Done well, it creates an experience very similar to personal observation.

So how can we do this well? What makes a compelling metrics story?

Every element must lead to a singular goal

This cannot be stressed enough. Any metrics story we tell must have a singular purpose, and every element of the package must exist only to achieve that purpose. Look at any report package you produce or consume. Is there a single purpose for the report? Does every piece of information support that single purpose? Does the audience for the report know the singular purpose? If the answer to any of these questions is no, then there is no good reason to invest time in reading it.

ITSM legend Malcolm Fry provides an excellent example of the singular goal approach with his “Power of Metrics” workshops. If you haven’t been able to attend one of his metrics workshops, you are truly missing out. I had the honor when Fry’s metrics tour came through Minneapolis in August 2012. The most powerful takeaway (of many) was the importance of having a singular focus in metrics reporting.

In the workshop, Fry uses a “Good day / Bad day” determination as the singular focus of metrics reporting. ThoughtRock recorded an interview with him that provides a good background of his perspective and the “Good day / Bad day” concept for metrics. The metrics he proposed all roll up into the determination of whether IT had a good day, or a bad day. You can’t get clearer and more singular than that. The theme is understood by everyone: IT staff, business leaders … all the stakeholders.

There are mountains of CSF/KPI information on the Internet and organizations become easily overwhelmed by all the data, trying to decide which CSFs and KPIs to use. Fry takes the existing CSF and KPI concepts and adds a layer on top of CSFs. He calls the new layer “Service Focal Point”.

The Service Focal Point (SFP) provides a single measurement, based on data collected through KPIs. Good day, bad day is just one example of using SFPs. We only need to capture the KPIs relevant to determining the SFP.

(Fry also recently recorded a webinar: Service Desk Metrics — Are We Having a Good Day or a Bad Day? Sign up, or review the recording if you are reading this after the live date).

Create a shared experience

A good metrics story creates a new experience. Earlier I wrote about how personal histories – personal experiences – are stronger than statistics, logic, and objective data in forming opinions and perspectives. Stories act as proxies for personal experiences. Where personal experiences don’t exist, stories can affect opinions and perspectives. Where personal experience does exist, stories can create additional “experiences” to help others see things in a new way.

If the CIO walks by the service desk, and sometimes observes them chatting socially, her experience may lead to a conclusion that the service desk isn’t working hard enough (overstaffed, poorly engaged, etc.) Giving her data demonstrating high first contact resolution and short caller hold times won’t do much to change the negative perception. Instead, make the metrics a story about reduced costs and improved customer engagement.

A great story creates a shared experience by allowing us to experience similarities between ourselves and others. One of the most powerful ways to create a shared experience is by being consistent in what we report and how we report it. At one point in my practitioner career I changed metrics constantly. My logic was that I just needed to find the right measurement to connect with my stakeholders. It created the exact opposite outcome: My reports became less and less relevant.

The singular goal must remain consistent from reporting period to reporting period. For example, you may tweak the calculations that lead to a Good day / Bad day outcome, but the “storyline” (was it a good day or a bad day?) remains the same. We now have a shared experience and storyline. Everyone knows what to look for each day.

Use whatever storyline(s) works for your organization. Fry’s Good day / Bad day example is just one way to look at it. The point is making a consistent story.

Make the stakeholders care

A story contains an implied promise that the story will lead me somewhere worth my time. To put it simply, the punch line – the outcome – must be compelling to the stakeholders. There are few experiences worse than listening to a rambling story that ends up going nowhere. How quickly does the storyteller lose credibility as a storyteller? Immediately! The same thing happens with metrics. If I have to wade through a report only to find that there is ultimately nothing compelling to me, I’ll never pay attention to it again. You’ll need to work pretty hard to get my attention in the future.

This goes back to the dreaded Intro to Public Speaking class most US college students are required to take. When I taught that class, the two things I stressed more than anything was:

  • Know your audience
  • Make your topic relevant to them

If the CIO is your primary audience, she’s not going to care about average call wait times unless someone from the C-suite complained. Chances are good, however, that she will care about how much money is spent per incident, or the savings due to risk mitigation.

Know your ending before figuring out the middle of the story

This doesn’t mean you need to pre-determine your desired outcome and make the metrics fit. It means you need to know what decisions should be made as a result of the metrics presentation before diving into the measurement.

Here are just a few examples of “knowing the ending” in the ITSM context:

  • Do we need more service desk staff?
  • How should we utilize any new headcount?
  • Will the proposed process changes enable greater margins?
  • Are we on track to meet annual goals?
  • Did something happen yesterday that we need to address?
  • How will we know whether initiative XYZ is successful?

A practical example

Where should we focus Continual Service Improvement (CSI) efforts? The problem with many CSI efforts is that they end up being about process improvement, not service improvement. We spend far too much time on siloed process improvement, calling it service improvement.

For example, how often do you see measurement efforts around incident resolution time? How does that indicate service improvement by itself? Does the business care about the timeliness of incident resolution? Yes, but only in the context of productivity, and thereby cost, loss or savings.

A better approach is to look at the kind of incidents that cause the greatest productivity loss. This can tell us where to spend our service improvement time.

The story we want to tell is, “Are we providing business value?”

The metric could be a rating of each service, based on multiple factors, including: productivity lost due to incidents; the cost of incidents escalated to level 2 & 3 support; number of change requests opened for the service; and the overall business value of the service.

Don’t get hung up on the actual formula. The point is how we move the focus of ITSM metrics away from siloed numbers that mean nothing on their own, to information that tells a compelling story.

If you would like guidance on coming up with valid calculations for your stories, I highly recommend “How to Measure Anything: Finding the Value of Intangibles in Business” by Douglas Hubbard.

… and a few more excellent resources:

Image credit

Do Your Metrics Tell a Story?

Do your service management metrics tell a story? No? No wonder nobody reads them.

That was a tweet I sent a few weeks ago, and it’s had some resonance. I know that during my practitioner days, I missed many opportunities to tell a compelling story. I wanted everyone else to get the message I was trying to communicate, and couldn’t figure out why my metrics weren’t being acted upon. I had a communications background before getting into IT, so I should have known better.

Facts are not the only type of data

I’ve blogged about metrics a few times before. In “Lies, Damned Lies, and Statistics: 7 Ways to Improve Reception of Your Data” I shared a story about how my metrics had gone astray. I was trying to make a point to reinforce my perspective on an important management decision. In what became a fairly heated meeting, I found myself saying at least three different times, “the data shows…” Why wasn’t it resonating? Why was I repeating the same message and expecting a different result?

readingGo back and read that article to see how it resolved. The short answer: I lost.

I’d love to live in a world where only objective, factual data is considered when making decisions or influencing others; but we have to recognize two important realities:

  1. Other types of data, especially personal historical observations that often create biases, are more powerful than objective data ever could be.
  2. Your “objective” factual data can actually reduce your credibility, if it is inconsistent with the listener’s personal observations. As the information age moves from infancy into adolescence, we are becoming less trusting of numbers, not more.

So, giving reasons to change someone’s mind is not only ineffective, it can also make things worse. Psychological research indicates that providing facts to change opinion can cement opposing opinion more deeply than before.

Information, whether accurate or not, can be found that backs up almost any perspective. Why should I trust your data any more than the data I already have? Read the comments section from almost any news story about a controversial subject. How many minds get changed?

We need a reason to care

Why should I pay attention to, act on, or react to, your metrics if there is no compelling reason for me to do so? We have to give our audience a reason to care. We want the audience of ITSM metrics to do something as a result of the metrics. The metrics should tell a story that is compelling to your intended audience.

Let’s look at a fairly common metric – changes resulting in incidents. Frequently we look at the percentage of changes that generated major incidents (or any incidents at all). Standing alone, what does this metric say? Maybe it shows a trend of the percentage going up or down over time. Even so, what action or decision should be made as a result of that data? Without context we can look for several responses:

Service Desk Manager: “Changes are going in without proper vetting and testing.”

Application Development Manager: “We need to figure out why the service desk is creating so many incidents.”

IT Operations Director: “Who is responsible for this?”

CIO: “zzzzzzzz”

Who has the appropriate response? The CIO of course (and not just because she’s the boss)! The reality is that the metric means nothing at all. Which is kind of sad really, since there may actually be something to address.

Maybe the CIO will initiate some sort of action, but not until she hears a compelling story to accompany the metric. If the metric itself doesn’t tell the story, decisions will be made based on the most compelling anecdote, whether or not it is supported by the metric.

Metrics need to tell a story

At a new job around 15 years ago, I inherited a report that had both weekly (internal IT) and monthly (business leadership) versions. Since the report was already being run, I assumed it must be useful and used. The report consisted of the standard ITSM metrics:

  • number of calls opened last month vs. historical
  • incident response rate by team and priority
  • incident resolution rate by team and priority
  • highest volume of incidents by service
  • etc.

However after a few months I realized that nobody paid attention to these reports, which surprised me. According to ITIL these are all good metrics to pull. I saw useful things in the data, and even made some adjustments to support operations as a result. However, my adjustments were limited in scope, and the improvements I saw initially didn’t hold and so everyone simply went back to the “old ways”. The Help Desk team that reported to me did experience a sustained significant improvement in their first contact resolution rate, but all other areas of support saw nothing but modest improvements over time.

The fact is that the reports didn’t tell a compelling story. There were other factors as well, but looking back now I can see that the lack of a consistently compelling metrics story held us back from achieving the transformation for which we were looking.

So your metrics need to tell a story, but how?

The traditional ITSM approach to presenting data does a poor job at changing minds or driving action, and it can actually strengthen opposing perspectives. Can you think of an example where presenting numbers drove a significant decision? Most likely, the numbers had a narrative that was compelling to the decision maker. It could be something like, “our licensing spend will decrease by 25% over the next three years, and 10% every year after.” That would be a pretty compelling story for a CFO decision maker.

In my next article, we’ll look at how metrics can tell a compelling story.

Image credit

ITSM Metrics: Known Knowns, Known Unknowns and Unknown Unknowns

Former US Secretary of Defense Donald Rumsfeld
Former US Secretary of Defense Donald Rumsfeld

Common sense tells us we ought to choose a select few ITSM metrics which clearly demonstrate value.

But what happens if we outgrow our original metrics? Or the goalposts change? Or we acquire 15 different companies?

Similarly, once we have completed the basics and want to start exploring continual service improvement – Do we start all over again? or can we work with what we have?

Former US Secretary of Defense Donald Rumsfeld famously stated in 2002:

“There are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns – there are things we do not know we don’t know.”

The same might be said of ITSM metrics. The reporting capabilities of most industry tools are based on a certain subset of metrics which are usually accessed via canned reports, bespoke queries or bespoke reporting (Known Knowns). But what if we want to peel back the layers of the ITSM onion and REALLY discover what is going on? We need to explore the Unknown Unknowns.

Next Generation BI?

The next logical step is to investigate Business Intelligence (BI) – but unfortunately most IT professionals I know shudder at the prospect of BI project because we want the results next month not next year.

UK based Service Management Company ‘RMS Services’ believes it has hit upon an ideal solution to this conundrum with what it claims to be next generation Business Intelligence.

In a nutshell: RMS Vision provides free form search of both database schemas and data from multiple data sources simultaneously.

Gone are the limitations of enterprise integrations, labour intensive excel pivots and custom reporting – to be replaced by on-the-fly analytics across local or enterprise data sources. Best of all, hundreds of chart options are auto-generated.

From the brochure:

“RMS Vision combines a powerful keyword search engine, with comprehensive graphical reporting to deliver real-time business intelligence and analytics on terabytes of data, permitting unrestricted cross-dimensional  associations between data entries and spanning multiple data sources.”

I believe the most compelling aspect of this offering is that you can begin to start exploring data without knowing precisely you are looking for. You can just surf, browse and discover.

The end result is more flexible access to the stuff you know about and a creative process of discovering the stuff you don’t know about. All of which lead to more insights and better decision making. So if you are frustrated with the limitations of the reports in your existing technology but don’t want to throw out the whole service desk – it’s worth a look.

More info here or for UK based readers RMS will be exhibiting at SDITS next week.