Posted by Joe The IT Guy
on September 24, 2015 in ITSM
If you read my blog
regularly you’ll know that I’ve already written simple introduction blogs related to:
Now it’s change management’s turn.
To misquote Amazing Fantasy
#15 – the first Spider-Man comic ever! – “with IT change, comes great responsibility!” (The original comic quote was: “...with great power there must also come -- great responsibility!”
if you’re interested).
The need for change, IT or otherwise, is an unavoidable part of modern business life, whether that change is:
- Reactive – aimed at resolving errors or to adapt to changing business or IT requirements, or
- Proactive – which could be to provide new products, services or functions; to reduce costs or to increase efficiency; or to increase performance or operational effectiveness
Change management, put in simple terms, is ensuring that such changes are managed and implemented in an optimal manner and with a sufficient level of control. So it’s a process, or collection of discrete activities, that allow organizations to consider, agree, and deploy changes to their IT ecosystem as easily, quickly, and cheaply as possible while effectively managing risk…more on this later.
So to give you an introduction to change management, I’ll briefly cover:
- Where change management fits in
- The objectives of change management
- ITIL definitions of change management
- The “change lifecycle”
- The benefits of change management
I refer to ITIL – the IT service management (ITSM) best practice framework formerly known as the IT Infrastructure Library – a fair bit (you might think too much) but you can quite easily use your own self-created change management process and activities, or look to alternative sources of ITSM and IT management advice such as ISO/IEC 20000
, ISACA’s COBIT
, Microsoft’s MOF
, or even a combination of a few
Where Change Management Fits In
Change – especially uncontrolled or poorly managed IT change – has associated risks, which can potentially result in either business-affecting incidents or problems. In fact, it’s not unusual for service desk personnel to cite poorly-delivered change as a major cause of incidents, even major incidents.
Plus the lack of effective change management, or the inability to demonstrate the right change controls, can be a major stumbling point in both internal and external compliance audits. Some common compliance concerns include the answers to questions such as:
- Is there adequate separation of duties between the key roles in the change management process?
- Are change requests approved and prioritized by appropriate personnel, including service owners?
- Is change impact thoroughly assessed?
- Are there detailed audit trails for all changes?
- Is there a process for tracking the progress of critical changes?
Thus, change management has a very serious purpose, to:
- Optimize, so not necessarily to minimize, IT and business risk exposure associated with the change (given that some risks might be accepted and managed accordingly)
- Minimize the severity of any impact or disruption brought about by the change
- Ensure the change is delivered first time and without the need for rollback and/or rework
- Provide business stakeholders with appropriate and timely communication about the change
Finally, change management is a commonly adopted ITIL process, usually second behind incident management
in terms of frequency. It’s also an early-adopted ITIL process, either paired with incident management or configuration management.
Change Management Definitions
It’s time for me to get all ITIL
on you as we look at what change management is!
ITIL uses the term “change” to describe:
“The addition, modification, or removal of anything that could have an effect on IT services.”
Where change management is:
“The process that ensures that standardized methods and procedures are used for the efficient and prompt handling of all changes, in order to minimize the adverse impact of any changes on IT services and business operation.”
So that’s sort of what I said earlier but said in a much fancier way.
Other common change-related ITIL-definitions include:
- Request for change (RFC) – “A formal proposal for a change to be made. It includes details of the proposed change, and may be recorded on paper or electronically. The term is often misused to mean a change record, or the change itself.”
- Change advisory board (CAB) – “A group of people that support the assessment, prioritization, authorization and scheduling of changes. A change advisory board is usually made up of representatives from: all areas within the IT service provider; the business; and third parties such as suppliers.”
For completeness, although I state my own benefits
below, ITIL states that the value of change management includes:
- “Protecting the business, and other services, while making required changes
- Implementing changes that meet the customers’ agreed service requirements while optimizing costs
- Contributing to meet governance, legal, contractual, and regulatory requirements by providing auditable evidence of change management activity. This includes better alignment with IISO/IEC 20000, ISO/IEC 38500 and COBIT where these have been adopted
- Reducing failed changes and therefore service disruption, defects, and re-work
- Reducing the number of unauthorized changes, leading to reduced service disruption and reduced time to resolve change-related incidents
- Delivering change promptly to meet business timescales
- Tracking changes through the service lifecycle and to the assets of its customers
- Contributing to better estimates of the quality, time and cost of change
- Assessing the risks associated with the transition of services (introduction or disposal)
- Improving productivity of staff by minimizing disruptions caused by high levels of unplanned or ‘emergency’ change and hence maximizing service availability
- Reducing the mean time to restore service (MTRS), via quicker and more successful implementations of corrective changes
- Liaising with the business change process to identify opportunities for business improvement.”
What this means is that change management is really all about knowing what needs to change and why, approving and prioritizing the changes, and then ensuring that changes are deployed with risk optimally managed.
Change Management Objectives
ITIL defines the objectives of the change management process as:
- “Responding to the customer’s changing business requirements while maximizing value and reducing incidents, disruption, and re-work.
- Responding to the business and IT requests for change that will align the services with the business needs.
- Ensuring that changes are recorded and evaluated, and that authorized changes are prioritized, planned, tested, implemented, documented and reviewed in a controlled manner.
- Ensuring that all changes to configuration items are recorded in the configuration management system.
- Optimizing overall business risk – it is often correct to minimize business risk, but sometimes it is appropriate to knowingly accept a risk because of the potential benefit.”
So, in practice, this could mean:
- Ensuring that new modules, or new functions within an existing business system, are delivered in a manner that doesn’t disrupt business operations. This could be at the point the new modules, or functions, are released or in the ongoing use of the changed application, i.e. the whole system might no longer work as it should post change.
- A change to resolve a major incident, i.e. an IT issue that is having a significant and adverse impact on business operations. This would normally be termed an emergency change.
- A change to address a business-affecting issue, for example a change in industry legislation might require business processes, or data collection, to change and thus the supporting IT needs to be changed to reflect it. This might need to be undertaken as an expedited change if the planning and lead-time is insufficient.
My simple diagram (OK I admit that it’s not that simple) hopefully provides a snapshot of what can happen with change management.
Change Management Benefits
A formal change management process should address many of the common issues encountered with uncontrolled change, such as:
- Change-related incidents
- Unauthorized changes (and their potential unwanted impact)
- Change scheduling conflicts
- Rush jobs to deploy changes
- The unexpected and unwanted side-effects of deployed changes
- The inability to back out or rollback failed changes
- Rush jobs to deploy fixes
- A lack of cross business input in assessing change impact or change priority
- The absence of appropriate approvals and audit trails
- Lack of change awareness, especially at the IT service desk
Thus the main benefits of formal change management include, but are not limited to, the following areas.
The financial benefits associated with minimizing change-related incidents and problems, such as a reduction in the:
Improved change visibility, control, and sometimes speed of change through the:
- Business costs associated with business-critical service downtime (when caused by changes)
- IT costs of dealing with change-related incidents and problems, from the service desk through to technical domain experts
- IT costs of backing out failed changes or deploying change fixes (including on-the-fly code fixing) – often paid overtime
- Business cost of delays to important or mandated changes
Better collaboration – the business-wide collaboration benefits include:
- Communication of the schedule of changes
- Use of a stage-gate approach to change approval
- Prioritization and fast tracking of changes, for example: the use of change models and having to deal with expedited or emergency changes at speed
Better use of potentially scarce IT resources, including:
- Better cross-functional risk and impact assessment
- Improved change prioritization and scheduling between competing needs
- The idea that defined roles and responsibilities, along with a single, consistent process, not only speed things up but also reduce the need for rework, duplication of effort, and wastage
- The ability to leverage existing knowledge, through effective knowledge management, to speed up change
Plus, of course, the usual goal for, and benefit of, ITSM: Better IT services, and improving customer service and the business’s perceptions of the IT organization as a whole.
Well there you have it, a quick guide and a simple introduction to change management. Hopefully you found it helpful.
If you want to read more from me, and few of my friends, on change management then please look at:
Posted by Oded Moshe
on September 17, 2015 in ITIL
Everyone loves heroes, and not just in comic books. Heroes come in and save the day when things go wrong, and naturally anyone suffering as a result of that ‘going wrong’ is pleased to be saved.
Society employs heroes that are there to save us if a misfortune occurs: firefighters, police, and even the army; and we expect our utility suppliers (water, electricity, gas, telephone, etc.) to have such heroes too, ready to go out in the worst weather to fix any damages. But actually what we, as customers and consumers, would prefer is that things just keep working seamlessly – no water or power failures in the first place – and certainly we don’t ever want to need firefighters rushing to our homes. We like to know that the hero is there, but we don’t want to actually need them and their heroics.
In service management (whether applied to IT or non-IT), the biggest and bravest heroes live inside the problem management
team, notably the reactive problem management team, seeking out root causes and solutions to fix what goes wrong. Just like firefighters, many of these guys enjoy their work the most when faced with challenges and having to fix catastrophic failures or mystery issues that require analysis and skill to solve.
However, if we judge this team only on how well they react to disasters and issues, then we inadvertently set up a mechanism whereby the more things go wrong, the better they look. It’s like judging the fire service on how many major fires they put out. The easiest way for them to look good would be for them to go around starting fires so they can put them out. Now that’s a shuddering thought!
Of course neither the firefighters nor most problem management teams would deliberately cause issues to happen, but without incentivizing them otherwise, they might not focus on trying to prevent disruptions.
For the fire service, prevention rests upon aspects like promoting risk awareness and installing/ maintaining smoke detectors, as well as ensuring human emergency skills and equipment are ready to roll should they be needed.
Reactive and Proactive
has always (well, since 1988) ascertained that problem management has two sides: reactive and proactive. Reactive
deals with what has actually gone wrong; proactive
deals with prevention of impact through means like:
- Fixing things before they have any impact, such as repairing back-ups where duplication is in place
- Ensuring things remain healthy by scheduling preventative maintenance
- Seeking potentially weak or suspect parts of the infrastructure and repairing them before they fail
All this sounds good, but how on earth do you measure it, and justify the money it costs? Within any organization, it’s always hard to justify spending money, particularly when that funding is for making things NOT happen. Whilst it may be the best and preferred situation for everyone, no-one gets fair recognition by pointing out the things that didn’t happen because of their work. For example, the heroes of the Victorian age tend to be the engineers who built the big visible things like bridges and ships, whereas the biggest advancement at that time was perhaps the work done in preventing infectious diseases through the less visible things like water supply and especially the sewers. But we don’t instinctively judge progress by seeing when cholera stopped being widespread.
Corporate management should also want a set of services that don’t break, failures that don’t happen, and business output uninterrupted by errors. But even if management recognizes this, it can be hard to set targets and encourage improvement. And it can be even harder to get funding to expand, or even keep, resources dedicated to this preventative work. The issue lies with the difficulty of quantifying this type of work, but thankfully there are workarounds.
Measuring the Value
So what can be measured that would indicate that the proactive problem management team is delivering what is needed by the business? The most powerful way is to measure the damage being caused and (hopefully) how it’s gradually being reduced month by month through things such as:
- Service availability. How often does someone not do their job because a service isn’t there for them?
- Repeat incidents. Even the most trivial interruptions and failures can get in the way of the business. Working on making sure recurring faults go away reduces the damage.
- Cost of IT. Failures cost money and spending too much money is damaging to the business. Not having failures saves money. It’s that simple.
One of the biggest messages to get across is that spending money on prevention is often money well spent. Most people who rely on their car to get to work spend money to have it serviced regularly and replace components like brake pads before they fail. Funding proactive problem management is just applying that proven logic to the business.
We prefer our car to keep working and don’t want to be in a situation where we admire the mechanic who fixed our car in the rain on the roadside at night. What that preference translates to, in ITSM terminology, is mean time between failures (MTBF)
– where the longer the time, the happier the user is likely to be, and it’s a good focus for the supplier to have.
So, here’s what I propose for service mangers today - let’s focus more on recognizing, rewarding, and funding the preventative aspects of what we do, and acknowledge the true heroes of problem management.
Posted by Nicole Katz
on September 8, 2015 in ITIL
For as long as ITIL has been around (26 years) and longer, it’s told us that Service Management needs a triple focus. People, Process, and Technology all must be addressed if services are to be delivered and supported as well as they should be.
It sounds simple enough, yet it can be hard for people in IT to see past the technology sometimes. After all, most guys joined the IT profession to play with technology toys.So they get understandably disappointed when told to look at other aspects.
The Three-Legged Stool
It doesn’t work having a great process without people who can deliver it, and it’s not good having the best of all possible software tools if you don’t have good processes to support it. It’s like a stool with two perfect legs – it can’t do the job it’s supposed to do. In the picture you can see the three legs do their jobs separately. Of course they have to be built to a common specification, at least be the same length, otherwise you will get a lopsided stool and fall off. For service management, considerably more integration is needed: each of the proverbial legs (process, people, and technology) needs to be built with the others in mind to deliver the best solution for a particular environment.
Integrated Build, Maintenance, and Improvement
For example, designing processes needs to take into account the people who will be required to operate these processes. If you build a theoretically perfect process that requires a skill, physical ability, or degree of experience that your staff doesn’t have, then it will be as relevant and helpful as a two-legged stool. So, knowing staff availability and skill needs to affect the process design. Similarly, knowledge of the processes (which staff will be required to follow) should be a relevant influence on recruitment and training of these staff members.
This isn’t just related to IT service management (ITSM) of course. Look at professional sports, for example, which is littered with cases of managers who develop excellent processes (tactics, formation, style of play, etc.) that should sweep them to victory, but they don’t, because the processes fail to factor in the skills and abilities of the specific players on the team. And just as many times, teams will fail when skilled players do not perform because the style of play imposed on them doesn’t match their skills. The best teams are where the approach and the skills are in harmony, and that only comes from a holistic view, building with what will be available and not in isolation.
The same idea can be applied to technology. Tools need to support the processes required, that’s how it’s taught in the ITIL®
Foundation courses. But in real life, the availability of a tool and its capabilities will affect which processes are possible. An organization’s choice of ITSM tool is often heavily influenced by whether the staff who will use it will ‘like it’ or ‘feel comfortable’ with it. This is the sensible approach; not pandering to staff’s whims but integrating the threefold approach to ITSM, making sure the technology and the people and the process are built – and can then continue to develop – together.
Building the Legs to Work Together
The pragmatic lessons of this are really quite simple. Work on process, people, and technology as a combined and interconnected ongoing effort. Allow each to influence the other. Technology will open up new process possibilities, improved processes will reveal technology requirements, and it will possibly also change skills requirements in people. New skills coming into the workforce, as with the Millennial’s familiarity and comfort with smart technology and social media, will influence what are the most relevant tools, and the processes for using them.
Encourage – and be encouraged by – the broad perspective.
Perhaps it is worth looking at your attitude to the three elements we’re discussing (people, process, and technology), and checking on how you can integrate them better. Maybe ask some questions like:
- Do your suppliers see their product(s) as essential parts of an integrated whole, or as a magic bullet that can work in isolation?
- When designing and documenting processes, do you consider and also document skills and experience that will be necessary to perform them?
- Do your process designers know the capabilities of your technology, and treat them as design constraints?
This is a good place to start. I’ll follow up, in another blog, with some direct tips to help you further.
Posted by Stuart Rance
on September 2, 2015 in Service Desk
I really enjoyed delivering a webinar with Stephen Mann
recently. The webinar, which was called Real-World Tips for Self-Service Success
, attracted a large audience, and generated some great feedback. If you missed the live event then you can still listen to the recording by following the link, and if you want a brief synopsis of what we spoke about, read this blog
. If you would prefer to read more about the topic (with or without watching the webinar) then start playing the webinar and click on the Attachments
button to access our white paper.
Quite a few attendees typed in questions, and although we didn’t have time to answer all of them during the live event, we have given them some thought. So here are my answers to some of the questions.
If your company doesn't have ITIL in place, do we need to approach self-service in a different manor?
Not at all. Nobody has “ITIL in place”. ITIL is just a set of best practices that you can adopt as part of your management system. You must have some kind of processes in place for managing incidents and requests, and I assume you have a service desk or something very similar. All of the ideas and suggestions we made about self-service were general ideas about IT service management, none of them was specific to ITIL.
Any ideas on how knowledge articles can be written or related so nuggets of wisdom can be interwoven into a self-service process - available at relevant points from the customer's perspective?
This is a very challenging question, and you are right that it is needed. The first thing to do is to identify what information you need to make available. You can do this by reviewing service desk calls to see what questions come up frequently, and also by talking to your users to find out what they would find useful. You should then stop thinking about “writing” and start thinking about what is the best medium for the knowledge you want to share. A short video or graphic can often be far more effective than a piece of writing.
Do you agree that self-service demands careful design of a supporting 'knowledge-base' of helpfiul information to coerce, guide, and support whatever process is being self-served?
We do talk quite a bit about the need for a good knowledge base during the webinar, so yes, I absolutely agree. I think this question must have been asked before we got to that part!
We know that many users will not or do not call support when they have an interruption or a question - they go to online search like Google or Bing. Is properly constructed self-service better than that, which may give generic or irrelevant answers?
It’s not only your users that do this. I do it, and I suspect that you use an internet search engine to try and solve problems too! There’s not necessarily anything wrong with this. In fact, the best way to get users to use your self-service portal rather than a generic search engine is to offer a better service! You could actually include a generic internet search within your portal to help you collect data about the help your users are looking for and use this to help you fine tune the relevance of the resources you provide for them. You could even incorporate the results of a generic search alongside the results of searching your own knowledge base, so that users can get both with a single search.
What about incorporating or embedding capabilities such as Google search into your organization's portal to help make your self-service look like something folks might be familiar with outside of IT?
This is a great idea. See my response to the previous question.
What measures/metrics are important to help you gauge how your self-service is working?
What’s important is that you measure things that matter to you. Don’t just use a generic metric, but think about why you’re investing in self-service, and measure to see that you achieved what you wanted. Some things that you might want to measure include:
- User satisfaction ratings when they have used self-service
- Percentage of incidents and service requests that are received via self-service
- Percentage of self-service incidents and requests that are resolved without needing manual intervention from the service desk or technical support
- Average time to resolution of self-service incidents compared to the same category of incidents handled by the service desk
How do you motivate users for enrolment in self-services such as password services?
This is one of the hardest aspects of self-service. You need to look at the whole spectrum of organizational change management and decide how this can work in your context. Start by identifying a sponsor in the organization who cares about success of the self-service project and who will support what you are doing. Continue by identifying “what’s in it for me” for the people you want to engage. Then work out a plan for communicating with them. Make sure they know how much easier things will be for them when they use self-service instead of phoning the service desk. AND MAKE SURE IT REALLY IS MUCH EASIER. Then communicate, communicate, and communicate. Share examples of how people have saved time and effort by using self-service, share how the company has saved money, shared how the business has become more efficient due to less wasted time, etc.
"Getting the right people involved..." I'm bound to say that I hope you mean start 'outside-in' and look at what is needed from the perspective of those being offered self-service as an option. Worth walking in their shoes for a mile... (Loaded question) What methods do you recommend for understanding the customer experience?
Of course, we should always take an outside-in customer-focused view when we design any aspect of IT services. I am a big supporter of the Lean concept “go to the Gemba”, which says that the way you find out what the users experience is by going to where the users are and seeing what they see.
I hope you have found some of these answers useful. Please feel free to share your own answers via the comments area below this blog or find me on Twitter at @StuartRance
Posted by Greg Sanker
on August 26, 2015 in Service Desk
Everyone knows that incident management
is designed to manage the overall life of an incident. Start to finish. Cradle to grave.
But what does that really mean?
The standard, accepted practice is that (most) incidents are started at the service desk – aka "Level 1 support". In fact, the service desk is generally synonymous with incident management ownership. The role of service desk employees includes ensuring timely and effective resolution.
Issues that cannot be fixed at level 1 are escalated to specialty teams, also known as Level 2 (or 3) “resolver” groups. Resolver groups have deep technical experience in a specific technology area (network, servers, application, etc.)
We’ve all heard horror stories of incident tickets that spend days, weeks, or months getting kicked from queue to queue. It’s a concept I call “bus therapy”. Basically, when a resolver group either can’t resolve a ticket, or doesn’t know what to do with it (and before the SLA expires!), they assign it to some other random queue, making it someone else’s problem.
The reason I call it bus therapy is because it’s like buying a one-way ticket to some other town, wishing it well, and sending it down the road, hopefully never to be seen again.
This happens when there’s not clear ownership for incidents. And when that happens, guess who suffers. You got it – the customer.
Who’s On First?
Incidents that are created, worked on, and resolved by the service desk are pretty straightforward. Ownership is clear, tracking resolution time is pretty simple, and, in the end (hopefully), a happy customer.
No problem here.
But incidents worked on by the service desk that requires deeper support for resolution – now that’s a different story. When that happens, the ticket is reassigned to the appropriate resolver group (network, servers, etc.).
But what if the resolver group determines it’s not their issue? Do they route the ticket on to another resolver group? Do they route it back to the service desk for rerouting?
What if the issue requires multiple resolver groups’ efforts? Who manages the ticket, or are there now multiple tickets?
Every hand off potentially adds delay as the ticket is queued awaiting the new resolver group to respond and begin working the ticket. The more hand offs, the more potential for delay.
It’s not that anyone is trying to give bad service to any particular incident. Everyone is busy, and tickets have a way of getting forgotten or lost in queues. Unassigned tickets can be particularly troublesome.
This is the shocking, secret life of escalated incidents:
- Potential for unclear or multiple owners
- Convoluted paths between resolver groups
- Unclear, or circular, paths to resolution
It really comes down to one fundamental principle: who owns an incident at any given time?
There’s really only two options:
- The person currently working it, or
- The incident owner, regardless of who’s working it
Two Roads Diverged
In the first option, incident ownership transfers with the ticket as it gets assigned to different people. This is the simplest, and perhaps most common, approach. The service desk analyst owns the incident while working it. If it gets transferred to a colleague for any reason, the ticket owner is simply changed, and off you go.
Where this model struggles a bit is when transferring ownership to a resolver queue, rather than a person, and the ticket sits unassigned for a period of time. At that point in time, it has no identified owner. The service desk analyst no longer owns it, and it’s sitting in a queue waiting for someone to notice and take ownership for it.
If there are multiple handoffs, each new group’s response time is added to the overall resolution time.
In the second option, ownership of the incident remains constant. It never transfers. The owner is generally the service desk analyst whom, as you recall, has ownership for all incidents.
With this approach, when issues go to resolver groups, a child ticket (sub-ticket, task, etc.) is created, related to the original (parent) ticket, and the child ticket is routed to the resolver group. If multiple resolver groups are required, additional child tickets are created and related to the single parent ticket.
The service desk maintains ownership of the parent ticket, and keeps watch over the child ticket(s). This gives the service desk the ability to monitor the overall coordinated response to an incident. The service desk calls attention to child tickets that don’t appear to be making progress, and takes action to ensure timely resolution.
The service desk is then positioned to facilitate the overall response to complex and escalating incidents. The service desk uses child tickets to effectively manage the incident, and rally additional resources as needed.
Which Is Better?
Neither, really. Or both, perhaps. I don’t want to go the “it depends” route, but, well, it kind of does depend.
In smaller organizations, transferring ownership can be clean and effective. In tight-knit groups, tickets are much less likely to get lost or bumped multiple times without being noticed.
But in a larger shop, especially where there are multiple, geographically dispersed resolver groups, and follow-the-sun
support, it’s easier for tickets to get lost in the shuffle.
It’s worth noting that the service desk is designed to be a customer-service contact center. Its primary purpose is to ensure all incidents are resolved within service level targets. Having a handle on all incidents facilitates high levels of service. It also puts them in a powerful position to correlate, detect, and trigger major incident response.
What to Do?
The bottom line is, either approach can be made to work perfectly well, depending on the circumstances. Personally, I prefer a service desk with clear ownership and end-to-end accountability for incident management. To me, this is the fulfillment of “managing the lifecycle” objective of incident management.
But that’s a decision that each organization must make for itself based on its unique circumstances and challenges.
As with all processes and tools efforts, the focus should be on the process first. Don’t rely on the tool to define the process. You have to understand what works best for your organization, and why, before you begin configuring your ITSM tool
All modern ITSM tools can be configured to effectively manage either of these approaches.
What approach have you seen to be most successful?
If you are struggling with service level performance and incident resolution times, and if you have too many tickets receiving bus therapy, you may want to revisit your incident model. Service desks that started small and grew with the business may never have made an intentional decision on incident ownership, and it’s worth revisiting.
Posted by Sophie Danby
on August 19, 2015 in Service Desk
Sadly, many IT departments don’t see the importance of delivering great customer service to their end users. After all, it’s not as though the end users can leave them for another support provider, right?
Technically this is true, but it’s also wrong… Have you heard of a new-fangled thing called Google
? At a recent IT service management (ITSM) conference
in London, a great point was made: “No ITSM tool vendor is the leader in providing technology to help solve IT issues. That award goes to Google.”
And according to Forrester Research
, only 17% of IT issues actually make it to the corporate IT service desk. So where does the other 83% go?
End Users Have Consumer-Driven Expectations of Support and Can Self-Help
End users are becoming increasingly more tech-savvy and their expectations of IT are increasing daily (to match the service experiences they receive in their personal lives). So why would they want to deal with a potentially unhelpful service desk analyst who doesn’t respond to their ticket for three days, when they can simply type their issue into a search engine (although we don’t actually recommend this
) to find a workaround or fix for their issue themselves in mere minutes?
In my opinion, given the continued rise of Shadow IT, personal cloud services, and BYOD, corporate IT departments cannot afford to ignore their end users nor to deliver a bad service experience. So make the most of the opportunity you have right now to improve your service experience before that 17% drops so low that the need for an internal service desk is questioned.
Here are five simple tips to get you thinking about (and hopefully started on) the road to providing a better service experience:
Whether you’re providing internal or external support, the best customer service and service experience comes from those people who spend more time listening than talking. Allow your end users to fully explain why they need help and what makes it so important for their issue to be fixed quickly. After all, just because their IT issue doesn’t seem important to you, it doesn’t mean that it isn’t disruptive and important to them, their working, and possibly a business-critical activity or service. So don’t blindly dive into the resolution script in front of you or prioritize the issue as low for level 2 support – actually listen to what the caller has to say and then act accordingly.
2. Don’t make excuses
The end user doesn’t care whether it’s your fault, his/her fault, your colleague’s fault, or your best friend’s cat’s fault. They just want you to address their issue. So take ownership of the issue, understand why they are frustrated, and don’t be defensive and/or make excuses. As Nike would say “Just do it” in terms of getting things fixed (of course bearing in mind my first tip).
3. Manage expectations
Okay, so it’s not ideal for the caller that you cannot immediately solve their issue, but do you know what is less ideal? Them having to guess when their issue will be fixed. Yes, they might be unhappy with you if you say that it’s going to take three days, but how unhappy are they going to be if you don’t set a resolution timeframe and three days later they have to call you for an update? Always let them know when their issue will be addressed and any reasons for delay – it might be an agreed service level target that says it can take up to three days based on workloads. In my opinion, not managing end user expectations effectively will simply lead to them becoming even more frustrated (and potentially contacting you every few hours for updates – which isn’t a great use of your time, or theirs).
In line with effectively managing expectations, always keep your end users updated on the status of their incidents. Don’t leave them in the dark; they’re probably not mind readers. Let them know if there is going to be a delay and let them know what you’ve achieved as you go along, ideally via self-service, so that they don’t assume you’re just sitting there doing nothing to help them.
5. Use customer satisfaction surveys
First and foremost, don’t ask for feedback if you’re not going to bother acting on it. If you’re wondering why very few people actually complete your post-service survey, this is probably the reason. No one is going to waste their time giving answers to your questions if they know they’re not going to see any action taken on what they have to say. Make your survey short, and use appropriate questions (I advise checking out the net promoter score and system
), and then ensure that you follow up on the answers. Show end users that you’re listening by communicating how you are going to address the highlighted issues, and provide evidence of improvements once completed.
So there you have it, my five quick tips on how to improve your service desk’s customer service and service experience. What do you agree with? What would you change? And what would you add? I’d love to know.
If you’re looking for further advice, then I also recommend looking at the following:
Posted by Gil Blinov
on August 12, 2015 in Service Desk
Sets of best practices for service management – like ITIL for example – are full of good ideas and good advice, and all that good information is valuable, but sometimes you are able to generate added value by combining two elements of advice from different parts of the guidance.
If you look in ITIL®
2011’s Service Operations book (Chapter 6.3.5), you’ll see a list of relevant metrics about service desk performance. Now go to ITIL’s Continual Service Improvement (CSI) book (Chapter 5.5.2) and you’ll find some words about tension metrics, which are different metrics that effectively compete with each other. Each book has some pretty good stuff on their own, but put them together and you really start getting somewhere!
Metrics, of course, are just things you can measure to give you an idea of how well something is performing. We use metrics every day – for example we might measure a car by how fast it goes or how much fuel it uses to cover 100km. This is, in fact, tension metrics. The faster your car, the more fuel it is likely to use. You might choose to drive slowly to save fuel, or quickly to save time. You won’t be able to do both because the two compete with each other – there is ‘tension’ between them.
Metrics for a Service Desk
If you focus only on one metric, it is usually simple enough to meet, because you are basically disregarding all other factors. So that may not be the perfect scenario.
Let’s take a look at two traditional metrics that are used to measure service desk performance:
- First-time fix rate. Easy to meet - just keep callers hanging on for as long as it takes.
- Short call duration. Just as easy - take their number, hang up, call back, and disturb them each and every time you need more information.
If you judge a service desk simply on one of the above metrics, you’re going to get behavior guaranteed to upset rather than delight customers. What the customers want is a balance of first-time fixing in a sensible amount of time. Just like you don’t want the world’s fastest car (way too expensive) nor the most fuel efficient (far too small and slow) for everyday motoring. You want something fast enough and cheap enough to run – along with other factors too, of course, like enough seats and luggage space.
So with the service desk, both first-time fix rate
and short call duration
are important, and both need to be measured (as do even more metrics besides those). This, however, then sets up a challenge that requires thought and consideration by service desk staff and managers. Do you keep the caller hanging on while you try a quick solution? Do you give up on the first-time fix rather than extend the call too long? It makes the service desk work harder on decision making, but also delivers a much better and balanced service overall.
This is just an overly simple illustration of course. In real life you would want to choose more than just two metrics that fight and challenge each other – making the decisions even more complex but hopefully also making the service better matched to the client’s concerns, wishes, character, and culture. There isn’t a single right answer, but here is my list of optimal service desk metrics – as an opening or food for thought:
- First time resolution rate
- Average call duration
- Percentage and number of abandoned calls
- Percentage and number of calls miss-assigned (e.g. to wrong support team)
- User and customer satisfaction survey results (that’s two different surveys)
- Staff turnover
- Total cost of operation: staff, equipment, resources, etc.
It’s not easy to measure everything on this list, and likely you don’t need to measure it all, but surely you would benefit from measuring across the implicit tension that exists between many of these measurements.
Some of these suggested metrics might surprise you – staff turnover for example. Each new worker on the desk can take days or even weeks to reach a reasonable operating performance level, while you are paying them; so keeping the turnover down, keeps costs down. Of course, it also means more experienced staff, and that experience should deliver faster and better service.
Using Metrics to Measure Value
No one set of metrics is right for every situation – sometimes speed matters more, sometimes economy, sometimes safety. That applies to cars or service desks. What matters is measuring the value that the customers get from the service. To do that for your particular situation, the first step is to establish what those customers would see as value. Start with possible metrics and discuss with the customers to work out the best bundle of measurements for your situation.
What is universal though is the need to try and make sure you have that tension element in your chosen set of metrics, so that the compromise between speed and cost – or whatever matters to your situation – is rewarded rather than just one target that can be easily reached at the expense of overall service quality.
We all use the tension metric concept in everyday life (as with the car). You probably also do so at work, perhaps without even realizing it. Can you think of any examples? Please share.
Posted by Stuart Rance
on August 4, 2015 in Service Desk
It’s summer time in the Northern hemisphere, and many of us are getting ready for our annual holidays. It’s really great to get away from work for a while, but some people don’t get much relaxation because they are constantly interrupted by emergency calls from work. There are things you can do to make these calls less likely, and that’s just as important a part of holiday planning as booking the flights and the hotel. If you’re going away tomorrow then it’s probably too late to do these things now, but you could get started as soon as you get back, so that next year’s holiday will be more restful.
Share Some Knowledge
Think about the things that only you can do. What would be needed so that someone else can do them? Could you provide written instructions, or teach somebody else how to do it? If so, then share that knowledge. It will have benefits for you and your organization all year round, not just when you’re on holiday.
Automate Routine Tasks
One great way to reduce the impact of being away for a while is to automate some of the tasks you usually carry out. You should only automate things that are well understood, reasonably frequent, and fairly simple. If you don’t understand the task thoroughly then automation will go horribly wrong. If the task isn’t reasonably frequent, then the effort needed to automate it will be too high compared to the effort it saves. If the task isn’t simple, then it will be really hard to automate, and the automation is likely to miss out on some complex cases. Even if the task is fairly simple you should always see if you can simplify it even more, before you automate it. Many routine tasks have built up complexity over the years, but could be much simpler if we started the design again.
Like sharing knowledge, automation is something that can really pay off in terms of benefits every day of the year, not just during holiday season.
Pay Off Some Technical Debt
Technical debt is the effect of compromises that you made in the past. Like financial debt, it is not always a bad thing, but you should never have too much, or let it be outstanding for too long. Here are some examples of technical debt that need to be managed:
- A new service was put into production even though it failed some operational tests, and backups don’t quite work properly. This is a perfectly reasonable thing to do, but you shouldn’t just forget about the issues afterwards. Investigate why the tests failed and fix the problem. That way you will avoid a disaster when you need the backups.
- You upgraded the firmware on all your servers to fix a security vulnerability, but one server couldn’t be shut down that day because it was running a critical task. Don’t just leave that server indefinitely, plan the upgrade for a time when the server is available.
- A disk failed in a RAID set. The data is all still available because the RAID set can operate with one disk missing. However, if you don’t get that disk repaired then eventually another disk might fail and then you will lose your data.
Every IT organization has some technical debt, but if you don’t actively manage it then it can get out of control and result in lots of incidents, problems, and urgent phone calls, probably just when you want to lie on the beach soaking up the sunshine.
Adopt Continual Service Improvement
If you have a culture of continual service improvement, then you’re probably already sharing knowledge, automating tasks, and paying off technical debt. If you don’t, then why not think about how you can start?
Continual service improvement
doesn’t need to be a big, complex process with lots of documents and activities. It’s mainly about attitudes, culture, and behavior. You can start by simply noting down things that ought to be done, prioritizing them, and picking one or two off the list whenever you can. Over time you will find that things are looking much better, and next time you go on holiday you’ll really be able to relax.
Posted by Danny Tashiev
on July 28, 2015 in Service Desk
TV programs such as The IT Crowd
and the Dilbert
comic strips convey IT teams and service desks in a comical yet often negative manner. They are very funny, I know I laugh at them, but they are funny mainly because they are based on truths – truths that have been with IT and the service desk for far too long. Sadly, I’m sure that many people resist calling service desks based on the assumption that what they've seen and read is correct.
However, the humor is often based on generalizations or snapshots from a previous time in the history of the corporate IT organization. Many IT organizations have moved on from the 1990s and I’d like to think that most service desks definitely have. So in this blog, I’d like to challenge some of these IT assumptions and help you to bust some typical service desk
1. IT folk work in the basement and hate interacting with people.
We may work in secure rooms sometimes
because of sensitive data and systems yes, but basements...rarely. In fact, in the future we are likely to see more and more service desk staff placed out amongst the other business employees, or in walk-in clinics and Genius Bars
. Global analyst firm Gartner have been pushing this greater visibility and interaction for a few years, as employees start to expect what they get with their consumer technology from the corporate IT department. As for hating to interact, that just doesn’t add up, as a large number of support staff have chosen to work on a service desk because they love to help people, and providing great customer service is their passion. In my opinion, you don’t have to create a Genius Bar but please take a long look at how your service desk agents appear to end users, after all they are the business’ window into IT and a big influencer on employee perceptions as to how the IT organization-as-a-whole is fairing.
2. They know about every piece of software ever written.
Just as any IT pro will not be completely conversant in all the systems and applications your organization runs, neither is the typical service desk agent. Most agents will have a good knowledge of common issues encountered on your organization’s most popular systems and software, but only some will have the necessary specialism in the more complex or obscure applications. And this is as it should be – just because a business team uses a piece of software all day every day, doesn't mean that the rest of the organization does. Service desk agents thus need to selectively build up their IT system (and business) knowledge using the Pareto principle – 80% of the benefit will come from just 20% of the possible knowledge. Ultimately, your service desk team should work like this to create the most value for the business, based on the difficulty of recruiting knowledgeable service desk staff (on the available wage) and to cope with staff churn levels. Service desk agents can function very effectively with just enough knowledge and, where possible, superior problem solving skills.
3. They know how to fix everything that has batteries or a power source.
Service desk teams really are amazing sometimes (in terms of what they know and can do) but like all of us they have their limitations. They're not electricians, they can't help you if your microwave doesn't work and they can’t install an alarm system – but they should be able to handle requests that relate to these types of requests, routing them through to the appropriate team rather than just saying we can’t help. There is also often an overlap between the IT service desk and the facilities help desk, in particular, with the installation of network points a great example – facilities might install them whereas IT would maintain them. So make sure that the dividing line for responsibilities is clear, as end users don’t want to be ping-ponged between IT and other corporate service desks – they just want or need a quick solution.
4. Fibs such as "I didn't touch anything!" or "No, I didn't touch that setting!" don’t really matter.
In order to troubleshoot efficiently and effectively, a service desk needs the end user to be totally honest about their issue and how it came about. However, people being people, might just try to avoid saying what they did to cause the issue in an attempt to avoid blame and any punitive recourse. So try to create a blame-free approach at the service desk. There are caveats to this – such as an end user who loses three mobile phones in a year is negligent and it’s an HR, not an IT, issue – but make it easier for end users to honestly share what they have done even if they're not 100% sure what they've done. It'll make everyone's life easier and save everyone a lot of time.
5. They don't know what they're talking about; they're just following a script.
Scripts benefit both end users and service desk agents. They should quickly get service desk agents to the core of the issue and to a swift resolution, even where the agent has a limited knowledge of the technology in question. Plus, if an issue has to be escalated to a more technical team then they need to know that all the basics have been covered. Most service desk agents will thankfully know more than just how to follow a script but they need to prove it. If they are blindly following scripts when they are inappropriate to the issue in hand, then this myth will never be busted. So set your service desk people free to use what they know, including their inherent problem solving skills. Empower your service desk agents to go off-script
when needed – it will most likely lead to a swifter solution, and most definitely result in a better service experience for the end user.
6. They just tell you to restart your machine because they're lazy/don't really know what they're doing.
It’s amazing how often restarting a phone, PC, or application will resolve an issue. It’s often a great first step, especially when devices and programs have issues that the service desk has not experienced before, and therefore don't know how to cope with. So a good old-fashioned reboot might be the best solution – there’s nothing wrong with that, but be wary of how it‘s offered. Don’t just say “please reboot your PC.” Better to explain that a reboot helps with a number of issues, and you never know – they might even try to reboot themselves next time before contacting you, thereby preventing an unnecessary service desk call (when the reboot works).
7. There's no point contacting the service desk, you can find the answer on Google.
There is what seems like an infinite amount of IT support information on Google and, yes, some of it will help end users but a lot of it won't. Not only is Google an information firehose
, but who knows how much of the information is inaccurate or dated? Plus how much of the advice is malicious rather than helpful – “install this questionable executable to cure all your woes”? Also how quickly can end users help themselves via Google? If it takes longer than via the service desk, especially with the involved people more senior, the cost to the business is easily going to be greater through this self-help route. In addition to this, if all end users went to Google instead of using your IT self-service system or logging a ticket directly, then a genuine problem could be missed. Thus any service desk that wishes to stay relevant needs to make IT support as easy to access and consume as Google; to do otherwise will always be a suboptimal solution from a business point of view.
So there you have it, a number of service desk myths that need to be busted. What do your end users think of you and what are you doing to change their opinions of your service desk where needed?
Posted by Gil Blinov
on July 23, 2015 in ITIL
The corporate IT service desk gets a lot of criticism. More specifically, service desk agents get a lot of criticism. They often get accused of using their service desk role as a stepping stone to "a better IT job." They are commonly chastised for following scripts, even when the scripts are completely inappropriate (but are the best they have under the circumstances).
On a more personal level, they are often treated as a herd rather than individuals; tar brushed with generalizations such as having poor interpersonal and customer service skills. On the upside though, they are assumed to know more about IT than most.
I'm getting to a point (of sorts), but first I wanted to throw out a few of the mean, but not unnecessarily untrue, things that are commonly said about IT help desk or service desk agents. I've been there and bought the t-shirt.
So how well do IT service desk agents do? Individually and collectively? They often hit the SLA/operational targets that their IT paymasters have forced upon them - such as first contact resolution levels, speed of response, and correct incident classification percentages - but they still fail to have a glowing reputation with end users (their business peers). This includes even those that are touted as IT superheroes within IT.
Is the Issue Simply that Service Desk Agent Performance Is Poorly Targeted?
There's no denying that some IT organizations have way too many service desk metrics, often metrics that conflict and/or drive the wrong service desk agent behaviors. However this is just part of the issue. While IT service desks and the agents that work within them would benefit from a better basket of metrics, there's much more to be done to get the service desk's corporate reputation to where I'd like to think it should be.
But what needs to change? Is there a need for tighter service desk processes? Probably not. Should they replace their ill-fitting and complicated help desk tool? Not necessarily. Should they recruit more staff, with better technology skills? Nope. I could continue but we’d probably end up with Is it Henry, the mild mannered janitor?
Staff Need to Rise Above Process to Think Differently
I'll repeat this as it's important - staff need to rise above process to think differently; and it's not just service desk agents, it needs to start with service desk and IT management. It could be the fault of legacy IT help desks that were designed to fix IT issues. It could be the fault of ITIL, the IT service management (ITSM) best practice framework formerly known as the IT Infrastructure Library. That's an odd thing to say isn't it? After all ITIL introduced the service desk to all of us still running an IT help desk.
Think about it. Many will quote the three or four Ps of ITIL - People, Process, Product (tools), and sometime Partners. There is, however, another P that's overlooked - Purpose
. How often do you hear of IT organizations investing in, reinvesting in, or changing people, processes, and ITSM tools? Especially the latter. How often do you hear of IT service desks (and perhaps IT organizations as a whole) reconsidering their purpose? Or even questioning the purpose they probably gave themselves in the late 1980s at the dawn of help desks?
The Service Desk Is All About Service
Sounds obvious doesn't it; but what's the purpose of your IT help desk or service desk? Does everyone who works on the service desk know this (assuming that you're right with what you have replied)? They probably don't. I'd happily bet that many of your service desk agents think that they are fixing IT issues rather than helping business colleagues (and services) work again.
I'd also bet that many have minimal insight into how each IT issue is impacting individuals, groups, and business services. Bar the automated priority level that is. You know this - we train people on the processes and the tool rather than the purpose and context of the service desk.
For me this needs to change, otherwise IT help desks and service desks will continue to work hard in earning a less-than-favorable corporate reputation.
So what's the purpose of your IT help desk or service desk? And don't just spout back something you've read in an ITIL book.
Like this article? You may also like: What is ITIL?
Please share your thoughts in the comments or on Twitter, Google+, or Facebook where we are always listening.