SysAid Blog

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

The Downside of Using Email to Manage IT Support

Posted by on February 21, 2017 in Help Desk
Downside of Email IT Support There are a number of reasons why email and other personal productivity tools are used for IT support, for example:
  1. Most IT staff usually have access to email
  2. IT staff know how to use email
  3. The email technology has already been “paid for” in providing a set of tools for personal productivity reasons
So it’s easy to think of email as being a cheap IT support technology, one that’s easy for IT support people to use. But easy isn’t always best…or even appropriate.

Breaking Down the Issues with Using Email to Manage IT Support

Let’s consider IT support operations – key activity by key activity – in the scenario where we’re part of a group of service desk agents using a communal email inbox to receive and manage end-user incidents and service requests: [caption id="attachment_1938" align="aligncenter" width="638" class="center"]Companion to ITIL v2 Original source: A Companion to ITIL (v2)[/caption]

Phase 1. Incident Detection and Recording

An end-user email comes in and it’s automatically “recorded” – because it’s sitting there as an entry in the communal inbox. However, does it contain all the required information from the end user? Well, we can’t say, as this will differ by issue or service request type (plus service requests might be mixed in with the far more time-sensitive incidents). We could use an email template to help end users provide the right information though; maybe even something showy that requires different information based on the issue or service request type. But what do we do if the end user calls by phone, rather than emails? Do we create an email ourselves, add the issue to an Excel spreadsheet, use a post-it note, or record nothing at all? And what about benefiting from the modern penchant for self-service? It’s not just about improving IT efficiency, it’s also about providing contact channels to suit end-user preferences and delivering a better customer experience.

Phase 2. Initial Classification and Support

I guess we could classify an issue, or service request, in an email inbox through the use of folders or tags, but what happens if the initial classification is wrong? The issue can be reclassified but would we know how much service desk time is wasted on misclassified issues? And what about prioritization? Are issues and requests dealt with on a first-in-first-out (FIFO) basis, with some bias towards “important” end users, or is a more scientific urgency and impact-based approach taken? Also, what about the ease and quality of initial support? Is information related to the task at hand readily available through integrated knowledge management capabilities? Do you have information related to the end user’s IT history and the IT assets they use? And what about information related to service level agreements (SLAs) and the targets for fixes and service request delivery? So of course we can solve the end user’s issue or service request but only if we have the right knowledge, skills, and experience and our service desk has the absolute minimum of staff churn.

Phase 3. Escalation to a Major Incident Process Where Needed

The reality is that if email is being used to manage IT support then the “process” for major incidents is very likely to be a lot of running around like headless chickens until things are “better again.” Major Incident Process Sadly, this might seem harsh, but using an email inbox and/or manual procedures will not be the quickest route to the required resolution (due to a lack of insight into the root cause, previous resolutions, and ongoing status). Most likely, there will also be insufficient communication to stakeholders, and probably no post-major-incident review to ascertain “what went wrong” and to identify any improvement opportunities.

Phase 4. Investigation and Diagnosis

So there was no immediate fix and one or more of our IT support or service desk agents now need to spend time investigating the issue to better understand what needs to be done to rectify things. But what happens here in terms of logging progress and important aspects of our investigations, such as: failed solution attempts, who is currently working on the issue, expected resolution time, and the eventual solution? Of course the email could be updated with all of this information, but will it be? Hard to believe, especially if an issue, once closed, is simply filed away in the “completed” folder with no metrics created, or knowledge captured, to improve resolution of similar issues in the future.

Phase 5. Resolution and Recovery

So the issue is now fixed or, in the case of service requests, the service delivered. The email system can be used to inform the end user, so all is good. Right? Well, it depends. Is everything that was learned, while resolving the issue, lost as soon as an email is “filed”? Meaning, do the other service desk agents need to reinvent the proverbial wheel when a similar issue gets reported in the future? And what about dealing with customer feedback on IT support’s performance, or is that ignored? Of course, knowledge management and customer feedback capabilities can be built and integrated, but surely this is just additional evidence that a fit-for-purpose help desk or service desk tool is so much more than an email system?

Phase 6. Incident Closure

Probably little to worry about here with email – the issue or service request can be moved into the “completed” folder (plus it can be moved back into the main inbox if the issue or service request needs to be readdressed). That is until we look at the email system’s ability to provide visibility into support operations – with metrics related to throughputs and efficiency, including the number of reopened issues. Thus transactionally, email can be used for incident management, but there are so many suboptimal elements and inefficiencies, which cost time and money, and can be addressed through the use of a fit-for-purpose help desk or ITSM tool.

But It’s Not Just Issues with the Transactional Elements of Email Handling

There’s also the ongoing monitoring, tracking, and communication of issues/requests to consider. And boy is there a lot to consider here, probably as much as with the previous six bullets combined:
  • Does the email system allocate a unique reference to each incident or service request such that an end user or IT team member can quote/find it when needed? And what about providing a suitable audit trail?
  • Can the email system calculate the timings between key activities such as email receipt, allocation, resolution, and closure? Thus allowing for the assessment of performance for individual tasks, incident and service request types, individual service desk agents, and the service desk team as a whole? Plus, can those who work on an issue or service request log the time they spend doing so?
  • From a management perspective, can incident-related data be used to quantify the adverse effect of IT issues on business operations – a cost of quality and an opportunity to improve things?
  • Are service desk agents able to identify issues and service requests that are taking too long to deal with? Even if there are no IT support SLAs to be met, what’s to say that tasks get accidentally delayed or even forgotten about, especially when multiple parties are involved?
  • How are issues and requests tracked, not just over time but also from person to person? How is responsibility or accountability assigned – is it the last person to “view” an email or the last person to add a note? Or are emails tagged to individuals or dropped into people-based folders rather than category-based folders?
  • Email software lacks “workflow, automation, and alerting” – so how do the individuals with the right skills or authority know that something needs their attention, or how does the system know if an issue has awaited third-party attention for too long? Do people have to regularly check the communal inbox, or has the email system been tweaked to allow for action-request emails (alerts) to be sent? Plus, I’d be willing to bet that such emails, if they exist, don’t automatically get resent (or someone else alerted) if the third party hasn’t done what they need to do in a reasonable time frame.
  • Communication-wise, of course emails can be sent to and received from the email system but how are they “organized” and is it easy to separate important emails from trivial ones? Plus, what happens when a telephone call is made or received, or a deskside support agent wants to notify the service desk of what they have discovered or tried as a resolution? What I’m trying to say here is that emails can be used, even if just for collecting notes, but the information within the emails is mostly unstructured and inaccessible at speed.

