Posted by Stuart Rance
on October 5, 2016 in Service Desk
IT organizations often spend huge amounts of time, money, and other resources on managing incidents, but they spend surprisingly little on problem management work that might reduce the number of incidents in the first place. This is often due to poor understanding of the difference between incidents and problems, and insufficient knowledge or understanding of how to manage problems.
Why Do We Distinguish Between Incidents and Problems?
Many people confuse incidents and problems, so let’s start by making the distinction clear
- An incident is an unplanned interruption to an IT service, or a reduction in quality of a service. Incidents have an impact on users, and on the business, and the purpose of incident management is to restore normal service.
- A problem is the cause of one or more incidents. The purpose of problem management is to manage the problem, eliminating future incidents where possible, and reducing the impact of incidents that can’t be prevented.
So, incident management
helps you get the business working again, problem management helps you prevent future incidents, or at least make them less painful when they do happen.
In the bad old days, when IT was a very technically-focused function, most IT teams didn’t distinguish incidents from problems. If something broke, then somebody would work on it until it was mended. IT technicians paid little attention to the business impact of whatever it was they were working on, and the customer just had to wait until it was fixed. But when we learned to distinguish between incidents and problems, this changed. Organizations could set up incident management to focus on doing whatever is needed to get the business working again, leaving problem management to deal with any underlying technical issues. Take, for example, a printer that isn’t working. There is no need for the customer to wait till the printer is mended. When we practice incident management we can simply help the customer route their printout to a different printer. Obviously, this doesn’t get the printer fixed, but that is probably something that doesn’t really concern the customer. We can of course go on to repair the faulty printer. But this is now a problem management activity, with lower priority as the outcome has very little direct impact on the customer.
How Do You Identify Problems?
Before you can start managing your problems, you need to identify them. Here are some common ways that organizations identify problems:
- Trend analysis of incident records. This activity is sometimes known as “proactive problem management” because its purpose is to help you identify problems that you don’t already know about.
- Major incidents. Every major incident should result in a problem being logged, to ensure you take steps to prevent the same thing from happening again.
- Multiple incidents at the service desk. Service desk agents should notice if there are multiple similar incidents being logged and log a single problem to ensure that these are investigated and the cause addressed.
These are some of the ways that problems can be identified, and you should make sure that you take full advantage of these, but also think about all the different ways that a problem could be identified in your organization. For example, think about your suppliers, software developers, or infrastructure teams, and make sure that you actively capture all of their input and use it to log problems.
How Should You Manage Problems?
Problem management has two objectives:
- To prevent incidents from happening
- To reduce the impact of incidents that cannot be prevented
Many organizations only think about the first of these objectives. They do root cause analysis to understand the problem, and then take steps to rectify whatever was causing it. This may take some time, and while a complete technical solution may prove very effective once it is in place, the business is likely to continue suffering in the meantime.
The best organizations that I work withstart
by thinking about how to reduce the impact of incidents – the second of our two objectives. They ask themselves, “What should we do if this happens again right now?” This might be a difficult question for technical support staff to answer if they don’t fully understand the problem, but it’s much better than just leaving service desk agents to flounder when the same thing does happen again. Organizations with really effective problem management create workarounds for problems as quickly as they can. They make sure there is a well-documented workaround in place as quickly as can be managed, and they also review the workaround every time it’s used to identify possible improvements. And with the latter, they will also go on to improve the workaround as they learn more about the cause.
So one benefit of thinking about reducing the impact of incidents, before you start analyzing their root causes, is that you reduce any business impact much faster.
But there’s a second benefit – sometimes it turns out that a workaround is so effective that there is actually no need to understand the root cause or fix it. Here’s a perfect example:
One of my friends had a gas leak under the concrete floor in his kitchen. He turned off the gas and called out the emergency gas fitter. This gas fitter ran a pipe around the outside of the kitchen so that the gas cooker could be reconnected and arranged for a structural engineer to diagnose the leak properly, so they would know where to dig up the kitchen floor. The structural engineer called a week later and said it would cost a huge amount of money to dig up the concrete and fix the pipe, but fortunately this was unnecessary because the new gas pipe was perfectly safe and did the job.
This example doesn’t involve IT, but I’ve used it anyway because it is a particularly good illustration of the fact that a safe and effective workaround is often enough. Why waste good money fixing an application when you have a workaround to the problem and it no longer has an impact on the business?
Of course, if your workaround is not sufficient then you do need to investigate the root cause of the problem. There are many different techniques you can use for this. My favourite approaches are timeline analysis and Kepner-Tregoe problem solving.
This is such an easy way to investigate a problem that it barely deserves a name. You simply list everything that happened in time order and then look for patterns. What is important is that you get all the data from multiple sources and then sort it by date and time, regardless of where it came from. So your timeline may have entries from system logs, emails, service desk records, and many other sources. This simple approach is surprisingly effective at building a complete picture of what’s been going on.
Kepner-Tregoe Problem Solving
I have to declare an interest here, I used to teach this proprietary approach to problem solving
, but I do think that it is incredibly effective. This is a very structured approach to problem solving, where you define the problem across a number of different dimensions (what, where, when, extent) and you also bound the problem by identifying what is NOT failing. You can then review the distinctions between these to identify possible causes.
Problem management presents a great opportunity to reduce both the number and the impact of IT incidents on your customers. If you are not already doing problem management you should certainly be thinking about introducing it
. And once you do, I think you may find my guide to problem management metrics
worth a read.
If you are already doing problem management, then make sure that you have the balance between devising workarounds and investigating root causes right. You don’t always have to understand the cause to resolve the problem, but you do always need to put a workaround in place as quickly as you can. You may even want to think about how to integrate incident and problem management
, but whatever approach you take you should make sure that you focus on value. Think first and last about what will be best for your customers and users.
Posted by Roy Eldar
on September 27, 2016 in Service Desk
Come the end of a busy week, does your IT service desk ever look a little bit like the set of a western movie
The atmosphere is dry and barren. Random objects are strewn across the office like 21st
-century tumbleweed. With your team members staring blankly into the distance, eyes burned by the constant glare of their monitors, tired and reeking of apathy. It’s been a heavy week, and you’ve been consistently ambushed with incidents. The service desk has spent day after day in the firing line of end users, having to repeatedly circle the wagons under the glare of SLAs and stretching performance targets. And now your team is tired.
Pinned to the notice board is a sign, “Wanted: Motivation.” Best not to mention the wild west reference to dead or alive.
The Good, the Bad, and the…Unmotivated
Looking around at your team you start to wonder when the motivation disappeared and how long it’s been gone, but it’s no good following the hoof prints back down the already well-trodden trodden path. Instead you need to get back on your horse, perhaps after drinking your milk, and rally your riders. And here’s a few suggestions on how to re-motivate your team to face another week, month, or even year of the IT support wild west:
1. Listen up, partner!
Communication is crucial – listen to your team and instigate a collaborative feedback cycle. According to research by weekdone.com
, 39% of workers don’t feel that their input is appreciated.
By asking your team members for their input and involving them in the decision-making process, it will make them much more likely to support day-to-day activities, improvement projects, or your decisions. And remember, once you have gained their feedback, visibly follow up to show them that you’re actively taking their opinion onboard.
2. Have one-on-ones, but hopefully not standoffs
Recognize each member of your team as an individual.
And that your team’s motivation level is directly correlated to your management style. Did you know that 75% of people voluntarily leaving jobs don’t quit their jobs; they quit their bosses
In addition to more one-on-one time, you could also learn what motivates individual staff members through psychometric tests. Try to understand how they like to be managed to optimize their productivity. Then as their manager, create attainable goals and clearly communicate plans to keep staff engaged and in the loop.
In the Workforce Mood Tracker™ Spring 2014 survey
, 73% of respondents credited “recognition” for having a positive impact on their happiness at work. So wherever possible recognize work, and even personal, achievements to make your team feel valued.
3. Shoot ‘em up!
Gamify your service desk metrics to help motivate your team to hit their KPIs. Reporting on IT service desk performance can quickly take the motivation out of your team, especially if they fall below their agreed SLA threshold. Make reporting less daunting and more fun by fostering a little healthy competition and regularly recognizing excellence versus key KPIs. You could choose the quickest resolution time, the highest rating on a feedback form, or the number of tickets closed within a day; and offer up an incentive for the winner such as leaving early, a chocolate bar, or even just their name at the top of a leaderboard. The reward part of “reward and recognition” doesn’t need to be costly.
Hitting targets should be fun. Yes, recognize underperformance, but don’t let it override the great job your team does on a daily basis.
4. Did someone say rodeo?
Inject friendship and fun into your working environment by organizing regular socials.
Gallup research has shown that close friendships at work produce a 50% increase in employee satisfaction
, and having a close friend at work increased the likelihood of engagement by seven times.
So try to support the cultivation of friendships within your team, through social events such as team building excursions, casual team lunches, or networking events. And remember that happy employees are more productive employees! Research from the University of Warwick has confirmed that being happy made employees about 12% more productive
and, you guessed it, more motivated.
5. Banish the barren work-land
Ensure that the work environment is pleasant and inviting. Research
by the International Journal of Science and Research has shown that:
“The quality and quantity of work generated by employees are influenced by the work environment while poor environmental conditions can cause inefficient worker productivity as well as reduce their job satisfaction.”
So assess the environment your service desk agents work in. Hopefully your team isn’t packed into a dingy office, filled with old IT equipment, like in the IT Crowd
. Consider the lighting, temperature, noise, layout, decoration, cleanliness, equipment, furniture, and air quality. Let team members give you input to sensible environmental and ergonomic improvements. Help to create a sense of pride in the work area by allowing your team to embrace their individuality and feel ownership over their personal workspaces. Invite them to make the workplace their own, and if you can find the budget, spend some company money on making it a better workplace.
Time to Round It Up, Cowboy…
Happiness and job satisfaction have been scientifically shown to increase productivity and motivation in the workplace. So try to create the kind of atmosphere that makes your staff come to work every day, not because they HAVE to, but because they WANT to.
- Listen to your staff and instigate a collaborative feedback cycle. Communication is crucial.
- Recognize each member of your team as an individual.
- Gamify your metrics to motivate your team to hit their KPIs.
- Inject friendship and fun into your working environment by organizing regular social events.
- Ensure that the work environment is pleasant and inviting.
Posted by Dena Wieder-Freiden
on September 20, 2016 in Service Desk
tells us that there are three components to business value:
- Business outcomes
- Customer perception
- Customer preferences
Once this has been successfully memorized for the ITIL Foundation Certification
exam, most people then forget it. That’s a shame because it gives an insight into why customers might be less impressed with the services they’re getting than expected. In this blog, I’d like to take a look at how each of these concepts can help us get things right.
IT service providers generally focus on what IT applications and IT infrastructure actually do – their outputs. But to deliver genuine value, we need to think in terms of outcomes – the end result for the customer and the organization as a whole. So, a service provider’s first challenge is to see beyond initial outputs from their IT services and understand the outcomes: how they influence the customer environment. That requires learning about the service in the customer environment, things like:
- What business services does your IT service support?
- Never mind what you meant, how is it actually used? (In fact, is it actually used at all?)
- How many of the features, which you got excited about building, are exciting to the business as well?
We can illustrate this by analogizing it to the difference between using a car and a requirement to travel. The outputs of owning a car are about driving; the outcomes might be the ability to get to work or the shops, or impressing the neighbors with what you can afford. Seeing the difference would help you choose the right car – or perhaps even suggest alternatives like traveling by bus or train.
Think about it. This is a serious and important jump for many in IT. It’s about seeing beyond the initial functionality, but it’s only a part of the challenge to real business-IT integration and customer satisfaction.
Perception and Preference
In order for a service (or that car) to deliver any value, the customer has to be in a position and a mindset to receive it. If not, then the best of all services will not be of any actual use.
Let’s stay with cars a moment. I lent my car to a friend, who returned it remarking on how easy it was to drive. I agreed, commenting specifically on how useful the cruise control is. My friend reacted with: “Cruise Control? Where is that?” This proves my point – if you aren’t aware of something, then it’s impossible to get value from it.
That kind of scenario is repeated in an IT context every day around the world: “Wow, I didn’t know it could do that”, or “where did you learn that?” At home, a few of us know all the features of our TV, DVD player, or cable TV. We have reached a stage in the evolution of technology where the users of that technology rely on intuition rather than training, and so services must work in a way that is obvious without words
. Unless it’s clear what a service can do, it will not get used, and the service provider’s efforts will not be appreciated – nor willingly rewarded.
And even knowing that the service is there at all can be a challenge without an easy-to-use and comprehensive service catalogue that the customers can reach – and feel is worth reaching and exploring.
This is an area that can really undermine the hard work put in by a service provider. Appreciation of value rests on the attitudes of the people you are supplying. And, just about always, people are the least predictable element of any organization or situation. No matter how well you think you know them, they can surprise you. Add to that the fact that IT services are typically supplied by
IT folks to
business folks, and you have a “disconnect” of preferences just waiting to cause troubles.
Once more, let’s use a car analogy: many years back, our family was searching for a new car, so my husband took me to see what he had found at a car dealer, confident he had found us the perfect solution. The car was strong and fast (as we specifically wished it would be), a model we knew, was in good condition and at a good price. So…no question for him, we should buy it. But I had to reject it…because it was white! Of course I didn’t want a white car, no matter how well-matched to our other needs it might be. How could he have not known that when it was already so clear and obvious to me ;)?
That kind of preference can look like bias, unreasonableness, or even bigotry. But even if it is, it is real, and a supplier must cope with it and deliver something that is acceptable.
For an IT service, the customers may have strong feelings about how the interface works, and reject one that doesn’t work “their way”. Or it may come from a source they disapprove of. Without establishing those preferences beforehand, once again IT service providers will be working hard to deliver something that will not be appreciated.
Knowing, Learning, and Matching
So, what I’m trying to say is – to be a successful service provider, it means getting out there and understanding not just what your customers need, but their attitudes, likes, and dislikes. In a large organization maybe you work with your business relationship team, or account managers, to help bridge the perception and preferences gap. Then again, there is no real substitute for getting out, talking, and listening to your customers yourself.
For more on this topic, I highly recommend you read Stuart Rance’s blog “What Value Are You Creating from Your IT Job?”
Posted by Sarah Lahav
on September 13, 2016 in Service Desk
“Customer experience” you say. What the heck is that?
If this sounds like you, don’t worry, you’ve come to the right place. You see we’re big evangelists of the customer experience
and believe that it’s something that every organization should have the opportunity to wrap their head around and to introduce into their business.
Why? Take a look at organizations such as Apple, Disney, Virgin, and Tesla. What’s the one thing that these companies all have in common? Other than being some of the biggest names in the world of customer service (as well as all being valued at over a billion dollars or more), they all understand the importance of the customer experience, and have “gone above and beyond” to ensure that their organizations are finely-tuned customer experience machines.
Yet, What They’re Doing is Nothing New
In fact, the entire idea of customer experience is nothing new. A quick bit of Googling and you will discover that the UK department store John Lewis
has been crafting its customer experience for more than a 100 years.
What is new, however, is that more and more organizations are taking customer experience on as a means to improve their competitive advantage through wowing their customers.
So What Does this Have to Do with ITSM?
In IT, and in IT service management (ITSM) roles in particular, we strive to provide great IT services but many of us have yet to make the leap to providing a great service experience. But who can blame people? It hasn’t been on the IT or ITSM radar until recently. For instance, ITIL
, an ITSM best practice framework, offers advice on how to create and deliver great IT services but it doesn’t outline how to offer a great customer or service experience.
“But why is it on the IT and ITSM radar?” I hear you cry.
The simplest answer is: consumerization. Not the consumerization of IT but the consumerization of service. Just as the consumerization of IT has been about the rising employee expectations of corporate hardware based on what they have in their personal lives, the consumerization of service is the rising employee expectations of corporate service providers based on personal-life experiences of service and support.
So while many IT organizations might be focused on delivering better customer service, employees empowered by their consumer-world experiences are now expecting a better customer experience.
Is Customer Service Miles Apart from Customer Experience?
Service and experience are similar but they are not the same.
is the interaction between the customer and the service. However, it doesn’t just reflect an outcome but also the emotional feelings a customer has towards the service (and service provider) too. And these feelings are based on a number of variables, especially touchpoints such as ordering, paying, and how issues are dealt with. It’s every touchpoint in the customers’ journey, every part of your service, affecting their experience.
A more formal customer experience definition is:
“The process of strategically managing a customer's entire experience with a product or company.”
~ Bernd Schmitt
And to really understand the customer’s entire experience, you need to see the service from their point of view
Step into Your Customers’ Shoes – Look at Their Customer Experience with Customer Journey Mapping
Customer journey mapping (CJM
) tells the story of the customers’ experience, from their first contact to their last, all the way through. It’s a useful exercise to help service providers to identify the touchpoints in a service
and where the customer experience can be improved.
Whether you’re using a customer journey map to look at a specific part of the customer journey, or the journey as a whole, you’ll quickly be able to identify:
- The key interactions that your customers have with your service
- How the interactions make the customers feel
- What the customers really want from you as their service provider, and
- Where the gaps are, that you need to fill to make the customer experience even better
What Does This Look Like in Practice?
Imagine the corporate self-service password reset service as an example. Normally when we think about something as “simple” as this, it’s easy to assume that the route to a successful outcome is equally as simple.
Without first mapping the customer journey out, it would be all too easy to assume that the journey might look like this:
- User logs into the self-service portal
- Searches for the password reset facility
- Resets password and returns to working
However, through the use of CJM we can start to uncover the additional steps that often go unaccounted for; and with it, the gaps or issues that are disrupting the customer experience.
So with the help of CJM we might discover that self-service password reset actually looks something like:
- User can’t log into their machine
- Tries multiple times to log in with no success; is convinced that it’s an IT issue
- First tries calling the service desk but can’t get through and gives up
- Resorts to self-service portal even though they don’t like using it
- Discovers the search facility in the self-service portal
- Types in “password not working”
- The search facility doesn’t show any related results (as the search facility hasn’t been “tuned” for different variations of “password reset”)
- Eventually stumbles on the password reset facility as they definitely don’t want to queue in the service desk’s telephone channel again
- Starts process to reset password
- Asked to check email to set a new password, but can’t access email because they are locked out of their machine and don’t have webmail or access via their mobile phone
- Tries to call service desk again ...
As you can imagine, the experience for the end user is far from a positive one. In fact, from an emotional perspective it’s probably extremely frustrating and another reason for IT’s name (and reputation) to be dragged through the mud. But without the process of CJM, it’s very unlikely that you’ll ever become aware of all the additional steps that your user has to go through to get the resolution they’re searching for.
What’s more, a successful journey map might initially leave you with more questions than answers, as well as the desired outline of where you need to improve. Here’s an example of some of the questions that might be raised re the previous scenario:
- Why did the user try calling the service desk before trying the self-service portal?
- Why couldn’t the user get through to the service desk via the phone?
- Has the user ever been properly educated in using the self-service function?
- How easy is it to discover and use the search function when you don’t use “IT’s language”?
- Was there plenty of up-to-date and relevant documentation to help make the password reset process easier?
- Has anyone from the service desk used the self-service password reset themselves to test for any use-case scenario “bugs”?
It’s this kind of investigation that will force you to start thinking differently about your current service and makes looking for issues and gaps a much easier experience.
In the earlier password reset example, the IT departments is offering a poor customer experience even though it might think it’s offering good customer service through the provision of such automated capabilities.
Connecting the Dots Between Customer Experience and Customer Service
That’s a lot of theory, so how do you apply it practically? Luckily for you, creating a seamless customer journey doesn’t need lots of tools and investment and it can be kicked off with just a group workshop, a flip chart, and a whiteboard. Here’s the steps:
- Gather together your service desk team members and brainstorm each element of your service.
- Create a stakeholder map including their influence.
- Create a customer persona based on one person or a segment of customers.
- Focus on a customer outcome, interviewing and observing customers at different stages of the customer journey.
- List the actions (touchpoints) a customer would take to reach that outcome horizontally, step-by-step, for example “initial contact” or “ticket submission.”
- Then list all of the relevant channels that customers connect with while using your service vertically, such as website, email, face-to-face, or telephone.
- Make sure that you capture the customer touchpoints.
- Each touchpoint needs to then be assigned an owner, whether that be the service desk manager, incident manager, problem manager, or someone else.
- Jot down how the touchpoint impacts the customer experience including the needs, perceptions, emotions felt at each stage, and what a successful customer experience looks like.
- Now repeat the process for your ideal customer journey. This can be used to compare the actual to the ideal, to identify gaps in the customer journey.
- Where gaps in customer experience are uncovered, brainstorm improvements and set priority actions.
You can find more detail via Google where a search will bring back “how to” information such as “How to create a customer journey map
Use CJM for the Service Desk or IT Service Delivery
So while ITIL has moved corporate IT departments from a technology-centric world to a service-centric one, more steps are needed if the departments wish to be more customer-centric.
CJM can be a great input to this, getting all team members “on the same page” and encouraging them to think about how to improve the customer experience not just customer service.
Have you tried customer journey mapping and, if so, how was it for you?
Posted by Sarah Lahav
on September 6, 2016 in ITIL
We all know IT organizations that run into difficulties working with their suppliers. They seem to really struggle, enduring fractious relationships and contracts that don’t meet their needs. On the other hand, some IT organizations enjoy positive relationships with a range of suppliers and seem able to get really good value for money. What is it that helps them achieve this? And what gets in the way?
Some Contracts Are Not Perfect
Some of the IT organizations that I work for rely on their procurement department to manage their suppliers. I’ve worked with a number of IT organizations that have less-than- ideal contracts with their suppliers due to typical scenarios like this:
- IT gives their requirements to procurement.
- Procurement negotiates and agrees on a contract with a supplier.
- The contract is not an exact match to the original requirements, as procurement has made a decision based on cost, and the ability to meet what they consider to be the most important requirements.
- The IT organization is then left to pick up the pieces and manage as best they can.
The contract doesn’t meet the required needs, the supplier isn’t helpful, the customers aren’t happy, and IT gets the blame. But it’s not their fault - and the contract has another five years to run.
Good supplier management can help you to manage situations like these. You may be stuck with a poor contract, but that doesn’t mean that you have to put up with poor service from your supplier.
Everyone Needs Supplier Management
All IT organizations need effective supplier management, because they all need a wide range of suppliers to help them deliver services. Sometimes there are suppliers delivering nearly all of the services, in which case these suppliers have to be managed. But even if your IT department has a supplier doing Supplier Integration and Management (SIAM) so you don’t have to, you still need to manage that supplier!
At the other extreme, you may come from an organization that runs all of its IT in-house, with your own software developers, service desk, infrastructure, and support. But you still have suppliers to manage. Even if you use only open source software, with no license restrictions or costs, you still have to obtain electricity and internet connectivity from suppliers. And very few organizations are big enough to deliver their own level 3 operating system support, even if they have open source operating systems.
So what can you do to manage suppliers well?
Three Levels of Supplier Management
There are three different timescales over which you need to do supplier management, and each of these needs a different approach, and each may be done by different people.
|Strategic Supplier Management
||Decide which suppliers to work with.
Negotiate and agree contracts.
|Tactical Supplier Management
||Review supplier performance regularly (usually monthly).
Manage service levels.
|Operational Supplier Management
||Manage day-to day work activities, for example escalating incidents to the supplier or accepting deliverables from them.
Strategic Supplier Management
This is the activity that is often carried out by a procurement department. It involves deciding which suppliers you want to work with and carrying out any legal, regulatory, or compliance checks to ensure that you will be able to work with them. Then, for each individual contract, it involves documenting the requirements, managing a process to enable suppliers to bid for the work, selecting a preferred bidder, and negotiating and agreeing a contract. There may be annual reviews, but usually the strategic component of supplier management will not have anything more to do until the contract is due for renewal. Getting things right at this level can avoid a whole host of problems further down the line.
Tactical Supplier Management
Most contracts include service levels, which are reviewed at regular meetings. Typically, this will be a monthly review, although the frequency can vary depending on the contract. Where there are many detailed numerical performance measures, which are used to set penalties and rewards, this often results in long and bad-tempered meetings where each side is more concerned with proving their point than with discussing the service…and agreement is hard to achieve. (See What behaviour do your SLA targets encourage
for more discussion of performance measures.)
When tactical supplier management is done well, conflicts are much less likely to happen. For example, one organization that I worked with used a simple spreadsheet to rate all of their major suppliers against the same set of criteria, such as:
- Delivering contractual obligations
- Responding to ad-hoc requests
- Customer experience
Every supplier received a monthly rating on a scale of 1-5 against each of these criteria, and every supplier saw not only their own score, but that of all the other suppliers. As a supplier myself, I found this incredibly helpful. I knew exactly where I stood and what my customer thought of me. I was incentivized to be “top supplier” each month, and when the contract was due for renewal I could tell the sales person that we had been the best supplier for the past 8 months. This was a real win-win because the customer was driving me to deliver what they needed, and I was able to focus on the things they really cared about.
Tactical supplier management is the level for facilitating continual improvement of the service. Work with your suppliers to put in place a Continual Service Improvement (CSI) register for each contract, so that you actually help your supplier to get better at doing the things you need them to do. Don’t use this as a stick to beat them with, but as a tool to help them to help you. If you’re not familiar with CSI then try reading The Help You Need to Adopt Continual Service Improvement.
Operational Supplier Management
Sometimes suppliers let us down because we don’t do enough to help them get it right. It is really important to ensure that every time we interact with the supplier, we give them everything they need to help us. If the supplier is running a service desk, then we must make sure they have a good description of the incident; if they are providing support to a project then we must make sure they have everything they need to deliver; and so on. It’s helpful to think about your interactions with your suppliers in exactly the same way as you think about interactions with your customers - from the perspective of customer experience.
It's All About Relationships
You do need a contract to define what the supplier will deliver, and what you will pay for this, but a contract is never enough.
You should recognize that your supplier is entitled to make a reasonable profit on the contract, and they should acknowledge that you are entitled to a decent level of service. As long as both parties agree on those two points, it’s usually possible to find a way of managing any contract deficiencies. If you have a good relationship, then anything is possible! Maybe you can allow them to miss some less important service levels that are difficult to meet, and in return they can focus on exceeding the contractual targets on the things that really matter to you. Maybe you can use continual service improvement to gradually tune the deliverables to the point that they are exactly what you need. The bottom line is that truly effective supplier management helps your suppliers to help you, rather than just giving them a hard time when they miss their targets.
Managing suppliers involves thinking about three levels of activity: strategic, tactical, and operational. Each of these levels makes a contribution to supplier management, but the most important thing you should do is to build a relationship with your suppliers.
If your current supplier relationships are confrontational, based on disputing penalties and rewards every month, then try stepping back and thinking about how you can help your suppliers to help you. If you get it right, then you will both benefit.
Posted by Roy Eldar
on August 30, 2016 in ITIL
I was thinking about incident management
and categories and it came to me that really, every single day, we find ourselves being categorized and pushed into a specific pigeonhole. In fact, it happens so often and naturally that we’ve come to expect it:
- Like in the frequent surveys after online purchases when we’re asked to choose from a pre-set list of responses, for example “good, average, bad,” or “rate us from 1 through 9”
- When we buy insurance or complete a tax return, we must always choose a work classification. If we don’t fit into one of their pre-set categories, then we just have to pick the nearest fit.
- And, of course, when we log a call, even if we (as end users) aren’t presented with a list to choose from, we know the operator, whether human or automated, is deciding which of their little virtual boxes we best fit into. And if it’s via a self-service portal, we’ll end up choosing our own best-fit pigeonhole.
I mentioned insurance above deliberately since a friend of mine just changed his job role from marketing support to a training role. When the insurance company was advised of this role change, the premium increased by 7%. Now that’s the power of categorization!
Categories Help Us Process Data Meaningfully
While we may not always like it, or might feel that it isn’t human-oriented, this kind of categorization is a vital part of getting data and metrics collected, analyzed, interpreted, and used for improvement. Without categories, the data we collect cannot be easily turned into useful information and knowledge. But with categories our technology can process the data. It becomes more science, less art, and we have far easier reporting, trending, and pattern recognition – all of which should make managing the service delivered better, for suppliers and customers alike.
Why Incident Categories Matter
What that means for us in IT service management (ITSM) is that we need to take this seriously, get it right and keep it right.
The most obvious part of ITSM that needs good categorization is incident management (that’s where I started, at the beginning of this blog) – designing, capturing, and maintaining the incident statuses that will help us in our work. While you might think that an incident category only affects incident management folks, in fact the consequences of this categorization are far reaching. And because of the range of impact, one set of incident categorization isn’t likely to be enough. Instead there is usually a need for two sets: opening and closing categories, plus a great deal more of pre-set categorization along the way from one to the other.
Allow me to illustrate that with a simple example. Say you’re trying to create an invoice using a financial support service, but when you print it the figures don’t line up and the total overlaps the edge of the page. For sure, something is wrong, so you call the service desk. Sometime in the future, the support professional who diagnoses and resolves this mistake will establish what caused it. We can imagine it might be the financial software, a hardware issue in the printer being used, network transmission, a mistake by the user, or something else entirely. But at this point, and certainly from your perspective as the caller, this is a fault with the financial service, and it should be categorized that way. If the service manager is not going to be aware of issues, it will look very unprofessional going to a review meeting without knowing how many calls have been logged relating to that service.
Getting the categorization wrong, or failing to categorize in a way that’s meaningful to service managers, will mean that the right information is not gathered and not having the right information inevitably makes other folks’ jobs that much harder.
Reaping the Benefits of Categorizing
On the other hand, once the investigation is done and an underlying cause found and fixed, it’s important to get a closing categorization that matches to the cause. Here you’re more likely to be looking at hardware, software, and the like – and perhaps also identifying the source, age, location, etc. of the offending item. If this categorization is wrong, then it’s hard to pinpoint faulty items and prevent them from causing future issues, like suspect batches or suppliers (internal and external) going unnoticed for too long.
The data collected during incident management needs to be categorized to allow easy and meaningful processing into information and knowledge. We need enough categories to reflect the range and indicate areas for concern; but not too many categories that we make it difficult to select the right one in the limited time we have when logging calls or updating records. It should be an ongoing challenge and balance between too many and too few, and to keep the categories reflecting our needs – and that changes over time. You can read more about that in this blog
by Stuart Rance.
Could This Be a Lever for Your Improvement?
Do your categories reflect your organization’s needs? Do they offer initial matching to the customers’ and the users’ concerns? When incidents and errors are closed, does your categorization match the needs of problem, knowledge, capacity, availability, and supplier management? And if not, who is responsible for getting it right? And do they have the budget, support and understanding to make it better? If they don’t, then your ITSM performance will not be anywhere as good as it could and should be.
Posted by Dena Wieder-Freiden
on August 23, 2016 in Service Desk
I recently ordered some items from a web site that I’d used before. The checkout price was $30, which I paid with a credit card and then forgot about it and got on with life while waiting for the items to arrive. A few days later I was checking my credit card statement, and there was the transaction, but at $31.85! Of course $1.85 isn’t worth too much effort, but it wasn’t the money, it was the principle. So I went back to the website and submitted a ticket pointing out the error. Within 30 minutes, I had a profuse apology and compensation with $10 worth of freebies - nice!
Truth is, I made lots of purchases lately, but all of the other purchases were below my attention threshold in terms of service. I clicked to place the order, and then I clicked to make the payment. That payment left my account as expected, and the goods came to my door, also just as expected. They were perfectly ordinary, everyday purchases. I might talk to my friends about what I had bought, the good (or not-so-good) price I paid and so on, but I wouldn’t mention the service quality.
When you think about it logically, that is what good service should be – all but invisible, delivering what you expect without fuss or incident. So, why was the one transaction that went wrong the one I ended up most impressed with? Certainly it has a lot more to do with human psychology than service performance, but still very relevant to anyone working in the IT service management
Failure Facilitates Good Service with Fixers as Heroes
As you can imagine, I was thoroughly delighted and impressed by the speedy, polite customer service of the company that accidentally overcharged me. I was happy to get some extra products for free and enjoyed telling my friends what great service this company offers.
But here’s the conflict then. The companies that got it properly right, I didn’t praise and publicize. The one that got it wrong, but corrected it nicely, is the one I felt most pleased with. So is the message here not to be too good? Should we strive for minor glitches and good fix rates, or should we aim at delivering what we’re supposed to?
Of course, for some services, in some situations, you’d feel that ‘getting it right’ without fuss or visibility is essential. Think of open heart surgery or flying a plane. And yet, even then, one of the great recent heroes is the pilot that landed the crippled plane on the Hudson River
. I also recall a conference with three great motivational speakers – all of whom had failed to do what they set out to do but were impressing folks with how they had dealt with the failure.
In fact, if you look at the way many ITSM teams operate, they do still give more emphasis to fixing failure than preventing unplanned occurrences. Ask someone to talk about what ITSM covers and many will still start with the service desk, incidents, and fixing faults. Is this a failure of ITSM culture? Instead of having things fail and then fixing them quickly, shouldn’t they focus on actually delivering without any mistakes, making life as easy as possible for the customers? Too often, correcting failures drives customer appreciation more than just seamlessly providing services or goods without any mistakes.
Should We Step Down from Perfection?
If we’re too perfect, will we be so unappreciated that we find we’re no longer seen as valuable and be punished for our success: de-funded, outsourced or passed over for promotion?
Perhaps one key to solving this conundrum is by education: making customers and staff realize what true success should look like. We all need great fire-fighters available should the fire break out. But we don’t really want to see them in action. What we want is smooth and effortless service. Perhaps I’ll go back and check on all the other suppliers who did deliver and start telling my friends how good they are!
Where do you stand in this conflict? Do you worry more about fixing errors than keeping them away? Do you put effort into making your staff see that their prime job is service delivery, not service repair? Or are you pragmatic enough to let things break a bit, to show how well you can fix things? Maybe you’re even tempted sometimes to break them, engineering a situation to showcase your fault-fixing prowess? No, of course you wouldn’t :).
Posted by Sivan Kroitoru
on August 16, 2016 in ITIL
Why do we IT service management (ITSM) people have trouble understanding and predicting how our customers and other colleagues in the business will behave?
Really understanding the customer’s perspective requires more than good intentions. On occasion, our own attitudes and preconceptions get in the way. Sometimes it feels like we’re struggling to understand a foreign language, and there is a reason for that – in a way, that’s exactly what is happening. Our own opinions can deflect us from accurate observations, seeing a familiarity that isn’t really there.
A Language Lesson: False Friends
When we see familiar things, we relax our guard, trust our instincts, and make presumptions. This can cause trouble. An example is false friends
between languages – we see or hear a word or phrase in another language that is very similar to one in our own language, but it means something very different. Sometimes it’s just amusing. Doors labelled in English are a nightmare to Portuguese speakers, for example: if a sign says “push” they are more likely to pull it, fooled because the Portuguese word for ”pull” is ”puxe”, pronounced ”pushay”. You can understand the confusion.
Other examples can hurt more than your pride – many Dutch words mean what they sound like in English, so see ”fietspad” and you might presume fiets = feet, pads = path and you stride confidently along what must be the footpath. Good logic but actually ”fiets” is bicycle and you are walking on the bike track; it will be your fault when a fast Dutch bicycle hits you. Yikes!
It isn’t just languages that fool you this way, as you may have noticed when travelling by air in recent years. Every airport must be equally concerned to prevent dangerous items being carried on board, and every airport has similar looking equipment to find metals, liquids and other dangerous stuff. You may have gone through security at the airport with your shoes on, but when changing planes a few hours later, you are told to take those same shoes off before passing through what looks like an identical piece of detection equipment. Familiarity doesn’t necessarily deliver knowledge.
False Friends in ITSM
It isn’t just foreign languages that can lead us astray: confusion and deception can affect us in our work environment as well. In fact, it affects service providers, customers, users, and probably just about everyone else too. Cultural factors drive this when we supply services across cultural boundaries. Those boundaries could be linguistic, geographical, generational, functional specialism – or a mix of them all.
These kinds of false friends can present themselves in a range of ways:
- Business jargonmeans words acquire very specialist meanings within professional areas. Think what we (ITSM people) have done with words like “problem” and ”incident”. Upon hearing our customers talk about problems, we shouldn’t presume they mean what we mean. And those customers will have their own specialist terms that we might hear and think are used in their everyday sense.
- Behaviour and reaction to situations can fool us too.Warning messages that would stop an IT professional in their tracks could just be seen, and ignored, by a customer with a different perspective. You might see ”insecure connection” as a reason not to proceed; others may just see the words but not the implications. The picture here – taken in a small company’s kitchen – shows that just asking nicely doesn’t always deliver the behaviour you wish to see. Just because you would respond to a polite request doesn’t mean others will; maybe more extreme measures are needed for some people.
- Expecting others to care about what you do.Drivers see a wide range of attitudes to speed limits. Some always and immediately adjust their speed to comply, others ignore them altogether, while many will compromise – driving somewhat over the limit, but not what they see as too much over. In fact, telling people to do something doesn’t necessarily mean it will happen, as the picture above shows. It is a false assumption to think others will follow an instruction just as you would.
Preventing Damage – Some Actions to Adopt
It is possible to avoid the effect of being fooled by misconceptions and misinterpreting other’s attitudes. Here are six ideas that might help you:
- Understand that these situations exist and will happen to you. Realize that your customers think differently, with their own preconceptions and expectations. Try not to presume you know what people mean, that they will know what you mean or behave as you would.
- Learn key aspects of your customers’ behavior and language. Talk with – and listen to – them; see how things have gone in the past and learn from that. Build those differences into your knowledge management system so your team and your colleagues are warned and prepared. The most powerful tool is being able to admit you don’t know their world and being willing to ask what things mean.
- Don’t fall into the trap of unconsciously imposing your views on others, so called accidental cultural imposition, where you presume others see the world the way you do.
- Understand where you and your people act in a non-standard way, be aware of the specialist jargon and attitudes that you have. Try to remove jargon; a glossary might help, but using widely understood words is better. At the very least, be aware of the terms that might confuse (incidents, problems) and be expecting issues.
- Find common ways to establish and maintain communication channels. Very often it is social communication that exposes difficulties in business communication. Don’t underestimate the benefits of treating your customers as people, rather than the last part of your service delivery process.
- Recognize communication failure as an accepted cause within the problem management system. It then becomes something that can be addressed and improved, but only when it is recognized as something subtler than “user incompetence”. Far too often, user blame is the attitude, rather than seeing an opportunity for clarification.
Of course, it isn’t just a case of you being fooled by your customers; you will probably be confusing your suppliers too. Those suppliers might be blaming you for things that can be solved by conversation and mutual understanding. Could you get a better service if you worked on a shared understanding with both your customers and your suppliers?
Perhaps the real key aspect is to be honest about your own preconceptions and attitudes, and this will help you to recognize them in others. What do you think?
Posted by Oded Moshe
on August 9, 2016 in ITIL
Configuration management is about collecting and maintaining useful information. In IT service management (ITSM), this means knowing about everything from hardware and software through to documentation and people – all of which is used to deliver services. We collect and hold data about those items, including information on how they are connected together.
Configuration management itself is way older than ITSM, with its roots firmly in old-fashioned engineering. Although we don’t know the equivalent term in Ancient Chinese, Egyptian, or Mayan, I guarantee that configuration management was being done in those times. They all must have understood the principles in order to get the Great Wall, the Pyramids, and Stonehenge right. And those creations look relatively simple compared to the bridges, ships, and railroads that mechanical and civil engineer Isambard Kingdom Brunel
and his successors were building – and crucially also maintaining – in the 19th
Of course the world has changed but there are lessons from that old engineering perspective that still have value today. At the same time, we should be very aware of how configuration management needs to be different for our new IT- driven world.
Should We Capture Everything We Can?
At first sight Configuration Management seems to be telling us to capture as much data as possible. After all, you can never have too much data can you? Big data is still a valid fashion goal for ITSM, so configuration management capturing as much data as it can sounds like the right approach.
In fact, however, pay attention in your ITIL®
Foundation course and you’ll learn otherwise. ITIL teaches that there are situations where we shouldn’t gather configuration data, such as:
- When we know we cannot be certain to capture changes and keep the data up to date.
- When capturing and maintaining the data is going to cost us more than the benefits we will get from knowing it.
And besides these things we might choose not to record, we should also learn to accept that that there are some things we simply will never be able to capture.
These concepts and caveats were central to having reliable configuration data in the past, certainly pre-IT and also in 20th
century IT. Back then everyone recognized that some items simply could not be monitored with sufficient frequency and accuracy to keep the information up-to-date and relevant. The driving thought was that it was better to know you didn’t know, than to think you knew and be wrong, making decisions on false inputs.
That Was Then and This Is Now
There is an argument for that concept – of some items being unmonitorable - being out-of-date and no longer a concern or, at least, much less of an issue nowadays.
With modern software tools, we can automatically find software and hardware across our multinational infrastructure, and our tireless technology can look for updates and changes several times a day if we wish. Nowadays, the internet of things
(IoT) can even come and tell us when things have changed, not waiting to be asked by the software but proactively enthusiastic to tell us. And the plummeting cost of processing and storage means maintaining the data should be so much less of an issue.
Configuration concepts – like variants – that made sense in the past are no longer sensible with modern data systems allowing multiple views into a single set of data. Variants were a popular exam question in ITIL V1 and V2 days, but disappeared when V3 arrived – a sign that the guidance does evolve J (and if you never needed to learn about them, don’t do it now, it doesn’t matter anymore.)
But Can We Use All that Data?
Technology has provided us with the ability to capture and hold just about everything, but maybe there’s still logic and reason in not capturing some things. I mean, besides the technology we still need processes and people to turn the data into something useful, right? I’d say that keeping technology, processes, and
people in balance is one of the skills that differentiate good ITSM organizations from the rest.
There are a few things to consider when looking at how the almost limitless data can be used:
- How often, after something has been missed, does it turn out the data was there but was not seen amongst all the other data being presented?
- Does staff typically only access a part of the available data – the bits they have used before – and leave most of it never seen?
The still relevant underpinning question to all of this remains: can we turn the data we capture into information and then into knowledge?
Because only then is it useful, and that takes us back to some of the configuration management thinking of earlier days.
While the technology might make it possible to capture any data we can possibly conceive of, we still need to ensure the processes and people, who are part of our ITSM organization, can cope and make sense of it – fast enough and accurately enough to be useful.
Aim Before Firing
Hitting everything may be effective, but it’s rarely as efficient as aiming for what is needed. Knowing what to aim for comes from understanding what is to be achieved. There is still value in knowing why you want to know something before you start recording it, and that is still driven by the priorities of the organization as whole. Maybe we still need to ask ourselves the same question our parents did – what configuration data will offer us the best value?
And use that as our starting point.
Posted by Stuart Rance
on August 2, 2016 in Service Desk
My colleague Ivor McFarlane
once described the concept of intelligent disobedience
to me. This term was first used in relation to guide dogs. Service animals need to be trained to obey their owners. However, there may be times when the dog has more knowledge about the environment than the owner – for example if the pedestrian crossing light is green but a car is approaching very fast. In that case obedience would actually pose a threat to the owner’s safety. Dogs can be trained to exercise judgement and to refuse to obey orders when this is the case. This idea has important business applications; we can train staff to exercise judgement rather than always mechanically follow rules or predetermined scripts. Staff who know when they should NOT follow the rules, and who are empowered to act on this knowledge can make better decisions.
Ivor has written an excellent blog on the topic
if you want to learn more.
When you are aware of a concept such as “intelligent disobedience” you find yourself noticing situations to which it applies. I was shopping in a large department store recently, and I spotted an unfortunate interaction between a shop assistant and a customer. The customer was a young woman, who was very modestly dressed and wearing a headscarf. She approached the changing rooms and spoke to the male shop assistant on duty, asking: “Do you have any female staff members in this area?” The shop assistant was very polite and explained that there were female staff members, but they were all “too busy” to serve customers at the moment, and he couldn’t interrupt them. He explained that he was responsible for serving in that area of the store and offered to help her himself, with every appearance of enthusiasm.
The customer didn’t make a fuss, she just quietly declined his offer of assistance and left. Presumably she went to a different shop, where they might actually listen to what she was asking for and make reasonable accommodations for her needs.
I wondered why the young sales assistant failed to recognize that the store was about to lose a probable sale. I wondered why he felt he couldn’t “interrupt” a female colleague, but had to serve the customer himself. I wondered what all the female sales staff were doing that could possibly be more important than selling to the store’s customers. I also wondered whether that disappointed customer would ever be back.
Teaching Service Desk Agents about Business-Focused Empathy
So how does my story above relate to the service desk?
Well, I have seen many similar interactions between users and service desks. What look like small failures to understand what users really want can be symptoms of a systemic failure to see the way things look from a user’s perspective, and can lead to low levels of satisfaction. Just like the young woman in the department store, users may decide to go elsewhere for help, and this can result in poor efficiency for both users and the IT organization.
Of course, a typical service desk tends to be very busy. It deals with a huge number of issues, and the sheer volume of work may mean that the service desk is simply not set up to deal with users as individuals, each with their own specific concerns and issues.
This is where the right kind of training comes in. It is vital to train service desk agents to follow the rules, and stick to the defined process, except when that is the wrong thing to do
. Any agent that keeps breaking the rules, and rarely follows the process, is going to cause a lot of issues. This should be followed up – the agent may need retraining, or indeed, the rules themselves may need to be reviewed. BUT an agent who follows procedures slavishly, even when this results in pain for their customers, is also doing the wrong thing. We must teach service desk agents a kind of business-focused empathy. They need to think about the ways in which their actions affect users and customers. They need to know how to listen to people and to consider the impact of the support they offer on the customers’ business processes.
For example, when a user reports that their printer isn’t working, the service desk agent probably has a pre-defined script to follow, and the interaction may end with someone being dispatched to replace or repair the printer. These scripts obviously help the service desk do the right thing most of the time, which means that responses to routine issues and requests probably run efficiently. But sometimes following the script may not be right for the customer. And if (like the shop assistant in my department store story) staff haven’t been trained to recognize when being “too busy” to do things differently is inappropriate, then business outcomes will be adversely affected.
If the user really needs that printout very urgently, then waiting for the printer to be mended may be the standard response, but it’s not the right one. One of my customers had an excellent service desk, and one of the things that made it excellent was that the service desk agents really understood the business, and were trusted to use that knowledge, even if it meant departing from the standard scripts. When a particular user called the service desk to say that their printer wasn’t working the agent understood that waiting for a repair wasn’t a viable option. Instead the response was “Email the document to me. I’ll print it out and bring it to your desk”. Now clearly this isn’t the way to respond to every printer fault, but in this particular case, the agent understood the urgency of the need for the printed document, felt empowered to use their initiative, and responded correctly.
How Can You Encourage Intelligent Disobedience?
If you want your service desk agents to make the right decisions, then your management must create the environment where this can happen.
Firstly, you should communicate the organizational vision and values to all your staff. Make sure that everyone knows what is important to you as an organization, and as an IT department, and as a service desk. Give them a clear understanding of how the organization creates value, and how they contribute to that. Ideally you should provide them with opportunities to spend some time working in other business units, so they can learn about what is important to their users.
Secondly, you should measure and reward the behaviours you want to encourage. Get people to report when they went outside the process to delight a customer, and then ask those customers for feedback. Maybe you could create a “customer advocate of the month” award, or something similar to show that you really do care about this.
Thirdly, make sure that your governance framework supports intelligent disobedience. Review your policies and procedures and make sure they have sufficient flexibility to allow people to do the right thing.
And Finally …
It’s time to reflect on the title of this blog. Do you know when to break the rules? Do you empathize with users and think about the impact of your actions on them? Or do you just follow an ITSM process and expect your users to be grateful, because, after all, you are following best practice, aren’t you?