Posted by Stuart Rance
on November 24, 2015 in Service Desk
Customer satisfaction isn’t only about the quality of the service you deliver, it’s just as much about how well you set and then meet customer’s expectations.
The most important thing to get right when you’re providing services is to say what you’ll deliver and then deliver what your customers expect. If you reliably meet customers’ expectations – every time – then those customers will value your service. If, on the other hand, you let customers down then they will be dissatisfied with your service, even if their expectations were unreasonable and could never have been met.
People who work on a service desk have a great opportunity to delight customers, by simply making sure that customers know what is going to happen, so that when you deliver services to them they get what they were expecting. On the other hand, if you set expectations incorrectly, or fail to deliver the service that you said you would, that leads to dissatisfaction.
I recently phoned my broadband supplier to ask them to switch my internet connection to a different phone line. The person on the service desk told me that this would take 30 days, and they immediately sent me an email with an exact timetable for the switch, saying that they would deliver a new modem the day before the switch, and I should return the old modem in the same packaging. I was pretty sure that the two modems were the same so this seemed a bit wasteful, but I guess they must have had their reasons.
The modem arrived on the appointed day, and next day the new broadband connection came to life and it all worked first time. About two days later, after the new connection had stabilized, they disconnected the broadband from the original line, so I packed up the modem and returned it to them. I was a happy customer.
I would obviously have preferred it if they could have done this without such a long delay, but they set my expectations correctly so this wasn’t a deal breaker. Now imagine my reaction to exactly the same situation if the service desk told me that it would take just one week, and then it took 30 days. Or if they told me that the swap would happen on one particular date and then it happened two days earlier at a time when I wasn’t around and couldn’t test the connection. The reason I was delighted with this service was because the supplier did exactly what they said they would do, exactly when they said they would do it.
Another recent service experience of mine was less satisfactory. I had bought a new fridge and when it was delivered there was obvious damage to the door. The delivery people told me that they would return it to the warehouse and I should hear from them within two days. Three days later I phoned to ask what had happened to my fridge and they seemed to know nothing about it, but promised to call me back within 24 hours. The next day I didn’t hear from them, so I phoned back and they expressed surprise that no one had returned my call and again promised to get back to me within 24 hours. The next day I phoned a senior manager in the company to complain. I explained that my complaint was not about the damaged fridge, these things happen, but about their failure to meet commitments to call me back. This time my issue was dealt with, and a new fridge was dispatched. It didn’t actually take very long for me to get my fridge, but I was not a happy customer because the organization failed to get the basics of customer satisfaction right. All they needed to do was tell me what to expect, and then meet my expectations.
How good is your service desk at setting customer expectations? Do you make sure that your customers know what is going to happen, and then deliver what you have promised?
Posted by Dena Wieder-Freiden
on November 17, 2015 in ITSM
I’m back from a wonderful trip to New Orleans for FUSION15
, plus a sneaky little post-event vacation, and I wanted to capture some of the great insights and advice the presenters at FUSION15 had to offer. Obviously there are only so many sessions an individual can attend at a multi-stream event, without the benefit of cloning, and there were many more sessions that I wished I could attend but was prevented by clashes.
However, I think I chose my sessions well and, without realizing it, I appear to have attended sessions across the IT service management (ITSM) mantra of people, process, and technology (or product if you are totally up-to-date with your ITIL training). So here are some key points I picked up.
“We Don’t Do People”
(ITSM legend, consultant, trainer, and ITIL author) started with this mantra, stating that we talk about IT services being supported by people, process, and technology, but too often we invest all our time and effort in the processes and technology, and forget about the people. Stuart explained how we can significantly improve the IT organization by focusing on people, offering a number of real-world stories about how the attitudes and behaviors of IT staff can dramatically influence the customer experience.
Stuart challenged the audience with questions, including:
- When you recruit, do you require people skills as well as tech skills?
- How do you measure and reward people?
- Is meeting your SLA more important than making your customer happy?
All of these questions are easy to ask but maybe not so easy to answer.
Stuart wasn’t slow in telling the audience some hard truths either, including:
- If you haven’t involved your end users/customers in your ITSM processes, then you'll fail.
- It's not a person who fails – it’s the training, process, technology, etc.
- To improve things, change the ITSM culture to include blame-free post mortems.
- Design customer experience into everything that you do – every process, every tool, every user interface, and every metric and KPI.
From Stuart’s People to Technology and Process, Namely Cloud and DevOps
and Kathleen Wilson
told the audience how Microsoft, in order to innovate and to stay competitive, needed to change its methods of delivering new features to its customers. They explained that the traditional IT models, which consisted of disparate IT teams with little to no collaboration, hindered Microsoft’s ability to innovate quickly. Then, they went on to describe how Microsoft successfully—and not so successfully, in some cases—applied DevOps internally, in its cloud services, and with its customers.
One of the key points for me was how much DevOps uses automation. With hindsight it makes so much sense – automation is needed for public-cloud-scale operations and in order to monetize the cloud. The most efficient and effective data centers have very few people – no different to the most optimized of factories or other physical production environments. This was cemented by keynoter Robert Tucker
when he said something akin to:
“If a job can be done by a set of steps, it’ll be eliminated. Replaced by a robot. Let that sink in.”
The session also introduced a new term for me – economy of skill
. While the “on-premise way” looked to economies of scale
with vertical IT silos such as networking, storage, servers, etc. and the associated finger-pointing along with, most likely, an absence of end-to-end accountability – the “cloud way” is about operating in a new, federated services model; with “one throat to choke” when it comes to accountability.
…And Back to People with SFIA
spoke to how more and more IT organizations are using the Skills Framework for the Information Age (SFIA) to keep track of the skills they have and the skills they need to obtain. With SFIA allowing organizations to understand: their IT skills gaps, how to address the gaps, and how to create skills-based role profiles and job descriptions to help deliver better individuals and teams.
I was new to SFIA – my excuse is that I’m a marketer with a very keen interest in ITSM – but I imagine that I’m not alone given SFIA’s UK origins. And when something is free to use, it would be rude to not at least take a look.
In summary, SFIA is a framework that provides a common language that describes skills (not roles). It includes a model for not only describing IT practitioners’ skills but also the levels of the skills needed in the context of organizational responsibility.
It’s interesting how SFIA doesn’t define organizational structures, roles, or jobs and is instead aligned with the things that need to be done in IT in order to be successful. And I particularly like how SFIA helps both the organization and the individual or, as Matthew explains it “SFIA plays a role in countering weapons of self-destruction.”
If SFIA sounds like it could help your organization, then why not download SFIA6 from http://www.sfia-online.org/en
And Even More People Advice with “Engaging Employees: Bridging the Generation Gap”
Rae Ann Bruno
pointed out that, while many IT organizations focus on attracting and retaining employees, to get the best results we also need to motivate and engage our employees and teams to deliver better customer service – that engagement can be the real differentiator.
And that, with several generations in the workforce, a “one size fits all” approach to motivation and engagement doesn't work. The session covered what motivates each generation and how to create an environment where teams will be highly engaged, productive, and successful.
Rae Ann offered up four traits that engaged employees exhibit and it’s interesting to consider how our service desk people rate against each of them:
- Enthusiasm – employees are enthusiastic about work
- Inspired – employees are motivated by their leaders
- Empowered – employees are allowed to do the work their way
- Confident – employees are sure they can achieve excellence
Engagement is an important consideration as we start to expect service desks to deliver a better customer experience. With 70% of engaged employees strong on customer service versus only 17% of disengaged employees. So get your service desk and other IT employees engaged!
Looking at engagement through a generations lens, generationally the workplace is made up of:
- Traditionalists (born 1925-1945)
- Baby boomers (1946-1959 with a second wave 1960-1964)
- Generation X (1965-1981)
- Generation Y (1982-1993)
- Generation Z (1994-)
Although I would argue that we should call the latter group Generation Now given their constant need for immediacy in the workplace, with Generation Y not too far behind them!
So unsurprisingly, research is showing GenY/Z as the least engaged part of the workforce, and moving jobs a lot as a result. The root cause is often the corporate failure to deliver against a key GenY/Z motivator – the individual’s ability to advance in their career/profession/company. It’s not great for the service desk for the IT organization as a whole if such personal ambitions can’t be accommodated.
Rae Ann’s session nicely complemented the keynote by “American Humorist,” Jeanne Robertson
when she asked:
“Have you ever wanted to take a young person's face in your hands and ask ‘are you in there?’”
It wasn’t a Generation-Z-bashing keynote but rather an exploration of how a sense of humor is more than just the ability to laugh. That instead it’s an attitude, and an approach to working that can be developed and improved – to laugh at yourself and to accept the things that cannot be changed about ourselves and the people around us.
And Then Back to Process with “Basic Change Management: A Practical Multiphase Approach”
offered practical advice on getting started with change management, detailing the common challenges of trying to adopt by-the-book change management, and the difficulties of starting small – which can make it very difficult to mature and move beyond being reactive.
I was pleased that Greg started with the purpose of change management, to:
- Enable beneficial changes to be made
- Minimize disruption to services
- Manage risk
- Control the lifecycle of all changes
It’s so much better than “the process that manages changes.”
Greg also offered up a simple two-phased approach to change management adoption. With Phase 1 involving:
- Introducing change control
- Focusing on business value
- Managing the environment
- Changing behaviors
With a need to measure:
- Progress of adoption – milestones and deliverables, and resistance
- Compliance – whether processes are being followed and impact reduction
Then in Phase 2:
- Controlling the lifecycle of changes
- Managing risk
- Business alignment
- Reducing rework
With a need to measure:
- Effectiveness – business outcomes and impact reduction
- Efficiency – time to value
Greg also offered pearls of wisdom that included:
Well there you have it, a sample of my learnings from FUSION15, and I could have written so much more. Care to share what you learned at FUSION?
Photo credit: Roy Eldar
- Processes produce outputs but outputs don't produce value; it’s what the business does with the outputs that can be valuable.
- Mature service management is about collaboration. Change Management is no exception – step out of your silo.
- Start small with change, think what you need now and work towards improvements. And keep it simple!
Posted by Stuart Rance
on November 10, 2015 in ITIL
Continual Service Improvement (CSI) is one of the most important concepts in ITIL, but very few IT organizations put anything in place to make it happen. Everyone knows that they need a service desk, and that they need incident management and change management. An IT organization without these things would deliver terrible service and have customers that are completely dissatisfied. I think that the same applies to CSI. If you aren’t continually improving your services, your processes, and your technology, then at best you will stagnate, while your competition gradually leaves you further and further behind. Staying still is not an option when everyone else is improving; it’s just a way to gradually decline into irrelevance.
It’s fairly easy to get started with CSI and it can make a huge difference to the value you create for your customers. In this article I’ll give you some practical suggestions of things you can do to make CSI work for you.
Why Do You Need CSI?
When you design a new service, or a new process, or some new infrastructure, it’s never 100% perfect. If you spent the time it would actually take to eliminate all errors and inefficiencies, it would take so long that every project would be delivered too late to have any value. This means that whenever you create a new (or updated) service (or process) it already has things wrong with it even before you get started. If you have CSI in place then this won’t matter, because you will immediately start monitoring and improving things, so that they gradually approach the perfection that you’d like to offer your customers. You won’t ever achieve perfection, but you can keep getting closer.
Don’t think that CSI is just about processes, or just about the efficiency of the IT department. CSI should help you to achieve things that have a direct impact on your customers. CSI can help you to:
- Review and improve your service portfolio, to ensure that you are delivering the services that your customers need, not just the services you’ve always delivered in the past.
- Review and improve every service, to ensure that it delivers what your customers expect, not just what you thought they needed.
- Review and improve your technology, to ensure that it underpins your services, helping you to deliver high quality services that meet customer expectations with minimum cost and maximum flexibility.
- Review and improve your IT service management (ITSM) processes, to ensure that they underpin delivery of the services, that they help you to meet customer expectations, and that they help you work efficiently to minimize the cost of delivering services.
- Review and improve the skills and competence of your people, to ensure that IT personnel have the right skills and competence to manage the technology, execute the processes, and deliver the services.
CSI won’t instantly make all of these things perfect, but it will help you to continually improve them, so that you can keep up with ever increasing customer expectations, and so that you can stay ahead of your competition.
If you'd like further information and need that extra push to get started with CSI, please go ahead and download my 7 tips, which begin with thinking about attitudes, behaviour, and culture.
DOWNLOAD THE TIPS
Please share your thoughts in the comments or on Twitter, Google+, or Facebook where we are always listening.
Posted by Joe The IT Guy
on November 10, 2015 in Service Desk
Is first contact resolution (FCR) a good KPI for the service desk and incident management? Many corporate IT organizations think that it is – after all, it’s definitely one that’s prominent in the ITIL books and is popular with many IT service management (ITSM) consultants. But is it right for every IT organization?
On one level, is it a just a measure of closed calls or of the percentage of end-user issues that were given proper care and attention? On another, what’s included in FCR stats? Just easy incidents, including password resets? FCR can be fiddled with, and I’ve even seen service desks that add room bookings into their FCR calculations. Are trickier issues disallowed for “fairness”? And I bet some would include wrong numbers if it made the FCR stats look better. FCR, along with other ITSM KPIs, can definitely drive the wrong behaviors.
However, the real issue for me is that IT organizations need to understand what they are trying to achieve before they can define their KPIs – so picking up an industry best-practice KPI and making important decisions based on it might not be in the best interest of the company using it. I’ll come back to this. First and foremost, IT organizations also need to understand what KPIs are, and their use.
So What’s a KPI?
The easiest place to start is to look at the KPI acronym and what it stands for, or at least what it should stand for:
- K is for Key. Most organizations will struggle to measure and report on every possible metric and, if there are too many KPIs, then the less important ones will most likely distract organizations from the key ones that they really need to focus on.
- P is for Performance. A KPI should help organizations and teams to understand how well they are performing, and each KPI should help them to focus on a critical success factor (CSF) that needs to be achieved.
- I is for Indicator. A KPI is not proof that something has been achieved – it’s simply an indicator that suggests how well you are currently doing. Achieving KPIs is not the end goal, it’s simply a tool to help organizations to focus on their activities, to implement remedial or improvement activities as needed.
Don’t Confuse KPIs with CSFs
Wow, us IT people really love our 3LAs (that’s three letter acronyms)!
CSFs are the things organizations or teams must achieve to help meet their goals and objectives. These may not be directly measurable, but it should be very clear how they contribute to success. Some examples of CSFs for ITSM processes include that:
- The business is protected from the adverse impact of IT change (a CSF for change management)
- IT service downtime doesn’t have a serious impact on the affected business service or process (a CF for availability management)
- Workarounds reduce the business impact of problems (a CSF for problem management)
And although IT organizations might not be able to directly measure these CSFs, they can discuss them with their customers and other stakeholders, and agree that this is what you are trying to achieve via ITSM.
Turning CSFs into KPIs
Once CSFs have been agreed it’s time to define KPIs that indicate how well the organization is performing against these CSFs. There should only be a small number of KPIs for each CSF, otherwise the numbers become unmanageable.
Looking at the “Downtime of the service does not have a serious impact on the customer’s business process” CSF, example KPIs could be:
- A maximum of four events in any year where there’s a total loss of the service to all users
- The maximum downtime for any total service outage is 30 minutes
And remember, achieving these KPIs will not definitively prove that the CSF has been met, but it will help to indicate it.
Organizations should agree with the customer that this is what will be measured, and then report the KPIs to indicate how good the performance has been. But, in customer reviews, there is a need to discuss the CSF, not the KPIs – with the customer discussion something like “Here is the KPI data, do you agree that downtime of the service has not had a serious impact on your business processes?” This way, organizations can focus on what’s important rather than on what’s being measured. Read that last sentence again – it’s a very important point with KPIs and CSFs.
Why Using Best-Practice KPIs Can Be Dangerous
The ITIL books include many example KPIs, but in each section that lists KPIs it says:
“These KPIs should not be adopted without careful consideration. Each organization should develop KPIs that are appropriate for its level of maturity, its CSFs and its particular circumstances.”
Let’s return to the example of FCR and think about whether this is a good KPI or not. Suppose that an organization just measures FCR, as the right thing to do, and then reports it to show how the service desk is increasing the number of customer incidents and requests it closes during the initial phone call. This has to be good, right?
But then suppose that the organization introduces a new self-service capability, to allow people to manage many of their own incidents and requests without the need for a phone call to the service desk. They might also automate password resets, and provide knowledge articles to help people resolve common issues for themselves. This should lead to faster resolutions and happier customers but, as more of the simple incidents and requests move away from the service desk, the agents will have a higher proportion of difficult incidents to deal with. Thus FCR will get worse and might even become irrelevant. Hence FCR might be a good KPI for some organizations, but it might be completely inappropriate for others. And, more specifically, using FCR to benchmark either over time or externally will be inappropriate as the average incident or request level changes over time.
So when an organization is defining KPIs it really does need to think about: its level of maturity; its customers; and its goals, objectives, and CSFs. It’s important that they choose a small number of KPIs that will help to indicate how well they’re doing versus the CSFs. They will also need to regularly review their KPIs to ensure they are still appropriate.
When did you last review the KPIs you use to manage your IT services? Maybe it’s time to think about them again. For further insights, I recommend you watch my good friend Rob England's webinar The Right Metrics for Your Service Desk.
This blog is based on a previous Joe blog written for Conference in a Box.
Posted by Roy Eldar
on November 4, 2015 in Service Desk
We live in an age of measurements and analytics, where organizations like to calculate how well they are doing, and how well (or badly) their employees are performing. This applies to IT service management (ITSM) where metrics, business dashboards, key performance indicators, and similar terms are everyday ITSM speak.
So…we have lots of numbers that represent what we do, and we hear that ”the numbers do not lie,” but too many organizations don’t make use of these numbers as they should; meaning they don’t derive the right information or follow up with the right actions, based on the outcomes.
One of the reasons service desk performance metrics are so under-used is the apparent belief that the numbers mean one specific thing when, actually, they often mean very little without context.
Trends and Contexts Matter More than Values
If you tell me you weigh 70 kilos, it tells me what you weigh. If you also tell me that you were 71 kilos last week and 70 the week before that, then I know more about you, and can surmise something about your lifestyle. If I then discover that you have just taken up weightlifting and are building up your size and strength for a competition, then I’d no doubt be more impressed than I would’ve otherwise, without that knowledge.
The same applies to ITSM. Many organizations measure their user or customer satisfaction on a scale from 1 to 5. Telling me you scored 3.9 might sound good, but less so if you scored 4.1 last month and 4.5 at this time last year. And even if satisfaction has dropped over the last 12 months, what is the context? Has your workload doubled; did your company launch several new products?
Understanding the context can help with proper prioritization and service improvement. Just taking numbers at face value without context means you are addressing symptoms only, instead of the underlying cause. Take that falling satisfaction metric, for example – retraining service desk staff or even employing more of them won’t help if the underlying cause is new services that don’t work properly!
Dig a Little Deeper
Let’s take the example of the user satisfaction score one more step. If your score was 3.0, and it’s been around that figure steadily for the last year or so, and there’s been no obvious external factors nor any major changes going on – what could that mean? That there’s room for improvement and you should get started on new training for the whole service desk team perhaps?
But wait a moment. What kind of 3.0 is that? With a scale of 1 to 5, there are multiple ways of getting an average of 3, and finding out why
you scored 3 might make an important difference to how you set about improving things. Here are some scenarios that will produce a score of 3 in your user satisfaction metric:
- Just about everyone rates you as a 3. Could be you are average, or could be that folks are too busy to take the survey seriously and just go for the middle box.
- You get an equal distribution of scores at 1, 2, 3, 4, and 5. The entire range of different levels of satisfaction averages to 3.
- Half of your users rate you as 1, the other half as 5. Some real extremes here.
- Half think you are 2, half as 4. A mix of good and bad but not so extreme.
Of course, real life is rarely as neat as any of these, but the point is that depending on how that score of 3 is obtained, you would set about improving things in different ways. In fact, depending on which option you were nearest, you might feel the need to go look for a range of other information.
Find the Pattern
The extreme example above is, sometimes, referred to as the ‘marmite factor’ (marmite is a yeast extract spread that people seem to either love or hate, with very few being indifferent to its taste.) Expressing this set of results only by its mean average of 3 is very misleading. If you get this result in a service desk situation, it raises two important questions:
- Why are the happy people happy? What are we doing right?
- Why are the others unhappy? What are we doing wrong to them?
Of course, in order to answer that, you need to find out which users are which. Is there a recognizable pattern? Do the people on one site love the service, and those on another hate it? Do your younger users like it and the older ones not? Is it language based? The list goes on and there is no point guessing; you need to do some analyzing to find out. But what you shouldn’t do is react immediately to that simple average without further investigation. You don’t…do you?
If you’re interested in learning more on the right service desk metrics, I highly recommend you watch this webinar
presented by Rob England, the IT Skeptic
Posted by Sarah Lahav
on October 27, 2015 in ITIL
In a world of constant change in every aspect of life, it might be reasonable to expect that deciding on changes and processing them would be a widely held skill, familiar to us all.
It’s so innate and essential that in IT service management (ITSM), for example, you’d expect perfect, polished, and pervasive change management to be the norm. Perhaps changes at work are more complicated than in our everyday lives and have broader, and more expensive, consequences? Probably more people will be involved, and we might be less likely to be the decision makers; but the underlying stages shouldn’t really be that different.
In practice however, the change management process still seems to be difficult, and is an ongoing source of discussion and debate across social media for ITSM professionals. Some of the reason for this, I believe is that IT spends too much effort on the wrong parts of the change process, trying to control too tightly or argue over things that cannot be changed.
The Stages of Change Management
The full change management process has three phases:
- Request: “Please may I have something new, some more of the same, or something different?”
- Thinking and Deciding: “Should we do it? If we do it what is the best way and the best time? What will it give us? What will it cost? Who should we ask?”
- Realization: Actually build the thing and put it out there so people can use it. “Make it so!” – as Captain Jean Luc Picard might say.
For an organization to make best use of their limited resources, and yet also maximize potential improvements, all three phases of change management need to be there and functioning well.
Understandably, technically-oriented IT departments seem happiest dealing with the last phase, i.e. actually building, testing, and implementing the technological consequences. But all three parts truly matter. Without an appropriate request process the best ideas might never see the light of day. And, unless the thinking and deciding phase is properly done, organizations will most likely end up spending their time and resources doing the wrong things.
Thinking and Deciding – Without Boiling the Ocean
Organizations are full of potential change; having lots of people involved in making decisions about each and every change is going to be impossible. Anyone who tries is going to disappear into a bureaucratic mess that will see changes blocked and slowed down by administration, or more likely, they will find changes taking place without going through the approved process.
The successful route is to focus the right resources on the right kinds of decisions; those situations where an IT decision actually needs to be made, where there are benefits, costs, and risks to be considered and balanced. The first step in allowing that focus is to identify two areas where IT should not spend time considering, discussing, and deciding.
Don’t Fight the Undefeatable
Some changes are inevitable, so time spent considering whether to do them is time wasted. For these, ITSM (and other service areas of the organization too) just need to accept it and get on with it, like it or not. Examples include:
- Direct instructions from CEO, Board of Directors, etc.
- Legal requirements
- Changes imposed by supplier actions, such as withdrawal of support for hardware or software
No matter how much anyone in IT might disagree, think carefully before deciding to challenge these; you were being told, not asked.
Of course, it should still be open to decide how best to handle the change. It is vital to establish the actual purpose of the change. Sometimes it can be hard to see this because the change might be presented with an assumption of how it should be done rather than what it is supposed to achieve. For example, the response to a supplier withdrawing support is often a request to upgrade to that supplier’s latest version. Alternative options exist though, like moving to a different supplier, building an in-house alternative, taking the risk to run the software unsupported (i.e., not to upgrade), and more.
Don’t Sweat the Small Stuff
In our everyday lives, we are all used to changes being decided at different levels of authority. Take a look at this example and see if it fits with your family experience.
|Kind of Change
||Caveats and Rules
|Moving to a new city
||All adults have to agree, all children consulted
|Decorate the house
||Veto rights for own bedrooms
||Delegated to whoever does the shopping
||Known list of unacceptable solutions
|Inviting friends over
||Anyone can do this
||Inform early if extra meals are involved
Obviously holding a family meeting to discuss minor issues isn’t sensible, nor is imposing major life changes on the whole family without some consultation. The same mechanism that makes the house run effectively – delegating changes and authorizing people to decide on minor or already agreed issues – works just the same in the work environment.
calls these standard changes
. For the most part, these are the kinds of changes that have happened before and therefore already have established rules. People are trusted to ‘just do it’.
Think like a parent – the first time your child invites a friend to sleep over, you would expect to be asked, discuss, and approve the occasion before it happens. Once you meet the friend and know things are fine, you trust your child to decide for himself/herself the next time. You may have caveats to that authority – not on Thursdays, or while you have relatives visiting, or you may require that they pay for consequential additional costs (like movies and popcorn). But the rules are set before, everyone knows where they stand and things progress smoothly. If they abuse this delegated authority, it can be removed (no friends allowed over whilst grounded).
All these techniques can apply in work-based standard changes too, along with all their benefits. The first person who wants a new project management software package will need to justify it. By the time the 30th
person needs it, it will be everyday routine.
In the extreme case, some changes might be actioned and recorded with no human involvement at all. For example, employees may be allowed to download free software onto their work PCs, and then auto-detection software will find the new programs, establish they are not on any blacklist, and record them. In case of future issues the information is there, but for the most part everyone is able to just get on with doing the stuff that actually does require a human thinking about.
So…if you can see how your human-sized attitudes work at home, maybe apply the same approach at work with your standard changes – it will surely simplify the process.
Posted by Stuart Rance
on October 21, 2015 in ITSM
I’m really looking forward to speaking at the FUSION service management conference this year. FUSION will be running from 1-4 November 2015 at the Hyatt Regency in New Orleans, and if you’ve been before then you know that you’re in for a great treat. If you’ve never been before then do please think about joining us this time; it’s an excellent opportunity to learn from, and network with, other service management professionals.
Hope I’ve convinced you! So while you’re there, if you want to hear me talking about the role of people in service management, then come to Breakfast Briefing 07
at 7:30 AM on Monday November 2nd
. FUSION is so big that you can choose between seven parallel breakfast sessions before the first keynote of the day. In between the daily keynotes there are sessions for you to choose from. The sessions are organized in nine parallel tracks
so you can decide what will give you the most value; the nine tracks include “The Beginner’s View”, “The Expert Focus”, and “Service Support and Operations”. In total, there will be more than 80 presentations and five keynotes to entertain, educate, and inform you. The hardest bit will be deciding which sessions to attend and which you’ll need to miss.
In between the sessions you can look round the expo hall
, where exhibitors
will be happy to show you their products and talk to you about service management. Even if you’re not looking for a new service desk tool right now, it’s good to see what people are offering because it might give you new ideas for configuring or getting more value out of tools you already use. As you walk around the show floor you can stop and talk to a wide range of people, and since everyone is there to learn and share ideas about ITSM, the chances are you’ll find like-minded people to chat with.
If you’d like to chat with me, I’ll be spending some time talking to people on the SysAid stand, so please do come by and say hello. You’ll find copies of my new white paper “We Don’t Do People” at the SysAid stand, so if you don’t manage to get up in time for the 7:30 AM breakfast briefing, you’ll still get the chance to find out what I think about this and get my tips. If you are not going to FUSION, you can find a brief summary of the ideas I’m covering in this blog post
from earlier this year.
Any conference goers who aren’t totally exhausted by the end of the day can attend the networking reception at 5:30 PM on Monday, and the conference party at 7 PM on Tuesday. Both are brilliant opportunities to network with other service management professionals, or just relax at the end of a long day.
So – I really am looking forward to FUSION this year. Are you going to join me? I’ll be tweeting from the conference as @StuartRance
, using the hashtag #SMFUSION15
, so you can follow along even if you’re not there.
Posted by Joe The IT Guy
on October 14, 2015 in ITSM
The IT service management
(ITSM) event season has kicked-off again, and it’s time for myself and the rest of the SysAid clan to jet off to the annual FUSION Conference
– which this year is being held in fabulous New Orleans. I’ve already packed my saxophone.
Taking place from the 1st
November, we’ll be joining over 1,500 delegates to “roar into the modern age of service management.”
What to Expect at FUSION
Well despite the “roaring” part, I’m assuming that there are not going to be real lions involved (can someone please verify this for me?). Unless of course Roy Atkinson
is planning on serenading us with a version of the Lion Sleeps Tonight
, in full costume, during one of his many presentations (I have it on good authority, from the very honest Sophie Danby
, that he has been known to thrown down a tune or two while sharing his ITSM wisdom at events). Roy
– please give us a heads up if this is going to happen, I will need to bring my camera!
What you can actually expect to hear and see at FUSION is presentations from a wide range of industry-renowned speakers on a variety of ITSM-based topics such as:
However, where things get really interesting with FUSION is the introduction of an array of “modern service management” content. Including topics such as:
That’s right, we’re not just focusing on the ITSM basics anymore – we’re playing with the big boys. In fact, this year the FUSION team is also introducing a brand new co-located event: DevOps FUSION
. Who can guess what the topic of this event is going to be?
My personal recommendations on the sessions to attend from this side of the FUSION party include:
By the way, if you’re not sure how DevOps fits in with ITSM and you can’t wait until (or can’t attend) the conference, then I highly recommend checking out this introductory DevOps whitepaper
from Barclay Rae
Over the course of the last year we’ve definitely witnessed more “modern age” topics creeping into the world of ITSM events, but this is the first time (to my knowledge) that there has been such a heavy focus on this “new wave.” For that reason, I think it’ll be very interesting to see whether or not this convergence of events and change of topic focus is successful.
I’m a big fan of all things DevOps and Agile, and the benefits they can provide to any given organization, but is the wider world of help desk and service desk managers ready for it yet? Are their organizations mature enough to benefit from these “new” (let’s face it we all plug it as “new” but DevOps isn’t new my friends) ways of working? Or is likely to be too overwhelming? Are we just adding fuel to the fire? Despite the sexy nature of these topics, I know for example that if I write an article over on my blog site
about incident management, it receives more than double the amount of attention as a blog on say, Lean IT. What do you think? I’m interested to hear your thoughts.
Go Listen to My Good Friend Stuart Rance
The only thing better than seeing Roy Atkinson dressed as a lion is a presentation by the one and only Stuart Rance
. You can catch Stuart’s breakfast briefing on “We Don’t Do People
” at 7.30am on Monday 2nd
November. Focused on the people issues of IT, Stuart will be sharing his advice around the ABCs of IT (that’s attitude, behavior, and culture). Want to get an idea of what might be covered? Check out his blog
on the same topic.
If you decide to attend (you should), be sure to say hi. I’ll be the groupie in the front row shouting “Stuart, Stuart, Stuart.” I really love this guy. I’m hoping my colleague Dena Wieder-Freiden
might join me in the cheerleading – she’s a massive Stuart fan too.
Come Play with SysAid
While I’ll most certainly be wandering into the DevOps event along with our CEO Sarah Lahav
at some point; we’ll primarily be found with the other SysAiders entertaining delegates over on the ITSM side of the house. Discussing ITSM best practices, showcasing our software solutions, giving away the best swag (portable chargers, plus a “Conference in a Box” focused on customer experience), and just generally being the life and soul of the exhibition floor (as always).
Last year, we also ran a short three-question survey on the future of ITSM
. This time around we’ll be asking you about your thoughts on customer experience (and you can take the survey now if you like!
). No need to leave your name, details, and blood type – the survey is completely anonymous. Unless of course you’d like to win an Apple iWatch, in which case you can leave us your business card for our prize draw (or if you’re a cool kid who doesn’t carry business cards you can write your details on a piece of paper).
Rest assured though, once the winner has been picked your details will be heading into the bin rather than our marketing database. We’ll only add you to our mailing list if you specify interest in our product or request general information about SysAid. That said, we can’t promise that some of the other naughty vendors who favor scanning quantity over quality won’t dip their hands into the bin for the information afterwards…. Just kidding!
Enjoy, Learn, and Drink Lots in the Bar
As always, it’s bound to be an excellent event – if not even more so this year with the introduction of the co-located DevOps conference. If you’re planning on attending, be sure to look me up on Twitter
. Talking of Twitter, don’t forget to keep your eye on what is bound to be an interesting and informative Twitter feed by checking out the #SMFUSION15 and #DevOps15 twitter streams. This is also where you can typically find the latest meet up of industry luminaries (usually at one of the hotel bars).
Not convinced whether or not you should attend? Check out our overview
of last year’s key takeaways to see what you’re missing. It’s my personal favorite of the three major US-based ITSM events (PINK and HDI being the other two) and in my opinion, one not to miss.
Posted by Stuart Rance
on October 8, 2015 in Service Desk
In many organizations there is a separate information security team that deals with all things relating to security. This team is responsible for designing and implementing all the controls needed to protect the organization, and for managing all major security incidents. So why does the service desk need to be involved, and what contribution should it make? Here are five reasons that you should consider:
1. Everyone’s Responsible for Security
The first and most obvious reason is that information security, also known simply as InfoSec
, isn’t just about process controls or technology controls that we can delegate to the InfoSec team and then ignore unless they affect us directly. Good information security depends on a good balance between people, process, and technology controls, where the people controls affect a broad range of personnel in the organization – all of whom need to take some responsibility for security.
Service desk agents, like everyone else in the organization, need to know what information security policies apply to them, and need to take responsibility for following these policies. Typical policies that everyone needs to follow include:
- Acceptable use policies– what you are allowed to do with email, social media, the company network, etc.
- Mobile device or BYOD policies– how personal devices such as laptops, tablets, and smartphones should be managed
- Password management policies– how often you have to change your password, rules about how passwords are made up, and whether you’re allowed to record passwords
- Remote working policy– rules for how people should work from remote locations, such as their home or a hotel room
- Information classification and handling policies– how documents and other information should be classified, labelled, and handled; for example: certain types of information may not be transferred out of a secure location, other types of information must always be encrypted, etc.
- Visitor policies– how visitors to your site should be managed
Your organization probably has lots more InfoSec policies that should be followed by all staff, so you need to find out what they are, and make sure your service desk staff understand and follow them.
2. Service Desks Are the Eyes and Ears of IT
Major security breaches at some organizations have remained undiscovered for many months, during which time the attackers have been able to make off with vast amounts of highly confidential data. Early detection is crucial.
Your service desk is the main interface between the IT organization and the people who use your IT services. This means people who work on the service desk are uniquely placed to understand what is happening within your user community. If they are appropriately trained, they can be a first line of defense against many potential security breaches.
For example, issues such as users being locked out of their accounts for no obvious reason, data being deleted or data integrity being compromised, and performance problems due to unusual system and network usage can all be early signs of something more serious. If your service desk staff have been trained to consider such issues, they may notice the very early signs of an attack and escalate this to the appropriate InfoSec team. By helping you to identify security incidents quickly, your service desk can help change a major incident into something more manageable.
3. Service Desks Can Communicate Information Security Messages to Users
The service desk is in regular contact with users, and you can use this as an opportunity to communicate essential InfoSec messages, to reinforce other training and awareness activity.
For example, you could put a banner message on your self-help portal reminding people never to copy confidential data to portable media, or you could include a permanent message, with the email you send asking a user to complete a post incident survey, about never sharing passwords.
This is a great opportunity for service desk management to collaborate with InfoSec staff, planning how they can help communicate essential messages, and building relationships.
4. Service Desks Have a Major Role to Play in Security Incident Management
Most organizations have a security incident management process that is designed to:
- Log, track, and manage security incidents
- Escalate security incidents to people with appropriate skills and management responsibility
- Triage incidents and implement an initial response to contain the damage and stop it from spreading
- Ensure that confidential information about security incidents is suitably protected
- Preserve evidence that may be needed in case of legal or regulatory involvement
- Investigate and resolve security incidents
- Communicate with stakeholders such as police, regulatory authorities, shareholders, and the press
- Carry out post incident reviews to learn from the security incident
It’s very hard to get all of these things right without practice, so a good InfoSec team will run rehearsals and simulations to ensure that everyone involved is ready and able to take the right action when an incident happens.
The service desk is often the first place to become aware of security incidents, so they have a major role in this process flow. In some organizations, the service desk will also be responsible for logging, tracking, escalating, and managing security incidents. In all cases, the service desk should be involved in the rehearsals and simulations, to ensure that they know what is expected, and to make sure they get it right when a real attack happens.
5. Service Desk Staff Are Role Models
Service desk staff deal with users when things aren’t working properly, giving advice and asking questions. It is important that they are trained to do this in a way that demonstrates behaviors you want to encourage, and avoids any behaviors you want to discourage.
If service desk staff ask users for their passwords, then this implies that it’s acceptable to share passwords, which may later make it easier for an attacker to trick people into giving out their passwords. If service desk staff send executable files by email, or ask users to click on a link to sign in to their accounts, then this will make those users more likely to fall for a phishing attack.
There are still some organizations where the service desk staff need to ask users for their passwords, in order to troubleshoot incidents or to build new computer systems. If this is your situation, then you urgently need to get new tools and redesign your process so that you can stop doing it. You can’t afford to consistently demonstrate the wrong behavior to your users, because it encourages them to do the wrong thing too. After all, you don’t really want train your users to give out their passwords to anyone who sounds sufficiently plausible, do you?
Don’t just leave information security to your InfoSec team. Your service desk staff can play a big role in helping to protect your information if you give them the skills, knowledge, tools, and training they need to play their part.
Posted by Sarah Lahav
on September 30, 2015 in Service Desk
It’s human nature to seek out others to communicate. Through communications we learn, relate, help, influence, and play. Communication is the currency and propellant of our society.
Thanks to technology we are connected and able to communicate more today than at any previous time in our recorded history. We have become ‘digital citizens’ and many of us ‘digital consumers’
Add to this that pretty soon just about any device will be able to interact and communicate with any other device (the infamous Internet of Things
concept), what could possibly go wrong?
Plenty it seems.
From home life, to work and everything in between, it seems a “failure to communicate” is cited as the biggest risk and the primary cause when things go wrong. “I didn’t know”, “You didn’t tell me”, “I didn’t realize”, and the infamous “That’s not what you said” are recognizable claims from the victims of poor or missing communications.
The biggest reason offered, for failing to communicate properly, is time. That is, not enough time to prepare a communication plan to ensure it’s effective, and not enough time by the recipient to read and digest properly.
Hopefully, through reminding you of the key concepts and basic principles of communications, I can help you decide if, when, and how much time you will invest to make sure your communications have the desired effect.
The Communication System
Firstly, communication is the act, by one or more persons, of sending and receiving information as messages. Such messages are distorted by noise from other communications happening simultaneously, and can be additionally affected by a filter (representing local bias, capability, or language) at both the sender and receiver ends.
Communication incurs within a situational context, has an effect, and provides the opportunity for feedback. Communication involves choices and those choices will determine the effectiveness.
Individual and organizational culture permeates all forms of communication.
In any interactional situation, communication is inevitable.
It’s almost impossible to get through any given day without the need to interact with someone, or something.
What’s the longest time you’ve gone or can go without some form of communication? Were you trying to avoid communication, or were others? Have you ever deliberately tried not to interact, only to discover that no response is in itself a response!
Communication is irreversible.
Once a message is received it cannot be taken back. Say something, click “send” on your email, or perhaps flash your headlights at the driver taking your braking distance – it’s done. There’s no easy way to ‘un-communicate’ a message received.
You can of course try to reduce its effect. “I didn’t really mean what I said”. “That’s not what I meant”. “You misunderstood what I said”. Communication is reparable – but at an added and unexpected cost of time, effort, and perhaps the relationship.
Sometimes the more clarification you offer, the worse the effect!
The good news is some communication – verbal for example, fades as soon as it’s spoken. It’s the digital communications that are persistent, and typically un-erasable.
Finally, communication is unrepeatable.
The circumstances that existed and set the context for a previous communication are subject to constant change.
Relationship dynamics, frame of mind, and the situational context are always in flux. As a result you can never recapture exactly the same situation; you can’t simply replay the communication and expect the same effect.
It should come as no surprise when I say the more important it is to make sure the communication has the desired effect, the more time you should invest in planning that communication.
My Planning Checklist
A communications plan is the obvious result of planning your communications, and is typically a written document. It can span a single improvement or change, or an entire program or project, and address the messaging of one audience, or multiple audiences. Here’s my checklist for planning communications:
- Know why you need to communicate. What do you want to be different as a result of communication, what is the purpose of the communication? What do you want your audience to hear, think, and do as a result?
- Create your starting message. Draft your base with a starting message irrespective of audience, tying this back to your purpose. Be prepared to revisit and change this as you address the needs of each audience.
- Consider who you need to communicate with. Make a list of your potential audiences. Exploit any existing ‘stakeholder analysis’ research or taxonomy of stakeholder communities.
- Define the scope of the messaging. Check if each audience is one or more discrete parties; sub-divide and segregate as necessary.
- Characterize and prioritize the audiences. Define a ‘persona’ or set of common characteristics for each audience. For example ‘ VIPs’ versus ‘general workforce’. Rank them by importance to your goals.
- Research and tune into each audience. Locate any available communications, reports, articles, and similar materials from the target audience. Research key objectives, performance measures, and likely problematic concerns. List and compare between audiences. Identify common themes.
- Connect to keywords. Identify and catalog keywords used, key concepts, important language, and culture-specific aspects of the audience.
- Be relevant. Find and define a basis for your message being relevant to the audience. Connect your message to a problem or area of interest for each audience.
- Position your message. Take your starting message and change as necessary to better position it in the ‘minds eye’ of each audience. Establish the reason why they should pay attention to your message over others.
- Assume their position. Put yourself in the position of each audience. Ask “what’s in it for me?” What do these audiences think about the topic or issue? Are they supporters, or protagonists? Will they create friction or remove it?
- Channel surf. Identify what delivery methods are preferred by each audience, and are available to use. What additional resources and costs might be involved? Decide what channels you will use to deliver each message.
- Plan of action. Develop your action plan to develop and combine the messaging with the selected channels, include any special resourcing or elements containing high costs or major risks.
- Develop with agility. Write your key messages for each audience. Be aware of and responsive to changes in circumstances within each audience. Be prepared to revisit any earlier item in this list.
- Time travel. Decide when you need or prefer to deliver your messages, differentiate between important milestones and interim progress markers.
- Collision avoidance. Check for other communication plans, similar messaging activities, or major activities within an audience scheduled for your preferred timeline. Conduct ‘collision avoidance’ – adjusting your timeline or influencing others to change theirs.
- Noise abatement. Subject to the likelihood of collisions competing for attention, are there any other major distractions that could negatively affect the success of your communications plan? If there are, how will you overcome this ‘noise’ and gain the attention you require? Be prepared to revisit items 8 and 9.
- Execute and orchestrate.Execute your communications plan, orchestrating its delivery with any actions of an associated program or initiative.
- RARE – Received And Responded to as Expected. How will you check the message was received and understood as you expected and as you require? Define a means for verifying RARE based upon your initial purpose statement. This could include an online survey, interactive ranking system, or a like/dislike question or prompt.
- Invite feedback. Optionally, communications are designed to solicit one or more of the three types of feedback from the audience based upon the ACE model (appreciation, coaching, and evaluation). The communication may also offer ways in which the audience can become more involved in associated activities – termed a call for action or CTA. Decide if a CTA is required and how you might invite and invoke feedback using one of the common methods.
- Research results. Analyze and assess the results of the communication to verify it had the desired effect. This includes situations where feedback was solicited. Was feedback received, in sufficient quantities, and useful?
The more important the message, the more value there likely is in investing your time to plan what the message is, who needs to hear that message, and what result you require to guarantee success.
If you have an important idea, change, improvement, or project, consider investing time, no more than perhaps 30 minutes, in drafting a simple communications plan for at least one audience using the checklist as your guide.
When you’re done, ask yourself – do you think about your messaging and approach differently than before? Was the difference important and helpful? Do you think your communication will be more effective?
I hope you found this article and my checklist for communications planning helpful. Lets keep the conversation going! Drop me a line and let me know how you are doing and remember…
Communications are inevitable, irreversible, and unrepeatable.