So How Well Is it All Working?

The last bullet above leads us nicely into another area, and probably the biggest area, of operational and management weakness when using email for the management of IT support – insight and reporting. With an email system you can probably manually count things such as the number of emails received or closed in a month, and split them between incidents and service requests. You might also be able to attribute them to individuals to ascertain personal “throughputs” (although I’d be worried about people playing the system and quickly jumping on the easiest of issues while avoiding those that take time). As mentioned earlier, the information or data held within the email system is unstructured and thus difficult to analyze and report on. So accessing insights into: incident and request volume peaks and troughs, average handling times for each incident type, achievement of SLAs, the costs of IT support by category, incident trends for problem management, business unit to business unit comparisons, and other metrics – is either impossible to get or a highly manual and time-consuming activity. Plus of course the email system will not have a modern reporting capability nor dashboards, nor any form of ability to slice and dice data to identify patterns or other insights such as business intelligence.

Finally, IT Support Is More than Just Service Desk

How does your IT organization manage problems (if they do at all) and changes? Do your monitoring or event management systems integrate with your email system? Can your email system launch automation capabilities to solve issues? I could go on but this blog is already long enough, many would say too long. My point is merely that using an email system for IT support is really only scratching the surface of support capabilities and missing others espoused by industry best practice such as the ITIL IT service management (ITSM) best practice framework. So if you’ve read this blog and still think that you can use the corporate email system for IT support, adding to it to get around all of the issues raised, then I’ll pose you one last question – “Would you build your own HR or CRM system?” Unless your answer is oddly “yes” then surely you should be applying the same “buy, not build” logic to invest in fit-for-purpose technology for IT support that’s optimized to business needs (and reliable), maximizes people efficiency through workflow and automation, delivers a better quality service to end users, and provides greater insight into operational performance and improvement opportunities.  
Continue reading

Is the Term “Service Desk” Merely an ITSM Marketing Coup?

Posted by on February 14, 2017 in Help Desk
Is the Term “Service Desk” Merely an ITSM Marketing Coup? There are lots of different names for “the corporate team or function that provides internal IT support to end users.” Examples that I’ve seen used on my IT service management (ITSM) travels include:
  • IT help desk
  • Service desk
  • IT support
  • Support center
  • Technical services/technical services center
  • Technical support (center)
  • Technical customer support
  • Level 1 support
  • Frontline support
And there are probably many more. But how often do each of these get used “in the wild”? And are some of the names better than others?

Let’s Start with What HDI Members Use

HDI, which is a professional association for the technical support industry, showed how different names are used by its members in their 2015 Support Center Practices & Salary Report: [caption id="attachment_1913" align="aligncenter" width="435"]HDI 2015 Support Center Practices & Salary Report Source: HDI 2015 Support Center Practices & Salary Report[/caption] So we have service desk at 36% and help desk at 23%, with the remaining 41% of companies using a variety of other names.

Have We Been Killing Off the IT Help Desk One ITIL Exam at a Time?

In many ways the HDI results are to be expected. ITIL, the most commonly-adopted ITSM best practice framework, took the IT help desk of old, and IT operations best practice, and built a body of ITSM advice around them. But, as ITIL and ITSM evolved, the term “IT help desk” no longer fit the new world of “managing IT as a service” and the term “service desk” was deemed to be a better name for the help desk 2.0 – which now offers more than just help for IT issues. In fact, the term “help desk” has been removed altogether from the ITIL lexicon. If you don’t believe me, then take a look at the ITIL 2011 books or the online ITIL Glossary: [caption id="attachment_1914" align="alignnone" width="800"]AXELOS ITIL glossary Source: AXELOS ITIL Glossary of Terms[/caption] It makes sense – we have ITSM, IT services, and the service lifecycle so why not a service desk instead of a help desk? Or does it?

What Does the “Service” in Service Desk Allude to?

It’s an interesting question, one that I’m not sure most people stop to think about. So I thought I’d give it a go. Why is the service desk called a service desk? Is it because the service desk is there to support the needs and wants of the users, or consumers, of services? If so, then a service desk is just the same as the supermarket meat counter that provides specially-tailored meat portions to customers. Or is it called a service desk because it services end-user needs, in the same way that supermarkets have service desks or customer services? Both reasons are conceivable. Or, is it called a service desk only because ITIL, backed by many ITSM tools, says that this IT support capability should be called a service desk rather than a help desk? If we go back 5-10 years, ITIL was a big part in ITSM tool marketing and selection; and ITIL-educated customers wanted to buy service desks not help desks.

Importantly, Do the Above Reasons Actually Matter?

Not really, as this is all inside-out thinking, which is where decisions and actions are made with internal rather than customer-focused motivations. So far this is more about what people in IT want to call it – due to evolution/reinvention or wanting to introduce a better help desk, rather than thinking about the customer perspective. For instance, they might say:
  • “Help desks only deal with break-fix issues.”
  • “Service desks take a different, more customer-focused, approach to IT support.”
  • Or, “Help desks of old didn’t do first contact resolution (FCR).”
However, there is, and was, no reason why an IT help desk couldn’t do more than break-fix, be more customer focused, or hit high levels of FCR. Instead, I think that the term “IT help desk” just didn’t fit with the “service-this” and “service-that” lexicon of service management best practice. Plus it didn’t help vendors to market and sell something better than the existing customer IT help desk tools, and therefore had to go.

