SysAid Blog

Blog Home
Welcome to the SysAid Blog - the place to go to find out where the IT industry is going, and what is SysAid’s role in it.

The First Call Resolution Paradox

Posted by on December 16, 2015 in Service Desk
First call resolution (FCR) trap You’ve no doubt heard the saying "if you can't measure it, you can't manage it." Therefore, naturally, we try to measure things so we can effectively manage them. Makes sense, as far as that goes, but there's a lesser-known saying  - "be careful what you measure, it just might improve."

Be Careful What You Measure

Somewhere along the way, the world of call centers became enamored with first call resolution (FCR). The idea is fairly sound, really – customers who are helped immediately (on the first call) are happier, more satisfied customers. But, as Doug Tedder points out in The First Contact Resolution Trap, it may not be the end-all metric it's often though to be. Hear me out on this one.
Having good people with solid technical skills and the right tools does wonders for rapid issue resolution. No denying that.  But, looking a little closer at the factors that underpin FCR, we find:
  1. Common issues that are relatively easy to resolve
  2. High volume of short calls
  3. Low volume of unique issues requiring significant research
So, how do we improve FCR? By getting really good at resolving common issues. And if that’s what you measure, well then (you know what they say), that’s what you’re going to get – a focus on how we react to incidents. It could be argued that we should work to get stock answers to questions and shorten calls; more common questions, shorter calls. But, I contend that the real value of incident management isn’t recovery of service. I whole-heartedly agree that when services go down, rapid recovery is the only thing that matters. That’s the heart of incident management. But customers ultimately want services that never go down – services that don’t require calls to the service desk. And if that’s what customers really want, shouldn’t we rather measure how we’re reducing call-generating issues before they happen? Shouldn’t we be trying to fix the issues that cause common issues? The real value of incident management, then, is the data gathered in the process of service restoration, and how that information is used to drive continual improvement.

Continual Service Improvement

Part of my problem with FCR is that it's a snapshot in time. If nothing changes in the environment, FCR is little more than a measure of how effective the service desk is in restoring the same issues again and again. Where’s the motivation to make improvements that actually lower FCR. Think about it. lf accolades come from having high FCR, where’s the motivation to reduce the factors (which I mentioned above) that make it possible? A careful analysis of your incident data can uncover service deficiencies or user issues that contribute to high incident rates. By identifying opportunities for continual service improvement and eliminating those deficiencies, you actually reduce the volume of common calls, as well as the overall call volume. This leaves a higher percentage of calls that require more research and take longer to resolve – the bane of FCR! Welcome to the FCR paradox.

The FCR Paradox

FCR truly is a metric that encapsulates multiple elements of good customer service:
  • Knowledgeable support staff (armed with excellent tools)
  • Quick service restoration
  • Strong issue ownership (one call gets it resolved)
  • Issues fixed the first time, without having to call back
The alternative, of course, would be to not measure FCR, and risk a poor customer experience. I would never suggest that measuring customer experience isn’t important. Of course it is. Hence the paradox. Gil Blinov describes it in Service Desk Tension Metrics, where opposing objectives are measured by metrics that are opposed to each other. It’s the tension between the two that achieve the desired result.

Focus on Outcomes, Not Metrics

Clearly, it’s not an either/or situation. We really do need to measure (which facilitates managing) the effectiveness of our call handling and incident resolution. But an over emphasis on FCR encourages an internally focused service desk that prides itself in being excellent at the very thing customers hate. If you can reduce or eliminate underlying issues, then you should. If you can’t, then get good at resolving them quickly. Don’t get caught in the FCR trap. By putting FCR in tension with metrics in support of a broader incident and business impact reduction program, you get your service desk engaged in what customers really want – less incidents, fewer calls to service desk, and more time spent achieving the goals of the organization.
Continue reading

Change Management Webinar – Here’s Your Questions Answered

