Posted by Stuart Rance
on August 4, 2015 in Service Desk
It’s summer time in the Northern hemisphere, and many of us are getting ready for our annual holidays. It’s really great to get away from work for a while, but some people don’t get much relaxation because they are constantly interrupted by emergency calls from work. There are things you can do to make these calls less likely, and that’s just as important a part of holiday planning as booking the flights and the hotel. If you’re going away tomorrow then it’s probably too late to do these things now, but you could get started as soon as you get back, so that next year’s holiday will be more restful.
Share Some Knowledge
Think about the things that only you can do. What would be needed so that someone else can do them? Could you provide written instructions, or teach somebody else how to do it? If so, then share that knowledge. It will have benefits for you and your organization all year round, not just when you’re on holiday.
Automate Routine Tasks
One great way to reduce the impact of being away for a while is to automate some of the tasks you usually carry out. You should only automate things that are well understood, reasonably frequent, and fairly simple. If you don’t understand the task thoroughly then automation will go horribly wrong. If the task isn’t reasonably frequent, then the effort needed to automate it will be too high compared to the effort it saves. If the task isn’t simple, then it will be really hard to automate, and the automation is likely to miss out on some complex cases. Even if the task is fairly simple you should always see if you can simplify it even more, before you automate it. Many routine tasks have built up complexity over the years, but could be much simpler if we started the design again.
Like sharing knowledge, automation is something that can really pay off in terms of benefits every day of the year, not just during holiday season.
Pay Off Some Technical Debt
Technical debt is the effect of compromises that you made in the past. Like financial debt, it is not always a bad thing, but you should never have too much, or let it be outstanding for too long. Here are some examples of technical debt that need to be managed:
- A new service was put into production even though it failed some operational tests, and backups don’t quite work properly. This is a perfectly reasonable thing to do, but you shouldn’t just forget about the issues afterwards. Investigate why the tests failed and fix the problem. That way you will avoid a disaster when you need the backups.
- You upgraded the firmware on all your servers to fix a security vulnerability, but one server couldn’t be shut down that day because it was running a critical task. Don’t just leave that server indefinitely, plan the upgrade for a time when the server is available.
- A disk failed in a RAID set. The data is all still available because the RAID set can operate with one disk missing. However, if you don’t get that disk repaired then eventually another disk might fail and then you will lose your data.
Every IT organization has some technical debt, but if you don’t actively manage it then it can get out of control and result in lots of incidents, problems, and urgent phone calls, probably just when you want to lie on the beach soaking up the sunshine.
Adopt Continual Service Improvement
If you have a culture of continual service improvement, then you’re probably already sharing knowledge, automating tasks, and paying off technical debt. If you don’t, then why not think about how you can start?
Continual service improvement
doesn’t need to be a big, complex process with lots of documents and activities. It’s mainly about attitudes, culture, and behavior. You can start by simply noting down things that ought to be done, prioritizing them, and picking one or two off the list whenever you can. Over time you will find that things are looking much better, and next time you go on holiday you’ll really be able to relax.
Posted by Danny Tashiev
on July 28, 2015 in Service Desk
TV programs such as The IT Crowd
and the Dilbert
comic strips convey IT teams and service desks in a comical yet often negative manner. They are very funny, I know I laugh at them, but they are funny mainly because they are based on truths – truths that have been with IT and the service desk for far too long. Sadly, I’m sure that many people resist calling service desks based on the assumption that what they've seen and read is correct.
However, the humor is often based on generalizations or snapshots from a previous time in the history of the corporate IT organization. Many IT organizations have moved on from the 1990s and I’d like to think that most service desks definitely have. So in this blog, I’d like to challenge some of these IT assumptions and help you to bust some typical service desk
1. IT folk work in the basement and hate interacting with people.
We may work in secure rooms sometimes
because of sensitive data and systems yes, but basements...rarely. In fact, in the future we are likely to see more and more service desk staff placed out amongst the other business employees, or in walk-in clinics and Genius Bars
. Global analyst firm Gartner have been pushing this greater visibility and interaction for a few years, as employees start to expect what they get with their consumer technology from the corporate IT department. As for hating to interact, that just doesn’t add up, as a large number of support staff have chosen to work on a service desk because they love to help people, and providing great customer service is their passion. In my opinion, you don’t have to create a Genius Bar but please take a long look at how your service desk agents appear to end users, after all they are the business’ window into IT and a big influencer on employee perceptions as to how the IT organization-as-a-whole is fairing.
2. They know about every piece of software ever written.
Just as any IT pro will not be completely conversant in all the systems and applications your organization runs, neither is the typical service desk agent. Most agents will have a good knowledge of common issues encountered on your organization’s most popular systems and software, but only some will have the necessary specialism in the more complex or obscure applications. And this is as it should be – just because a business team uses a piece of software all day every day, doesn't mean that the rest of the organization does. Service desk agents thus need to selectively build up their IT system (and business) knowledge using the Pareto principle – 80% of the benefit will come from just 20% of the possible knowledge. Ultimately, your service desk team should work like this to create the most value for the business, based on the difficulty of recruiting knowledgeable service desk staff (on the available wage) and to cope with staff churn levels. Service desk agents can function very effectively with just enough knowledge and, where possible, superior problem solving skills.
3. They know how to fix everything that has batteries or a power source.
Service desk teams really are amazing sometimes (in terms of what they know and can do) but like all of us they have their limitations. They're not electricians, they can't help you if your microwave doesn't work and they can’t install an alarm system – but they should be able to handle requests that relate to these types of requests, routing them through to the appropriate team rather than just saying we can’t help. There is also often an overlap between the IT service desk and the facilities help desk, in particular, with the installation of network points a great example – facilities might install them whereas IT would maintain them. So make sure that the dividing line for responsibilities is clear, as end users don’t want to be ping-ponged between IT and other corporate service desks – they just want or need a quick solution.
4. Fibs such as "I didn't touch anything!" or "No, I didn't touch that setting!" don’t really matter.
In order to troubleshoot efficiently and effectively, a service desk needs the end user to be totally honest about their issue and how it came about. However, people being people, might just try to avoid saying what they did to cause the issue in an attempt to avoid blame and any punitive recourse. So try to create a blame-free approach at the service desk. There are caveats to this – such as an end user who loses three mobile phones in a year is negligent and it’s an HR, not an IT, issue – but make it easier for end users to honestly share what they have done even if they're not 100% sure what they've done. It'll make everyone's life easier and save everyone a lot of time.
5. They don't know what they're talking about; they're just following a script.
Scripts benefit both end users and service desk agents. They should quickly get service desk agents to the core of the issue and to a swift resolution, even where the agent has a limited knowledge of the technology in question. Plus, if an issue has to be escalated to a more technical team then they need to know that all the basics have been covered. Most service desk agents will thankfully know more than just how to follow a script but they need to prove it. If they are blindly following scripts when they are inappropriate to the issue in hand, then this myth will never be busted. So set your service desk people free to use what they know, including their inherent problem solving skills. Empower your service desk agents to go off-script
when needed – it will most likely lead to a swifter solution, and most definitely result in a better service experience for the end user.
6. They just tell you to restart your machine because they're lazy/don't really know what they're doing.
It’s amazing how often restarting a phone, PC, or application will resolve an issue. It’s often a great first step, especially when devices and programs have issues that the service desk has not experienced before, and therefore don't know how to cope with. So a good old-fashioned reboot might be the best solution – there’s nothing wrong with that, but be wary of how it‘s offered. Don’t just say “please reboot your PC.” Better to explain that a reboot helps with a number of issues, and you never know – they might even try to reboot themselves next time before contacting you, thereby preventing an unnecessary service desk call (when the reboot works).
7. There's no point contacting the service desk, you can find the answer on Google.
There is what seems like an infinite amount of IT support information on Google and, yes, some of it will help end users but a lot of it won't. Not only is Google an information firehose
, but who knows how much of the information is inaccurate or dated? Plus how much of the advice is malicious rather than helpful – “install this questionable executable to cure all your woes”? Also how quickly can end users help themselves via Google? If it takes longer than via the service desk, especially with the involved people more senior, the cost to the business is easily going to be greater through this self-help route. In addition to this, if all end users went to Google instead of using your IT self-service system or logging a ticket directly, then a genuine problem could be missed. Thus any service desk that wishes to stay relevant needs to make IT support as easy to access and consume as Google; to do otherwise will always be a suboptimal solution from a business point of view.
So there you have it, a number of service desk myths that need to be busted. What do your end users think of you and what are you doing to change their opinions of your service desk where needed?
Posted by Gil Blinov
on July 23, 2015 in ITIL
The corporate IT service desk gets a lot of criticism. More specifically, service desk agents get a lot of criticism. They often get accused of using their service desk role as a stepping stone to "a better IT job." They are commonly chastised for following scripts, even when the scripts are completely inappropriate (but are the best they have under the circumstances).
On a more personal level, they are often treated as a herd rather than individuals; tar brushed with generalizations such as having poor interpersonal and customer service skills. On the upside though, they are assumed to know more about IT than most.
I'm getting to a point (of sorts), but first I wanted to throw out a few of the mean, but not unnecessarily untrue, things that are commonly said about IT help desk or service desk agents. I've been there and bought the t-shirt.
So how well do IT service desk agents do? Individually and collectively? They often hit the SLA/operational targets that their IT paymasters have forced upon them - such as first contact resolution levels, speed of response, and correct incident classification percentages - but they still fail to have a glowing reputation with end users (their business peers). This includes even those that are touted as IT superheroes within IT.
Is the Issue Simply that Service Desk Agent Performance Is Poorly Targeted?
There's no denying that some IT organizations have way too many service desk metrics, often metrics that conflict and/or drive the wrong service desk agent behaviors. However this is just part of the issue. While IT service desks and the agents that work within them would benefit from a better basket of metrics, there's much more to be done to get the service desk's corporate reputation to where I'd like to think it should be.
But what needs to change? Is there a need for tighter service desk processes? Probably not. Should they replace their ill-fitting and complicated help desk tool? Not necessarily. Should they recruit more staff, with better technology skills? Nope. I could continue but we’d probably end up with Is it Henry, the mild mannered janitor?
Staff Need to Rise Above Process to Think Differently
I'll repeat this as it's important - staff need to rise above process to think differently; and it's not just service desk agents, it needs to start with service desk and IT management. It could be the fault of legacy IT help desks that were designed to fix IT issues. It could be the fault of ITIL, the IT service management (ITSM) best practice framework formerly known as the IT Infrastructure Library. That's an odd thing to say isn't it? After all ITIL introduced the service desk to all of us still running an IT help desk.
Think about it. Many will quote the three or four Ps of ITIL - People, Process, Product (tools), and sometime Partners. There is, however, another P that's overlooked - Purpose
. How often do you hear of IT organizations investing in, reinvesting in, or changing people, processes, and ITSM tools? Especially the latter. How often do you hear of IT service desks (and perhaps IT organizations as a whole) reconsidering their purpose? Or even questioning the purpose they probably gave themselves in the late 1980s at the dawn of help desks?
The Service Desk Is All About Service
Sounds obvious doesn't it; but what's the purpose of your IT help desk or service desk? Does everyone who works on the service desk know this (assuming that you're right with what you have replied)? They probably don't. I'd happily bet that many of your service desk agents think that they are fixing IT issues rather than helping business colleagues (and services) work again.
I'd also bet that many have minimal insight into how each IT issue is impacting individuals, groups, and business services. Bar the automated priority level that is. You know this - we train people on the processes and the tool rather than the purpose and context of the service desk.
For me this needs to change, otherwise IT help desks and service desks will continue to work hard in earning a less-than-favorable corporate reputation.
So what's the purpose of your IT help desk or service desk? And don't just spout back something you've read in an ITIL book.
Like this article? You may also like: What is ITIL?
Please share your thoughts in the comments or on Twitter, Google+, or Facebook where we are always listening.
Posted by Stuart Rance
on July 20, 2015 in Service Desk
Many IT organizations see employee self-service as a ‘knight in shining armor’, ready to solve all their service desk issues in one quick project.
However, for many organizations, their investment in self-service often results in a white elephant rather than a white knight, i.e. it’s a possession that is useless or troublesome and which soaks up money and other resources without delivering much return on the investment. A self-service white elephant typically has low rates of adoption and utilization – often due to an overemphasis on the technology.
There’s a Webinar for That
Sadly, these suboptimal self-service projects are a common issue, and consequently my good friend Stephen Mann
and I are running a free webinar this Wednesday, July 22
that will offer practical tips for self-service management
success, based on what some organizations have done to get self-service right.
UPDATE: This webinar is now avaiable on-demand here.
We’ll show you how these organizations have succeeded, by:
- Understanding the common challenges and potential pitfalls with self-service.
- Offering practical advice on how to design, launch, manage, and encourage the use of an employee self-service facility for IT (or any other corporate service provider).
- Providing sensible actions that will help you to either get started with, or to improve upon, self-service within your organization.
Here’s a quick overview of what we’ll be covering.
The Benefits of Self-Service
The main beneficiary of self-service is the business people who need to engage with, and rely on, IT but there are also benefits for the service desk and for the whole of IT.
We will outline how the customers and end users will benefit from employee self-service through:
- Faster access to help for users
- Improved user communication
- Increased service hours
- Support for more languages and time zones
- Faster incident resolution
- Faster request fulfilment
- A better user experience
Whereas the IT organization will not only benefit from happier customers, they will also benefit from employee self-service through:
- Improved efficiency and/or reduced cost
- The ability to leverage automation for even greater efficiency and cost savings
- A better ability to handle high volumes of incidents when problems occur
So that’s some of the upside we’ll cover, but self-service is a game of white knights versus white elephants. The benefits are there to be won – but IT organizations need to ensure they don’t end up as the owner of a white elephant, a self-service capability that nobody wants and nobody uses.
How to Avoid Common Self-Service Mistakes
In the webinar, we’ll go into the detail of where organizations commonly fall down with their self-service initiatives, and the best practice that should be adopted to dramatically increase the chances of self-service success. For example:
- Involving customers and end users in the design, and then keeping them involved
- Defining the scope or purpose of the project very carefully
- Making as much use of automation as you can
- Focusing on user experience rather than cost saving
- Making sure all stakeholders, including the end users, understand “What’s in it for me”
- Providing high quality knowledge (articles, videos, etc.) and making sure it’s accessible and comprehensible to the people it’s aimed at
- Providing encouragement and incentives for end users to adopt self-service
- Giving end users a choice
This blog is just a tease for the webinar. It’s a mere 600+ words compared to the free 5000+ word “Self-Service to the Rescue” white paper that can be downloaded while you listen.
So please listen in to hear us talking about all this, in far greater detail, as well as:
- What to include in a self-service capability – there’s more than you think when you start to list things
- How to run a self-service project
- The stakeholders to involve in self-service design through to delivery
- How to avoid confusion over self-service, service catalog, and service request catalog
- Whether you actually need self-service at all
Please join us for our webinar
on Wednesday, July 22 – we don’t think you’ll regret it, that is unless you’re a fan of white elephants.
It’s about time that IT organizations viewed self-service as a capability not a technology – come hear how to do it.
Posted by Joe The IT Guy
on July 14, 2015 in ITIL
If you regularly read my blog
you’ll know that I’ve already written a fair bit on the tough nut to crack that is problem management. It’s often something that’s started as part of the latest IT service management
(ITSM) tool implementation project, but it’s not unusual for this initial investment in problem management (processes) to fail in execution due to one or more reasons.
From a problem management uptake perspective, if you believe what the annual industry surveys report, roughlytwo-thirds of IT organizations are already “doing” problem management. But it’s not always what it should be, i.e. the investment of time and resources to proactively investigate and address recurring IT and business issues, and their root causes. It’s this type of investigation that helps to identify the issues that cause (or may ultimately cause) repetitive and potentially serious IT and business issues or failures. Instead, IT organizations are often just doing major incident reviews, using problem management techniques, as and when needed. It’s problem management of sorts but not truly effective problem management.
In reality, problem management is often somewhat of the “poor relative” to service desk and incident management activities. Whereas service desk and incident management
are commonly receiving adequate investment in terms of staff, definition, training, and ongoing operation, problem management, on the other hand, is often “something to be done later” and therefore often not done at all.
In my opinion, the low levels of proactive problem management adoption is quite ironic. The pressure to cut IT operational costs is why many IT organizations don’t do problem management, but it should be the reason why they need to be doing problem management. Ofall the major ITIL processes, the investment of time and resources in truly effective problem management activity can provide some of the highest returns to an organization.
So to give you a simple introduction to problem management, I’ll quickly cover:
- What problem management is
- The objectives of problem management
- The “problem lifecycle”
- The benefits of problem management
I refer to ITIL a fair bit, you might think too much, but you can quite easily use your own self-created problem management process and activities or look to alternative sources of ITSM and IT management advice such as ISO/IEC 20000
, ISACA’s COBIT
, or Microsoft’s MOF
Where Problem Management Fits In
Problems (definition below) can be identified throughout the IT ecosystem. For example: acceptance into production, changes, updates/patches, vendor products, user errors, production execution, and failures. However, the main source for problem identification with an organization is probably the analysis of incidents as part of what is often called the “proactive problem management process.”
However, not only isproblem management often solely associated with major incidents, another barrier to effective problem management is that problems are often confused with incidents (with the terminology interchanged wrongly). Or they are seen as an incident state rather than a separate entity requiring a different type of ITSM response.
If it helps, an easy way to remember the difference between the two is that:
- Incident management is “put the fire out ASAP!” (so it’s firefighting), whereas
- Problem management is “how did this happen?” and “how do we stop this happening again?” (so it’s arson investigation/fire prevention).
To succeed at problem management, IT senior management needs to appreciate that far too much costly, and possibly scarce, IT resources are currently spent fighting repetitive fires and that these resources would be better utilized supporting problem management activity to tackle the root causes, rather than the symptoms, of IT failures.
Problem Management Definition
, the ITSM best-practice framework formally known as the IT Infrastructure Library, uses the term problem to describe:
“The unknown cause of one or more incidents.”
With problem management:
“The process of minimizing the adverse effect on the business of incidents and problems caused by errors in IT infrastructure and systems, and to proactively prevent the occurrence of incidents, problems, and errors.”
A problem will become a “known error” when the root cause is known and a temporary “workaround” or a permanent alternative solution has been identified.
For completeness, although I state my own benefits below, ITIL states that the value of problem management includes:
- “Higher availability of IT services by reducing the number and duration of incidents that those services may incur. Problem management works together with incident management and change management to ensure that IT service availability and quality are increased. When incidents are resolved, information about the resolution is recorded. Over time, this information is used to speed up the resolution time and identify permanent solutions, reducing the number and resolution time of incidents.
- Higher productivity of IT staff by reducing unplanned labour caused by incidents and creating the ability to resolve incidents more quickly through recorded known errors and workarounds.
- Reduced expenditure on workarounds or fixes that do not work.
- Reduction in cost of effort in fire-fighting or resolving repeat incidents.”
Problem Management Objectives
ITIL defines the objectives of the problem management process as:
- “Preventing problems and resulting incidents from happening.
- Eliminating recurring incidents.
- Minimizing the impact of incidents that cannot be prevented.”
Importantly, it can’t operate in a vacuum.
Problem management should have strong relationships with other key IT service management processes. In addition to the more-obvious linkages with incident and change management, it also needs to use configuration management data to help determine the impact of problems and resolutions. Let’s also not forget that availability management has a dependency on problem management information and activity, and some problems will require investigation by capacity management teams and techniques.
Problem management can also be an entry point into IT service continuity activity and major incident management, where a significant problem needs to be resolved before it starts to have a major adverse impact on the business. Finally, from a service level management perspective, problem management contributes to improvements in service levels, and its management information should be used as the basis for service review activity.
The “Problem Lifecycle”
While not a linear lifecycle like incident management, you can view a problem going on a journey from identification through to “resolution.” Where resolution might come from error control or the creation of a workaround.
Thus it’s worth understanding that there are two common problem management “sub-processes”:
- Problem control – which focuses on transforming problems into known errors (and workarounds)
- Error control – which focuses on resolving known errors via the corporate change management process
The result might be one of three outcomes:
- That a change is required to correct a problem – the organization should use an “error control” process to correct the problem via the corporate change management process.
- A problem cannot be fixed but a workaround is identified; the problem is classified as a known error with a workaround (a temporary way of resolving the incident); it’s logged in a known error database and made available to all support teams for ongoing incident resolution activity.
- No fix or workaround is identified. When a problem is investigated but no solution or workaround is identified, it is recorded as a “known problem” — with the information again made available for the benefit of all support teams.
It’s important to recognize that these three problem states are not mutually exclusive and that a problem may move between them over time. For instance, when possible, a workaround should still be made available while a problem is awaiting the implementation of a required change.
My simple diagram hopefully provides a snapshot of what can happen with problem management.
Problem Management Benefits
In my opinion the key benefits of problem management include, but are not restricted to:
Well there you have it, a quick guide and a simple introduction to problem management. Hopefully you found it helpful.
- Decreasing downtime and thus potentially maximizing business productivity
- Preventing incidents before they adversely impact business operations
- Making better use of potentially scarce IT resources
- Better collaboration between different IT teams in preventing recurring issues; defined roles and responsibilities and a single, consistent process not only speed things up but also reduce duplication of effort and wastage
- The ability to leverage existing known error and “workaround” knowledge to prevent the proverbial “reinvention of the wheel” and to speed up resolution
- Reducing the costs associated with both IT service delivery and IT support – best practice processes and automation can both save time and effort, and therefore cost
- Reducing the adverse effect of business-impacting incidents through prevention or workarounds; this might potentially include lost revenue, lost reputation, or even lost customers
- Improving customer service and the business’s perceptions of the IT organization as a whole
If you want to read more from me, and few of my friends, on problem management, then please look at:
Posted by Stuart Rance
on July 9, 2015 in ITIL
I was recently involved in a discussion about IT services and how to deliver acceptable levels of availability. This discussion was triggered by a failure of the London air traffic control (ATC) system
on 12 December 2014, but the ideas apply to any system, not just safety critical services like air traffic control.
Although the ATC failure did not last long, the impact was enormous, as many flights were diverted, resulting in lots of aircraft being in the wrong place. Airline schedules took a full day to get back to normal, many passengers were stranded, and there was a lot of disruption to travel plans.
There are two ways to improve the availability of an IT service. One is to reduce the frequency of failure. The other is to reduce the time needed to recover from it. The ATC system is a safety critical service. Failure is unacceptable, since it will result in deaths and injuries, and this is why planes had to be grounded. Some of my colleagues argued that since failure of the ATC system is unacceptable, it should have been designed to prevent any possible failure; fast recovery would not have helped as planes would still have been grounded. I, however, argued that in the real world we can never prevent every possible failure, so reduced recovery time will always be essential.
I found support for my view in an article published by The Register
, which said that ATC can continue to operate for up to 8 minutes when they lose access to flight plans (which is what happened on 12 December), but that after 8 minutes they must start to divert planes. So a failure that recovers within 8 minutes has negligible impact, and one that lasts even a few minutes longer has a major impact.
It’s Not Just About Air Traffic Control Systems
I have come across similar issues in many other IT services. In one case we designed a service that could fully fail over to a backup location within 300 milliseconds of any hardware or software failure (yes that really is less than 1/3 of a second). Clearly this kind of solution is not going to be needed for the sort of IT services that most of us work with, but it certainly was a viable solution for this particular customer, albeit one that was difficult to design and expensive to provide.
About 20 years ago I was involved in a project to provide laptops to mobile engineers. This service enabled the engineers to collect their calls, and update them, remotely, providing a significant competitive advantage over the previous telephone based system. Management suggested that we needed to make sure the laptops were locked down, to prevent the engineers from making changes that could impact the key business application, but I know something about the way engineers behave, and I didn’t think this would be possible. The solution we designed involved giving every engineer a CD that took about 20 minutes to completely recover the laptop back to the initial working configuration – and, crucially, without erasing any of the data that they had already stored on the laptop. This meant that nothing they did to the laptop could result in extended downtime, unless they actually managed to physically break it.
I often see service level
agreements that specify availability in the form of percentage uptime, with figures like 99.95% availability during business hours. The problem with this is that it is almost impossible to design a solution to meet this target. We can predict the likely frequency of predictable hardware failures, but most real IT failures aren’t due to predictable hardware failures, they are caused by complex interactions of people, processes, software and networks. In these circumstances the best we can do is have a good plan to restore service to our users when it does go wrong, and this means getting the designers to focus on recovery time.
How many of your IT services have been designed with recovery time as a key design constraint? How confident are you that you could recover each of your IT services within a time that is acceptable to your customers? How well tested are your recovery plans? If you can’t confidently provide a positive answer to all of these questions, then maybe it’s time to review how you plan to meet your customers’ availability needs.
Like this article? You may also like: We Don’t Do People!
Please share your thoughts in the comments or on Twitter, Google+, or Facebook where we are always listening.
Georgetown University Law Center
Posted by Kim Haimovic
on June 29, 2015 in Service Desk
is home to high-profile professors who have served for the U.S. Supreme Court as well as graduate students streaming in from 67 countries. Situated just a few blocks from DC's Capitol Hill, Georgetown Law is a bustling hub for law-making and academia. Recently, I had the opportunity to ask the university’s Tier 3 Senior Technician, Dustin Nigro, about his insights into managing the service desk for a prominent educational institution.
What do you believe are the biggest service desk challenges and considerations for a university or any educational institution?
BYOD is one of our biggest challenges. Students, by nature, tend to be early adopters of technology and often use multiple devices and email addresses, so it can be challenging to track an individual, their assets, and their email history.
Students also tend to use the latest devices and apps on the market, and they need all of these to function within their academic environment. We’ve been dealing with BYOD for much longer than most organizations – it’s magnified like crazy in the education sector.
Another challenge is creating the right service desk culture. Academic institutions
often have a deep-rooted organizational hierarchy. At Georgetown Law, we’re providing services for a diverse group of people comprising of many VIP guests (members of the Supreme Court for example), internal university faculty, staff and graduate students. The VIPs in our community prefer to interact with people that they are familiar with and prefer to receive a more personal service. They want to be treated as people, not handled as numbers –
via predefined emails, phone trees, or self-service. These high-profile VIPs are often transient or adjunct professors, so we can’t rely on them being familiar with our in-house software. We’ve had to find ways to manage the service desk using technology that people are already used to (e.g. email). This also allows our service desk team to categorize incidents accurately and enter useful data into the system. It’s a win-win.
Then there is the challenge of security. Academic institutions are often the targets of large phishing attacks, so password security
has become a huge priority. With this, comes the need to change passwords on a regular basis. SysAid helps us to isolate and resolve such issues.
How has your team managed to provide appropriate support for the diverse needs of students, staff, and high-profile guests?
The university distinguishes its members according to tier levels that include a ‘high-profile faculty’, the Dean’s level, internal staff, and graduate students. Many of the high-profile faculty members come from the U.S. federal courts, government, prestigious law firms, and the Supreme Court. As a result, our service desk priority tier levels reflect this distinction. It has been crucial for us to establish Service Level Agreements (SLAs
) that incorporate priorities according to these tier levels, particularly regarding our response times. When it comes to ‘VIPs’ (such as members of the U.S. federal courts and government), the sky is the limit in terms of the extent to which we’re prepared to support them. SysAid has allowed us to set up priority levels that distinguish between users as well as incident types, all of which correspond back to our SLAs. For any given incident, the respective SLA triggers a timer according to the priority of the given user, and our response times range from five minutes to two hours.
Our support role, when it comes to our students, is to simply maintain the systems they’re using for studies (such as email, learning systems, and apps) rather than provide hands-on support.
What were your university’s key priorities when selecting a service desk?
We were looking for a reliable solution to ensure that staff and students could simply get on with learning and practicing law in an efficient manner without technological hitches. We needed a solution to centralize and manage all facets of IT – from network operations and web operations to AV operations and the service desk. Our service desk at the university is responsible for managing requests from 1,700 faculty staff plus 15,000 students and active alumni outside of the campus. We receive approximately 800-1000 incoming service requests a month and are required to track over 3,000 assets.
In addition, our CIO George Petasis, has always been passionate about the ITIL service delivery framework, and being that service desk management is one of its key components, it was crucial for us to find an ITIL-compliant
service desk solution that would enable us to introduce and manage processes, such as change management, with relative ease.
How challenging was it to implement your service desk and what were the cultural implications for the university and staff?
We pretty much had to set up the service desk from scratch and we only had four weeks to get it up and running before the start of semester. Within this tight deadline, we had to establish certain ITIL processes and ensure that we were set up to track tickets
, as the beginning of term is always a busy time for requests. Luckily, SysAid was easy and incredibly quick to implement and we received excellent support from the Professional Services team, which made it possible for us to rapidly integrate the LDAP and import all the data we needed into the system (such as SLAs and categories), as well as establish the definitions for the status and prioritization of requests. In parallel, we centralized all incoming requests into a single point of contact: the service desk.
We rolled out the service desk in stages in order to gradually integrate it into the university’s day-to-day culture. Naturally, there were initial fears and apprehension among staff – that the new system would pose a burden on them and take up their precious time. To help with these concerns, we explained the new processes through presentation and an email campaign, also conveying that the new service desk would provide help, rather than require additional work from staff.
For our team of admins, training
has always been key to ensuring that the service desk is performing effectively. Initially, we conducted several face-to-face group Q&A’s for admins and we distributed a manual and several of SysAid’s videos (including some hosted by Joe The IT Guy
). In our academic environment, it is common for lectures and forums to be recorded on camera, so we made use of these classroom resources in order to re-use recorded training sessions for admins at a later stage. We conveyed to our admins what essential data we were looking to receive in tickets, and we defined some crucial terminology such as “notes”, “pending”, and “resolution”, as well as clarifying contexts such as in what circumstances it’s necessary to add data to a knowledge base. We’ve continued to provide training sessions post-implementation so that admins can provide us with feedback on live processes including any flaws.
How do you feel the service desk responds to the needs of your university?
It’s our backbone for day-to-day operations – it allows us to manage all aspects of IT for the university. SysAid gives our department accountability as a business unit because we can track our performance and contribution to the organization.
It allows us to see what’s going on day-to-day, monthly, and yearly. This is crucial for an educational institution.
We are also using the service desk’s escalation rules
with priorities and categories. This gives us control over all processes and the ability to configure the system to our ongoing needs. For us, SysAid is a very robust system that incorporates everything we’ve ever needed and wanted for the university. In particular, it has significantly more value in terms of its ITIL capabilities, its flexibility, the fact that it’s easy to configure the templates and the interface, and the ease of use for non-IT end users.
Which processes have you rolled out so far and what are your future plans?
Everything we do is based on best practices. The benefit of SysAid for us is that we don’t have to put in a lot of effort when it comes to ITIL – the system takes care of much of the ITIL framework. We are running incident management and all of our SLAs are set up in SysAid. We’ve set up escalation alerts and we use multiple escalation rules to define how and what the alerts trigger, and who gets notified. We’re currently using SysAid’s Remote Discovery Service with LDAP
, which we find to be a very convenient way to connect with the external server without the need to open ports.
In addition, we are now in the process of rolling out the service desk for our finance department, to manage their HR and payroll requests. They will be able to track all of their data and resolution times. SysAid enables us to manage processes across multiple departments
by distinguishing between the “user permission groups” of various departments. It also allows us to set up automatic routing per department for requests to specific pre-determined groups.
Our future plans include rolling out asset management
. This will enable us to identify the assets associated with each user from within their ticket and provide us with data about the specific software on each user’s machine, thereby assisting us to diagnose users’ issues. Other plans also include setting up change management with SysAid and implementing the self-service portal internally (as the culture of submitting tickets is becoming more familiar to our permanent staff).
How valuable is a service desk for non-IT departments?
Most university departments are in essence ‘service-based’ in the sense of needing to respond to the requests of internal clients.
Non-IT departments are often keen to convert their paper documents into electronic records. SysAid allows any department to centralize and track its internal requests and data flow. This, in turn, means that the IT department can manage multiple organizational processes from a single platform.
Finally, what would be your advice to universities or schools wishing to set up or replace a service desk?
Do your homework, plan, and set realistic goals. Roll the system out in phases over time and make sure that you train those who will be using the system. Without training for your admin staff, your implementation will suffer. It is also imperative to ensure that you set up your definitions, SLAs, and categories according to your specific KPIs, otherwise the processes and technology will not serve your institution’s needs.
Like this article? You may also like: Hospital IT Heroes
Please share your thoughts in the comments or on Twitter, Google+, or Facebook where we are always listening.
Posted by Sophie Danby
on June 18, 2015 in SysAid
I’m delighted to announce that we’ve added a new mobile asset management
add-on and application (on iOS), which provides barcode scanning, audit, and reporting capabilities to the SysAid Service Desk. This is available as an add-on to our Configuration Management Database (CMDB)
The add-on (which has been driven by SysAid customers), will help those facing challenges such as:
- Loss of assets
- The inability to track inventory, including checking out and in scenarios
- Limited auditing and reporting capabilities
So What Does It Do?
The add-on allows you to create a new asset by scanning its barcode; it is then synced with your SysAid account. Subsequently, you will be able to track the asset in the CMDB for the rest of the asset’s lifecycle..
In addition, you will be able to add the cost and asset type, as well as the condition and depreciation formula to be used. Once an asset is scanned into the CMDB, you can immediately check out that asset to a person or location.
At regular intervals, with the use of a barcode reader or using the SysAid barcode app on your mobile device, you can scan assets and access them in real time from the CMDB record. You can also update the record to include things such as: asset condition, ownership, and location. This data will then sync with your CMDB.
Using the app you can process inventory intake and audit different people and different locations (rooms, floors, buildings) that have been assigned ownership of the assets. You can also create reports for different departments that may require this data for financial and purchasing forecasting, as well as to reduce loss of assets.
How Does This Enhance Your Service Desk?
The SysAid barcode add-on will assist additional departments within the organization, not just IT, by providing a robust asset management solution, which includes:
- Financial forecasting
- Operational inventory control through audits
- Dynamic maintenance control through real-time updating and reporting
- The option to incorporate change management and control for all organizational assets
The add-on allows all departments within the organization to track and control the receipt, issue, use, maintenance, and removal of assets. It also allows for snapshot reporting on asset condition, cost, and depreciation – to help improve financial forecasting and purchasing decisions.
Here’s a few example scenarios that briefly show how the SysAid barcode add-on could be used in your organization:
- Your Chief Financial Officer (CFO) can see the cost of assets over time. By understanding the cost and depreciation of assets, your CFO can better forecast for the future.
- Facilities can use the add-on to better understand and track where assets have been placed and who last used a specific asset. The add-on also allows them to quickly update and report on items requiring repair or replacement (maintenance). All-in-all it helps the team to be more responsive and to resolve issues more quickly.
- HR can initiate a new employee number and automatically open a service request for IT and other departments to supply the equipment they require. The service providers can then associate all the new equipment (“assets”) to the employee within the CMDB. When the employee leaves the company, HR, IT, and other departments can collectively ensure all company property is returned.
Where Can You Learn More?
If you’re interested in seeing the barcode add-on and application in action, then you can watch the brief demonstration video below. Or for further information you can contact email@example.com
Posted by Stuart Rance
on June 16, 2015 in ITIL
I’ve written about continual service improvement (CSI) before. If you haven’t read my previous articles then you might like to look at Continual Service Improvement (CSI) - The Most Important Service Management Process
and The Help You Need to Adopt Continual Service Improvement
. These will give you some background on what CSI is, and how you can get started.
Theory of Constraints (TOC) is a set of “thinking tools” that were developed by Eliyahu Goldratt
. TOC was popularised in a novel called The Goal
, which described how TOC solved a range of problems at a fictional manufacturing plant. I can’t describe the various TOC tools in detail in this blog, but I will try to show how some of the TOC tools can make a significant contribution to your CSI efforts.
One key principle of TOC is that you need to consider the whole system, not just one aspect of it. This is a really important idea when you are thinking about continual improvement. TOC reminds us that sometimes improving one part of the system will make no difference to your overall result, and it is even possible that an improvement to one part will make the overall result worse. TOC summarises this with the statement “Any improvements made anywhere besides the bottleneck are an illusion”. For example you should not think about how you can improve “incident management” or “problem management
” or “knowledge management” in isolation. These processes work together to deliver value to your customers and you need to think about improvements in terms of how they impact the whole end-to-end system, not just how they affect one part.
The first TOC tool that I learned about is called the Evaporating Cloud
. This tool provides a systematic way of resolving conflicts and problems. The Evaporating Cloud can be used in CSI to help with decisions such as which improvement opportunity you should invest in. You begin by identifying your conflict – whatever it is that is making your decision difficult – in the simplest possible terms. For example, you want to improve your change management process, but the change management team is happy with things as they are. There you go – that’s your conflict, and once you have done that, the approach taken by the Evaporating Cloud is quite different to other decision-making approaches. You don’t decide your change manager is a fool and dig your heels in. You don’t even start looking at alternative courses of action. What you do is look for a common goal. For example, in the context of IT service management (ITSM) continual improvement, this common goal might be to improve customer satisfaction, or increase profitability. If all participants can agree on a common goal then this gets you a long way towards agreeing on how to get there. In many ways this is similar to the ITILCSI approach, which starts by identifying the vision. After identifying a common goal, the Evaporating Cloud shows you how to continue by following the steps below:
- Documenting the opposed “wants” that lead to the conflict; for example, I want to invest in improvement X and you want to invest in improvement Y.
- Documenting the underlying “needs” that lead to each of the wants; for example: why do I want to invest in improvement X? what need does investing in X satisfy? why do you want to invest in improvement Y? what need does investing in Y satisfy?
- Crucially, you always talk to the other side of the conflict respectfully, making sure that you begin with their wants and needs, and checking that these have been identified correctly, making changes where necessary.
- Finally you identify an intervention that can separate one of the wants from the underlying need, so finding a way to meet everyone’s needs and satisfy the shared goal.
Another TOC tool that I have found really helpful in conjunction with CSI is the Ambitious Targets tool (if you are familiar with TOC, then this is a simplified version of the prerequisite tree). This can really engage staff in improvement planning, because it plays to our greatest strength. All of us know how to resist change.
The basic approach is to agree on the ambitious target, for example “we will create 500 new knowledge base articles next month”, and then to get everyone in the room to think of reasons why we can’t achieve it. Write these reasons on flipcharts, and keep going round the room until everyone has had a chance to list their objections. Then for each objection ask the person who raised it what they think should be done about it. I was quite sceptical about this approach until I tried it in a workshop, where it worked wonderfully well. People generally had excellent intuition about how to solve the problems that they had identified themselves, and really wanted to. We ended up with a set of actions and owners that would clearly make the initiative succeed. I have since used this in many workshops and it has always been really effective.
In summary, TOC includes a great set of tools that can help you with continual service improvement. Here are some things you can do to start using them in your environment.
- If you haven’t yet read The Goal, then get yourself a copy and read it now. If you have already read The Goal then read The Phoenix Project, which is based on The Goal and uses a very similar style to consider problems in an IT environment.
- Start thinking about how you could improve end-to-end value delivery, rather than planning how to improve individual processes.
- Try using the Ambitious Target tool approach next time you’re in a workshop trying to plan a difficult project.
- Find out who runs TOC training in your local geography and consider attending a course.
- If you enjoy learning complex ideas by reading, then buy a copy of Thinking for a Change. Putting the TOC Thinking Processes to Use. This book gives a detailed introduction to all of the TOC tools, as well as the TOC approach to improvement (based on understanding “What to change?”, “To what to change?” and “How to cause the change?”).
Like this article? You may also like: The Help You Need to Adopt Continual Service Improvement
Please share your thoughts in the comments or on Twitter, Google+, or Facebook where we are always listening.
The ITSM Show
Posted by Sophie Danby
on June 8, 2015 in ITSM
(formerly known as the Service Desk and IT Support Show, SITS) is done and dusted for another year – congratulations to Toby Moore
and his colleagues on a very well organized and delivered IT service management (ITSM) event.
We are all hopefully back at work now but what did we learn? Or for those that didn’t attend did they learn anything from the event’s Twitter stream (#SITS15
)? I hope we and they did, but just in case I have pulled together some sage advice from the sessions I attended and the Twitter stream.
So What Did I Learn (Or Think Was Valuable to Others)?
On Service Desks
- “You are NOT the break/fix center, you have to take a strategic view.” – @jarodgreene
- "Some people want the EasyJet of Service Desks. Some want BA. Know your customer expectations & what you can deliver." – @stephenmann
- “Your service desk should challenge your customer's expectations. Otherwise you'll never innovate at the rate you need to.” – @patb0512
- “67% of service desks spend their time firefighting incidents. Even actual fire fighters don't spend that long on it!” – @GBaylisHall
- "Only 17% of IT issues actually make it to the Service Desk." – @stephenmann (stat via Forrester Research)
- “None of the vendors at #sits15 are the leaders of ITSM. Google is the number 1 tool used to solve IT issues!” – @stephenmann
- “Outsourcing your service desk disconnects vital business users from the most vital business service” – @stephenmann
- “If you don't get the service desk right, it doesn't matter how good the rest of your IT department is.” – @GBaylisHall
- “50% of the people you hire to your service desk will likely leave within 2 years.” – @GBaylisHall
On the Changing Expectations of Corporate IT
- “What a 14 year old can do with IT vs. what corporate IT can do.” – @VigilantGuy
- "Never assume that technology is enough to deliver against service expectations." – @sarahlahav
- “Be aware employees will make comparisons between corporate IT experiences with their personal experience.” – @stephenmann
- "Many IT orgs miss out on improvement opportunities by not looking outside of their IT ecosystem." – @sarahlahav
- "Stop thinking about IT first. Start investing in new technology to create more (& new) business value." – @patb0512
- “If you don't like change, you are going to like irrelevance even less.” – @patb0512
- “It's quite easy to set user expectations. Just communicate with them!” – @AndieKis
- “Companies tend to reject innovation as they're tied up with their customers' immediate needs.” – @IanAitchison
- “People buy based on the services but stay with a supplier because of the service.” – @sarahlahav
- “IT is not a function. It's a capability.” – @stephenmann
On Using ITSM Outside IT (Enterprise Service Management, ESM)
- "Don't use #ITIL language with other departments when it comes to #ESM." – @VigilantGuy
- "Don't try & sell #ESM as an IT strategy. It's a business strategy. Talk in IT terms & you likely won't succeed." – @stephenmann
- “IT don't want to talk to humans. HR don't want to touch technology. And finance? Well they just don't give a sh!t (no budget!)” – a great barriers to ESM quote from an audience member
- “#ESM is sold by communication, delivered by communication , supported by communication not by #ITSM value prop.” – @gobbymidget
- When speaking with other lines of business… “Ditch the term Enterprise Service Management. Just simply call it ‘a better way of doing things.” – @stephenmann
- “IT shouldn't just try & sell technology to the business (ESM). Sell your expertise, your knowledge & lessons learned.” – @stephenmann
On Improving IT and Performance
- “Don't just let an #ITSM vendor sell you a tool. Get their help with people & process issues. They have experience to help you.” – unknown
- “People, attitude and governance need to be sorted out before processes will work.” – @barclayrae
- “How many of you understand the journey your users go on with your service desk? Their service journey? START HERE.” – @patb0512
- “DevOps isn't about just Dev and Ops. Must involve the whole community.” – @marksmalley
- “Principles and values are more important than processes devops.” – @barclayrae
- "You have to take several steps with configuration management before you can show real value to the business." – @NybergTobias
- “The perfect configuration manager is a little bit butler, a little bit engineer, a little bit used car salesman, with a dash of politician.” – @NybergTobias
- “Knowledge management isn't just about writing documents. And your IT team shouldn't be the source of all your knowledge.” – @patb0512
Stuart Rance’s Session in Particular Had a Lot of Buzz
It’s also worth shouting about the fact that Stuart Rance was named “ITSM Contributor of the Year” at SITS.
event manager @tobyonsushi
with his #ITSM
Contributor of the Year award. Well done!”
Sadly I didn’t attend his session on “We Don’t Do People” but have still curated a number of interesting tweets for you:
- “Talk less, listen more and storytelling.” .... Nailed it in the first 2 minutes
- “Don't do what you have been told to do, when it's the wrong thing to do.”
- “Let your staff know that they can do what they need to for customer. Ignore the process when it is okay to ignore it.”
- “IT organisations need to teach their people intelligent disobedience.”
- “Recruit appropriately. For behaviours not tech. Then monitor and reward to drive appropriate behavior.”
- “Involve the customer in process design since almost every process is aimed at customer experience.”
- “Caring about customers and putting them ahead of all else absolutely needs leadership from the very top.”
Further insights on this topic can be seen on Stuart’s recent blog here
Additional Advice for Those Working on a Service Desk
AT SITS we asked a few ITSM industry authorities and presenters "What is your top tip for someone working on a service desk?". Watch the short video below to hear the gems we caught on camera.
I hope you have found my curated tweets of interest and feel free to share your favorite tweets as comments below.
You can see more curated #SITS15 Tweets in Toby Moore’s Storify
Like this article? You may also like: What Can Estonia Teach You about IT Service Management?
Please share your thoughts in the comments or on Twitter, Google+, or Facebook where we are always listening.