Let Me Play Devil’s Advocate for a Moment

So to sum up – the “service desk” is named as it is because it’s what most people call it these days, it’s best practice. Agree? Well I disagree. Not with the logic of good or best practice but with it’s what most people call it these days. In my experience, most people still call the service desk “the IT help desk” or “IT support” not “the service desk.” Why? Because “most people” are the corporate end users, or customers, that need support – as surely they must outnumber service desk, and even all IT, personnel in the majority of companies! So was “service desk” merely a new term introduced to market and sell more books, training, exams, technology, and consultancy? Sadly, I’m struggling to see beyond this, as an IT help desk could have delivered everything a service desk does without the name change. You can read more on the help desk vs. service desk debate in Joe the IT Guy’s blog: “You Say Tomato: Help Desk vs. Service Desk
Continue reading

Enterprise Service Management Is Not Just for Service Requests

Posted by on February 7, 2017 in General IT
Enterprise Service Management (ESM) Enterprise service management (ESM) is the use of IT service management (ITSM) tools and processes to support other lines of business within an organization. It’s a term that’s generally used by IT people, who know and understand ITSM, but may be off-putting to those less familiar with IT.  In fact, I enjoyed a presentation by Elina Pirjanti at the itSMF conference in Estonia last year, where she asked us to stop calling it “enterprise service management” (in fact, she wrote a blog about it too). Everyone else in the organization thinks of this way of working as “digitalization” or “digital transformation” and we should use their language, rather than trying to force IT language on the rest of the organization. And this is fair enough, at least up to a point; particularly when I know that all the articles I’ve read about ESM recently have a focus on using ITSM tools to help manage service requests from business units such as HR, legal, or facilities. This is certainly an important use case, and is something that almost every organization should be doing. ITSM tools are great for logging and tracking service requests, as well as supporting automation of request fulfilment, and providing reporting so that you know how well you’re doing.  Why would we not choose to take advantage of these capabilities that are already at hand? Here are my thoughts on how you can take advantage of ITSM to help other areas of your organization…

Providing a Single Portal for All Service Requests

Today, we’re seeing cases of ESM that go a little bit beyond just managing service requests for different units within a business. For example, in some organizations, ESM now provides a single portal for employees to access all the business services they need, whether it’s ordering a new laptop, notifying the reception desk that a visitor is expected, or requesting a pension statement from the finance department. This improves employee experience, as well as providing greater efficiency for internal business units, and increased transparency and understanding of what work is being done by each team. The most effective organizations extend this portal outside their own organization, providing a way to work more effectively with suppliers, and with external customers.

Using Incident and Problem Management Outside IT

When people think of ESM as “digital transformation”, they are only thinking about request fulfilment, and this is all that they include in their ESM project. The trouble is that if those of us familiar with the possibilities inherent in ITSM tools and processes just stick to request fulfilment, then we are needlessly limiting ourselves. There is a huge opportunity for ESM – or whatever we choose to call it – to exploit the value of other ITSM capabilities across the enterprise. I have worked with organizations who are very good at managing their IT incidents and problems, but had never considered using the same approach for managing incidents and problems in other parts of their business. A few forward thinking organizations, however, have now started to consider this. Recently I was talking to a friend who was working as a management coach for a transportation company. This company provides drivers to take trucks on single journeys. Their key business metric is the percentage of trucks that arrive at their destination at the correct time, and they typically manage to get about 98.5% of the trips to meet this target. The CEO wanted to improve, but realized that achieving a very ambitious 100% success rate would require much better, and more detailed, understanding of exactly what was happening with the failing trips. Failures might be caused by breakdowns, unexpected traffic, drivers falling ill, and many other causes too numerous to list; and without good data it would be impossible to devise an investment strategy that would lead to improvement. The way forward is obvious, once you’ve thought of it. We suggested implementing processes based on IT incident and problem management – to help them deliver better service to their customers, and to supply the missing data. The transport company already use tools and processes for managing IT incidents. By using the same tools to implement an incident management process focused on truck movement, the organization will be able to:
  • Understand the current status of all the trucks that have issues, providing management with transparency and enabling them to prioritize their resources where they will deliver the best value.
  • Provide clear and accurate data about incidents to people who are helping to resolve them, reducing communication errors and improving incident resolution times.
  • Access a knowledge base with information about how other similar incidents have been resolved in the past, allowing the organization to learn from experience, rather than depending on the knowledge of the person managing the specific incident.
  • Categorize incidents so that they can see trends, and prioritize problem management activity.
If the organization also implements a problem management process, they will also be able to:
  • Identify trends, based on incident management data, so that they know which incident types need a better way to resolve them.
  • Research and document the best way to deal with different incident categories, to enable their best people to influence what happens throughout the organization.
  • Understand the costs and benefits of different approaches to incident resolution, and make targeted investments that will improve business performance.
If you have been involved in IT incident and problem management, then I’m sure you can add to this list.

Design for Experience

But before you go off and implement ESM across your organization, I need to offer a warning. As I was writing this blog, I discussed the concept of using incident and problem management with a friend who doesn’t work in IT. Their immediate reaction was “I already waste too much time fighting my computer. I don’t want to waste even more time filling in forms for some IT manager when I could be getting on with my job.” If you want the benefits of ESM, then you’ll need to think about how people in your organization already view IT, what their current experiences are telling them, and what training they might need. You will need co-operation to get people to change the way they work, and if you don’t design your solution so that it works well for them, then your project is never going to succeed. So make sure you talk to all the stakeholders before you do anything. Understand their concerns and make sure you work with them to design a solution that works for everyone.

So What’s Next?

In this blog, I have given only one example of how incident and problem management processes might be used outside of IT, but I have seen similar approaches in use in many different industries, and I am confident that there are many more I have never imagined. So, have a think about your own organization. Perhaps you can see how an imaginative application of ITSM tools and processes outside of IT could benefit your organization?  If you can think of an ESM solution that will work well and give a great experience to all your stakeholders, don’t let the potential difficulties stop you.  You could end up providing your business with a real competitive advantage.
Continue reading

