Posted by Stuart Rance
on January 17, 2017 in ITSM
I visited two very different customers recently. They had very different problems and the solutions I suggested for them were also very different. But there was one thing that they had in common — they had both delayed starting the improvements they knew were needed because the costs and risks were too high. Instead, they had done nothing and so allowed their problems to continue completely unchecked.
For both these customers, the solution was very similar. Both needed to “Start where you are”, “Keep it simple” and “Progress iteratively”. These are three of the guiding principles from ITIL Practitioner, and between them they encourage IT service managers to adopt an agile approach to resolving issues, rather than taking on big, risky, expensive IT service management (ITSM) projects. I created a few podcasts on these topics for SysAid’s Back to ITSM Basics
project, so please do listen to those if you are interested.
If you also need improvements that seem too expensive, or too risky, then read on to learn how you can get started.
A Big Organization with a Big Problem
One of the organizations that I visited is very large. It provides support services to many external customers all over the world, and has lots of service desks. Some of these service desks are dedicated to a single customer, others support multiple customers, and some are for internal users. Some of them provide logging and dispatch only, others provide level 1 support as well. While many of the service desks use the same ITSM tool for logging and managing incidents, there are quite a few other tools in place as well.
Almost all of the customer communication, for all the different service desks, takes place by phone. The organization would like to shift to more efficient channels, e.g. text-based chat and a self-service
web portal, but because the company is so big, the implementation costs would be enormous. IT has, in fact, identified a tool that could provide chat for all of their complex environment, but since they can’t be confident that an implementation project would run smoothly or that the returns would justify such a big investment, they can’t get the funding for this.
As I talked to the IT department, the solution to their problem became obvious. Instead of trying to implement chat for all of their users, which would be a very big and expensive project, they could start where they are, start small, and grow in small steps.
The organization’s users already have a tool that supports chat, although it is not currently used for IT support. So it would be quite easy for IT to start there.
Here’s what they can do:
Find a small group of users and offer to use this existing tool to provide them with IT support. Monitor carefully to reveal any issues for the service desk or the users, and resolve them before scaling up to support more internal users. Eventually the IT department will reach the limits of how well this tool can scale in their environment, but by then they will have:
- Identified and resolved many issues relating to how the service desk works when handling chat-based interactions
- Understood which types of incident are best handled by chat, and which are better managed using phone or other channels
- Discovered what communication and support works best to encourage users to migrate from phone to chat
- Collected data about how many calls each service desk agent can manage using chat, and how much this could save if scaled up to the whole organization
This gradual implementation of chat would be very low risk, and, by starting with a tool that is already in use and familiar, would not involve much cost. By the time the IT department has scaled up to supporting a large number of internal users they will know whether a full implementation using an expensive tool will be a cost-effective investment, and they will also have learned what needs to be done to ensure success. If they wish to go ahead with an expensive new tool, this will give them everything they need to create a business case for the next stage.
A Small Organization with a Security Problem
The other organization that I visited is MUCH smaller. They have just two staff working on their in-house service desk, supported by a manager who carries out other roles as well. They have a few thousand users in a small number of offices, all in a small part of one country. They are finding it difficult to manage user access controls.
When a new user joins the organization, they ask about what access this user needs, and then grant individual rights to the specific applications and data. When people change jobs or leave the organization, it’s difficult to find all the access rights that have been granted, so these are often left in place – and this creates a significant security risk.
The support manager knew that the solution to their issue was to move to role-based access controls (RBAC), where all access rights are granted to roles, and then those roles are assigned to users. But there had been no attempt to migrate to RBAC because of the risks involved. Sometimes things go wrong during even the best planned migrations, and this could cause significant cost and risk to the business.
The solution for this customer was also to take an agile approach. Instead of attempting to change everything at the same time, the organization could start where it is, keep it simple, and do it a bit at a time.
Here’s what they can do:
Next time a new employee joins the company, grant all the rights that user needs to a newly created role, and then assign this role to the new user. This should be no more work and no more risk than would normally be involved in providing appropriate access to a new user. Once confident that the role works well, and that no changes are needed, go on to migrate one existing user to the role, removing the current rights that user has. Again, this would carry only a small amount of risk, and the change could be undone quickly and easily. Next, continue adding users a few at a time. Once confident that there are unlikely to be any issues, move over everyone else who should be assigned to that role. When the opportunity arises, create a second role, and migrate users in the same incremental, low-risk, way.
This approach means it will take quite a long time to completely move from the current situation to a well-managed RBAC implementation. But the one improvement that you can guarantee will never be finished is the one you think it’s too risky to start in the first place. By starting where you are, keeping it simple, and progressing incrementally, the improvement this company wants will eventually be achieved, with little risk, and without a big project that keeps its two support staff tied up and unavailable for long stretches of time.
Many organizations use agile software development to reduce risk and speed up time to market. The same ideas apply equally well to ITSM
. Almost every ITSM improvement can be carried out in an agile way, and there really is no need for huge, expensive ITSM improvement projects.
If you’ve been putting of improvements that you KNOW you need, because of the cost and risk, then why not think about how you can “Start where you are”, “Keep it simple” and “Progress iteratively”?
Posted by Sarah Lahav
on January 10, 2017 in Help Desk
In my previous blog, What’s Essential for an IT Help Desk?,
I discussed the things that every help desk should do. These were:
- Log and manage calls from IT users
- Resolve incidents
- Generate useful reports
- Continually improve
If you’re not already doing all four of these, then please go and read that blog to help you initiate some of the changes you need to make.
If you’re already doing all the essentials, then you might want to think about ways of using your help desk
to create more
value for you, and for your customers. A great help desk can do a lot more than just the essentials. Here are some things to think about if you’re ready to take the next step.
Identify and Manage Problems
The trouble with excellent incident management
is that incidents keep happening. No matter how good you are at managing incidents, and how grateful users are for the service, they still suffer from the disruption to their work and wish they had not needed to call you in the first place; you are using up valuable resources managing something nobody actually wanted to happen.
This is where problem management
comes in. Problem management can help you to:
- Stop incidents from happening, or at least make them less frequent.
- Reduce the impact of any incidents that you can’t prevent.
This means that your users get a better service, and your help desk has less work to do. That’s a win-win for you and your customers.
A small help desk could easily be put off by the idea of doing problem management because they may fear it’s too time-consuming or too difficult, but in fact it’s straightforward. If you don’t already do problem management and want to start, just follow these simple steps:
- Identify some problems. You can do this by looking at your incident records to look for incidents that keep happening, or asking anyone who works on the help desk to log a problem whenever they notice repeat incidents.
- Pick one or two problems to investigate. You don’t have to investigate every problem that you identify. Start with the ones that happen the most often and the ones that have the biggest impact on the business, because these are the ones that cause the most pain.
- Fix the problem if you can. The best response to a problem is to identify why it happens and remove the causes.
- Document a workaround for problems you can’t fix. If you can’t remove the cause of a problem, then think about how you can reduce the impact when it happens again and document this. Put your plan into action next time the problem occurs, and review what happens, so you can document anything that you need to change, to improve the outcome.
- Pick some more problems to investigate. You will find that you free up resources each time you fix a problem, and this means that you can start working on some more problems. If you do this consistently, you can create a cycle of continual improvement that is of enormous benefit to you and your customers.
When you provide your users with the information they need to help themselves you can get much faster incident resolution, with less effort and reduced costs. At a minimum you can simply allow users to log their own incidents via a web interface, and then provide them with status updates via the same channel so they don’t need to keep phoning you. Ideally you should do a lot more than this, by using the same web interface as a channel for providing accurate and accessible information about common issues and how to resolve them.
and problem management can work well together. You use problem management to identify the common types of incidents and document how to resolve them. Then you provide this information directly to the users, rather than making them phone you to ask for help each time a common incident occurs.
Proactively Communicate with Users
One of the help-desk essentials I described in my previous blog
was managing incidents, and this includes providing users with status updates. Users value regular and timely status updates on their incidents, but a proactive help desk can provide much more user communication than this. Examples of good proactive communication that the help desk can provide include:
- Telling users about new and changed services, to ensure they are properly prepared for them
- Making sure people know when the service is going to be unavailable for scheduled maintenance or other activities
- Letting users know that you are aware of and working to resolve any incident that impacts many users before they all phone to tell you that something’s wrong
- Encouraging users to adopt practices that help protect your valuable information; you can do this by sending routine security reminders
There are lots of different ways that the help desk can communicate with users. For example:
- Messages displayed on screens when people log on
- Messages displayed on a self-service portal or service status page that users can review when they need to know what’s happening
- Announcements over office loudspeaker systems
- Posters on walls and office doors
I’m sure you can think of many more ways to communicate with your users, but the important thing is to get the balance right. Too much communication can be as bad as too little, as people will eventually stop paying attention. So, make sure you get feedback from your users on how well your communication is working.
This blog has described some of the ways your help desk can help to create value. You do need to ensure that you start with the essentials first, but if you want a great help desk, you should not you limit yourself to that.
A great help desk will use problem management to help reduce the number and impact of incidents, it will provide self-help so users can resolve their own incidents, and it will proactively communicate with the users to help keep them informed. How many of these things does your help desk do?
I do hope these blogs have given you some ideas of things you could do to provide a better help desk for your customers. Please let me know which things you try, and how well they work out for you.
Posted by Stuart Rance
on January 3, 2017 in ITSM
If you’re involved in ITSM improvements
, and especially if you’re fairly new to the field, it’s easy to feel overwhelmed. One thing that can really help you to focus is to follow the principle “Start Where You Are”.
It sounds obvious, doesn’t it? Of course you should start where you are. After all, where else could you possibly start? But this principle captures some very important ideas in a really simple phrase, and by following it, you can avoid many of the mistakes that can cause IT service management projects to fail.
What “Start Where You Are” really means is don’t throw away everything you already do and start again from zero. If you try to impose a completely new way of working, without building on what’s already in place, you will inevitably waste time, money, and effort. AND you will alienate the very people you need to have on your side. When you tear up everything that people are doing and tell them to start working differently, you’re bound to stir up opposition – and sometimes outright resistance. If you do this, then it can become really difficult to integrate the changes you need into your organization and culture.
It’s much better to start by looking at how people currently work and talking to them about it. If you can engage them, then you can actively involve them in thinking about how to build on what they do now so they can deliver better outcomes in the future. And this means you can focus all your efforts on putting the changes you need into effect, rather than into managing reluctant, resistant, or even hostile staff.
How to Carry Out an ITSM Assessment
I’ve carried out IT service management assessments for many different organizations over the years. These ITSM assessments have usually been a first step in a program to improve how the organization delivers value to its customers. As you can probably guess, I’ve rarely been welcomed with open arms. After all, nobody likes an outside consultant to come in and tell them all the things they’re doing wrong. And yet, this is what people (and organizations) expect consultants to do. My clients expected me to come in and look for the things they were doing wrong, and to write a report listing these things and saying what needs to be changed. But if I did that, I knew that my assessments would be of limited value. They would probably be resisted and might even be ignored, no matter how much the organization had paid for them.
Fortunately, I discovered that there was a much better way to approach assessments. I could begin by identifying the things that were being done WELL. Things that are being done well in one part of an organization are great opportunities for improvement across the organization – they can usually be replicated without meeting much resistance. After all, people are copying best practice from their peers, rather than listening to some external consultant. What’s more, when people know that their strengths have been recognized and validated, they are more likely to accept suggestions for improvements in areas where there are weaknesses.
Ask People What Needs Improving
The other thing I discovered was this. If you want to know what isn’t working properly and how to fix it, ask the people doing the job. It’s amazing how many people in an organization know exactly what needs fixing, if only someone would listen to them.
I learned that if I took all the ideas from staff working in an organization and combined them with my independent assessment, I could come up with a plan to help deliver better outcomes for customers. AND it was a plan that started where my customer was.
So if you’re planning an IT service management improvement project, please don’t throw away all the good things you’re doing. Look to see what you do well and think about how you can start where you are.
Best of luck to anyone who’s listening, and if you are planning improvements, drop me a line to let me know how it goes! You can find me on Twitter as @StuartRance
(This blog was originally published as a podcast by Stuart Rance, as part of SysAid’s "Back to ITSM Basics" program.)
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.