Posted by on December 10, 2015 in ITIL
Change Management Q&A Not so long ago, I presented a webinar on change managementcalled Never Underestimate the Importance of Change Management. Normally webinars are a lonely alternative to conventional seminars, because instead of looking at faces of real people, during the webinar it’s just you and a telephone and the hope of people out in cyberspace listening. This time though, with good responses to our three polling questions (that’s another whole very interesting blog coming soon) and lots of questions from the listeners, I felt much less alone. The only downside though was that there wasn’t time to answer all of the listeners’ questions, hence this blog.
Most of the questions call for the traditional consultant’s first response: “It depends”; and this deserves attention in its own right. Best practice is about documenting approaches that seem to have worked for someone – be they best practices about IT service management (ITSM), cooking, or anything else. Whether they’ll work exactly like that for you depends on how matched your situation and circumstances are to those where the best practices initially succeeded. Add in the wide variation in pressures and constraints that face different organizations and you see the limitations of a generic answer. I wrote about that recently here so I won’t go on about it again; instead let’s dive into those questions now. Please note that some answers could be an entire blog on their own, but I will be as brief as I can here to fit everything in. Question: "I’m about to develop a change management policy for the department because I have realized that when other techs make changes on the environment, they do not document changes and it is very difficult to backtrack on changes that were made. How do I drive the point home that we need to have a policy in place and it is imperative that it needs to be followed?" My answer: Anyone making changes needs to document what they are changing. Unless you have a perfect memory, and are immortal, there is a need for reference documentation. Not just in case it goes wrong, but for re-use if it goes right. In terms of getting a policy in place and adopted, the most powerful message I know is to determine, document, and present the damage that has been caused by NOT doing this over the last 12 months or so. Look back on incidents, errors, and especially business impact caused. Try and set financial costs for them and show that it’ll happen again next year unless a more sensible policy is adopted. Question: "With standard changes (or as we call them routine changes), do they always need to be reported, or do you approve the ability to make those changes, and allow them to make those changes without having to report those changes every time they make them (especially for daily changes)?" My answer: Yes, see above :) – it’s like capturing events where most of what you capture won’t be used but you don’t know which bits you will need later. Be sensible – capture essentials and don’t waste resources capturing excessive detail. Much of the data for this kind of ‘safe’ change can be what I call ‘attic data’. You need to be sure it is still there if you ever need it. Like those things you keep in your attic in case you ever need them but don’t have around all the time. Question: "My organization does IT application changes. Should we have two approval processes? That is, one before the change is actually developed, and then the Change Approval Board Review after it is developed?" My answer: You can call it two approval processes that are connected or you can call it one that integrates what you need to do; just make sure the right people are asked, and answer, the right question at each stage. I’d say it was one process but a more important question I would ask is ”does your current situation work?” If it does, don’t change too much. In fact, the normal change process in the ITIL ST book encourages multi-point approvals through the process. Question: "How would you apply change management to a practical area, for example, changing out a network switch?" My answer: Again it depends on context; but assuming you trust your network team, then you empower them to make change under standard change procedure. They document it in such a way that problem management would spot it as a cause should it generate unwanted symptoms later. Question: "How do you change the expectation of an environment that has become comfortable with disappointment in change?" My answer: This question certainly warrants a whole blog to address properly. Quick response for now: show them what it could be like, pick a customer, run their changes right, write it up, publicize it, make the rest of your customers jealous. But be prepared to deliver against any promises you make, or you could just make things even worse. 3 Questions: "Do you have guidance on the appropriate level of change management to introduce into an organization that is growing from a startup into an enterprise size (400+ users, 250+ production systems)?" "What is your perspective on how many changes to "bulk" into a single release package" "IT CM is often perceived as an obstacle, too much paperwork. What is the right balance between process controls and process efficiency / agility?" My answer: The answers to these questions really do depend on the actual situation, circumstances, and constraints of the organization. It’d be nice to come and see the situation and offer targeted advice. But for now, the answer really is ‘it depends’ – on frequency and scope of changes, security, success rates, business criticality, customer and staff expectations and abilities, and much more! First place I would go to get trusted opinions are to the people doing the job now. Question: "Change Management in my previous company became very bureaucratic. Have you seen this and how do you think this can be avoided?" My answer: Yes, it is very common. The answer is to embrace standard change, establish who you can trust, and trust them. Take some risks – falling into bureaucracy will likely stop the organization progressing more than a few failed changes. Question: "What should be some ground rules for denying a change, particularly if we know that IT is not ready, yet business is pushing with urgency?" My answer: Discuss damage! Establish what the likely damage would be if you went forward with the change. That is, presumably, your reason for not wanting to do it. If you are getting pressured to do the change anyway, despite the expected damage, then make those requiring it sign off and formally accept the risks you set out. Question: "What do you think is the first step to prepare an organization for ITSM change management? What is your best tip to an organization to start from zero again?" My answer: Start where you will make a difference. Focus as a first step on the kind of changes that have been causing the most trouble and/or causing the most damage recently. Question: "How do you deal with change management when management is secretive and does not give you the full picture?" My answer: This is another question that could inspire me to write a whole blog! Very few of us have the whole picture, even if we think we do. Establish what you do and what you don’t know. Make the best decisions you can. Document the damage caused by decisions that were not optimal because management withheld information. Let management know the damage they are causing. Thanks to all those who sent in questions, and if you have more questions, follow-ups, or want to disagree with what I have said, then please respond to this blog, or find me on Twitter.
Continue reading

Reap All of the BYOD Benefits and None of the IT Headaches with Nubo VMI