Back to ITSM Basics: The 9 Guiding Principles of ITIL Practitioner

Posted by on January 31, 2017 in ITIL
9 Guiding Principles of ITIL Practitioner In a previous blog I talked about “starting where you are” as a guiding principle for people who want to improve outcomes for customers. I talked about how this means not throwing away everything you already do and starting again from zero, and how following this principle can really help you to do a great job when you’re planning IT service management improvements. What I didn’t mention was that “Start where you are” is one of the guiding principles in the new ITIL Practitioner Guidance, which was launched in February 2016. I was delighted to be included as one of the authors of this publication, and I want to tell you a bit more about it. The ITIL Practitioner Guidance describes nine guiding principles, and I believe everybody in service management should think about all of them, because if you follow these guiding principles, they can really help you succeed. In addition to Start Where You Are, the other ITIL guiding principles are as follows:
  • Focus on Value: Everything you do should be based on maximizing value for your customers.
  • Design for Experience: Think about, and manage, how your users and customers experience your services and their interactions with you.
  • Work Holistically: Consider the end-to-end value chain, and how all the bits fit together. Don’t optimize one process or activity at the expense of the overall service.
  • Progress Iteratively: Make a series of small improvements, rather than trying to create one enormous project. Agile works really well as an approach to ITSM improvements.
  • Observe Directly: Don’t just rely on reports and metrics, go to where the work happens and see what people actually do.
  • Be Transparent: Make sure everyone knows what’s happening, engage them early, and make sure they understand organizational goals as well as the actions you’re taking.
  • Collaborate: It takes a lot of people to deliver IT, which makes it all too easy for IT teams to have too narrow a focus without due regard for the bigger picture. IT that runs in silos is often the cause of our problems, but if we collaborate across teams then we can do a much better job.
And finally
  • Keep It Simple: Eliminate everything that you don’t need, so that you can focus on the things that are really important.
We should remind ourselves to think about all of these guiding principles whenever we plan any ITSM improvement. If we could all learn to focus on these things instead of on our processes and technology, then we’d do a much better job for our customers, and we’d create more value for everyone.

Combining the Guiding Principles

Each of the guiding principles I’ve talked about has a lot of value on its own, but the real benefit comes from combining them. For example, you could combine the ideas of Observe Directly, Be Transparent, and Collaborate when you’re carrying out an ITSM assessment. I’ve done this and it leads to great results. For instance, on one assessment I invited the customer to join me when I interviewed the IT people responsible for planning changes and releases. Not only did this give the customer great insight into the issues that IT were dealing with, but it also helped me to create a report that really did focus on customer value. That made for a better result all round. Another very powerful combination of principles is Focus on Value, Design for Experience, Work Holistically, and Keep It Simple. I used all four of these principles to make absolutely sure that the new incident management process one customer asked me to design really did work for both the customer and the IT organization involved. Actually, this was another occasion where I engaged the customer in helping to design the process — after all the process was there to satisfy their needs —  so, in fact, we also used Collaborate, Be Transparent, and Observe Directly. And really, now that I think about it some more, we also used Start Where You Are to make sure we didn’t waste the great work that had already been done in this area. That’s eight out of the nine principles right there in just this one example! And here’s another example of how I’ve used these guiding principles in practice. This story is based on a real client but I’ve changed some of the details for privacy reasons. The organization operated in many countries, and had lots of separate service desks. Some of the service desks supported just a few users, others supported users in four or five different countries. Some of the service desks were managed in-house, others were outsourced. The organization wanted to improve the service offered to roaming users, and to provide a more consistent worldwide service, but they didn’t even have any consistent metrics that they could use to compare quality of service in different locations. They had an “ITIL Consultant” who proposed to create a new process, which could be deployed to all locations. The consultant had told the customer that it would take about nine months to write the documentation for this new process. I worked with the customer to understand the situation, and then proposed a different approach that would deliver value much faster. This is what I recommended:
  • Break the work down into a number of activities, each of which would deliver some value — [Progress Iteratively]
  • Talk to customers and users, and agree on a small number of business-focused metrics that we would measure for each service desk — [Collaborate], [Focus on Value], [Design for Experience], [Observe Directly]
  • Select the two or three best performing service desks and investigate how these could expand to provide support to more locations, replacing poorly performing desks — [Start Where You Are], [Progress Iteratively], [Be Transparent], [Keep It Simple]
  • Continue to measure the agreed metrics and allow the best performing service desk to take over gradually over a period of time — [Progress Iteratively], [Start Where You Are]
Whatever you’re responsible for in IT, I think that the ITIL Practitioner guiding principles can really help you to focus on what’s important, for you and for your customers, so please read about them, and think about how you could incorporate them into your work. You can buy the ITIL Practitioner Guidance from AXELOS, or from TSO or from other online bookstores.  Consider each guiding principle in turn and think about how you could use it to improve what you’re doing, whether this is an improvement project or just doing your normal work. As always, please let me know how these ideas work out for you. You can contact me easily on Twitter at @StuartRance.
Continue reading

Using the Knowledge from Within (Your Help Desk)

Posted by on January 24, 2017 in Help Desk
Having an external perspective is valuable, and even essential, for an organization to establish improvement ideas. That ability to ”see the wood for the trees” coupled with knowledge of the broader world outside your organization can be helpful. That’s why consultants are often worth the money: to deliver that outside world view and help an organization adopt approaches that have proven to be helpful to others. This is often referred to as following best practice, and getting external help to do so – a traditional IT service management (ITSM) approach taken by many CIOs and IT managers. But there is another, often equally important, perspective (aside from the wider world view) that an organization should be aware of in pursuit of continual improvement. And that’s the perception based around familiarity, local knowledge, and shared experience, which is available to companies that want them. These are far cheaper than the external consultant path, and will complement and refine best practice approaches. The most powerful concentration of useful knowledge and awareness in many organizations resides right inside their help desk – especially true if that help desk is internal and local to the user community.

