Posted by Stuart Rance
on March 7, 2017 in ITSM
If I asked you how your organization does problem management, would you, like so many of the people I have worked with over the years, tell me that you don’t do it? You know you ought to, of course, but you simply don’t have the time and resources to get started.
I’m willing to bet that if you’re one of those people, and you asked me to take a close look at the running of your IT operation, you’d be surprised. Because, quite often, when I look at what people who work in IT organizations actually do, as opposed to listening to what they tell me they do, I find that they’re already quietly getting on with many of the things that need to be done to manage problems. They just don’t call what they do problem management. Too often people believe that problem management is something formal and complex that can’t be put in place without specialized tools and extensive training. And so they fail to recognize the power – or the potential – of the steps they’ve already put in place.
I’m always really pleased when I come across a situation like this, because it’s a great position for an organization to be in. It only takes a very small amount of effort to create an effective problem management capability when you’re building on what’s already being done. (See my blog Back to ITSM Basics: Start Where You Are
for some more thoughts on this idea.)
So what should you look for if you want to know whether or not your IT organization already has in place the foundation it needs to build an effective problem management capability? Where do you start?
Well, you start by understanding the difference between managing incidents – which any IT organization must do routinely – and managing problems.
What’s the Difference Between Incident Management and Problem Management?
In case you aren’t familiar with the difference between incidents and problems here’s a brief summary.
An incident is “An unplanned interruption to an IT service or reduction in the quality of an IT service”
Most incidents are detected by users who phone the service desk to report that something is wrong. The purpose of incident management is to get the business working again, and to reduce the overall impact of the incident as far as possible. For example, if a user reports that a printer isn’t working, then you could resolve the incident by routing their printout to another nearby printer so that they can get the document they need.
Incident management activities include:
- Identifying, categorizing, logging, and prioritizing incidents
- Diagnosis and escalation (where needed)
- Incident resolution and closure
- Ensuring that users are kept informed about status
- Managing the lifecycle of incidents and ensuring that SLA targets are met
For more information, see ITSM Basics: A Simple Introduction to Incident Management
A problem is “The cause of one or more incidents”
The purpose of problem management is to prevent incidents from happening and to minimize the impact of incidents that can’t be prevented. For example, you could identify that a particular model of printer tends to fail after two years of use and plan to replace these printers before they fail. This would completely prevent the associated incidents. Alternatively, you could order a stock of spare printers so that you can replace them very quickly when they do fail, which would minimize the impact of the failures when they occur.
Problem management activities include:
- Analyzing incident trends to identify problems that should be investigated
- Reviewing information from other sources, such as vendors or development teams, to identify problems that need to be managed
- Investigating problems to identify what is causing the incidents
- Developing and testing workarounds that can help to minimize the impact of future incidents
- Identifying remedial actions that can prevent future incidents
For more information, see ITSM Basics: A Simple Introduction to Problem Management
Hidden Problem Management
I started this blog by saying that many IT organizations are actually doing some problem management, even if they claim not to be. Here are some examples of things that I have seen in place:
- A major incident review being held after every major incident, where everybody involved helps to understand:
- What caused the incident
- What can be done to prevent future similar incidents
- What can be done to minimize the impact if the same thing happens again
This then results in improvement activities.
- Technical support teams keeping up to date with information from vendors, identifying patches that need to be installed, and other proactive actions that can be taken to help prevent future incidents.
- A service desk manager identifying frequent incidents, and reporting them to vendors or technical support teams for investigation.
- A service desk agent developing a workaround for an incident and discussing it with co-workers, so it can be used whenever similar issues arise.
I have no doubt that there are many other examples of hidden problem management taking place. So, if you “don’t do problem management
” why not take a close look at your organization and see what you discover?
Building an Effective Problem Management Capability
If you know you should be doing problem management, but keep putting it off because you think that it would involve too much effort and expense, then you should think about using three of the ITIL Practitioner guiding principles
to help you get started: Observe Directly
, Start Where You Are
, and Progress Iteratively
- Observe Directly – Go and talk to people who work on the service desk, and in technical support teams. Make sure you know and understand what they are already doing. Identify the things that help your organization manage problems – there will almost certainly be some, if you look for them.
- Start Where You Are – Think about how you could build on the things that people are already doing. If there really is nothing, introduce something, however small, making sure it’s straightforward but capable of producing useful results. But it’s more than likely that there will be a lot of good practice around, once you go looking for it. Start measuring and reporting the good practice that already exists; share best practice between teams; gradually increase the scope of the work that is already being done.
- Progress Iteratively – Make small improvements, and measure how effective they are. Build on the ones that work well, and modify the ones that work less well. Then do it again.
If you follow these guiding principles you should find that you’re building an effective problem management capability at a very low cost and with minimum effort. And 2017 could be the year your increasingly proactive approach results in better service and happier customers. You can’t ask for better than that, can you? So why not give it a try?
Posted by Doug Tedder
on February 21, 2017 in Service Desk
Categorization is a critical aspect of many IT service management (ITSM)
processes. Categorization helps us:
- Route work associated with an incident or a request
- Produce effective management reporting that enables further analysis or process improvements
- Translate what a consumer is telling us into something that IT can understand and do something about
There’s a lot of good advice about categorization that is readily available via an internet search. A couple of great articles can be found right here on the SysAid blog. Stuart Rance
shared his thoughts about categorization in his post titled Improving Categorizing Incidents
. Another SysAid blog post, Incident Categorization – Reasons and Consequences
, discusses the benefits of a good categorization scheme and the consequences of poor categorization.
But how do you go about defining your categorization scheme? I have some ideas about categorization that I’d like you to consider.
Good Categorization Is About Balance
The most important thing to understand about categorization is that it is all about balance. If a categorization scheme is too simple, it will inhibit work flow and trend analysis. The categories will simply be too broad or vague to facilitate effective process execution or continual improvement.
The other end of the spectrum is a categorization scheme that is overly complex. While further definition may help with more precise workflow and analysis, this comes at a cost – the up-front time it would take a service desk agent to determine the exact category of an incident or request. While good documentation may mitigate this risk, keep in mind that a primary objective of a service desk is to complete its tasks in a timely manner. Service desk agents don’t necessarily have time to read through a lengthy procedure while the consumer is on the other side of a telephone call or chat session.
Also, categories can and should change over time. As services are introduced or retired from the managed environment, there will be impact to a categorization scheme. A good categorization approach recognizes that, and should strike a balance between the need for consistency for managing day-to-day activities with the flexibility needed when services do change.
Common Categorization Mistakes
Unfortunately, many organizations don’t take the need for balance into consideration when defining their categorization schemes. They often don’t think about how they want to leverage their categorization schemes in terms of workflow routing, reporting, or identifying improvements. As a result, I’ve seen them make the following mistakes:
- Define categories based on the organizational chart
This might work, and seem very straight-forward…until the organization chart changes.
- Top level categories are “too technical”
Generally speaking, the consumer has no knowledge of the underpinning technologies that are used in delivering service, and are unable to articulate an issue in technical terms. As a result, the service desk has to translate (read: guess) from the business-reported symptom to the technical taxonomy.
- Too many top-level entries or a scheme that is “too deep”
I once worked with a client that had a six-level deep categorization scheme. I’ve seen clients that had dozens of top-level entries in their categorization scheme. If there are too many entries (keep in mind that “too many” for one organization may or may not be too many for another organization), handle times for logging an incident will become needlessly excessive.
- Assuming that the consumer “knows” the categorization scheme
Yes, it may make absolute sense to the IT organization, but how (or even why) will the consumer know about the categorization scheme? The consumer has no idea how the scheme is defined, how the scheme is intended to be used, or even the cause of their issue so that it can be properly categorized within an IT-centric scheme.
- Using “other” or “miscellaneous” as a category
Frankly, this is laziness! If these categories are defined, they will (and do) inevitably become a dumping ground, nullifying the reasons for categorization to begin with!
Another Way of Looking at It
Consider this – what is the trigger for categorization? How an incident is categorized is essentially based on what the consumer has said
So why not take a consumer-centric approach to categorization?
In my experience, most categorization schemes have been defined following an “inside-out” approach. The scheme is defined based on the IT organization’s processes and services, and is pushed from “inside” IT “out” to the consumer. So why not look at it from the consumer’s perspective? Looking at this from the “outside,” or consumer’s perspective, what should the consumer’s experience be? This is known as “outside-in” thinking
So rather than trying to categorize incidents by “hardware” or “software” or “network” (all IT-ish ways of looking at an incident), why not categorize based on the consumer’s perspective? This might look something like “can’t print,” “error message,” “not working or slow,” or “need help.” From this top level, the service desk agent can then drill into the issue to identify further symptoms that will assist in determining how to manage the issue. Following this approach essentially defines the roadmap for helping the service desk agent categorize the issue; for example, “not working > intranet > broken link” or “need information > software > excel”.
Advantages of an Outside-In Approach
Here’s a few advantages of taking an outside-in approach to categorization:
- It improves the customer experience – service desk agents can have a conversation (rather than follow a script) with the consumer to manage the incident.
- Strikes the right balance – it allows for the needed flexibility (changes in offered services can be easily added or removed at a sublevel), while having consistency at the top level.
- Removes the ‘tech speak’ from categorization – consumers need not be intimated by a call to the service desk, as the service desk will be enabled to speak and use terms that the consumer understands.
Taking an outside-in approach to categorization may seem awkward at first. But by taking this approach, both the consumer and the service provider will benefit by facilitating a good customer experience (and for more on that, I highly recommend you read Sarah Lahav
’s blog Bridging the Gap Between Service and Customer Experience
Posted by Stephen Mann
on February 21, 2017 in Help Desk
There are a number of reasons why email and other personal productivity tools are used for IT support, for example:
- Most IT staff usually have access to email
- IT staff know how to use email
- 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"]
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.”
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.
Posted by Dena Wieder-Freiden
on February 14, 2017 in Help Desk
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
, 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"] Source: HDI 2015 Support Center Practices & Salary Report
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.
, 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"] Source: AXELOS ITIL Glossary of Terms
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”
Posted by Stuart Rance
on February 7, 2017 in General IT
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.
Posted by Stuart Rance
on January 31, 2017 in ITIL
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.
- 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
(This blog was originally published as a podcast by Stuart Rance, as part of SysAid’s "Back to ITSM Basics" program.)
Posted by Dena Wieder-Freiden
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.
Posted by Stuart Rance
on January 17, 2017 in ITSM
I visited two very different customers recently. They had very different problems and the solutions I suggested for them were also very different. But there was one thing that they had in common — they had both delayed starting the improvements they knew were needed because the costs and risks were too high. Instead, they had done nothing and so allowed their problems to continue completely unchecked.
For both these customers, the solution was very similar. Both needed to “Start where you are”, “Keep it simple” and “Progress iteratively”. These are three of the guiding principles from ITIL Practitioner, and between them they encourage IT service managers to adopt an agile approach to resolving issues, rather than taking on big, risky, expensive IT service management (ITSM) projects. I created a few podcasts on these topics for SysAid’s Back to ITSM Basics
project, so please do listen to those if you are interested.
If you also need improvements that seem too expensive, or too risky, then read on to learn how you can get started.
A Big Organization with a Big Problem
One of the organizations that I visited is very large. It provides support services to many external customers all over the world, and has lots of service desks. Some of these service desks are dedicated to a single customer, others support multiple customers, and some are for internal users. Some of them provide logging and dispatch only, others provide level 1 support as well. While many of the service desks use the same ITSM tool for logging and managing incidents, there are quite a few other tools in place as well.
Almost all of the customer communication, for all the different service desks, takes place by phone. The organization would like to shift to more efficient channels, e.g. text-based chat and a self-service
web portal, but because the company is so big, the implementation costs would be enormous. IT has, in fact, identified a tool that could provide chat for all of their complex environment, but since they can’t be confident that an implementation project would run smoothly or that the returns would justify such a big investment, they can’t get the funding for this.
As I talked to the IT department, the solution to their problem became obvious. Instead of trying to implement chat for all of their users, which would be a very big and expensive project, they could start where they are, start small, and grow in small steps.
The organization’s users already have a tool that supports chat, although it is not currently used for IT support. So it would be quite easy for IT to start there.
Here’s what they can do:
Find a small group of users and offer to use this existing tool to provide them with IT support. Monitor carefully to reveal any issues for the service desk or the users, and resolve them before scaling up to support more internal users. Eventually the IT department will reach the limits of how well this tool can scale in their environment, but by then they will have:
- Identified and resolved many issues relating to how the service desk works when handling chat-based interactions
- Understood which types of incident are best handled by chat, and which are better managed using phone or other channels
- Discovered what communication and support works best to encourage users to migrate from phone to chat
- Collected data about how many calls each service desk agent can manage using chat, and how much this could save if scaled up to the whole organization
This gradual implementation of chat would be very low risk, and, by starting with a tool that is already in use and familiar, would not involve much cost. By the time the IT department has scaled up to supporting a large number of internal users they will know whether a full implementation using an expensive tool will be a cost-effective investment, and they will also have learned what needs to be done to ensure success. If they wish to go ahead with an expensive new tool, this will give them everything they need to create a business case for the next stage.
A Small Organization with a Security Problem
The other organization that I visited is MUCH smaller. They have just two staff working on their in-house service desk, supported by a manager who carries out other roles as well. They have a few thousand users in a small number of offices, all in a small part of one country. They are finding it difficult to manage user access controls.
When a new user joins the organization, they ask about what access this user needs, and then grant individual rights to the specific applications and data. When people change jobs or leave the organization, it’s difficult to find all the access rights that have been granted, so these are often left in place – and this creates a significant security risk.
The support manager knew that the solution to their issue was to move to role-based access controls (RBAC), where all access rights are granted to roles, and then those roles are assigned to users. But there had been no attempt to migrate to RBAC because of the risks involved. Sometimes things go wrong during even the best planned migrations, and this could cause significant cost and risk to the business.
The solution for this customer was also to take an agile approach. Instead of attempting to change everything at the same time, the organization could start where it is, keep it simple, and do it a bit at a time.
Here’s what they can do:
Next time a new employee joins the company, grant all the rights that user needs to a newly created role, and then assign this role to the new user. This should be no more work and no more risk than would normally be involved in providing appropriate access to a new user. Once confident that the role works well, and that no changes are needed, go on to migrate one existing user to the role, removing the current rights that user has. Again, this would carry only a small amount of risk, and the change could be undone quickly and easily. Next, continue adding users a few at a time. Once confident that there are unlikely to be any issues, move over everyone else who should be assigned to that role. When the opportunity arises, create a second role, and migrate users in the same incremental, low-risk, way.
This approach means it will take quite a long time to completely move from the current situation to a well-managed RBAC implementation. But the one improvement that you can guarantee will never be finished is the one you think it’s too risky to start in the first place. By starting where you are, keeping it simple, and progressing incrementally, the improvement this company wants will eventually be achieved, with little risk, and without a big project that keeps its two support staff tied up and unavailable for long stretches of time.
Many organizations use agile software development to reduce risk and speed up time to market. The same ideas apply equally well to ITSM
. Almost every ITSM improvement can be carried out in an agile way, and there really is no need for huge, expensive ITSM improvement projects.
If you’ve been putting of improvements that you KNOW you need, because of the cost and risk, then why not think about how you can “Start where you are”, “Keep it simple” and “Progress iteratively”?
Posted by Sarah Lahav
on January 10, 2017 in Help Desk
In my previous blog, What’s Essential for an IT Help Desk?,
I discussed the things that every help desk should do. These were:
- Log and manage calls from IT users
- Resolve incidents
- Generate useful reports
- Continually improve
If you’re not already doing all four of these, then please go and read that blog to help you initiate some of the changes you need to make.
If you’re already doing all the essentials, then you might want to think about ways of using your help desk
to create more
value for you, and for your customers. A great help desk can do a lot more than just the essentials. Here are some things to think about if you’re ready to take the next step.
Identify and Manage Problems
The trouble with excellent incident management
is that incidents keep happening. No matter how good you are at managing incidents, and how grateful users are for the service, they still suffer from the disruption to their work and wish they had not needed to call you in the first place; you are using up valuable resources managing something nobody actually wanted to happen.
This is where problem management
comes in. Problem management can help you to:
- Stop incidents from happening, or at least make them less frequent.
- Reduce the impact of any incidents that you can’t prevent.
This means that your users get a better service, and your help desk has less work to do. That’s a win-win for you and your customers.
A small help desk could easily be put off by the idea of doing problem management because they may fear it’s too time-consuming or too difficult, but in fact it’s straightforward. If you don’t already do problem management and want to start, just follow these simple steps:
- Identify some problems. You can do this by looking at your incident records to look for incidents that keep happening, or asking anyone who works on the help desk to log a problem whenever they notice repeat incidents.
- Pick one or two problems to investigate. You don’t have to investigate every problem that you identify. Start with the ones that happen the most often and the ones that have the biggest impact on the business, because these are the ones that cause the most pain.
- Fix the problem if you can. The best response to a problem is to identify why it happens and remove the causes.
- Document a workaround for problems you can’t fix. If you can’t remove the cause of a problem, then think about how you can reduce the impact when it happens again and document this. Put your plan into action next time the problem occurs, and review what happens, so you can document anything that you need to change, to improve the outcome.
- Pick some more problems to investigate. You will find that you free up resources each time you fix a problem, and this means that you can start working on some more problems. If you do this consistently, you can create a cycle of continual improvement that is of enormous benefit to you and your customers.
When you provide your users with the information they need to help themselves you can get much faster incident resolution, with less effort and reduced costs. At a minimum you can simply allow users to log their own incidents via a web interface, and then provide them with status updates via the same channel so they don’t need to keep phoning you. Ideally you should do a lot more than this, by using the same web interface as a channel for providing accurate and accessible information about common issues and how to resolve them.
and problem management can work well together. You use problem management to identify the common types of incidents and document how to resolve them. Then you provide this information directly to the users, rather than making them phone you to ask for help each time a common incident occurs.
Proactively Communicate with Users
One of the help-desk essentials I described in my previous blog
was managing incidents, and this includes providing users with status updates. Users value regular and timely status updates on their incidents, but a proactive help desk can provide much more user communication than this. Examples of good proactive communication that the help desk can provide include:
- Telling users about new and changed services, to ensure they are properly prepared for them
- Making sure people know when the service is going to be unavailable for scheduled maintenance or other activities
- Letting users know that you are aware of and working to resolve any incident that impacts many users before they all phone to tell you that something’s wrong
- Encouraging users to adopt practices that help protect your valuable information; you can do this by sending routine security reminders
There are lots of different ways that the help desk can communicate with users. For example:
- Messages displayed on screens when people log on
- Messages displayed on a self-service portal or service status page that users can review when they need to know what’s happening
- Announcements over office loudspeaker systems
- Posters on walls and office doors
I’m sure you can think of many more ways to communicate with your users, but the important thing is to get the balance right. Too much communication can be as bad as too little, as people will eventually stop paying attention. So, make sure you get feedback from your users on how well your communication is working.
This blog has described some of the ways your help desk can help to create value. You do need to ensure that you start with the essentials first, but if you want a great help desk, you should not you limit yourself to that.
A great help desk will use problem management to help reduce the number and impact of incidents, it will provide self-help so users can resolve their own incidents, and it will proactively communicate with the users to help keep them informed. How many of these things does your help desk do?
I do hope these blogs have given you some ideas of things you could do to provide a better help desk for your customers. Please let me know which things you try, and how well they work out for you.
Posted by Stuart Rance
on January 3, 2017 in ITSM
If you’re involved in ITSM improvements
, and especially if you’re fairly new to the field, it’s easy to feel overwhelmed. One thing that can really help you to focus is to follow the principle “Start Where You Are”.
It sounds obvious, doesn’t it? Of course you should start where you are. After all, where else could you possibly start? But this principle captures some very important ideas in a really simple phrase, and by following it, you can avoid many of the mistakes that can cause IT service management projects to fail.
What “Start Where You Are” really means is don’t throw away everything you already do and start again from zero. If you try to impose a completely new way of working, without building on what’s already in place, you will inevitably waste time, money, and effort. AND you will alienate the very people you need to have on your side. When you tear up everything that people are doing and tell them to start working differently, you’re bound to stir up opposition – and sometimes outright resistance. If you do this, then it can become really difficult to integrate the changes you need into your organization and culture.
It’s much better to start by looking at how people currently work and talking to them about it. If you can engage them, then you can actively involve them in thinking about how to build on what they do now so they can deliver better outcomes in the future. And this means you can focus all your efforts on putting the changes you need into effect, rather than into managing reluctant, resistant, or even hostile staff.
How to Carry Out an ITSM Assessment
I’ve carried out IT service management assessments for many different organizations over the years. These ITSM assessments have usually been a first step in a program to improve how the organization delivers value to its customers. As you can probably guess, I’ve rarely been welcomed with open arms. After all, nobody likes an outside consultant to come in and tell them all the things they’re doing wrong. And yet, this is what people (and organizations) expect consultants to do. My clients expected me to come in and look for the things they were doing wrong, and to write a report listing these things and saying what needs to be changed. But if I did that, I knew that my assessments would be of limited value. They would probably be resisted and might even be ignored, no matter how much the organization had paid for them.
Fortunately, I discovered that there was a much better way to approach assessments. I could begin by identifying the things that were being done WELL. Things that are being done well in one part of an organization are great opportunities for improvement across the organization – they can usually be replicated without meeting much resistance. After all, people are copying best practice from their peers, rather than listening to some external consultant. What’s more, when people know that their strengths have been recognized and validated, they are more likely to accept suggestions for improvements in areas where there are weaknesses.
Ask People What Needs Improving
The other thing I discovered was this. If you want to know what isn’t working properly and how to fix it, ask the people doing the job. It’s amazing how many people in an organization know exactly what needs fixing, if only someone would listen to them.
I learned that if I took all the ideas from staff working in an organization and combined them with my independent assessment, I could come up with a plan to help deliver better outcomes for customers. AND it was a plan that started where my customer was.
So if you’re planning an IT service management improvement project, please don’t throw away all the good things you’re doing. Look to see what you do well and think about how you can start where you are.
Best of luck to anyone who’s listening, and if you are planning improvements, drop me a line to let me know how it goes! You can find me on Twitter as @StuartRance
(This blog was originally published as a podcast by Stuart Rance, as part of SysAid’s "Back to ITSM Basics" program.)