Posted by Sarah Lahav
on December 8, 2016 in Technologies
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.
Posted by Stuart Rance
on October 5, 2016 in Service Desk
IT organizations often spend huge amounts of time, money, and other resources on managing incidents, but they spend surprisingly little on problem management work that might reduce the number of incidents in the first place. This is often due to poor understanding of the difference between incidents and problems, and insufficient knowledge or understanding of how to manage problems.
Why Do We Distinguish Between Incidents and Problems?
Many people confuse incidents and problems, so let’s start by making the distinction clear
- An incident is an unplanned interruption to an IT service, or a reduction in quality of a service. Incidents have an impact on users, and on the business, and the purpose of incident management is to restore normal service.
- A problem is the cause of one or more incidents. The purpose of problem management is to manage the problem, eliminating future incidents where possible, and reducing the impact of incidents that can’t be prevented.
So, incident management
helps you get the business working again, problem management helps you prevent future incidents, or at least make them less painful when they do happen.
In the bad old days, when IT was a very technically-focused function, most IT teams didn’t distinguish incidents from problems. If something broke, then somebody would work on it until it was mended. IT technicians paid little attention to the business impact of whatever it was they were working on, and the customer just had to wait until it was fixed. But when we learned to distinguish between incidents and problems, this changed. Organizations could set up incident management to focus on doing whatever is needed to get the business working again, leaving problem management to deal with any underlying technical issues. Take, for example, a printer that isn’t working. There is no need for the customer to wait till the printer is mended. When we practice incident management we can simply help the customer route their printout to a different printer. Obviously, this doesn’t get the printer fixed, but that is probably something that doesn’t really concern the customer. We can of course go on to repair the faulty printer. But this is now a problem management activity, with lower priority as the outcome has very little direct impact on the customer.
How Do You Identify Problems?
Before you can start managing your problems, you need to identify them. Here are some common ways that organizations identify problems:
- Trend analysis of incident records. This activity is sometimes known as “proactive problem management” because its purpose is to help you identify problems that you don’t already know about.
- Major incidents. Every major incident should result in a problem being logged, to ensure you take steps to prevent the same thing from happening again.
- Multiple incidents at the service desk. Service desk agents should notice if there are multiple similar incidents being logged and log a single problem to ensure that these are investigated and the cause addressed.
These are some of the ways that problems can be identified, and you should make sure that you take full advantage of these, but also think about all the different ways that a problem could be identified in your organization. For example, think about your suppliers, software developers, or infrastructure teams, and make sure that you actively capture all of their input and use it to log problems.
How Should You Manage Problems?
Problem management has two objectives:
- To prevent incidents from happening
- To reduce the impact of incidents that cannot be prevented
Many organizations only think about the first of these objectives. They do root cause analysis to understand the problem, and then take steps to rectify whatever was causing it. This may take some time, and while a complete technical solution may prove very effective once it is in place, the business is likely to continue suffering in the meantime.
The best organizations that I work withstart
by thinking about how to reduce the impact of incidents – the second of our two objectives. They ask themselves, “What should we do if this happens again right now?” This might be a difficult question for technical support staff to answer if they don’t fully understand the problem, but it’s much better than just leaving service desk agents to flounder when the same thing does happen again. Organizations with really effective problem management create workarounds for problems as quickly as they can. They make sure there is a well-documented workaround in place as quickly as can be managed, and they also review the workaround every time it’s used to identify possible improvements. And with the latter, they will also go on to improve the workaround as they learn more about the cause.
So one benefit of thinking about reducing the impact of incidents, before you start analyzing their root causes, is that you reduce any business impact much faster.
But there’s a second benefit – sometimes it turns out that a workaround is so effective that there is actually no need to understand the root cause or fix it. Here’s a perfect example:
One of my friends had a gas leak under the concrete floor in his kitchen. He turned off the gas and called out the emergency gas fitter. This gas fitter ran a pipe around the outside of the kitchen so that the gas cooker could be reconnected and arranged for a structural engineer to diagnose the leak properly, so they would know where to dig up the kitchen floor. The structural engineer called a week later and said it would cost a huge amount of money to dig up the concrete and fix the pipe, but fortunately this was unnecessary because the new gas pipe was perfectly safe and did the job.
This example doesn’t involve IT, but I’ve used it anyway because it is a particularly good illustration of the fact that a safe and effective workaround is often enough. Why waste good money fixing an application when you have a workaround to the problem and it no longer has an impact on the business?
Of course, if your workaround is not sufficient then you do need to investigate the root cause of the problem. There are many different techniques you can use for this. My favourite approaches are timeline analysis and Kepner-Tregoe problem solving.
This is such an easy way to investigate a problem that it barely deserves a name. You simply list everything that happened in time order and then look for patterns. What is important is that you get all the data from multiple sources and then sort it by date and time, regardless of where it came from. So your timeline may have entries from system logs, emails, service desk records, and many other sources. This simple approach is surprisingly effective at building a complete picture of what’s been going on.
Kepner-Tregoe Problem Solving
I have to declare an interest here, I used to teach this proprietary approach to problem solving
, but I do think that it is incredibly effective. This is a very structured approach to problem solving, where you define the problem across a number of different dimensions (what, where, when, extent) and you also bound the problem by identifying what is NOT failing. You can then review the distinctions between these to identify possible causes.
Problem management presents a great opportunity to reduce both the number and the impact of IT incidents on your customers. If you are not already doing problem management you should certainly be thinking about introducing it
. And once you do, I think you may find my guide to problem management metrics
worth a read.
If you are already doing problem management, then make sure that you have the balance between devising workarounds and investigating root causes right. You don’t always have to understand the cause to resolve the problem, but you do always need to put a workaround in place as quickly as you can. You may even want to think about how to integrate incident and problem management
, but whatever approach you take you should make sure that you focus on value. Think first and last about what will be best for your customers and users.
Posted by Roy Eldar
on September 27, 2016 in Service Desk
Come the end of a busy week, does your IT service desk ever look a little bit like the set of a western movie
The atmosphere is dry and barren. Random objects are strewn across the office like 21st
-century tumbleweed. With your team members staring blankly into the distance, eyes burned by the constant glare of their monitors, tired and reeking of apathy. It’s been a heavy week, and you’ve been consistently ambushed with incidents. The service desk has spent day after day in the firing line of end users, having to repeatedly circle the wagons under the glare of SLAs and stretching performance targets. And now your team is tired.
Pinned to the notice board is a sign, “Wanted: Motivation.” Best not to mention the wild west reference to dead or alive.
The Good, the Bad, and the…Unmotivated
Looking around at your team you start to wonder when the motivation disappeared and how long it’s been gone, but it’s no good following the hoof prints back down the already well-trodden trodden path. Instead you need to get back on your horse, perhaps after drinking your milk, and rally your riders. And here’s a few suggestions on how to re-motivate your team to face another week, month, or even year of the IT support wild west:
1. Listen up, partner!
Communication is crucial – listen to your team and instigate a collaborative feedback cycle. According to research by weekdone.com
, 39% of workers don’t feel that their input is appreciated.
By asking your team members for their input and involving them in the decision-making process, it will make them much more likely to support day-to-day activities, improvement projects, or your decisions. And remember, once you have gained their feedback, visibly follow up to show them that you’re actively taking their opinion onboard.
2. Have one-on-ones, but hopefully not standoffs
Recognize each member of your team as an individual.
And that your team’s motivation level is directly correlated to your management style. Did you know that 75% of people voluntarily leaving jobs don’t quit their jobs; they quit their bosses
In addition to more one-on-one time, you could also learn what motivates individual staff members through psychometric tests. Try to understand how they like to be managed to optimize their productivity. Then as their manager, create attainable goals and clearly communicate plans to keep staff engaged and in the loop.
In the Workforce Mood Tracker™ Spring 2014 survey
, 73% of respondents credited “recognition” for having a positive impact on their happiness at work. So wherever possible recognize work, and even personal, achievements to make your team feel valued.
3. Shoot ‘em up!
Gamify your service desk metrics to help motivate your team to hit their KPIs. Reporting on IT service desk performance can quickly take the motivation out of your team, especially if they fall below their agreed SLA threshold. Make reporting less daunting and more fun by fostering a little healthy competition and regularly recognizing excellence versus key KPIs. You could choose the quickest resolution time, the highest rating on a feedback form, or the number of tickets closed within a day; and offer up an incentive for the winner such as leaving early, a chocolate bar, or even just their name at the top of a leaderboard. The reward part of “reward and recognition” doesn’t need to be costly.
Hitting targets should be fun. Yes, recognize underperformance, but don’t let it override the great job your team does on a daily basis.
4. Did someone say rodeo?
Inject friendship and fun into your working environment by organizing regular socials.
Gallup research has shown that close friendships at work produce a 50% increase in employee satisfaction
, and having a close friend at work increased the likelihood of engagement by seven times.
So try to support the cultivation of friendships within your team, through social events such as team building excursions, casual team lunches, or networking events. And remember that happy employees are more productive employees! Research from the University of Warwick has confirmed that being happy made employees about 12% more productive
and, you guessed it, more motivated.
5. Banish the barren work-land
Ensure that the work environment is pleasant and inviting. Research
by the International Journal of Science and Research has shown that:
“The quality and quantity of work generated by employees are influenced by the work environment while poor environmental conditions can cause inefficient worker productivity as well as reduce their job satisfaction.”
So assess the environment your service desk agents work in. Hopefully your team isn’t packed into a dingy office, filled with old IT equipment, like in the IT Crowd
. Consider the lighting, temperature, noise, layout, decoration, cleanliness, equipment, furniture, and air quality. Let team members give you input to sensible environmental and ergonomic improvements. Help to create a sense of pride in the work area by allowing your team to embrace their individuality and feel ownership over their personal workspaces. Invite them to make the workplace their own, and if you can find the budget, spend some company money on making it a better workplace.
Time to Round It Up, Cowboy…
Happiness and job satisfaction have been scientifically shown to increase productivity and motivation in the workplace. So try to create the kind of atmosphere that makes your staff come to work every day, not because they HAVE to, but because they WANT to.
- Listen to your staff and instigate a collaborative feedback cycle. Communication is crucial.
- Recognize each member of your team as an individual.
- Gamify your metrics to motivate your team to hit their KPIs.
- Inject friendship and fun into your working environment by organizing regular social events.
- Ensure that the work environment is pleasant and inviting.
Posted by Dena Wieder-Freiden
on September 20, 2016 in Service Desk
tells us that there are three components to business value:
- Business outcomes
- Customer perception
- Customer preferences
Once this has been successfully memorized for the ITIL Foundation Certification
exam, most people then forget it. That’s a shame because it gives an insight into why customers might be less impressed with the services they’re getting than expected. In this blog, I’d like to take a look at how each of these concepts can help us get things right.
IT service providers generally focus on what IT applications and IT infrastructure actually do – their outputs. But to deliver genuine value, we need to think in terms of outcomes – the end result for the customer and the organization as a whole. So, a service provider’s first challenge is to see beyond initial outputs from their IT services and understand the outcomes: how they influence the customer environment. That requires learning about the service in the customer environment, things like:
- What business services does your IT service support?
- Never mind what you meant, how is it actually used? (In fact, is it actually used at all?)
- How many of the features, which you got excited about building, are exciting to the business as well?
We can illustrate this by analogizing it to the difference between using a car and a requirement to travel. The outputs of owning a car are about driving; the outcomes might be the ability to get to work or the shops, or impressing the neighbors with what you can afford. Seeing the difference would help you choose the right car – or perhaps even suggest alternatives like traveling by bus or train.
Think about it. This is a serious and important jump for many in IT. It’s about seeing beyond the initial functionality, but it’s only a part of the challenge to real business-IT integration and customer satisfaction.
Perception and Preference
In order for a service (or that car) to deliver any value, the customer has to be in a position and a mindset to receive it. If not, then the best of all services will not be of any actual use.
Let’s stay with cars a moment. I lent my car to a friend, who returned it remarking on how easy it was to drive. I agreed, commenting specifically on how useful the cruise control is. My friend reacted with: “Cruise Control? Where is that?” This proves my point – if you aren’t aware of something, then it’s impossible to get value from it.
That kind of scenario is repeated in an IT context every day around the world: “Wow, I didn’t know it could do that”, or “where did you learn that?” At home, a few of us know all the features of our TV, DVD player, or cable TV. We have reached a stage in the evolution of technology where the users of that technology rely on intuition rather than training, and so services must work in a way that is obvious without words
. Unless it’s clear what a service can do, it will not get used, and the service provider’s efforts will not be appreciated – nor willingly rewarded.
And even knowing that the service is there at all can be a challenge without an easy-to-use and comprehensive service catalogue that the customers can reach – and feel is worth reaching and exploring.
This is an area that can really undermine the hard work put in by a service provider. Appreciation of value rests on the attitudes of the people you are supplying. And, just about always, people are the least predictable element of any organization or situation. No matter how well you think you know them, they can surprise you. Add to that the fact that IT services are typically supplied by
IT folks to
business folks, and you have a “disconnect” of preferences just waiting to cause troubles.
Once more, let’s use a car analogy: many years back, our family was searching for a new car, so my husband took me to see what he had found at a car dealer, confident he had found us the perfect solution. The car was strong and fast (as we specifically wished it would be), a model we knew, was in good condition and at a good price. So…no question for him, we should buy it. But I had to reject it…because it was white! Of course I didn’t want a white car, no matter how well-matched to our other needs it might be. How could he have not known that when it was already so clear and obvious to me ;)?
That kind of preference can look like bias, unreasonableness, or even bigotry. But even if it is, it is real, and a supplier must cope with it and deliver something that is acceptable.
For an IT service, the customers may have strong feelings about how the interface works, and reject one that doesn’t work “their way”. Or it may come from a source they disapprove of. Without establishing those preferences beforehand, once again IT service providers will be working hard to deliver something that will not be appreciated.
Knowing, Learning, and Matching
So, what I’m trying to say is – to be a successful service provider, it means getting out there and understanding not just what your customers need, but their attitudes, likes, and dislikes. In a large organization maybe you work with your business relationship team, or account managers, to help bridge the perception and preferences gap. Then again, there is no real substitute for getting out, talking, and listening to your customers yourself.
For more on this topic, I highly recommend you read Stuart Rance’s blog “What Value Are You Creating from Your IT Job?”