Let Your Help Desk Help You

Collecting and analyzing data is an important and valuable exercise. At the heart of good problem management is working with the collected incident data, seeking trends and patterns, and initiating corrective or, better yet, preventative actions. Don’t stop doing that, but remember also that users are people, and the heart of the help desk role is people-to-people communication. So… along with looking at the cold, hard statistics, it makes good sense to collect information on how your users actually feel about the services you deliver, the things you get right, and the things you get wrong. In fact, what exactly do they see as right and wrong? Their ideas may not line up with yours. A good help desk offers IT management a quick, simple, and reliable route towards understanding how their users actually feel about the services delivered. But how often do those IT managers do the simple and obvious thing: go and talk to the help desk staff. So much can be gained from opening channels of conversation, no need for anything too formal, just go and talk to them, maybe over coffee or even a beer?

A Conversation Is Worth a Thousand Statistics

In fact, talking with front line staff is, and always has been, a good plan for most organizations. As mentioned earlier, this shouldn’t be seen as an alternative to formal analysis but as a human-oriented complement to statistical and factual analysis. A whole range of subtler nuances are available from ongoing dialogues with help desk staff, and even more from sitting down and watching them in action. For example, here are some things that might be learned/discovered:
  • How often do they need to calm users down before they can capture relevant information? Is it clear why the users get upset? Is it just that they need their services fixed, or is the mechanism you have for calling the help desk part of the problem? Features that are attractive from a supplier perspective – like menu choices (the press 1 for complaints, press 2 for requests kind of thing) – may cause users to get even more upset than they initially were when they decided to call the help desk!
  • How much user self-help is going on out there? The conversations that help desk staff have are likely to expose how often users have tried to fix things themselves, and how often they have discussed and tried approaches with colleagues before calling the help desk. This kind of information is rarely captured by any formal mechanism but should have influence over how services are built, maintained, and supported.
  • And, crucially, how happy are the help desk staff? That might not sound like a top priority but consider how expensive staff turnover can be – recruitment, training, security clearance, etc. before a new staff member is fully contributing. Keeping staff happy is key to reducing those kinds of costs.

Keep the Conversations Going

Of course, the help desk people are not the only staff a manager could usefully spend time with. Second and third line support personnel have their own tales to tell, as do service level managers. In fact, just about every one of them offers information and early warning signs about possible future issues. Therefore, don’t just rely on measurements and numbers – remember that service is about people, so take the time to talk to those people who are out there delivering those services on your behalf. Image credit
Continue reading

Major ITSM Improvements Should Start with Small Steps

Posted by on January 17, 2017 in ITSM
I visited two very different customers recently.  They had very different problems and the solutions I suggested for them were also very different. But there was one thing that they had in common — they had both delayed starting the improvements they knew were needed because the costs and risks were too high. Instead, they had done nothing and so allowed their problems to continue completely unchecked. For both these customers, the solution was very similar. Both needed to “Start where you are”, “Keep it simple” and “Progress iteratively”. These are three of the guiding principles from ITIL Practitioner, and between them they encourage IT service managers to adopt an agile approach to resolving issues, rather than taking on big, risky, expensive IT service management (ITSM) projects. I created a few podcasts on these topics for SysAid’s Back to ITSM Basics project, so please do listen to those if you are interested. If you also need improvements that seem too expensive, or too risky, then read on to learn how you can get started.

A Big Organization with a Big Problem

One of the organizations that I visited is very large. It provides support services to many external customers all over the world, and has lots of service desks. Some of these service desks are dedicated to a single customer, others support multiple customers, and some are for internal users. Some of them provide logging and dispatch only, others provide level 1 support as well. While many of the service desks use the same ITSM tool for logging and managing incidents, there are quite a few other tools in place as well. Almost all of the customer communication, for all the different service desks, takes place by phone. The organization would like to shift to more efficient channels, e.g. text-based chat and a self-service web portal, but because the company is so big, the implementation costs would be enormous. IT has, in fact, identified a tool that could provide chat for all of their complex environment, but since they can’t be confident that an implementation project would run smoothly or that the returns would justify such a big investment, they can’t get the funding for this. As I talked to the IT department, the solution to their problem became obvious. Instead of trying to implement chat for all of their users, which would be a very big and expensive project, they could start where they are, start small, and grow in small steps. The organization’s users already have a tool that supports chat, although it is not currently used for IT support. So it would be quite easy for IT to start there. Here’s what they can do: Find a small group of users and offer to use this existing tool to provide them with IT support. Monitor carefully to reveal any issues for the service desk or the users, and resolve them before scaling up to support more internal users. Eventually the IT department will reach the limits of how well this tool can scale in their environment, but by then they will have:
  • Identified and resolved many issues relating to how the service desk works when handling chat-based interactions
  • Understood which types of incident are best handled by chat, and which are better managed using phone or other channels
  • Discovered what communication and support works best to encourage users to migrate from phone to chat
  • Collected data about how many calls each service desk agent can manage using chat, and how much this could save if scaled up to the whole organization
This gradual implementation of chat would be very low risk, and, by starting with a tool that is already in use and familiar, would not involve much cost. By the time the IT department has scaled up to supporting a large number of internal users they will know whether a full implementation using an expensive tool will be a cost-effective investment, and they will also have learned what needs to be done to ensure success. If they wish to go ahead with an expensive new tool, this will give them everything they need to create a business case for the next stage.

A Small Organization with a Security Problem

