Posted by Doug Tedder
on December 27, 2016 in ITSM
“What advice do you have when your business case for ITSM is created but ignored?” This is what @sysaid
tweeted to me in reply to my tweet regarding my blog The Case of the Missing Business Case.
What a great question!
As I talk about in my original blog, every IT service management (ITSM)
implementation should begin with the development of a business case. The business case provides IT with an opportunity to demonstrate its understanding of the business it serves by objectively discussing the opportunities, risks, benefits, and deliverables of the ITSM implementation – in business terms
. A well-written business case articulates the needed investments, in terms of people, time, and money, as well as how ITSM implementation supports business goals and objectives. It helps make the ITSM implementation a business initiative, enabled by IT, and not just another “IT project.” But most importantly, the business case secures the first critical deliverables for any ITSM initiative – senior management investment and support.
”Yes, I did all of that, but…”
You wrote a strong business case. You addressed all of the pertinent topics. And your business case gets ignored.
Now what? Has all of the time developing and writing the business case been for naught?
Don’t give up just yet. Here’s 7 things you could try.
First, check yourself.
Objectively review your business case from the perspective of senior management. Are your assumptions reasonable? Have you clearly articulated resource needs and anticipated benefits. Is the business argument strong enough? Have you demonstrated that you will be a good steward of the company’s funds?
Engage your sponsor.
If you identified a sponsor in your business case, get that person involved. Ask for guidance and support for gaining approval of the initiative.
Engage key stakeholders.
Identify and meet with key stakeholders. Discuss how ITSM can help alleviate pain points or enhance performance for their specific issues. Not only will you build relationships, you may even learn some things that may further strengthen your business case. Gain their support and ask them to advocate for your proposal.
Publicize (really publicize) goals and measures.
Assuming you have the ability to collect some of the measures regarding the goals defined in the business case, start publicizing them. Post goals and current measures on an intranet page, outside your cubicle or office, in the break area – anywhere where people will see. Explain how not meeting these goals is impacting the organization and how ITSM would help. In the words of Dr. John Kotter
, you want to “establish a sense of urgency.” Using measures helps build credibility and a sense of urgency for the business case.
Conduct an experiment.
Can you “try out” a small part of the ITSM implementation? Take a current data sample to do a tabletop exercise to confirm assumptions or anticipated benefits of the implementation. Then, share the results with your sponsor and your key stakeholders to further enable their advocacy for the ITSM initiative.
Execute the communication plan.
As part of the business case, you most likely developed a high-level communication plan
regarding the initiative. Execute it! Look for opportunities to talk up the benefits and risks that you described in the business case. Go to staff meetings; do a roadshow; publish an article on your corporate intranet site or newsletter. The goal is to attract attention and gain grass-roots support for the ITSM implementation.
Sometimes the timing just isn’t right.
Keep in mind that due to business influences beyond your control, sometimes even the best-written business cases aren’t immediately approved. Don’t take it personally. It doesn’t mean that the ITSM initiative wasn’t a good idea; perhaps there are other business priorities that must be addressed first. If you find yourself in such a situation, use it as a learning opportunity and ask for feedback from those senior managers who reviewed the business case. Doing so demonstrates that you care and are committed to the success of the business. Good ideas are good ideas – and including feedback from senior managers in the next version of the business case will make for a stronger business case!
Persistence Pays Off
I once had a former manager tell me “if you don’t believe in your story, then you can’t expect anyone else to either.” You’ve built a good business case. Win hearts and minds through positive persistence – it will pay off!
Posted by Sarah Lahav
on December 20, 2016 in General IT
As 2016 ends and we look forward to another year in IT service management (ITSM), one wonders what we (ITSM pros) should be focused on in the next twelve months. There’s been a lot of buzz this year about things such as DevOps
, enterprise service management
, customer experience
, and digital transformation
. But I think there’s a wealth of opportunities for us and the businesses we serve in another area – automation.
Not the process automation that we’ve benefited from since the early days of ITSM tools, or the orchestration that has made virtualization and cloud so much easier. I’m instead referring to a different type of automation, where we “cede power to the machines” and their ability to learn, i.e. machine learning
– “the study and construction of algorithms that can learn from and make predictions on data”
(source: Wikipedia), where:
“Advanced machine learning algorithms are composed of many technologies (such as deep learning, neural networks and natural-language processing), used in unsupervised and supervised learning, that operate guided by lessons from existing information.”
Source: Gartner IT Glossary
recently stated that:
“Smart machines will enter mainstream adoption by 2021, with 30 percent adoption by large companies, according to Gartner, Inc. Technologies including cognitive computing, artificial intelligence (AI), intelligent automation, machine learning and deep learning fall under the umbrella term for smart machines.)”
But I’m far more bullish about machine learning from an ITSM and IT support (or for any service and support scenario) perspective, as many opportunities, and possible solutions, to use machine learning in our everyday activities already exist. And I think we will quickly see ITSM tool vendors partnering with machine learning technology partners to deliver against them.
ITSM Is Full of Opportunities for Machine Learning
ITSM pros have spent much of the last two decades optimizing IT service delivery and support in the enablement of business operations. Different operational elements have been addressed – from the adoption of best practice processes, the recruitment and training of the “right kind of people,” to the exploitation of technology (in particular workflow and automation, knowledge management, remote control, self-service, and more recently business intelligence
). Much of this has been done to improve efficiency and effectiveness – it’s what we seem to do in ITSM.
But we still often place too much reliance on human effort, and human intellect, when we could cede the power – okay, some specific tasks – to the machines. For example, tasks where algorithms can be used to understand patterns and context to decide the best course of action without human input. The results and benefits being similar to the use of our existing orchestration-type automation:
- Greater speed/efficiency – machines can be quicker than the smartest of humans. They also work 24/7 including all public holidays.
- Reduced costs – people costs are still a large part of the overall IT department budget and, while technology isn’t necessarily cheap, the cost of automation should be more than covered by people-cost savings.
- Better people utilization – it’s as simple as freeing up time-poor staff from repetitive (and potentially mundane) tasks to allow them to focus on the more important things.
- Reduction in human error – people make mistakes and it doesn’t matter if they are inexperienced, rushing, or tired – these mistakes might have an adverse business impact. Automation makes far fewer mistakes, with these usually still people related.
- Greater ability to change – quickly changing ways of working, or even just responses to simple questions, can be problematic for people as they unconsciously flit between old and new for a while. Automation, on the other hand, just stops the old way and starts the new way.
- Better customer experience – while automation is often seen as a boon for the service provider, it also extends its benefits to the service receivers – whether it be speedier delivery, the passing on of cost reductions, greater probability of service delivery, or better support and customer service when things do go wrong.
A new AXELOS survey and report
, “The ITSM Professional in 2030: A future full of opportunities” (January 2017), also shows that most ITSM professionals are already betting on automation and machine learning:
- Automation – 89% of respondents “think that an increase in automation will take over the repetitive tasks of IT, creating more time for service managers to focus on delivering more value to their organizations.”
- AI/machine learning – 77% of respondents “said they believed these trends would have a profound impact on the IT workforce, liberating ITSM professionals from routine tasks and free up time for responding to demands for more creativity and ‘human’ input.”
So where can machine learning help?
Five Examples of Machine Learning Use Cases in ITSM
These are all things that can be done or used now:
So what do you think of the possibility of machine learning becoming a staple of ITSM? Or are you already using it? I’d love to get your feedback in the comments section below.
- Identifying and predicting issues and problems. The technology can also offer up the most likely resolutions. It will reduce mean time to resolution (MTTR) and opens the door for predictive maintenance (and less reactive fixing).
- Better understanding the risks of proposed changes. Not only understanding what will be impacted but what the likely impact will be.
- Predicting what’s needed or even what will happen. From demand and capacity planning to understanding the future levels of customer satisfaction based on what’s happening or planned.
- Greater access to information and known solutions. Machine learning improves search accuracy, with data-based recommendation capabilities similar to what people already get in their personal lives from companies such as Amazon and Netflix.
- Easier and better knowledge management. The last two decades have shown that people aren’t great at knowledge management – or the knowledge article creation part of it at least. Machine learning can be employed to both identify “missing” articles gaps and to create new articles automatically from existing tickets, i.e. the already documented resolutions.
Posted by Stuart Rance
on December 13, 2016 in Service Desk
One of the biggest problems we have to deal with in IT service management (ITSM) strikes whenever we fail to meet the expectations of our customers and users
. No matter how good the service, and no matter how well we support it, when we don’t deliver what people expect they’re unhappy.
I’ve worked with lots of IT organizations who regularly failed to meet expectations, and who don’t accept any responsibility for this. There always seems to be an excuse, for example:
- “Their expectations aren’t reasonable.”
- “The business doesn’t give us the resources we’d need to do that.”
- “We’ve delivered what the service level agreement (SLA) says the users are entitled to.”
- “We didn’t prioritize it because the customers didn’t tell us it was important.”
- “We can’t introduce new functionality as fast as they want, we’re far too busy resolving issues as it is.”
- “We can’t make that change, it’s far too risky. They’ll have to wait.”
Perhaps you’ve heard things like this in your organization; maybe you’ve even said some of them yourself. If that’s the case, then maybe it’s time for some serious reconsideration. If you want to deliver a great service to your customers and users, explaining why you can’t do things isn’t good enough. What the most effective ITSM organizations do is to take responsibility for managing customer expectations. Of course, this is easy to say, but not so easy to do. Here are my suggestions.
If you want to improve your organization’s ability to meet expectations reliably, then you need to do four things:
- Understand what people expect
- Communicate what can be achieved and try to influence expectations
- Manage your services to deliver what people expect
- Report your achievements to ensure that people know what you delivered
All four of these are important, and you’re most likely to meet your customer’s expectations only if you pay close attention to all of them.
In the rest of this blog, I’ll be examining these four things in a bit more detail. But before I start, there’s an important distinction to bear in mind (see Users, Customers – What’s in a Name?
). ITIL distinguishes customers (who negotiate, agree and pay for the service) from users (who actually use the service). If you’re not familiar with this distinction, then think about a toy shop. The parents buy the toys but the children use them. When I talk about customer expectations I mean the expectations of both of these groups. Failing to consider the needs and expectations of users is just as bad as not meeting the expectations of paying customers.
Understand What People Expect
If you want to understand your customers and users’ expectations, you need to talk to them. And you need to do it on a regular basis, because needs change over time, and expectations change in line with them.
Many IT organizations rely on SLAs to tell them what customers and users need. Unfortunately, SLAs may have been negotiated months or even years earlier, and are, in any case, often written by the IT organization rather than by customers. You may know and understand the SLA, but what about your customers?
If you use SLAs to plan and deliver services, then you need to discuss them with your customers AND USERS on a regular basis. Do they understand the targets? Are the targets expressed in clear business terms, or are they technical IT targets of little relevance to anyone else? Are the targets still right for their needs? If you’re not yet in the habit of talking to your customers, please don’t wait for the next annual review to come round. Unless you happen to be in the middle of managing a major incident, the best time to talk to your customers about their expectations is right now.
Communicate What Can Be Achieved and Try to Influence Expectations
Sometimes customers do indeed have unrealistic expectations, and we can’t deliver what they expect because it would just be too expensive. For example, they may believe that you can deliver a service that responds in less than a second to thousands of transactions a minute, with all incidents being resolved within 2 minutes. Now how amazing does that sound?!
If you know what they expect and you really can’t deliver it, talk to them about it now. Don’t wait until after you’ve failed to deliver. Be honest, explain why this can’t be done; show them the potential cost of meeting the unrealistic expectation compared with the benefits. Sometimes this will be all you need to do to help your customers understand why they need to modify their expectations. On the other hand, you might be surprised to discover that the customer really DOES need that level of service, and is prepared to accept that they’ll have to pay for it. One customer that I worked with told the IT department that they wanted a service that failed over instantly. The IT department assumed that the 20 seconds needed for recovery after a RAID disk or cluster member failed would be good enough, but when I checked with the customer they really were prepared to pay what it took to fail over within ¼ of a second – because after that length of time the costs to the business would be enormous.
In any case, you need to agree what can really be achieved. When you have agreed, write this down, preferably using the customer’s own words. Don’t hide behind obscure technical targets. For example, many IT organizations specify a goal for percentage service availability. This could be 99.5% or 99.9%, but however meaningful this is to the technical staff, customers probably have no idea what it means. It’s much better to specify how often the service is likely to fail and how long it will take to fix. For example, “Complete service failure will happen at most 4 times a year and will be resolved within 4 hours” is much more helpful than “99.82%”.
Manage Your Services to Deliver What People Expect
It’s not enough to agree on targets with your customers, if you can’t achieve them. You need to make sure that you put in place whatever measures are needed to do what you said you would do. Let’s take the example we’ve just used. If you’ve agreed that “Complete service failure will happen at most 4 times a year and will be resolved within 4 hours,” then you need to think about how you can manage both of these numbers. What might cause a complete service failure, and how likely is it to happen? How can you make it less likely? How would you recover from this failure? How long would it take? What can you do now to cut the recovery time? This is all fairly standard risk management activity, but if you don’t have a risk register and you don’t manage your risks, then you’re just waiting to fail.
Report Your Achievements to Ensure that People Know What You Delivered
Finally, you need to talk to your customers about what you have actually achieved. Again, you should do this in terms they find useful. Don’t provide customers with a 200-page report every month if they just want to know what exceptions happened, but don’t just tell them what went wrong. The most important thing to do in a regular report is to tell customers what you are doing to improve. Explain what you are doing to make their experience better next week, next month, or next year. Discuss these improvements with them. Are you focusing on the right things? Will the proposed improvements actually make their experience better? Do they have suggestions to make?
What do your customers think of the services you deliver? Do you have good feedback mechanisms in place so that you really understand how they feel? Mechanical customer surveys have a part to play, but nothing can replace getting out there and talking to your customers, AND your users. If you make sure that you understand what they want, that they understand what you can deliver, and that you are working together to ensure the best value from the IT services
that you manage on their behalf, then you won’t have any problem with managing customer expectations.
You can read more about customer experience in my white paper ”Back to ITSM Basics” Might Not Be What You Expect
Posted by Sarah Lahav
on December 8, 2016 in General IT
Most tech predictions focus on the next “big thing.” With our appetite for new and different, we tend to overlook the power of ongoing trends. 2017 is a year when existing innovations will settle down, mature, and have their heyday.
Innovations are most powerful when they are taken for granted
. Consider smartphones. When Apple released the iPhone in 2007, it was the world’s hottest technology. Over the past 10 years, smartphones have lost hype but gained influence. If at least 2 billion people
own smartphones, they are not merely a technology but an institution of human society. Their ubiquity is power.
In 2017, four ongoing trends will make strides towards that honor of being taken for granted:
1. DevOps – We’ll Do It Our Way
In 2016, every tech company seemed to experiment with DevOps. Organizations all want to release software daily or weekly without errors and downtime. Yet no one agrees on the definition of DevOps. Is it a culture? A set of processes and technologies? A philosophy?
DevOps is probably all the above, and the definition is flexible by design. DevOps is not unlike “mindfulness” training, a hot trend from the health world. If you want to be more mindful, should you meditate, keep a journal, go to yoga classes, or do all three? Who knows until you try them out? Ditto with DevOps: the best approach is the one that works for your company.
DevOps is destined for ubiquity. Companies will get beyond their DevOps identity crisis in 2017 by defining and applying the methodology in their own way.
2. Cloud Computing – Let’s Get Our Money’s Worth
In 2016, no one can dispute the cost-efficiency, convenience, agility, and other values of cloud computing. That doesn’t mean companies have saved money by switching to cloud services. Why?
Well, when you start an expensive new sport, like skiing, it’s tempting to overbuy equipment. You might choose the heaviest, warmest coat at the store. A year later, when your skiing improves, the coat becomes unbearably hot and sweaty. You wish you had bought a lighter jacket and some layers for half the price of that wearable furnace.
2017 is the year when companies will downgrade, ditch, or replace the bulky, expensive cloud services they didn’t need in the first place. The cloud will finally save money.
3. Cybersecurity – The Internet of Things (IoT) Battle
On October 21st
of this year, a DDoS attack against Dyn, a major DNS host, showed us how vulnerable the Internet of Things (IoT) is. Some of the U.S.’s largest metropolitan areas couldn’t access Twitter, Netflix, Reddit, PayPal, and dozens of other popular web services. As security expert Brian Krebs explains
, the attackers hacked Internet-connected digital video recorders (DVRs) and IP cameras and then used them to flood traffic towards Dyn’s servers.
Commentators have raised alarms about the vulnerability of IoT for years
. It’s not a new trend. Although the Dyn attack seems ominous now, it will force IoT cybersecurity to mature in 2017. IoT device manufacturers will make cybersecurity a priority rather than an addendum.
4. Help Desk – I’ll Do It Myself
A surprising number of people still email or call help desks directly. They don’t bother consulting the end-user portals, knowledge bases, and other self-service options.
At SysAid, where we provide help desk
and IT service management (ITSM)
solutions, we’ve learned that Millennials do the opposite: they dread getting on the phone. They troubleshoot independently and then submit digital tickets if that fails. Frankly, they save time and money for help desks.
In 2017, help desks will try to convince Gen Xers and Baby Boomers to use self-service. To that end, help desks will improve the quality of content in knowledge bases so that anyone can follow along. They will also make self-service more social. Historical issues from the community will constitute the bulk of knowledge base content.
Will this work? Not in every case. I’m sure you know somebody who hates e-readers and says, “I just like to hold a physical book.” Likewise, a lot of end users say, “I just want to speak with a real human being.” That cohort of end users (maybe 20 percent) won’t change.
The Mark of Importance
Some forecasters ask you to ponder a hazy future; I ask you consider a more concrete present. In 2017, embrace the innovations that stop
making headlines and start
defining whole industries. Being taken for granted is an inglorious mark of importance – and power.
Posted by Sarah Lahav
on November 16, 2016 in Help Desk
An IT help desk
can easily take on a huge range of activities, but if you have limited resources then you must think about the essentials. This is true even if you’d like to grow your help desk over time so that it delivers every capability of a fully featured enterprise service desk; it’s much wiser to start with something more limited, deliver some value to your customers, get some feedback, and then grow incrementally, rather than trying to start everything at once.
So what are the essential things that a help desk has to do? Here’s my list, based on my many years of experience in the industry.
Log and Manage Calls from IT Users
One of the most important capabilities of an IT help desk is great interaction with users. This means that you must provide a user-friendly way for customers to contact the help desk, and you must make sure that every user interaction is captured so that it doesn’t get lost. Typically, users contact the help desk by telephone, but if you can provide other channels such as a web portal to help users contact you, then that’s even better.
Every time a user contacts the help desk, you must create a record showing what they asked, and how you responded. Even if it’s just a quick question that you could answer straight away you should always keep a record; one day you might need to know what happened, and if you don’t record it then it’s gone forever.
But the help desk’s fundamental responsibilities don’t end when you put the phone down after a call. A great help desk must also take responsibility for making sure that every call is properly managed. So, you must make sure the customer’s issue gets resolved (I’ll come back to that in a minute). You must also keep the customer updated. And, later, check that the customer is happy with how the call was resolved.
A help desk that just logs incidents and passes them on to other groups to resolve doesn’t add very much value. There are some help desks that work like this, but they are very unpopular with users. And what help desk wants its users to see them as nothing but an obstruction that slows down their access to the people who can really help them?
I think that every help desk should be able to live up to its name. It should provide some level of help. The people who work on the help desk should have the skills, training, and access to knowledge
in order to be able to resolve a reasonable percentage of user incidents, ideally during the initial customer call.
If you’re setting up a new help desk, or planning improvements to your existing help desk it’s very important to focus on this. Think about the types of incident your help desk should be able to resolve on its own, and then make sure you recruit and train help desk technicians that can deliver real value to your users.
There will always be some incidents that the help desk can’t resolve. When that happens your help desk staff need to have the right relationships with the groups who can resolve those incidents. Make sure they can escalate such incidents to the right people, and that escalations get the right response. You should make sure that everyone knows who is responsible for getting back to the user with updates. But even if the help desk isn’t responsible for updates, they should still be keeping an eye on all outstanding incidents to make sure that progress is being made and users are happy.
Generate Useful Reports
Help desk reporting
is NOT an optional extra. You need reports to understand what value you are getting from your help desk, what areas need to improve, whether your users are happy with the service they’re getting, and so on.
The first questions you need to ask yourself about help desk reporting are “Who are the reports for?” and “What will they use the reports to do?” Don’t make the mistake of generating long, boring reports full of numbers that nobody cares about, or even bothers to read, just because you have the data. Keep the reports as short as possible, and base them on the things your stakeholders care about.
There are some examples of metrics and KPIs, which you might want to include in your help desk reporting, in Stuart Rance’s
recent blog Defining Metrics for a Help Desk
, but these are just examples. The important thing is that your
reports have the information that your
I’m sure that some people won’t agree with me including continual improvement as an ESSENTIAL activity for a help desk, but I’m going to do it anyway. Because the alternative to continual improvement isn’t staying where you are, it’s becoming gradually irrelevant. Never forget that in a competitive market – and every market is competitive nowadays – your customers always have choices. If every other organization invests in continual improvement and you choose to carry on as you are then they are going to leave you behind. Eventually someone will notice that you offer poor service, and poor value for money, and that is not where you want your company to be.
So, think about what matters to your stakeholders and make sure that you keep improving. There are many ways that a help desk can improve; you may want to think about some combination of:
- Cost reduction
- Faster incident resolution
- Improved communication with users
- Increasing number of channels available for users to communicate with you
- Supporting a wider range of services and issues
- Adding support for request fulfilment, change management, or other ITSM activities
Whatever you decide to focus on, you should make sure that you measure and report progress, so that stakeholders can see that the help desk is continually improving.
So now you know what I think is essential for every help desk:
- Log and manage calls from IT users
- Resolve Incidents
- Generate Useful Reports
- Continually Improve
If you’re doing all these things then congratulations, you’re probably running a pretty good help desk. If not, then I highly recommend that you think about what it would take to get there.
There are, of course, lots of added value things that you could do to make your help desk even better, and I’ll be writing about some of those in my next blog.
Posted by Dena Wieder-Freiden
on November 7, 2016 in Help Desk
The help desk
was a new idea for IT departments back in the 1980s and 90s. That’s when organizations figured out that it was far better to have a team of people fielding all the calls for help that came in to IT, rather than having the engineers’ work disrupted by breaking off what they were doing to answer the phone calls from users needing help. Justified by that initial benefit, help desks appeared and evolved across the IT industry and across the world.
Despite an initial goal of minimizing disruption to IT, the positive benefits of a dedicated group focused on communication, for the user community, quickly became evident. At its heart, a good help desk
does exactly what its name implies – it delivers help to those who need it.
The New Terminology
Beginning around the year 2000, the IT service management (ITSM)
scale and scope moved up and onwards – and one of the apparent ”upgrades” has been the substitution of the term help desk
by the term service desk
to imply a wider range of responsibilities, most especially the capture and completion of service requests.
While that’s all good and true, it shouldn’t take all our attention away from the initial purpose of the help desk; those basic help desk skills and functions are still needed and, indeed, are still there inside the modern service desk: help is delivered and service requests are resolved. We need to remember that a key role of ITSM organizations is to deliver that help desk capability because when users can’t do what they need to, they don’t feel a need for service, they feel the need for help – and delivering help is not quite the same as responding to service requests.
I’ll explain what I mean…
Dealing with Service Requests
Service requests require consistency and following procedures. It’s about someone asking for something they’re entitled to have. That could be a wide range of things, from access to an application or a building through new software to a replacement PC. A key aspect is ensuring that entitlement is actually there, which means following procedures and rules. So, with the occasional exception of course, the service request part of the service desk needs laid-down procedures and staff to follow them. This makes it eminently suitable for automation, therefore we see more and more of this role being delivered via self-service portals
without the need for human interaction.
Answering the Cry for Help
On the other hand, the help desk role is a little different. When folks need help, it isn’t from entitlement but from a position of need. Often, they need more than just the answer to what’s wrong, they need support and understanding. Some kinds of help can be accessed perfectly well through self-service portals, but for many situations, human-to-human interaction is required.
Far more often than with service requests, calls for help don’t fit neatly into the laid-down procedures, rather they require an element of adaptation and amendment with a certain amount of innovation from the help desk staff. In unexpected circumstances (and we all meet those from time to time), a good help desk will actually have to go against the rules – something that management should encourage. For more on that, please read Do You Know When to Break the Rules?
by Stuart Rance
where he discusses a concept he heard presented by Ivor Macfarlane
called “intelligent disobedience” – knowing when not to follow the rules can lead to better decisions under certain circumstances.
So … don’t let the modern terminology distract you or your staff from the (very much!) still current need for a help desk. Folks with service desk
in their job title should continue to see themselves as offering help to those who need it – and going the extra mile past laid-down rules to offer it.
Even more importantly, managers responsible for service desks need to realize that they are also
automatically responsible for their company’s help desk – and be aware of the dual roles they and their staff are taking on.
In all the latest hype about self-service and automation, it can help to ask yourself if your service desk is a place where users can feel comfortable coming up to – when they need help, when they are confused as to what to do, or when things just seem to be going wrong and they don’t how to deal with it.
Posted by Stuart Rance
on November 1, 2016 in Help Desk
Some time ago, I wrote a blog about Defining Metrics for the Service Desk
. Recently someone asked me what about the help desk? This person works for an organization that doesn’t have an enormous service desk, with hundreds of agents and a complex multi-level service catalogue. Instead, there’s a help desk with just a few technicians who provide support to their users. I’ve worked with IT departments from several small- and medium-sized organizations. In one organization, the help desk consisted of just two technicians whose manager also managed many other people in a variety of different roles. In other organizations, the help desk may have up to 30 or 40 agents, but they don’t operate on the same scale as a large corporate service desk.
Many of the differences between a help desk and a service desk
stem from this difference in scale. Typically, a help desk doesn’t have the kind of sophisticated telephone system that routes calls and generates statistics on how long it takes each agent to answer the phone. Instead, staff use a combination of a normal telephone and a web-portal to receive calls from users, and respond to them. The behavior we want to encourage, the metrics needed to encourage that behaviour, and the data available for actually doing the measuring, are all likely to differ significantly from what works best for a service desk.
But Some Things Don’t Change…
Some of the advice I offered in my blog about metrics for a service desk does apply just as well to a help desk. This includes:
- Making sure you understand what you’re trying to achieve, and what’s important to you and your customers. Write this down – even if you can’t measure it. Then use this to help you define KPIs that will help to indicate how well you’re doing.
- Always remembering that KPIs are just indicators. Don’t ever make the mistake of believing that achieving the numbers means you’re doing a good job.
- Defining your own help desk metrics and KPIs. Never just copy them from a book or another organization (or even a blog like this one). You know much more than I do about what matters to your organization and its customers.
- Reviewing your help desk KPIs regularly to make sure that they are still appropriate. The things that you (and your customers) care about will inevitably change over time, and when they do, you need to make sure your KPIs reflect this.
Objectives for a Help Desk
So now that we’ve spent some time thinking about general advice, let’s focus on some of the practical things you can do. The most important first step to take is to spend some time thinking about the things that your help desk should achieve, and then to write those things down as simply as you can. Remember that these achievements don’t have to be measurable. However, they do have to be the things that you and your customers really care about. Here are some examples of things you might care about:
- Customers find it easy to contact the help desk when they need to.
- The help desk solves customer issues quickly.
- The help desk communicates well with users, keeping them informed and meeting their expectations.
- The help desk collaborates with other parts of the IT organization when needed.
But please don’t just copy these ideas. Make your own list, one that is relevant to your situation, and then talk to your customers about it. Make sure everyone agrees that these are the most important things for you to achieve.
Once you and your customers have reached agreement about what you should achieve, you have some objectives to work with.
Defining KPIs that Support the Help Desk Objectives
For each of the objectives that you’ve written down you should now think of 2 or 3 KPIs that you can measure to indicate how well the help desk is meeting the objective. It’s important to remember that your KPIs are just indicators; don’t have too many of them, collecting more data than you need is a waste of everyone’s time and effort.
Here are some examples of KPIs a help desk could use to indicate whether they are achieving the objectives in my list of examples:
: Customers find it easy to contact the help desk when they need to.
- KPI: Less than 8 hours per week when users are working but there is no service desk coverage
- KPI: Failures of the web-portal recover automatically within 5 minutes
: The help desk solves customer issues quickly.
- KPI: 98% of incidents are resolved within the times defined in the SLA
- KPI: The backlog of open incidents reduces every week
: The help desk communicates well with users, keeping them informed and meeting their expectations.
- KPI: Fewer than 10 calls per week from users asking about the status of their incident
- KPI: Post incident user satisfaction rating averages greater than 4 out of 5
: The help desk collaborates with other parts of the IT organization when needed.
- KPI: No negative feedback about the help desk from other parts of the IT organization
When you look at these KPIs and think about them, these are the important points to notice:
- Every KPI supports an important objective, and achieving the KPI will indicate that the objective is being met.
- Every KPI can be measured.
- Every KPI has a clear and unambiguous target.
How to Use the Help Desk KPIs
If you decide to follow the advice I’ve been offering, by this point you will have a list of objectives for your help desk, and a list of KPIs for measuring and reporting on how well it is performing. At this stage, it’s all too easy to get so caught up in the KPIs that you lose sight of the original objectives; and it’s vital that you don’t let that happen.
The best way to make sure that you always stay focused on your objectives is to create reports that include them; list the measured metrics and trends under the objective they refer to. This way you will be able to lead conversation about your reporting back to the things that matter.
When you take the report to your customer, the conversation should be about the objectives. Ask about them directly: “Did the help desk solve your issues quickly?” You can provide the metrics to show how quickly you solved issues, and you can use the trends to show that you are improving every week, but don’t present the numbers and tell the customer that this means you did a great job. You must allow your customer to tell you how well you did.
For example, think about a KPI that reads “98% of incidents are resolved within the times defined in the SLA”. Let’s suppose the help desk achieved 99% this month, but one incident that didn’t get resolved within the timeframe specified by the SLA had a huge financial impact. Your customer might well not agree that you did a good job, and your KPI definitely needs some tweaking.
So, use the KPIs for setting thresholds to help you take action when things aren’t going well, and for trend analysis, to see which things are getting better and which might need improvement. But DON’T use them to tell your customers that they are satisfied!
Appropriate KPIs for a help desk are unlikely to be exactly the same as those for a service desk, but the underlying principles don’t change. Identify your objectives, then identify things you can measure and report to indicate how well you’re meeting the objectives. Use what you discover to help you communicate with your customers and to help you identify what you need to improve.
When did you last review your help desk metrics? When did you last talk to your customers about them? Are you measuring and reporting the right things? As always do please let me know if you try the ideas from my blogs.
Posted by Sarah Lahav
on October 25, 2016 in Help Desk
Working in IT, particularly on the IT help desk, can often be a “glass half empty” rather than a “glass half full” experience – with many of the day’s activities related to things that have gone wrong. So it’s easy to avoid anything else that is remotely negative in nature, but unfortunately if something is wrong – in terms of people, process, or technology
– one has to bite the bullet to provide negative, but hopefully constructive, feedback. Here I provide ten tips for providing such feedback, along with advice on how to ensure that you go about it the right way.
1. Check, Check, and Recheck
Are you 100% sure that the person you’re providing the negative feedback to is deserving of it? Are you sure that the issue isn’t simply because of bad instruction, faulty processes, misunderstanding, or someone else’s mistake? Always ensure that you have all the facts, and never make assumptions. You’ll only create further damage if your feedback is based on inaccuracies and/or is un-deserving.
2. Highlight how improvements can be made
When a person receives negative feedback it’s common for them to go into defensive mode. They can often become upset, and worse still, apathetic – the result of which means they actually get worse, not better. It’s also often the case that an individual simply can’t see a way to be better. Think of how many times you’ve completed what you thought was a simple task, only for one day somebody to point out that there’s a much easier and quicker way? Sometimes you simply can’t see that you’re being inefficient, or that a better way exists.
Don’t criticize someone without showing examples of how they can improve.
3. Don’t Save Negative Feedback Up
If you give too much feedback in one go the individual that you’re dealing with might not be sure of which piece of advice to focus on first. Also, to be called out on a number of things can feel overwhelming and make the individual potentially feel like a failure. If, on the other hand, you’re only providing negative feedback on one task or action, it’s more likely to be viewed as smaller mistake that can be easily rectified. It also makes point number one (check, check, and recheck
) more difficult if you leave feedback to a later date because it makes it harder to pinpoint where and why an issue occurred, and what the associated facts were.
4. Know Your Audience
Different people take feedback and criticism in different ways. Some might get upset, some might get angry, some may choose not to listen, and others may be very welcoming to an opportunity to improve. Thinking in advance about who you’re talking to and how they might react can help you prepare how to best deliver your feedback. Do you need to highlight what they did well first (maybe, but be careful that that’s not the only bit they remember)? Do you need to speak softly in an understanding manner? Do you need to be very direct? Understand your audience and tailor your approach accordingly.
5. Provide Your Feedback Face to Face
Unless you don’t have this opportunity, always opt to provide your feedback in person. The absence of tone in an email can leave you open to the recipient inferring something that isn’t there, especially if they’re already feeling vulnerable or defensive. Telephone is better than email, but it still leaves you unable to display an open and friendly demeanour, make eye contact, or showcase positive body language. If face-to-face really isn’t an option, try a video call so that the person can at least see you when you speak to them.
6. Let Them Talk
Ask them to give their assessment on the situation that you’re referring to. Not only does this help with tip number one (check, check, and recheck
), but it helps you to understand their version of events. You may also find that they carry out tip number two (highlight how improvements can be made)
for you by offering up their own suggestions for improvements based on their own review of the situation. Most people will understand that there has been an issue, and will welcome the opportunity to discuss it with you.
You want to provide criticism in a way that adjusts the negative behaviour, but doesn’t create a problem between you and the individual. You want to ensure that they still feel comfortable with you, and still feel connected to you, their team, and the company. It’s therefore important when acting on tip number six (let them talk
) that you listen carefully to what they have to say. People are unlikely to want to spend the time and effort improving for someone who isn’t interested in their opinions and feelings.
8. Ascertain the Basis of the Problem
Why did the said individual perform the way that they did? What was the root cause of the issue? If you’ve carefully taken point seven (listen
) into consideration then you may have already established why the issue occurred, but if not be sure to discuss this. You can’t fix the issue without fully understanding the problem.
9. Agree on Next Actions
Agree on an action or improvement plan to be followed to ensure that the issue does not reoccur. You need to provide the individual with an opportunity to improve, and you can only do this by agreeing together on a course of action. Set dates for review and let the person know that you’re there to help them should they for any reason struggle to move forward with your feedback or change their behaviour. Don’t just criticize and then close the door.
You may also find it useful to set up a follow-up discussion, simply to allow the person time to digest the information you have given them, accept the criticism, and recover from any injured pride or anger they may have experienced.
10. Be Willing to Accept Criticism Yourself
Accept that you may have some responsibility to take in the issue at hand. Perhaps you didn’t communicate clearly enough to begin with? Perhaps the individual didn’t feel supported, or felt out of their depth and you didn’t realize? Understand that when you provide criticism and you set about with tip six (let them talk
) that you may find yourself to be part of the problem. If so, ensure that the changes you’re required to make are recorded as part of tip nine (agree on next actions
Focus on Improvement
Remember that the goal of feedback is to improve the behavior of the other person to help both them and your overall business. Negative feedback is an opportunity to make someone work better – do it right and you should notice significant improvements.
So, those are my top ten tips on how to deal with providing negative feedback. Is there anything else that you would add?
Posted by Dena Wieder-Freiden
on October 18, 2016 in Service Desk
It isn’t often I get to start an IT service management
(ITSM) blog with a William Shakespeare
quote, but he put it perfectly in Romeo and Juliet
: “What’s in a name? A rose by any other name would smell as sweet.” Sadly, as our Shakespearean heroes discover in their tragic demise, human society does indeed get hung up on the names, labels, and words we use. ITIL®
has been guilty of hijacking words from the English language and assigning them their own special ITIL meanings (you know like “incident” or “problem”), which has caused many people to get confused and miss the significance of the concept being described. Just like in Shakespeare’s play, all that baggage of the Montague and Capulet families damages the simple meaning of a boy and a girl in love.
So…ITSM Users and Customers
Let’s focus now on one important concept that I find gets very confusing because of the terminology. In ITIL, the terms customer
are given significant differences in meaning.
has financial involvement – they pay for the service. This could mean actually paying with real money, but not always. Sometimes it might be the budget holder who is charged, or it might just be signing off on a business case without tangible money being transferred. But in each case, the customer is in a position to see the bigger balance between the cost of the service and the benefits it gives.
is just that – someone using the service. They deal with inputs and outputs, not what it costs or on the value it offers for the money paid out. Users will have opinions based just on what the service does, nothing much beyond that.
The truth is we’re all already familiar with these concepts, as they are part of our everyday lives. Let me show you what I mean with a few examples.
Choosing a Car
So, imagine your car was stolen and the insurance company sends you a check in the sum of your compensation. Off you go to buy a replacement. You walk around the car dealer and a nice, shiny red car with a pretty prancing horse motif catches your eye. “Yes,” you think, “I’ll have that one.” Then they tell you what the Ferrari costs and you go home in a second-hand Ford still able to pay the mortgage and feed the children.
That’s you being a customer, able to balance the pleasures and benefits of having that car against the cost and what you can afford. Customers can make those compromises because they see both sides. The user (maybe your kid who also drives the car) will just be driving the car, and isn’t ever going to be satisfied with what they drive, always wanting more when it isn’t their money.
At the Toy Store
You’ve probably all seen both sides of this example, as an adult and as a child. Off you go to the toy store with your son, daughter, niece, nephew (you get the picture), and you let them look around at all the toys, intending to buy them one as a treat. The children will not be looking at the price tags, rather they’ll be totally focused on what the toy does and how much fun it is, or will be, if they can have it. The adults will have other considerations. First and foremost, they’ll care what each toy costs, both in terms of whether they can afford it and whether it seems to deliver value for the money. They might also have a broader view, by considering educational value as well as entertainment value.
Here the adult is obviously the customer, and the child is the user.
Different Roles, Not Just Different People
In the IT scenario, and our ordinary lives, it’s important to realize that a customer
and a user
are roles – not necessarily different people. You may choose the cheaper option when you’re acting as the customer, and still find yourself annoyed later at the lack of facilities, reliability, or support (or lack thereof) when you’re acting in your role as the user.
That comes out in an ITSM situation when the customer agrees, for example, to a service level agreement (SLA) with support from 8am-8pm on weekdays. Despite that making good economic sense during initial negotiations, the user in you will still feel aggrieved when the system goes down while you’re using it on a Saturday and nobody is available to help you until the next working day.
At home, you might be offered a deal by the power company – for an extra $400 a month they can guarantee stability and continuity of the electricity supply. That seems far too much to your customer view and so you turn it down. Still, six months later when the power fails, the user in you is upset – maybe with the power company, maybe with yourself?
Call Them What You Like, But See the Two Roles
Of course, just because ITIL uses those two words – customer and user – doesn’t mean you need to. But it does matter that you can see the two roles and address them. Customers, of course, must make the decisions about what can be afforded, but users need to be involved if services are to match their abilities, styles, preferences, and culture of work. If not, then the service will not be used to its potential and is unlikely to deliver value for money.
And this doesn’t end once a service goes live – ongoing maintenance and improvement depend on dialogue with both groups. ITIL gives us channels for discussions with both customers and users. Negotiating and reviewing SLAs, within service improvement programs
, change management
, and more is done with customers. And the service desk
is the major interaction with users – besides taking calls when things go wrong, the service desk can also gather users’ concerns and desires, and then feed them into improvement programs.
A good organization will take steps to set up and maintain communication with both types of stakeholders. Is that what you’re doing?
Posted by Sarah Lahav
on October 10, 2016 in Help Desk
The term “service desk” can give rise to a number of conversations, and sometimes arguments. For instance, should you call it a help desk, service desk, or something else
? And for companies with relatively small, and probably very busy, IT support teams, the idea of having someone sitting at a desk waiting to answer the phone
is a people overhead that they just can’t afford.
But don’t let the “desk” in service desk and help desk put you off formalizing and better enabling your IT support people – whether it’s through the adoption of industry best practice for IT service management (ITSM) or the investment in a fit-for-purpose help desk or ITSM tool. Maybe, just maybe, if this technology category was called “IT support tools” it might instantly seem more relevant to your company’s lean and mean IT support operations.
Looking at the Small IT Support Team Status Quo
All companies have some form of IT support but are they performing as well as they could be?
Of course the largest of companies need to have formalized and often highly-populated IT support teams – here there’s so much IT gluing business operations together, that things are bound to occasionally go wrong. So they’ll have a help desk (or service desk), plus other ITSM activities, enabled by fit-for-purpose ITSM technology.
At the other end of the company-size spectrum, IT support staff can’t always be justified. With the very smallest of companies using self-support and peer-support (most likely ably assisted by Google), or specialist third-parties to provide IT support as and when needed.
But what about those companies somewhere in the middle, which are of a size, and IT importance, needing one or more IT support personnel to help keep the IT, and thus the business, operational (and often also to drive it forward with new technology)? These IT support personnel rarely have the time to catch their breath, bouncing from one IT issue to another, and also fitting in non-business-critical IT support tasks as, and when, they can. They work hard, very hard, but could they work “smarter”?
Getting the Most Out of Limited IT Support Resource
Some might say that overworked IT support personnel in very small IT teams need more technical training, which they then might never have time to undertake. Others might say that they just need more IT support colleagues, which could of course be right, but budgetary restrictions prohibit it.
However, taking a step back out of IT support, what have companies traditionally done to improve the efficiency and effectiveness of staff since the late 1980s? The answer – provided staff with fit-for-purpose technology for both personal productivity enhancement (for instance email, laptops, and then smartphones) and business process enablement.
Stepping back in, IT support personnel in small IT teams might already have great personal productivity technology but what about technology for the enablement of their IT support processes? In fact, how many realize that they might have IT support processes? They just do what they think is best to “get the job done” day after day, week after week.
They will of course have access to some enabling technology – which might be for monitoring, network management, or remote support. They might even use their personal productivity technology – such as email and spreadsheets – to support their processes. They just don’t have access to what most larger IT support teams use – fit-for-purpose help desk
or ITSM technology.
How Help Desk and ITSM Technology Helps Smaller IT Support Teams
If you’re part of a small IT support team, there’s no desk involved, right? In fact, the only time you likely sit down for a prolonged period of time is while eating your lunch. But it’s probably not a lunch hour, as you just don’t have time for such an extravagance.
Have I hit a raw nerve yet? I don’t mean to but really, this is the crux of the matter – the introduction of IT support technology might offer capabilities to improve efficiency and effectiveness but the real win for small IT teams is to create more time to get things done! It’s the classic “doing more with less” (or “delivering more with less”) that has been echoing around ITSM conferences for the last decade.
So It’s About Time…
…And yes, you can read that two ways, both of which are appropriate here.
A fit-for-purpose IT support tool, call it whatever you like, will help small IT support teams to use their limited time better, even optimally. The generic, cross-process capabilities such as knowledge management
, workflow, automation, alerts, and even calendaring will help to stop them from “wasting” time on repetitive, often manual activities.
Plus certain tool capabilities will save IT support time directly. For instance, implementing an end-user self-service capability will use knowledge management to support end-user self-help. And self-service automation
, such as password reset, will further remove many of the common, yet simple, IT support tasks from the IT team’s daily to-do list. Mobile access to asset, ticket, or knowledge management information also saves time as IT support people dart from end-user issue to end-user issue.
Plus, there are many other benefits that are not so directly related to saving time. Such as using standard, best-practice processes and templates to optimize IT support activities. Or insight into operational performance and service delivery, with reporting used to demonstrate IT support’s worth, to identify improvement opportunities, or even to build a business case for increasing the size of the IT team.
Of course this final section only scratches the surface of how a help desk or ITSM tool can help smaller IT teams, but hopefully the blog has shown that a physical desk definitely isn’t necessary to benefit from them.