Posted by on December 7, 2015 in BYOD
Nubo for BYOD Enterprises continue to cruise full speed ahead towards a truly mobile reality, and the ITSM industry is no exception. Many businesses are looking at how to efficiently mobilize enterprise apps, asset and incident management and many other services without the substantial burden that device management has placed on IT resources. Luckily, a groundbreaking innovation has arrived that can gives businesses the simplest and most secure route to maximizing the benefits of BYOD, which as you know is all about giving your employees the tools and information they need to be productive, and add value by making timely and informed business decisions from wherever they are. Today that means being able to access top-notch enterprise and consumer apps from your smartphone or tablet. SysAid has partnered with Nubo Software, a leading innovator of Virtual Mobile Infrastructure (VMI) technology.
Allow me to explain a little about Nubo. We are a cloud-based remote enterprise workspace that lets you remotely deliver any mobile app to your employees with zero implementation time or maintenance needed. Instead of installing and managing native apps on personally owned devices, your business apps are run virtually from a mobile OS on a secured cloud. Those apps are transferred to smartphones and tablets as a display, using a remote display protocol made specifically for mobile performance. Your users access the workspace by downloading the Nubo thin client app from Google Play or Apple’s App Store. Since the environment is entirely remote, zero corporate data is stored on employee devices, offering maximum data security. The result is a win-win for both employees and IT. Users working with apps in Nubo will still enjoy the native mobile user experience they’re used to with their favorite consumer apps, as Nubo was developed for optimal bandwidth efficiency and mobile sensor support. Analyst firm 451 Researchrecently highlighted Nubo’s speed and efficiency, which is eight times more efficient than the rest of the VMI pack. Nubo’s ability to support multiple users per virtual machine is also unmatched. You can read the full report here. With no corporate data stored on devices, your IT no longer has to manage devices. Your employees no longer need to worry about their privacy being compromised if their phone is lost or stolen - remote wiping becomes obsolete and unnecessary. Corporate data stays on the cloud, and IT can easily disconnect the compromised device from access to the work environment. You can also wave goodbye to the significant resources you’d normally devote to implement and maintain such an infrastructure - Nubo manages all of that for you on their secured cloud, giving you an easy and simple route to secure mobility. A customized control panel makes adding new apps as simple as drag and drop. Distributing apps to individuals or groups and updating user and device access are all done with a tap or a click from any device. An innovation of SysAid Founder Israel Lifshitz, Nubo lets your business support mobility more than ever before with ease, simplicity and security. For further information, email us at info@nubosoftware.com.
Continue reading

Work on a Service Desk? Say What You’ll Do, then Do What You Said

Posted by on November 24, 2015 in Service Desk
Customer satisfaction at the service desk Customer satisfaction isn’t only about the quality of the service you deliver, it’s just as much about how well you set and then meet customer’s expectations. The most important thing to get right when you’re providing services is to say what you’ll deliver and then deliver what your customers expect. If you reliably meet customers’ expectations – every time – then those customers will value your service. If, on the other hand, you let customers down then they will be dissatisfied with your service, even if their expectations were unreasonable and could never have been met.

Setting Expectations

People who work on a service desk have a great opportunity to delight customers, by simply making sure that customers know what is going to happen, so that when you deliver services to them they get what they were expecting. On the other hand, if you set expectations incorrectly, or fail to deliver the service that you said you would, that leads to dissatisfaction. I recently phoned my broadband supplier to ask them to switch my internet connection to a different phone line. The person on the service desk told me that this would take 30 days, and they immediately sent me an email with an exact timetable for the switch, saying that they would deliver a new modem the day before the switch, and I should return the old modem in the same packaging.  I was pretty sure that the two modems were the same so this seemed a bit wasteful, but I guess they must have had their reasons. The modem arrived on the appointed day, and next day the new broadband connection came to life and it all worked first time. About two days later, after the new connection had stabilized, they disconnected the broadband from the original line, so I packed up the modem and returned it to them. I was a happy customer. I would obviously have preferred it if they could have done this without such a long delay, but they set my expectations correctly so this wasn’t a deal breaker. Now imagine my reaction to exactly the same situation if the service desk told me that it would take just one week, and then it took 30 days. Or if they told me that the swap would happen on one particular date and then it happened two days earlier at a time when I wasn’t around and couldn’t test the connection. The reason I was delighted with this service was because the supplier did exactly what they said they would do, exactly when they said they would do it. Another recent service experience of mine was less satisfactory. I had bought a new fridge and when it was delivered there was obvious damage to the door. The delivery people told me that they would return it to the warehouse and I should hear from them within two days. Three days later I phoned to ask what had happened to my fridge and they seemed to know nothing about it, but promised to call me back within 24 hours. The next day I didn’t hear from them, so I phoned back and they expressed surprise that no one had returned my call and again promised to get back to me within 24 hours. The next day I phoned a senior manager in the company to complain. I explained that my complaint was not about the damaged fridge, these things happen, but about their failure to meet commitments to call me back. This time my issue was dealt with, and a new fridge was dispatched. It didn’t actually take very long for me to get my fridge, but I was not a happy customer because the organization failed to get the basics of customer satisfaction right. All they needed to do was tell me what to expect, and then meet my expectations. How good is your service desk at setting customer expectations? Do you make sure that your customers know what is going to happen, and then deliver what you have promised?  
Continue reading

FUSION15: People, Process, Technology, and Even More People

Posted by on November 17, 2015 in ITSM
ITSM learning at FUSION15 I’m back from a wonderful trip to New Orleans for FUSION15, plus a sneaky little post-event vacation, and I wanted to capture some of the great insights and advice the presenters at FUSION15 had to offer. Obviously there are only so many sessions an individual can attend at a multi-stream event, without the benefit of cloning, and there were many more sessions that I wished I could attend but was prevented by clashes. However, I think I chose my sessions well and, without realizing it, I appear to have attended sessions across the IT service management (ITSM) mantra of people, process, and technology (or product if you are totally up-to-date with your ITIL training). So here are some key points I picked up.

“We Don’t Do People”