The other organization that I visited is MUCH smaller. They have just two staff working on their in-house service desk, supported by a manager who carries out other roles as well. They have a few thousand users in a small number of offices, all in a small part of one country. They are finding it difficult to manage user access controls. When a new user joins the organization, they ask about what access this user needs, and then grant individual rights to the specific applications and data. When people change jobs or leave the organization, it’s difficult to find all the access rights that have been granted, so these are often left in place – and this creates a significant security risk. The support manager knew that the solution to their issue was to move to role-based access controls (RBAC), where all access rights are granted to roles, and then those roles are assigned to users. But there had been no attempt to migrate to RBAC because of the risks involved. Sometimes things go wrong during even the best planned migrations, and this could cause significant cost and risk to the business. The solution for this customer was also to take an agile approach. Instead of attempting to change everything at the same time, the organization could start where it is, keep it simple, and do it a bit at a time. Here’s what they can do: Next time a new employee joins the company, grant all the rights that user needs to a newly created role, and then assign this role to the new user. This should be no more work and no more risk than would normally be involved in providing appropriate access to a new user. Once confident that the role works well, and that no changes are needed, go on to migrate one existing user to the role, removing the current rights that user has. Again, this would carry only a small amount of risk, and the change could be undone quickly and easily. Next, continue adding users a few at a time.  Once confident that there are unlikely to be any issues, move over everyone else who should be assigned to that role. When the opportunity arises, create a second role, and migrate users in the same incremental, low-risk, way. This approach means it will take quite a long time to completely move from the current situation to a well-managed RBAC implementation.  But the one improvement that you can guarantee will never be finished is the one you think it’s too risky to start in the first place.  By starting where you are, keeping it simple, and progressing incrementally, the improvement this company wants will eventually be achieved, with little risk, and without a big project that keeps its two support staff tied up and unavailable for long stretches of time.

Summary

Many organizations use agile software development to reduce risk and speed up time to market. The same ideas apply equally well to ITSM. Almost every ITSM improvement can be carried out in an agile way, and there really is no need for huge, expensive ITSM improvement projects. If you’ve been putting of improvements that you KNOW you need, because of the cost and risk, then why not think about how you can “Start where you are”, “Keep it simple” and “Progress iteratively”?
Continue reading

How to Deliver More Value from Your Help Desk

Posted by on January 10, 2017 in Help Desk
Valuable Help Desk In my previous blog, What’s Essential for an IT Help Desk?, I discussed the things that every help desk should do. These were:
  • Log and manage calls from IT users
  • Resolve incidents
  • Generate useful reports
  • Continually improve
If you’re not already doing all four of these, then please go and read that blog to help you initiate some of the changes you need to make.
If you’re already doing all the essentials, then you might want to think about ways of using your help desk to create more value for you, and for your customers. A great help desk can do a lot more than just the essentials. Here are some things to think about if you’re ready to take the next step.

Identify and Manage Problems

The trouble with excellent incident management is that incidents keep happening. No matter how good you are at managing incidents, and how grateful users are for the service, they still suffer from the disruption to their work and wish they had not needed to call you in the first place; you are using up valuable resources managing something nobody actually wanted to happen. This is where problem management comes in. Problem management can help you to:
  • Stop incidents from happening, or at least make them less frequent.
  • Reduce the impact of any incidents that you can’t prevent.
This means that your users get a better service, and your help desk has less work to do. That’s a win-win for you and your customers. A small help desk could easily be put off by the idea of doing problem management because they may fear it’s too time-consuming or too difficult, but in fact it’s straightforward. If you don’t already do problem management and want to start, just follow these simple steps:
  • Identify some problems. You can do this by looking at your incident records to look for incidents that keep happening, or asking anyone who works on the help desk to log a problem whenever they notice repeat incidents.
  • Pick one or two problems to investigate. You don’t have to investigate every problem that you identify. Start with the ones that happen the most often and the ones that have the biggest impact on the business, because these are the ones that cause the most pain.
  • Fix the problem if you can. The best response to a problem is to identify why it happens and remove the causes.
  • Document a workaround for problems you can’t fix. If you can’t remove the cause of a problem, then think about how you can reduce the impact when it happens again and document this.  Put your plan into action next time the problem occurs, and review what happens, so you can document anything that you need to change, to improve the outcome.
  • Pick some more problems to investigate. You will find that you free up resources each time you fix a problem, and this means that you can start working on some more problems. If you do this consistently, you can create a cycle of continual improvement that is of enormous benefit to you and your customers.

Provide Self-Help

When you provide your users with the information they need to help themselves you can get much faster incident resolution, with less effort and reduced costs.  At a minimum you can simply allow users to log their own incidents via a web interface, and then provide them with status updates via the same channel so they don’t need to keep phoning you. Ideally you should do a lot more than this, by using the same web interface as a channel for providing accurate and accessible information about common issues and how to resolve them. Self-help and problem management can work well together.  You use problem management to identify the common types of incidents and document how to resolve them. Then you provide this information directly to the users, rather than making them phone you to ask for help each time a common incident occurs.

Proactively Communicate with Users

One of the help-desk essentials I described in my previous blog was managing incidents, and this includes providing users with status updates. Users value regular and timely status updates on their incidents, but a proactive help desk can provide much more user communication than this. Examples of good proactive communication that the help desk can provide include:
  • Telling users about new and changed services, to ensure they are properly prepared for them
  • Making sure people know when the service is going to be unavailable for scheduled maintenance or other activities
  • Letting users know that you are aware of and working to resolve any incident that impacts many users before they all phone to tell you that something’s wrong
  • Encouraging users to adopt practices that help protect your valuable information; you can do this by sending routine security reminders
There are lots of different ways that the help desk can communicate with users. For example:
  • Messages displayed on screens when people log on
  • Messages displayed on a self-service portal or service status page that users can review when they need to know what’s happening
  • Announcements over office loudspeaker systems
  • Posters on walls and office doors
I’m sure you can think of many more ways to communicate with your users, but the important thing is to get the balance right. Too much communication can be as bad as too little, as people will eventually stop paying attention. So, make sure you get feedback from your users on how well your communication is working.

Conclusion