Stuart Rance (ITSM legend, consultant, trainer, and ITIL author) started with this mantra, stating that we talk about IT services being supported by people, process, and technology, but too often we invest all our time and effort in the processes and technology, and forget about the people. Stuart explained how we can significantly improve the IT organization by focusing on people, offering a number of real-world stories about how the attitudes and behaviors of IT staff can dramatically influence the customer experience. Stuart challenged the audience with questions, including:
  • When you recruit, do you require people skills as well as tech skills?
  • How do you measure and reward people?
  • Is meeting your SLA more important than making your customer happy?
All of these questions are easy to ask but maybe not so easy to answer. Stuart wasn’t slow in telling the audience some hard truths either, including:
  • If you haven’t involved your end users/customers in your ITSM processes, then you'll fail.
  • It's not a person who fails – it’s the training, process, technology, etc.
  • To improve things, change the ITSM culture to include blame-free post mortems.
  • Design customer experience into everything that you do – every process, every tool, every user interface, and every metric and KPI.

From Stuart’s People to Technology and Process, Namely Cloud and DevOps

John Clark and Kathleen Wilson told the audience how Microsoft, in order to innovate and to stay competitive, needed to change its methods of delivering new features to its customers. They explained that the traditional IT models, which consisted of disparate IT teams with little to no collaboration, hindered Microsoft’s ability to innovate quickly. Then, they went on to describe how Microsoft successfully—and not so successfully, in some cases—applied DevOps internally, in its cloud services, and with its customers. One of the key points for me was how much DevOps uses automation. With hindsight it makes so much sense – automation is needed for public-cloud-scale operations and in order to monetize the cloud. The most efficient and effective data centers have very few people – no different to the most optimized of factories or other physical production environments. This was cemented by keynoter Robert Tucker when he said something akin to: “If a job can be done by a set of steps, it’ll be eliminated. Replaced by a robot. Let that sink in.” The session also introduced a new term for me – economy of skill. While the “on-premise way” looked to economies of scale with vertical IT silos such as networking, storage, servers, etc. and the associated finger-pointing along with, most likely, an absence of end-to-end accountability – the “cloud way” is about operating in a new, federated services model; with “one throat to choke” when it comes to accountability.

…And Back to People with SFIA

Matthew Burrows spoke to how more and more IT organizations are using the Skills Framework for the Information Age (SFIA) to keep track of the skills they have and the skills they need to obtain. With SFIA allowing organizations to understand: their IT skills gaps, how to address the gaps, and how to create skills-based role profiles and job descriptions to help deliver better individuals and teams. I was new to SFIA – my excuse is that I’m a marketer with a very keen interest in ITSM – but I imagine that I’m not alone given SFIA’s UK origins. And when something is free to use, it would be rude to not at least take a look. In summary, SFIA is a framework that provides a common language that describes skills (not roles). It includes a model for not only describing IT practitioners’ skills but also the levels of the skills needed in the context of organizational responsibility. It’s interesting how SFIA doesn’t define organizational structures, roles, or jobs and is instead aligned with the things that need to be done in IT in order to be successful. And I particularly like how SFIA helps both the organization and the individual or, as Matthew explains it “SFIA plays a role in countering weapons of self-destruction.” If SFIA sounds like it could help your organization, then why not download SFIA6 from http://www.sfia-online.org/en.

And Even More People Advice with “Engaging Employees: Bridging the Generation Gap”

Rae Ann Bruno pointed out that, while many IT organizations focus on attracting and retaining employees, to get the best results we also need to motivate and engage our employees and teams to deliver better customer service – that engagement can be the real differentiator. And that, with several generations in the workforce, a “one size fits all” approach to motivation and engagement doesn't work. The session covered what motivates each generation and how to create an environment where teams will be highly engaged, productive, and successful. Rae Ann offered up four traits that engaged employees exhibit and it’s interesting to consider how our service desk people rate against each of them:
  1. Enthusiasm – employees are enthusiastic about work
  2. Inspired – employees are motivated by their leaders
  3. Empowered – employees are allowed to do the work their way
  4. Confident – employees are sure they can achieve excellence
Engagement is an important consideration as we start to expect service desks to deliver a better customer experience. With 70% of engaged employees strong on customer service versus only 17% of disengaged employees. So get your service desk and other IT employees engaged! Looking at engagement through a generations lens, generationally the workplace is made up of:
  • Traditionalists (born 1925-1945)
  • Baby boomers (1946-1959 with a second wave 1960-1964)
  • Generation X (1965-1981)
  • Generation Y (1982-1993)
  • Generation Z (1994-)
Although I would argue that we should call the latter group Generation Now given their constant need for immediacy in the workplace, with Generation Y not too far behind them! So unsurprisingly, research is showing GenY/Z as the least engaged part of the workforce, and moving jobs a lot as a result. The root cause is often the corporate failure to deliver against a key GenY/Z motivator – the individual’s ability to advance in their career/profession/company. It’s not great for the service desk for the IT organization as a whole if such personal ambitions can’t be accommodated. Rae Ann’s session nicely complemented the keynote by “American Humorist,” Jeanne Robertson when she asked: “Have you ever wanted to take a young person's face in your hands and ask ‘are you in there?’” It wasn’t a Generation-Z-bashing keynote but rather an exploration of how a sense of humor is more than just the ability to laugh. That instead it’s an attitude, and an approach to working that can be developed and improved – to laugh at yourself and to accept the things that cannot be changed about ourselves and the people around us.

And Then Back to Process with “Basic Change Management: A Practical Multiphase Approach”

Greg Sanker offered practical advice on getting started with change management, detailing the common challenges of trying to adopt by-the-book change management, and the difficulties of starting small – which can make it very difficult to mature and move beyond being reactive. I was pleased that Greg started with the purpose of change management, to:
  • Enable beneficial changes to be made
  • Minimize disruption to services
  • Manage risk
  • Control the lifecycle of all changes
It’s so much better than “the process that manages changes.” Greg also offered up a simple two-phased approach to change management adoption. With Phase 1 involving:
  • Introducing change control
  • Focusing on business value
  • Managing the environment
  • Changing behaviors
With a need to measure:
  • Progress of adoption – milestones and deliverables, and resistance
  • Compliance – whether processes are being followed and impact reduction
Then in Phase 2:
  • Controlling the lifecycle of changes
  • Managing risk
  • Business alignment
  • Reducing rework
With a need to measure:
  • Effectiveness – business outcomes and impact reduction
  • Efficiency – time to value
Greg also offered pearls of wisdom that included:
  1. Processes produce outputs but outputs don't produce value; it’s what the business does with the outputs that can be valuable.
  2. Mature service management is about collaboration. Change Management is no exception – step out of your silo.
  3. Start small with change, think what you need now and work towards improvements. And keep it simple!
Well there you have it, a sample of my learnings from FUSION15, and I could have written so much more. Care to share what you learned at FUSION? Photo credit: Roy Eldar
Continue reading

The Help You Need to Adopt Continual Service Improvement

Posted by on November 10, 2015 in ITIL
The Help You Need to Adopt Continual Service Improvement Continual Service Improvement (CSI) is one of the most important concepts in ITIL, but very few IT organizations put anything in place to make it happen. Everyone knows that they need a service desk, and that they need incident management and change management. An IT organization without these things would deliver terrible service and have customers that are completely dissatisfied. I think that the same applies to CSI. If you aren’t continually improving your services, your processes, and your technology, then at best you will stagnate, while your competition gradually leaves you further and further behind. Staying still is not an option when everyone else is improving; it’s just a way to gradually decline into irrelevance. It’s fairly easy to get started with CSI and it can make a huge difference to the value you create for your customers. In this article I’ll give you some practical suggestions of things you can do to make CSI work for you.

Why Do You Need CSI?

When you design a new service, or a new process, or some new infrastructure, it’s never 100% perfect. If you spent the time it would actually take to eliminate all errors and inefficiencies, it would take so long that every project would be delivered too late to have any value. This means that whenever you create a new (or updated) service (or process) it already has things wrong with it even before you get started. If you have CSI in place then this won’t matter, because you will immediately start monitoring and improving things, so that they gradually approach the perfection that you’d like to offer your customers. You won’t ever achieve perfection, but you can keep getting closer. Don’t think that CSI is just about processes, or just about the efficiency of the IT department. CSI should help you to achieve things that have a direct impact on your customers. CSI can help you to:
  • Review and improve your service portfolio, to ensure that you are delivering the services that your customers need, not just the services you’ve always delivered in the past.
  • Review and improve every service, to ensure that it delivers what your customers expect, not just what you thought they needed.
  • Review and improve your technology, to ensure that it underpins your services, helping you to deliver high quality services that meet customer expectations with minimum cost and maximum flexibility.
  • Review and improve your IT service management (ITSM) processes, to ensure that they underpin delivery of the services, that they help you to meet customer expectations, and that they help you work efficiently to minimize the cost of delivering services.
  • Review and improve the skills and competence of your people, to ensure that IT personnel have the right skills and competence to manage the technology, execute the processes, and deliver the services.
CSI won’t instantly make all of these things perfect, but it will help you to continually improve them, so that you can keep up with ever increasing customer expectations, and so that you can stay ahead of your competition.

If you'd like further information and need that extra push to get started with CSI, please go ahead and download my 7 tips, which begin with thinking about attitudes, behaviour, and culture. DOWNLOAD THE TIPS

Please share your thoughts in the comments or on Twitter, Google+, or Facebook where we are always listening.
Continue reading

ITSM Basics: Getting Your KPIs Right

Posted by on November 10, 2015 in Service Desk
ITSM Basics Is first contact resolution (FCR) a good KPI for the service desk and incident management? Many corporate IT organizations think that it is – after all, it’s definitely one that’s prominent in the ITIL books and is popular with many IT service management (ITSM) consultants. But is it right for every IT organization? On one level, is it a just a measure of closed calls or of the percentage of end-user issues that were given proper care and attention? On another, what’s included in FCR stats? Just easy incidents, including password resets? FCR can be fiddled with, and I’ve even seen service desks that add room bookings into their FCR calculations. Are trickier issues disallowed for “fairness”? And I bet some would include wrong numbers if it made the FCR stats look better. FCR, along with other ITSM KPIs, can definitely drive the wrong behaviors.
However, the real issue for me is that IT organizations need to understand what they are trying to achieve before they can define their KPIs – so picking up an industry best-practice KPI and making important decisions based on it might not be in the best interest of the company using it. I’ll come back to this. First and foremost, IT organizations also need to understand what KPIs are, and their use.