This blog has described some of the ways your help desk can help to create value. You do need to ensure that you start with the essentials first, but if you want a great help desk, you should not you limit yourself to that. A great help desk will use problem management to help reduce the number and impact of incidents, it will provide self-help so users can resolve their own incidents, and it will proactively communicate with the users to help keep them informed. How many of these things does your help desk do? I do hope these blogs have given you some ideas of things you could do to provide a better help desk for your customers. Please let me know which things you try, and how well they work out for you.
Continue reading

Back to ITSM Basics: Start Where You Are

Posted by on January 3, 2017 in ITSM
ITSM: Start where you are If you’re involved in ITSM improvements, and especially if you’re fairly new to the field, it’s easy to feel overwhelmed. One thing that can really help you to focus is to follow the principle “Start Where You Are”. It sounds obvious, doesn’t it? Of course you should start where you are. After all, where else could you possibly start? But this principle captures some very important ideas in a really simple phrase, and by following it, you can avoid many of the mistakes that can cause IT service management projects to fail. What “Start Where You Are” really means is don’t throw away everything you already do and start again from zero. If you try to impose a completely new way of working, without building on what’s already in place, you will inevitably waste time, money, and effort. AND you will alienate the very people you need to have on your side. When you tear up everything that people are doing and tell them to start working differently, you’re bound to stir up opposition – and sometimes outright resistance. If you do this, then it can become really difficult to integrate the changes you need into your organization and culture. It’s much better to start by looking at how people currently work and talking to them about it.  If you can engage them, then you can actively involve them in thinking about how to build on what they do now so they can deliver better outcomes in the future. And this means you can focus all your efforts on putting the changes you need into effect, rather than into managing reluctant, resistant, or even hostile staff.

How to Carry Out an ITSM Assessment

I’ve carried out IT service management assessments for many different organizations over the years. These ITSM assessments have usually been a first step in a program to improve how the organization delivers value to its customers. As you can probably guess, I’ve rarely been welcomed with open arms. After all, nobody likes an outside consultant to come in and tell them all the things they’re doing wrong. And yet, this is what people (and organizations) expect consultants to do. My clients expected me to come in and look for the things they were doing wrong, and to write a report listing these things and saying what needs to be changed. But if I did that, I knew that my assessments would be of limited value. They would probably be resisted and might even be ignored, no matter how much the organization had paid for them. Fortunately, I discovered that there was a much better way to approach assessments. I could begin by identifying the things that were being done WELL. Things that are being done well in one part of an organization are great opportunities for improvement across the organization – they can usually be replicated without meeting much resistance. After all, people are copying best practice from their peers, rather than listening to some external consultant. What’s more, when people know that their strengths have been recognized and validated, they are more likely to accept suggestions for improvements in areas where there are weaknesses.

Ask People What Needs Improving

The other thing I discovered was this. If you want to know what isn’t working properly and how to fix it, ask the people doing the job. It’s amazing how many people in an organization know exactly what needs fixing, if only someone would listen to them. I learned that if I took all the ideas from staff working in an organization and combined them with my independent assessment, I could come up with a plan to help deliver better outcomes for customers. AND it was a plan that started where my customer was. So if you’re planning an IT service management improvement project, please don’t throw away all the good things you’re doing. Look to see what you do well and think about how you can start where you are. Best of luck to anyone who’s listening, and if you are planning improvements, drop me a line to let me know how it goes! You can find me on Twitter as @StuartRance. (This blog was originally published as a podcast by Stuart Rance, as part of SysAid’s "Back to ITSM Basics" program.)  
Continue reading

The Case of the Ignored Business Case

Posted by on December 27, 2016 in ITSM
Ignoring the ITSM business case “What advice do you have when your business case for ITSM is created but ignored?” This is what @sysaid tweeted to me in reply to my tweet regarding my blog The Case of the Missing Business Case. https://twitter.com/sysaid/status/803235463532265473 What a great question! As I talk about in my original blog, every IT service management (ITSM) implementation should begin with the development of a business case. The business case provides IT with an opportunity to demonstrate its understanding of the business it serves by objectively discussing the opportunities, risks, benefits, and deliverables of the ITSM implementation – in business terms. A well-written business case articulates the needed investments, in terms of people, time, and money, as well as how ITSM implementation supports business goals and objectives. It helps make the ITSM implementation a business initiative, enabled by IT, and not just another “IT project.” But most importantly, the business case secures the first critical deliverables for any ITSM initiative – senior management investment and support.

”Yes, I did all of that, but…”

You wrote a strong business case. You addressed all of the pertinent topics.  And your business case gets ignored. Now what? Has all of the time developing and writing the business case been for naught? Don’t give up just yet. Here’s 7 things you could try. First, check yourself. Objectively review your business case from the perspective of senior management. Are your assumptions reasonable? Have you clearly articulated resource needs and anticipated benefits. Is the business argument strong enough? Have you demonstrated that you will be a good steward of the company’s funds? Engage your sponsor. If you identified a sponsor in your business case, get that person involved. Ask for guidance and support for gaining approval of the initiative. Engage key stakeholders. Identify and meet with key stakeholders. Discuss how ITSM can help alleviate pain points or enhance performance for their specific issues. Not only will you build relationships, you may even learn some things that may further strengthen your business case. Gain their support and ask them to advocate for your proposal. Publicize (really publicize) goals and measures. Assuming you have the ability to collect some of the measures regarding the goals defined in the business case, start publicizing them. Post goals and current measures on an intranet page, outside your cubicle or office, in the break area – anywhere where people will see. Explain how not meeting these goals is impacting the organization and how ITSM would help. In the words of Dr. John Kotter, you want to “establish a sense of urgency.” Using measures helps build credibility and a sense of urgency for the business case. Conduct an experiment. Can you “try out” a small part of the ITSM implementation? Take a current data sample to do a tabletop exercise to confirm assumptions or anticipated benefits of the implementation. Then, share the results with your sponsor and your key stakeholders to further enable their advocacy for the ITSM initiative. Execute the communication plan. As part of the business case, you most likely developed a high-level communication plan regarding the initiative. Execute it! Look for opportunities to talk up the benefits and risks that you described in the business case. Go to staff meetings; do a roadshow; publish an article on your corporate intranet site or newsletter. The goal is to attract attention and gain grass-roots support for the ITSM implementation. Sometimes the timing just isn’t right. Keep in mind that due to business influences beyond your control, sometimes even the best-written business cases aren’t immediately approved. Don’t take it personally. It doesn’t mean that the ITSM initiative wasn’t a good idea; perhaps there are other business priorities that must be addressed first. If you find yourself in such a situation, use it as a learning opportunity and ask for feedback from those senior managers who reviewed the business case. Doing so demonstrates that you care and are committed to the success of the business. Good ideas are good ideas – and including feedback from senior managers in the next version of the business case will make for a stronger business case!