So What’s a KPI?

The easiest place to start is to look at the KPI acronym and what it stands for, or at least what it should stand for:
  • K is for Key. Most organizations will struggle to measure and report on every possible metric and, if there are too many KPIs, then the less important ones will most likely distract organizations from the key ones that they really need to focus on.
  • P is for Performance. A KPI should help organizations and teams to understand how well they are performing, and each KPI should help them to focus on a critical success factor (CSF) that needs to be achieved.
  • I is for Indicator. A KPI is not proof that something has been achieved – it’s simply an indicator that suggests how well you are currently doing. Achieving KPIs is not the end goal, it’s simply a tool to help organizations to focus on their activities, to implement remedial or improvement activities as needed.

Don’t Confuse KPIs with CSFs

Wow, us IT people really love our 3LAs (that’s three letter acronyms)! CSFs are the things organizations or teams must achieve to help meet their goals and objectives. These may not be directly measurable, but it should be very clear how they contribute to success. Some examples of CSFs for ITSM processes include that:
  • The business is protected from the adverse impact of IT change (a CSF for change management)
  • IT service downtime doesn’t have a serious impact on the affected business service or process (a CF for availability management)
  • Workarounds reduce the business impact of problems (a CSF for problem management)
And although IT organizations might not be able to directly measure these CSFs, they can discuss them with their customers and other stakeholders, and agree that this is what you are trying to achieve via ITSM.

Turning CSFs into KPIs

Once CSFs have been agreed it’s time to define KPIs that indicate how well the organization is performing against these CSFs. There should only be a small number of KPIs for each CSF, otherwise the numbers become unmanageable. Looking at the “Downtime of the service does not have a serious impact on the customer’s business process” CSF, example KPIs could be:
  • A maximum of four events in any year where there’s a total loss of the service to all users
  • The maximum downtime for any total service outage is 30 minutes
And remember, achieving these KPIs will not definitively prove that the CSF has been met, but it will help to indicate it. Organizations should agree with the customer that this is what will be measured, and then report the KPIs to indicate how good the performance has been. But, in customer reviews, there is a need to discuss the CSF, not the KPIs – with the customer discussion something like “Here is the KPI data, do you agree that downtime of the service has not had a serious impact on your business processes?” This way, organizations can focus on what’s important rather than on what’s being measured. Read that last sentence again – it’s a very important point with KPIs and CSFs.

Why Using Best-Practice KPIs Can Be Dangerous

The ITIL books include many example KPIs, but in each section that lists KPIs it says: “These KPIs should not be adopted without careful consideration. Each organization should develop KPIs that are appropriate for its level of maturity, its CSFs and its particular circumstances.” Let’s return to the example of FCR and think about whether this is a good KPI or not. Suppose that an organization just measures FCR, as the right thing to do, and then reports it to show how the service desk is increasing the number of customer incidents and requests it closes during the initial phone call. This has to be good, right? But then suppose that the organization introduces a new self-service capability, to allow people to manage many of their own incidents and requests without the need for a phone call to the service desk. They might also automate password resets, and provide knowledge articles to help people resolve common issues for themselves. This should lead to faster resolutions and happier customers but, as more of the simple incidents and requests move away from the service desk, the agents will have a higher proportion of difficult incidents to deal with. Thus FCR will get worse and might even become irrelevant. Hence FCR might be a good KPI for some organizations, but it might be completely inappropriate for others. And, more specifically, using FCR to benchmark either over time or externally will be inappropriate as the average incident or request level changes over time. So when an organization is defining KPIs it really does need to think about: its level of maturity; its customers; and its goals, objectives, and CSFs. It’s important that they choose a small number of KPIs that will help to indicate how well they’re doing versus the CSFs. They will also need to regularly review their KPIs to ensure they are still appropriate. When did you last review the KPIs you use to manage your IT services? Maybe it’s time to think about them again. For further insights, I recommend you watch my good friend Rob England's webinar The Right Metrics for Your Service Desk. This blog is based on a previous Joe blog written for Conference in a Box. Image credit
Continue reading

Usable Metrics Are More than Just Numbers

Posted by on November 4, 2015 in Service Desk
Service Desk Metrics We live in an age of measurements and analytics, where organizations like to calculate how well they are doing, and how well (or badly) their employees are performing. This applies to IT service management (ITSM) where metrics, business dashboards, key performance indicators, and similar terms are everyday ITSM speak. So…we have lots of numbers that represent what we do, and we hear that ”the numbers do not lie,” but too many organizations don’t make use of these numbers as they should; meaning they don’t derive the right information or follow up with the right actions, based on the outcomes. One of the reasons service desk performance metrics are so under-used is the apparent belief that the numbers mean one specific thing when, actually, they often mean very little without context.

Trends and Contexts Matter More than Values

If you tell me you weigh 70 kilos, it tells me what you weigh. If you also tell me that you were 71 kilos last week and 70 the week before that, then I know more about you, and can surmise something about your lifestyle. If I then discover that you have just taken up weightlifting and are building up your size and strength for a competition, then I’d no doubt be more impressed than I would’ve otherwise, without that knowledge. The same applies to ITSM. Many organizations measure their user or customer satisfaction on a scale from 1 to 5. Telling me you scored 3.9 might sound good, but less so if you scored 4.1 last month and 4.5 at this time last year. And even if satisfaction has dropped over the last 12 months, what is the context? Has your workload doubled; did your company launch several new products? Understanding the context can help with proper prioritization and service improvement. Just taking numbers at face value without context means you are addressing symptoms only, instead of the underlying cause. Take that falling satisfaction metric, for example – retraining service desk staff or even employing more of them won’t help if the underlying cause is new services that don’t work properly!

Dig a Little Deeper

Let’s take the example of the user satisfaction score one more step. If your score was 3.0, and it’s been around that figure steadily for the last year or so, and there’s been no obvious external factors nor any major changes going on – what could that mean? That there’s room for improvement and you should get started on new training for the whole service desk team perhaps? But wait a moment. What kind of 3.0 is that? With a scale of 1 to 5, there are multiple ways of getting an average of 3, and finding out why you scored 3 might make an important difference to how you set about improving things. Here are some scenarios that will produce a score of 3 in your user satisfaction metric:
  • Just about everyone rates you as a 3. Could be you are average, or could be that folks are too busy to take the survey seriously and just go for the middle box.
  • You get an equal distribution of scores at 1, 2, 3, 4, and 5. The entire range of different levels of satisfaction averages to 3.
  • Half of your users rate you as 1, the other half as 5. Some real extremes here.
  • Half think you are 2, half as 4. A mix of good and bad but not so extreme.
Of course, real life is rarely as neat as any of these, but the point is that depending on how that score of 3 is obtained, you would set about improving things in different ways. In fact, depending on which option you were nearest, you might feel the need to go look for a range of other information.

Find the Pattern

The extreme example above is, sometimes, referred to as the ‘marmite factor’ (marmite is a yeast extract spread that people seem to either love or hate, with very few being indifferent to its taste.) Expressing this set of results only by its mean average of 3 is very misleading. If you get this result in a service desk situation, it raises two important questions:
  • Why are the happy people happy? What are we doing right?
  • Why are the others unhappy? What are we doing wrong to them?
Of course, in order to answer that, you need to find out which users are which. Is there a recognizable pattern? Do the people on one site love the service, and those on another hate it? Do your younger users like it and the older ones not? Is it language based? The list goes on and there is no point guessing; you need to do some analyzing to find out. But what you shouldn’t do is react immediately to that simple average without further investigation. You don’t…do you? If you’re interested in learning more on the right service desk metrics, I highly recommend you watch this webinar presented by Rob England, the IT Skeptic. Image credit
Continue reading

Should Change Management Be That Difficult?

Posted by on October 27, 2015 in ITIL
Stages of Change Management In a world of constant change in every aspect of life, it might be reasonable to expect that deciding on changes and processing them would be a widely held skill, familiar to us all. It’s so innate and essential that in IT service management (ITSM), for example, you’d expect perfect, polished, and pervasive change management to be the norm. Perhaps changes at work are more complicated than in our everyday lives and have broader, and more expensive, consequences? Probably more people will be involved, and we might be less likely to be the decision makers; but the underlying stages shouldn’t really be that different. In practice however, the change management process still seems to be difficult, and is an ongoing source of discussion and debate across social media for ITSM professionals. Some of the reason for this, I believe is that IT spends too much effort on the wrong parts of the change process, trying to control too tightly or argue over things that cannot be changed.

The Stages of Change Management

The full change management process has three phases:
  1. Request: “Please may I have something new, some more of the same, or something different?”
  2. Thinking and Deciding: “Should we do it? If we do it what is the best way and the best time? What will it give us? What will it cost? Who should we ask?”
  3. Realization: Actually build the thing and put it out there so people can use it. “Make it so!” – as Captain Jean Luc Picard might say.
For an organization to make best use of their limited resources, and yet also maximize potential improvements, all three phases of change management need to be there and functioning well. Understandably, technically-oriented IT departments seem happiest dealing with the last phase, i.e. actually building, testing, and implementing the technological consequences. But all three parts truly matter. Without an appropriate request process the best ideas might never see the light of day. And, unless the thinking and deciding phase is properly done, organizations will most likely end up spending their time and resources doing the wrong things.

Thinking and Deciding – Without Boiling the Ocean

Organizations are full of potential change; having lots of people involved in making decisions about each and every change is going to be impossible. Anyone who tries is going to disappear into a bureaucratic mess that will see changes blocked and slowed down by administration, or more likely, they will find changes taking place without going through the approved process. The successful route is to focus the right resources on the right kinds of decisions; those situations where an IT decision actually needs to be made, where there are benefits, costs, and risks to be considered and balanced. The first step in allowing that focus is to identify two areas where IT should not spend time considering, discussing, and deciding.

Don’t Fight the Undefeatable