Persistence Pays Off

I once had a former manager tell me “if you don’t believe in your story, then you can’t expect anyone else to either.” You’ve built a good business case.  Win hearts and minds through positive persistence – it will pay off!
Continue reading

Machine Learning – the Next Big Thing for ITSM in 2017

Posted by on December 20, 2016 in General IT
Machine Learning for ITSM As 2016 ends and we look forward to another year in IT service management (ITSM), one wonders what we (ITSM pros) should be focused on in the next twelve months. There’s been a lot of buzz this year about things such as  DevOps, enterprise service management, customer experience and consumerization, and digital transformation. But I think there’s a wealth of opportunities for us and the businesses we serve in another area – automation. Not the process automation that we’ve benefited from since the early days of ITSM tools, or the orchestration that has made virtualization and cloud so much easier. I’m instead referring to a different type of automation, where we “cede power to the machines” and their ability to learn, i.e. machine learning“the study and construction of algorithms that can learn from and make predictions on data” (source: Wikipedia), where: “Advanced machine learning algorithms are composed of many technologies (such as deep learning, neural networks and natural-language processing), used in unsupervised and supervised learning, that operate guided by lessons from existing information.” Source: Gartner IT Glossary And Gartner recently stated that: “Smart machines will enter mainstream adoption by 2021, with 30 percent adoption by large companies, according to Gartner, Inc. Technologies including cognitive computing, artificial intelligence (AI), intelligent automation, machine learning and deep learning fall under the umbrella term for smart machines.)” But I’m far more bullish about machine learning from an ITSM and IT support (or for any service and support scenario) perspective, as many opportunities, and possible solutions, to use machine learning in our everyday activities already exist. And I think we will quickly see ITSM tool vendors partnering with machine learning technology partners to deliver against them.

ITSM Is Full of Opportunities for Machine Learning

ITSM pros have spent much of the last two decades optimizing IT service delivery and support in the enablement of business operations. Different operational elements have been addressed – from the adoption of best practice processes, the recruitment and training of the “right kind of people,” to the exploitation of technology (in particular workflow and automation, knowledge management, remote control, self-service, and more recently business intelligence). Much of this has been done to improve efficiency and effectiveness – it’s what we seem to do in ITSM. But we still often place too much reliance on human effort, and human intellect, when we could cede the power – okay, some specific tasks – to the machines. For example, tasks where algorithms can be used to understand patterns and context to decide the best course of action without human input. The results and benefits being similar to the use of our existing orchestration-type automation:
  • Greater speed/efficiency – machines can be quicker than the smartest of humans. They also work 24/7 including all public holidays.
  • Reduced costs – people costs are still a large part of the overall IT department budget and, while technology isn’t necessarily cheap, the cost of automation should be more than covered by people-cost savings.
  • Better people utilization – it’s as simple as freeing up time-poor staff from repetitive (and potentially mundane) tasks to allow them to focus on the more important things.
  • Reduction in human error – people make mistakes and it doesn’t matter if they are inexperienced, rushing, or tired – these mistakes might have an adverse business impact. Automation makes far fewer mistakes, with these usually still people related.
  • Greater ability to change – quickly changing ways of working, or even just responses to simple questions, can be problematic for people as they unconsciously flit between old and new for a while. Automation, on the other hand, just stops the old way and starts the new way.
  • Better customer experience – while automation is often seen as a boon for the service provider, it also extends its benefits to the service receivers – whether it be speedier delivery, the passing on of cost reductions, greater probability of service delivery, or better support and customer service when things do go wrong.
A new AXELOS survey and report, “The ITSM Professional in 2030: A future full of opportunities” (January 2017), also shows that most ITSM professionals are already betting on automation and machine learning:
  • Automation – 89% of respondents “think that an increase in automation will take over the repetitive tasks of IT, creating more time for service managers to focus on delivering more value to their organizations.”
  • AI/machine learning – 77% of respondents “said they believed these trends would have a profound impact on the IT workforce, liberating ITSM professionals from routine tasks and free up time for responding to demands for more creativity and ‘human’ input.”
So where can machine learning help?

Five Examples of Machine Learning Use Cases in ITSM

These are all things that can be done or used now:
  1. Identifying and predicting issues and problems. The technology can also offer up the most likely resolutions. It will reduce mean time to resolution (MTTR) and opens the door for predictive maintenance (and less reactive fixing).
  2. Better understanding the risks of proposed changes. Not only understanding what will be impacted but what the likely impact will be.
  3. Predicting what’s needed or even what will happen. From demand and capacity planning to understanding the future levels of customer satisfaction based on what’s happening or planned.
  4. Greater access to information and known solutions. Machine learning improves search accuracy, with data-based recommendation capabilities similar to what people already get in their personal lives from companies such as Amazon and Netflix.
  5. Easier and better knowledge management. The last two decades have shown that people aren’t great at knowledge management – or the knowledge article creation part of it at least. Machine learning can be employed to both identify “missing” articles gaps and to create new articles automatically from existing tickets, i.e. the already documented resolutions.
So what do you think of the possibility of machine learning becoming a staple of ITSM? Or are you already using it? I’d love to get your feedback in the comments section below.
Continue reading
Page: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 Next
Watch & learn from industry experts about ITSM and help desk hot topics!