Some changes are inevitable, so time spent considering whether to do them is time wasted. For these, ITSM (and other service areas of the organization too) just need to accept it and get on with it, like it or not. Examples include:
  • Direct instructions from CEO, Board of Directors, etc.
  • Legal requirements
  • Changes imposed by supplier actions, such as withdrawal of support for hardware or software
No matter how much anyone in IT might disagree, think carefully before deciding to challenge these; you were being told, not asked. Of course, it should still be open to decide how best to handle the change. It is vital to establish the actual purpose of the change. Sometimes it can be hard to see this because the change might be presented with an assumption of how it should be done rather than what it is supposed to achieve. For example, the response to a supplier withdrawing support is often a request to upgrade to that supplier’s latest version. Alternative options exist though, like moving to a different supplier, building an in-house alternative, taking the risk to run the software unsupported (i.e., not to upgrade), and more.

Don’t Sweat the Small Stuff

In our everyday lives, we are all used to changes being decided at different levels of authority. Take a look at this example and see if it fits with your family experience.
Kind of Change Authority Mechanism Caveats and Rules
Moving to a new city Family meeting All adults have to agree, all children consulted
Decorate the house Parents Veto rights for own bedrooms
Choosing dinner Delegated to whoever does the shopping Known list of unacceptable solutions
Inviting friends over Anyone can do this Inform early if extra meals are involved
Obviously holding a family meeting to discuss minor issues isn’t sensible, nor is imposing major life changes on the whole family without some consultation. The same mechanism that makes the house run effectively – delegating changes and authorizing people to decide on minor or already agreed issues – works just the same in the work environment. ITIL® calls these standard changes. For the most part, these are the kinds of changes that have happened before and therefore already have established rules. People are trusted to ‘just do it’. Think like a parent – the first time your child invites a friend to sleep over, you would expect to be asked, discuss, and approve the occasion before it happens. Once you meet the friend and know things are fine, you trust your child to decide for himself/herself the next time. You may have caveats to that authority – not on Thursdays, or while you have relatives visiting, or you may require that they pay for consequential additional costs (like movies and popcorn). But the rules are set before, everyone knows where they stand and things progress smoothly. If they abuse this delegated authority, it can be removed (no friends allowed over whilst grounded). All these techniques can apply in work-based standard changes too, along with all their benefits. The first person who wants a new project management software package will need to justify it. By the time the 30th person needs it, it will be everyday routine. In the extreme case, some changes might be actioned and recorded with no human involvement at all. For example, employees may be allowed to download free software onto their work PCs, and then auto-detection software will find the new programs, establish they are not on any blacklist, and record them. In case of future issues the information is there, but for the most part everyone is able to just get on with doing the stuff that actually does require a human thinking about. So…if you can see how your human-sized attitudes work at home, maybe apply the same approach at work with your standard changes – it will surely simplify the process. Image credit
Continue reading

Come to FUSION 15 and Learn about ITSM

Posted by on October 21, 2015 in ITSM
Learn ITSM from Stuart Rance I’m really looking forward to speaking at the FUSION service management conference this year. FUSION will be running from 1-4 November 2015 at the Hyatt Regency in New Orleans, and if you’ve been before then you know that you’re in for a great treat. If you’ve never been before then do please think about joining us this time; it’s an excellent opportunity to learn from, and network with, other service management professionals. Hope I’ve convinced you! So while you’re there, if you want to hear me talking about the role of people in service management, then come to Breakfast Briefing 07 at 7:30 AM on Monday November 2nd. FUSION is so big that you can choose between seven parallel breakfast sessions before the first keynote of the day. In between the daily keynotes there are sessions for you to choose from. The sessions are organized in nine parallel tracks so you can decide what will give you the most value; the nine tracks include “The Beginner’s View”, “The Expert Focus”, and “Service Support and Operations”. In total, there will be more than 80 presentations and five keynotes to entertain, educate, and inform you. The hardest bit will be deciding which sessions to attend and which you’ll need to miss.
In between the sessions you can look round the expo hall, where exhibitors will be happy to show you their products and talk to you about service management. Even if you’re not looking for a new service desk tool right now, it’s good to see what people are offering because it might give you new ideas for configuring or getting more value out of tools you already use. As you walk around the show floor you can stop and talk to a wide range of people, and since everyone is there to learn and share ideas about ITSM, the chances are you’ll find like-minded people to chat with. If you’d like to chat with me, I’ll be spending some time talking to people on the SysAid stand, so please do come by and say hello. You’ll find copies of my new white paper “We Don’t Do People” at the SysAid stand, so if you don’t manage to get up in time for the 7:30 AM breakfast briefing, you’ll still get the chance to find out what I think about this and get my tips. If you are not going to FUSION, you can find a brief summary of the ideas I’m covering in this blog post from earlier this year. Any conference goers who aren’t totally exhausted by the end of the day can attend the networking reception at 5:30 PM on Monday, and the conference party at 7 PM on Tuesday. Both are brilliant opportunities to network with other service management professionals, or just relax at the end of a long day. So – I really am looking forward to FUSION this year. Are you going to join me? I’ll be tweeting from the conference as @StuartRance, using the hashtag #SMFUSION15, so you can follow along even if you’re not there.
Continue reading
Subscribe
Watch & learn from industry experts about ITSM and help desk hot topics!