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?
Posted by Sarah Lahav
on July 26, 2016 in ITIL
Capacity management was an important driver for the development of ITIL®
. The original team writing the ITIL
books back in the 1980s evolved from an earlier team dealing specifically with capacity management and performance measurement.
Initially, capacity management was almost completely technically focused, reflecting the expensive hardware and storage days of the 1980s, where efforts were rightly focused on getting the best possible performance – and maximizing the capacity – of the hardware available, to secure the best possible value for the considerable quantity of money typically spent on that hardware.
Since those days, the scope of ITIL capacity management has evolved and expanded to reflect changing times:
- Performance management focuses on the most expensive and/or most loaded aspect of the system’s supporting services. Over the last 30 years we have seen that move from processing power, memory, and storage to network bandwidth; and that will surely change more in the future.
- The human capacity aspects have changed too, with a range of skills shortages causing focus on automating tasks and maximizing the use of the rarer or more expensive skill sets.
More significantly, ITIL now sets out a capacity management scope that is much wider than operational infrastructure. That scope stretches from business capacity, through service capacity, and then down into the traditional focus area of component capacity. But, for many, this wide spectrum is neither well understood, nor well practiced.
The sheer scale of this range makes it difficult to appreciate, especially when viewed from an IT service management (ITSM) perspective. Not least, this is because the wide range of experience, knowledge, and skills required is unlikely to be found in one individual, making successful ITSM capacity management very much a team game, requiring empowerment by managers for those with specific expertise.
Fashionable Capacity Management
Let’s start with a non-IT example: the fashion industry – an industry where one individual can theoretically have all the necessary skills to offer their clients the whole range of capacity management.
Our fashion industry capacity manager starts with business capacity management.
What’s needed are the answers to key questions like:
- What kind of clothes will people be buying next year?
- What are the new trendy colors?
- How much clothes will they buy?
- How much will they pay?
These are answered by attending the right trade shows, seeing what the world’s designers are showing, and understanding what can be copied.
That solved, we come to service capacity management
, whose questions are more like:
- What dresses, shirts, etc. should we make to meet the demand?
- What range of sizes is best?
- What quantity of each size should we make?
There are many more questions like that of course, which our fashion capacity management expert would answer for their customers. Don’t worry if your fashion knowledge doesn’t stretch to understanding them all; this is just an example.
And then we come to component capacity management,
which deals with what you need to have in order to actually make things happen. In our fashion example, for instance, this covers, among other things:
- Meters of cloth
- Kilometers of thread
- Buttons, hooks, zips, and the rest
- Number of machines and machine operators, and the skills they must have
Specifically, component capacity management actually gives you the answer to what you must buy, obtain, own, etc. in order to deliver what the organization needs.
So, putting it all together, we see that the whole spectrum of capacity management – from business through service to component – is necessary to create the key deliverable: what the organization needs to buy and implement. In ITSM, this is what is known as the Capacity Plan
Back to ITSM
Let’s take that fashion analogy back into IT services now.
Yes, the distance from start to finish in IT is greater and the difference between understanding the business environment and the need for components much wider.
But the key message should ring true all the same. We need to know what materials and skills will have to be supplied and available over the next accounting period (a year for most of us) to deliver what we have to deliver. In order to know that, the first two sets of question need to be answered first (and in order). Without the answers relating to business capacity management
, we cannot answer the service ones. And without the service ones we don’t even have meaningful questions about component capacity, let alone answers.
In ITSM, we are likely to need either the business themselves or external consultants to answer the higher level questions. And we need answers in a way that the IT- focused guys doing component capacity can understand and process into good answers.
Do you have this level of support available for your IT capacity team? Do you expect them to find it for themselves? Or do you just focus on getting better at what you did last year, rather than what you should do next year?
In the fashion business, if you keep making last year’s dresses, you probably won’t survive at all. That situation holds true in IT too!
Posted by Roy Eldar
on July 19, 2016 in Service Desk
Your IT service desk staff are hopefully warriors, battling incidents and tirelessly delivering against service requests on a daily basis to ensure the smooth running of the technology that supports and drives your organization forward.
But sadly, due to the high intensity of the service desk role, people move on and need to be replaced. So what should you be looking for in an IT service desk candidate? Do you replace “like for like” or do you look to take your team to the next level? A level where the service desk is about more than just providing technical support, with customer service and the customer experience a growing requirement of end users whose expectations are rising in line with their personal-life experiences of technology, service, and support.
The Changing Corporate IT Support Environment
The world is now so technology driven that it’s easy to fall into the trap of believing that your next hire should be a computer whiz, with a knack for newer technologies. But the reality is that the person you should be searching for is a different beast, especially with the ongoing technology evolution. While this new technology is more critical to business operations, it is often much easier to support – without the technical knowhow needed for legacy IT.
Of course you could just employ a low-paid script follower now that the technical knowledge is becoming less important. But will that really work? I’d imagine not, especially given the aforementioned rising expectations of end users based on the effects of consumerization that extend much further than merely the consumerization of IT and BYOD
So the “rules” for hiring IT support people need to change, and below I outline three common traits of super successful service desk staff that you should be looking for in your next hire.
Attribute 1 – Extraordinary Customer Service Skills
Straight off the bat – great customer service skills will paramount to the ongoing success of your service desk.
More and more organizations are now favoring exceptional customer service skills over technical ability, with the premise that technical skills can be learnt, whereas customer-centricity, more often than not,cannot.
Service desk agents also need a good understanding of the business’ goals so that they can be more focused in helping end users/customers in using technology to achieve those needs. As outlined by Andrew Hiles and Yvonne Gunn in their book Creating a Customer-Focused Help Desk: How to Win and Keep Your Customers
, your help desk or service desk staff must be customer orientated and able to see the business needs:
“Staff should think ‘business’ and ‘customer’ not ‘technology.’ Agents must be able to establish good working relationships with both customers and the technical support areas outside the desk where problems will be solved.”
So when interviewing, take the time to ask the candidate to share an experience when they’ve gone above and beyond the call of duty for a customer or simply provided great service. And of course be on the lookout for signs of natural customer-centricity and empathy.
Attribute 2 – A Super-Fast Aptitude for Learning
Much of the technical know-how a service desk agent needs can be learnt.
As mentioned earlier, when recruiting service desk agents, it’s easy to get caught up in the technical skills. But be aware this potentially limits your choice from the pool of potential candidates.
So instead draw up a skills matrix identifying your “rock bottom” technical requirements and rate the candidate’s proficiency in these areas, but also their interest to learn. Then use another column of the skills that can be taught, again rating the candidate’s willingness to learn. This way you can recognize skills gaps and put an effective training program in place to find and shape staff with the perfect attitude into more technically able agents.
Additionally, rather than looking solely for technical ability, you may also wish to seek out candidates with unexpected transferable skills.
Finally, don’t fall into the trap of believing that your next hire must be a computer science graduate, and instead cast your net wider and look towards other analytical disciplines such as history or even literature. Search out subjects that require strong research experience and an adeptness to aggregate and view data in a unique way. Remember that as long as the agent possesses a willingness to learn, there’s nothing that your knowledge base or training program, or one-on-one coaching, can’t teach them.
Attribute 3 – Exceptional Interpersonal Skills
To connect with customers, and to truly understand their issues, your service desk agents need to possess great interpersonal skills.
So compassion and communication are key traits to look for in a service desk agent. They need to be able to “walk a mile in your customers’ shoes” to understand the customers’ needs, and be able to empathize with the situation. Agents also need to be active listeners to accurately pinpoint the issue before searching for the solution; while also being clear and concise communicators to relay information to customers (plus to hand over issues or to share knowledge within the team).
So the next time you are hiring for a service desk agent consider the importance of these three attributes to the role. Of course there are others, what do you look for?
As you can appreciate, hiring the right type of service desk agent is just part of the puzzle – you also need to hire the right amount. If you want to know more about the optimal staffing of a service desk, then I recommend this blog – ITSM Basics: Is Your IT Help Desk Staffing Right?
from my friend and colleague, Joe The IT Guy
Posted by Greg Sanker
on July 12, 2016 in Service Desk
Ever hear that ITSM (and ITIL) are not about the processes? If that’s true, then why are the ITIL volumes full of processes? Incident management, change management, release, and so on. Twenty-six of them, at last count. What am I missing?
Processes Are Great, But…
If you look at IT from the perspective of the customer – as all IT providers should – it becomes immediately obvious that processes are vastly less important than the outcomes the customer can see. Customers know processes are key to producing outcomes, but frankly, the customers care very much about the outcomes, and very little about the processes themselves.
So, let’s agree on this:
Outcomes are more important than processes.
talks about Business Capability versus Processes
over at Future of CIO
. The article is well worth reading; in it, she describes a process as how it’s done
, whereas a capability is what is done
. In other words – what’s accomplished, or (the outcome).
It comes down to this – a process by itself doesn't produce value
. Processes produce outputs
. What the business is able to achieve with those outputs are business outcomes
, and can be measured in monetary terms.
In a corporate environment, directors and senior managers are accountable for how they spend the company's money. They must ensure that what the company is investing in produces optimum value for the stakeholders.
IT spend is no different. Whatever investments a company makes in IT must be held to that same standard – that of producing maximum value for the organization.
Where I'm driving at is simply this: companies don't invest in processes. At least they shouldn't. What they do invest in is the capabilities that processes enable
for the company.
Think of it like this. A manufacturing company owns a tool like, say, an industrial sewing machine. Picture it sitting in a dark warehouse under a musty tarp. Last time it was used was 1996 when the company made automotive upholstery. Does it still work? We assume so. But it takes more than a functional tool to make a sellable product.
For the sewing machine to produce value, you'll need:
- Operation and maintenance manuals and processes
- Technicians who are familiar with the machine to get it functional, test it out, and calibrate it
- Designers and layout staff to design products
- Manufacturing engineering to develop production templates and processes
- Trainers and line supervisors to oversee daily operations
- Skilled operators who are trained on the machine and processes
A pretty extensive list, and I'm greatly simplifying it to make a point. Hopefully you'll agree the machine by itself doesn't produce value. It has
value, but alone, it produces
no value. The same is true of IT processes – best practice or otherwise.
This is the difference between processes and capabilities. A capability
is the combination of people, processes, technologies, and often – strategic partnerships, along with the wherewithal to effectively coordinate the workings of the components such that the net result has value.
You see how a process is simply one piece of a capability. Processes are important, of course, and they should be well engineered and executed. But alone, even the best of processes aren't particularly valuable.
I couldn't do justice to this topic without bringing up the not-so-polite phrase “a fool with a tool is still a fool.” Just because you have a process – a piece of a capability – doesn't mean you're able to produce business value.
This is why I prefer to talk about capabilities
because it includes all the required elements as well as how well the organization orchestrates them to produce a business outcome.
But, Out Here in the Real World...
All of which brings us to the big 'who cares'?
You might be thinking: "Out here in the real world, we're focused on doing what needs to be done to deliver the types and quality of services our customers need. This is just an academic play on words that has no bearing on real life."
It’s a fair point, but before I respond, let me ask you a couple of questions:
- When you get your car fixed, do you care about the tools and processes the mechanic uses?
- Do you understand how a commercial kitchen works? Do you know the difference between a chef, sous chef, expediter, or caller?
Most people are really only concerned with the results, though “factory-certified mechanic,” or “world renowned chef” might catch your attention. But a car that takes the family on vacation without breaking down, or incredible tasting food is what really matters in the end.
Now to the real question: what difference does it make. Well, the certified mechanic with an enviable tool chest, whose customers' cars break down, risks going out of business. The chef with impeccable knife skills, whose guests get food poisoning, may find himself unemployed.
Out in real life, it's results that matter – the outcomes of the activities we do.
I was in a conversation recently and when I mentioned that I was well on my way to ITIL Expert certification, That Look came over their face. The "oh, you're one of those (process) people" look. I found myself explaining that processes are tools we use to deliver value to our customers. I made the analogy of the carpenter hired to make cabinets. When we talk about what I want built, I don't expect him to talk about his laser guided compound miter saw, or his pneumatic face frame clamping system. I would want to talk about things like styles, design options, wood, and finish choices. I expect him to be an expert with his tools; that's a given, part of why I hired him.
And when friends come to admire my new cabinets, not one asks about the tools of the carpenter.
When evaluating your IT capabilities, consider:
- People. What knowledge, skills, and expertise are required? What attitudes, behaviors, and culture best support the desired outcomes?
- Processes. What are the key inputs and outputs? How does the process fit within the current organization? How well is the process producing the desired outputs?
- Tools. Where and how can tools/automation optimize delivery? How do these tools integrate into the organization’s infrastructure? Have your processes been engineered to meet the business’s requirements, and does the technology fully support them?
- Partners. Where and how is the organization leveraging external providers to optimize delivery? Does the organization have the necessary skills and experience to effectively manage these relationships?
As an ITSM professional, processes are one of the tools you use to create capabilities. The wise practitioner is focused on coordinating the optimal balance of these elements to create value for their organization.
Posted by Sarah Lahav
on July 5, 2016 in Service Desk
Has this ever happened to you?
You’re asked to look at a pressing issue and report back your findings and ideas at the next management status meeting.
You interrupt what you're doing, invest time, do the research, and develop a rationale for what's causing the issue, as well as some ideas on how it can be addressed.
The status meeting is well attended by all the right decision-makers. You present your ideas, your logic is irrefutable, your research and data bulletproof. Heads nod in agreement. It seems to go well.
The meeting ends, and when back at your desk a “ding” signals the arrival of an email thanking you for your ideas. A short time later, you hear from others your proposal has been parked.
What went wrong you wonder?
Too often people make the mistake of focusing too much on the content and not enough on how it’s delivered. There is a huge danger in using a ‘one size fits all’ approach when presenting ideas. You suspect this is at the root of your disappointment.
Developing a Strategy of Persuasion
In an earlier blog
I discussed how to approach writing a communications plan. If you recall, a checklist emphasized a number of key considerations regarding potential audiences, including knowing beforehand who they are — identifying and characterizing each 'persona', their interests, and the language and keywords (buzzwords) they commonly use.
In this blog, I'd like to focus on how to develop your strategy to persuade each persona, and avoid your message being misunderstood, misheard, and ignored, or your ideas parked.
Let's go back to this hypothetical status meeting. Remember, this was a management meeting.
Let’s assume you know who typically attends. You also know and can characterize their individual personas. I'll talk about this a little more in a moment.
I’m also going to assume that although you’re familiar with the language and buzzwords used by each participant, you didn’t properly research the current communication noise nor tune into it as part of your proposal.
So, given a do-over, how would you better prepare the information and message you need to convey, and unlock their minds so they can properly assess my ideas?
No Shortage of Helpful Personas
The good news is, there’s no shortage of models and analysis on how leaders make decisions.For example:
- Dan Lovallo and Olivier Sibony identified five decision-making styles: Visionary, Guardian, Motivator, Flexible, and Catalyst.
- McKinsey & Company offer a free survey to uncover what type of decision maker you are or know.
Other research suggests types such as the following:
As I said, no shortage, they all help.
But, I’m going to use the five types or personas
offered by Robert Miller in his book, “The 5 Paths to Persuasion: The Art of Selling”
, mainly because it’s very easy indeed to read (Miller uses storytelling to get his points across), and the selling perspective is also key. After all, we are asking our audience to “buy into” our idea. We want them to take some form of ownership.
In his book, Miller describes a new framework for understanding how best to influence decision-makers. Developed from a multi-year study of nearly two thousand executives, the framework concludes there are five (common) types of executives:
- and Controllers
Miller describes them as follows; perhaps you can recognize some of them in your own organization.
"… Easily enthralled with new ideas, particularly bold and innovative ones, but will not make a move until they are sure others have thought through the details.
"… Need to cautiously and methodically work through each pro and con of every conceivable option before rendering a decision.
"… Highly suspicious of every piece of information I will really trust anything that doesn't fit with their worldview.
"… Make decisions based mainly on how other trusted people, including themselves, have made similar decisions in the past.
"… Must be in charge of every aspect of the decision-making process, and need to have some ownership of an idea before proceeding with it.”
Obviously, there's no cookie-cutter approach that meets every need, but Miller gives us some excellent pointers on how to position and “sell” our ideas to decision-makers who fit these personas. The most successful proposals are custom tailored. They have deciphered the executive type, and matched communication tools and tactics with the type.
Paraphrased, here are some of the strategies suggested for each type.
Buzzwords include: results, proven, actions, show, watch, easy, clear, focus
. Fight the urge to join their excitement. Focus the discussion on results. Keep arguments simple and straightforward. Use visual aids to stress features and benefits.
Buzzwords include: quality, academic, think, numbers, intelligent, plan, expert, proof
. Thinkers need lots of information. Have your research at the ready in both its raw and summarized forms. They will want to dig deep and look at things from every perspective.
Remember, this type will be demanding, disruptive, disagreeable and even rebellious. Their buzzwords include much more open, softer language, such as: feel, grasp, power, action, suspect, trust, demand, issue, culture, cult
. Credibility is critical here, your credibility, or that of your research and sources. Find a way to attract the credibility, perhaps by gaining an endorsement from someone the skeptic trusts.
Buzzwords include: innovate, expedite, expertise, similar to, previous experience, best practice, case study, standard
. Followers need to feel certain they are making the right decision and that others have succeeded in similar situations.
Logical and analytical, their buzzwords include: details, facts, reason, logic, power, manage, handle, done, black-and-white
. They respond to structure and, like the skeptic, credibility. They appreciate details but only if presented by an expert or presented expertly. They can react negatively to open selling of an idea. They need to convince themselves.
I'm not suggesting you script everything. Nor can I say the buzzword and types are a complete list. But they offer a great starting point.
Make sure you are aware of the types of decision-makers you may face. Maintain your core message and keep returning to it at every opportunity, but plan to speak briefly to each type of decision-maker in turn, using their preferred language and set of buzzwords. Let each of them know this as you do so.
Deliberately engaging and disengaging each decision-maker using words and style of communication they are tuned to, helps to ensure that your core message is heard the way you need and intend it to be heard. It also helps solicit individual support that may be used by the group as a whole to overcome isolated objections.
Hopefully, this all too brief exploration of decision-making types will help you develop more effective tactics to tailor your proposals and arguments, so they receive the consideration and endorsement they deserve.
Posted by Stuart Rance
on July 5, 2016 in ITIL
When creating a request for change (RFC), it's tempting to stick to the bare minimum. After all, most of us have better things to do than populating endless forms with information that nobody really needs to know. I mean what are the chances of the requested change going wrong?
Apparently pretty high it seems, if the oft-quoted incidents-related-to-change numbers are to be believed. So with a high proportion of incidents caused by a change
can you really afford to be slapdash when submitting an RFC? So what can you do to make your RFC process, and forms, better? Here are my top tips for supercharging your requests for change.
1. Ensure that All the Required Supporting Players Are On Board
You may have internal and/or external supporting players as part of your RFC process. So it's essential that they are aware of what, and when, work needs to be done. Sounds like common sense, right? Well yes it is, but you'd be amazed how many times this dependency isn't taken into consideration. It's also critical to your change management process that you ensure that such supporting players have the bandwidth to carry out what you’re asking and within the timescale proposed. Just presuming that those required to help with RFCs are just sitting around waiting for you to give them something to do will definitely cause you issues. In order to keep your change process running smoothly, and to keep your colleagues happy and on-side, you’re going to want to have these discussions before
you write the request for change, not after it’s been submitted.
2. Ensure that Your RFC Has Sufficient Lead Time
Is there really enough notice to make it work? Ideally your organization will already have a change policy and the RFC notice period will be clearly defined within it. If not, be realistic and ensure that you take all stages and connected changes, including those by supporting players, into account. The last thing you want is to have everybody lined up to do their part only to find out that another change, which is going to take a couple of days, needs to happen first. You won’t be very popular if this happens.
3. Ensure that You Get Your Change Approved by the Right People
Are the right people approving your change, based on the services affected and business impact? Again, I’m hoping that your change policy is in place and that approvers have been properly thought through. Without it, you’ll struggle to know who these people are and will likely waste time trying to find out. However, it remains vitally important that you gain approval from the people in the business that know the business impact of proposed changes. For instance, proposing shutting down the payroll server on the 25th of the month is a stupid idea.
4. Ensure that All Relevant Parties Are Notified of the Proposed Change
Is there a plan to notify everyone affected of the requested change? The name of the game here is information sharing and making life easier for the service desk. Sticking a message up on an infrequently visited news page on your company intranet is probably not going to cut it. And have you ever spoken to a stakeholder when they've called to say that they can’t access a service, watching them turn into a monster after telling them, "But we did inform you Mr. CFO...it was on the intranet"? Equally important is not bombarding everyone “just to be safe.” Ensure that notifications are targeted and timely, in a medium that will be seen. Don’t know what that medium is? Just ask your stakeholders.
5. Ensure that You Locate All Tickets Related to the Change
Is the proposed change linked to any related incidents, problems, known errors, releases, projects, or other changes? It's tempting to assume that all related tickets will have already been linked as part of the RFC completion, but the chances are that a quick search will locate at least a few more. Knowing what issues the change will impact will give yourself, change approvers, and the change advisory board (CAB) a more detailed account of risk and urgency together with an additional way to measure success post-change.
Feeling Super(Charged) Yet?
These five tips should take your change process and RFCs from acceptable to trusted, and save RFCs from needing to be passed backwards and forwards for additional information.
Remember that wherever possible you should use standard repeatable changes to save everyone time and effort. However, don't be tempted to try to hoodwink your colleagues into thinking a change is standard when it's not. The repercussions can be wide reaching and will reflect badly on not just yourself but your entire department.
So that’s my top tips covered. What tips would you add?
If you would like to hear more about improving your organization’s change practices, then I recommend this change management webinar by ITSM-industry luminary Ivor Macfarlane.
Posted by Stuart Rance
on June 28, 2016 in Service Desk
I was riding home on my bike recently when the traffic lights turned red, as they do. I stopped, and waited for them to turn green again so I could go. There were cars all around me. When the lights finally did turn green I pedalled as hard as I could to try to get clear of the traffic and into a safe space at the edge of the road.
Unfortunately, my bike picked that exact moment to develop a fault.
that is supposed to disconnect the wheel from the chain when you are rolling down a hill decided that now was a really good time to go into operation. But it wasn’t supposed to. The result was that no matter how hard I pedalled – and believe me, I pedalled as hard as I could – the bike just stayed still, before slowly starting to topple over. I felt like a character in a classic cartoon, working hard but making no progress and heading for a fall.
Later, when I’d had a bit of time to recover, I started to ask myself what it was about this incident that felt so oddly familiar. And then I realized that it’s a great metaphor for what is wrong with many of the IT organizations I’ve known. However hard they work, they never seem to get anywhere. The thing is, no matter how hard we work, we can’t make any progress unless everything is connected to create a functional value chain.
What Is a Value Chain?
When I refer to a value chain, I am thinking about all the different things that have to work together smoothly to deliver a result. For a typical IT organization, it might look something like this…
The infrastructure teams support servers, storage, and networks. The application teams use this infrastructure to create applications for teams in the business units to use. And it is the teams in the business units who provide goods or services to the external customers who, in the end, pay for everything. Any work done by any of these teams that doesn’t actually create value for the external customers is just like me pedalling my bike without actually being connected to the mechanisms that make the bike move. It might be difficult and time consuming, but it isn’t particularly worthwhile.
How to Identify Activities that Create Value
So how can we differentiate between activities that create value for the external customers, and those which are just like pedalling a broken bike? One technique that I have found very useful is called value stream mapping
. This is a method Lean
practitioners use when they want to understand an entire flow of activities. You start by talking to all the people involved and getting them to write down what they actually do. Don’t start with the existing process documentation – you want to know what people do in practice, not what they are supposed to do if they go by the book. It usually works best if you get everyone to write the things they do on post-it notes so that you can rearrange the activities until you can see the whole sequence on a wall. This draws on another Lean principle, Visual Management - make everything visible to all the people involved so they can identify improvements themselves.
Once you have mapped out all the activities, you consider each one in turn and ask yourself whether this step creates value for external customers. Some useful questions to facilitate this are:
- If we stopped doing this would our external customers notice?
- If we did twice as much of this would it be better for our external customers?
For example, think about managing incidents. If you had twice as many incidents would this be better for your external customers? Probably not! Everybody needs incident management, but the truth is it doesn’t actually create any value. I’m not saying that you shouldn’t do incident management, but simply that doing lots of incident management is NOT a good thing, because incidents don’t create value and are inherently costly and disruptive. You might be much better off if you did more problem management and availability management to prevent incidents from happening in the first place.
Once you’ve identified all the things you do, and understood which of these activities create value for your customers, you can think about how to work more efficiently.
How Do You Use What You’ve Learned?
The first step is to eliminate as many of the things that don’t create value for external customers as you can. The more activities you can eliminate the better. Identify the things that don’t create value and stop doing them. This is a great way to increase efficiency without making people work harder.
Then try to optimize how you do the things that are left. These are the value-creating steps of your process, so each of them should focus on creating value for your customers
. The more efficiently you carry out these steps, the better you’ll be at creating customer value, and that’s what we’re all here for in the first place.
Some organizations choose to engage a team of Lean consultants to help them run a big improvement project, but I usually find that the people who actually do the work can make many improvements themselves, if they are given the encouragement to do so, and somebody explains a simple technique, like value stream mapping,
So how about you? When did you last stand back and look at what you do from a value creation perspective? If you feel like you’re pedalling hard but not making any progress, then maybe it’s time to consider value stream mapping.
Posted by Dena Wieder-Freiden
on June 16, 2016 in Service Desk
As an exhibitor, it seems to take forever to plan for the Service Desk and IT Support Show (SITS)
but, once you are there, the two-day event is a case of “blink and you’ll miss it.” Of course if you didn’t attend this year’s event, then you’ll have missed it anyway. Not just the ocean of IT service management (ITSM) vendors displaying their respective wares but also the hectic schedule of educational sessions.
Thankfully, this is where this blog comes in – it’s a potted summary of some of that educational content, organized in a number of action-based statements:
- Benefit from ITIL Practitioner
- Don’t forget the negative impact of self-service success
- Look to the Twitter stream
- Get the basics right
1. Benefit from ITIL Practitioner
ITIL Practitioner was referenced in a number of SITS presentations, Paul Wilkinson
even recommended that you “pin up the nine guiding principles of ITIL Practitioner on your wall” and use it as a reference in your day-to-day activities. These principles are:
- Focus on value
- Design for experience
- Start where you are
- Progress iteratively
- Observe directly
- Work holistically
- Keep it simple
- Be transparent
For those of you who might not be familiar with the new ITIL Practitioner publication (and exam), I recommend that you read Stephen Mann
’s blog: 8 Things that Stand Out in the New ITIL Practitioner Guidance Book
. You can also find more information by visiting the official ITIL Practitioner page on the AXELOS website
also talks about how to deliver business value using ITIL Practitioner in one of his audio blogs, which can be found on our Back to ITSM Basics
2. Don’t Forget the Negative Impact of Self-Service Success
Stephen Mann’s session looked at self-service from a different perspective. We have seen and heard a lot about how to improve the chances of self-service in the past few years such as this white paper
but little (possibly even nothing) has been shared re the adverse impact of self-service success. For example, that:
- Self-service will remove many of the “easy” tickets (both incidents and service requests) from the service desk queue.
- Service desk agents will need to be “better equipped” for the more complex issues and requests.
- Service desk agents will be a premium resource, with retaining staff more important (and harder).
- Smaller service desk teams will mean less flexibility.
- Metrics and targets will become skewed on a number of levels.
To ensure that service desks don’t get caught out by their self-service success, there are a number of things that they should be doing:
- Reimagine the service desk role
- Value service desk agents more
- Work smarter, not harder
- Exploit opportunities for self-service, service desk, and IT operations management (ITOM) automation
- Reinvent and re-baseline metrics
- Invest in better relationship management
- Expect self-service evolution
No doubt Stephen will be creating a blog that explains all these in more detail.
3. Look to the Twitter Stream
Due to the demands of exhibiting, I was unfortunately unable to attend many of the SITS sessions in person. Thankfully however, anyone can still learn things from the #SITS16 Twitter stream, even if you aren’t at the event.
For example, and for your benefit, here are some of the best tweets of advice, commentary, takeaways, and statistics:
- “Stop calling your colleagues your customers. Stop alienating them” – Simon Kent
- “Metrics are a platform for improvement” – Stephen Mann
- “Encourage a ‘no blame’ culture. Otherwise you drive people to do the wrong things just because it's safer” – Ivor Macfarlane
- “To keep the 90% success, praise the 10% good try” – Ivor Macfarlane
- “Who cares about the keys to the safe if you don’t event know where the safe is” – Matthew Hooper
- “Let CSI be your greatest strength, focus on learning and encourage idea creation” – Matthew Hooper
- “If we don't start talking in business language we deserve to be outsourced” – Matthew Hooper
- “You need to deliver proactive support to continue providing value. Technology can pick up the reactive support.” – Ollie O’Donoghue
- “Building a global service desk – we need to take into account people and culture” – Suresh GP
- “Just because you have a badge to say you can understand processes etc., it doesn’t mean you’re any good at managing people” – Barclay Rae
- “IT organisations still have a responsibility to security. This is often forgotten in the rush to be all shiny and agile” – Barclay Rae
- “Major incident management becomes easier when you nurture relationships” – Ian Connelly
- ‘Listening, reasoning and analytical skills. Those are qualities of a good IT analyst” – Simone Jo Moore
- “How to achieve a zero blame culture: be brave, be public, reward behaviours you want” – Ben Moss
- “Focus more on agility rather than stability” – Charles Arajuo
- “Lose the Nonsense! Kill those reports no-one reads, stop the useless meetings” – Daniel Breston
- “Key #SITS16takeaways: evolve or get left behind; focus on your customer (but don't call them customers); speak business not IT” – Sophie Danby
4. Get the Basics Right
SysAid’s primary aim throughout the event was to help educate attendees on the basics of ITSM. This was done through our “Back to ITSM Basics” box, which included a wealth of helpful content from Stuart Rance and Joe the IT Guy
(plus chocolate and other goodies).
The Back to ITSM Basics advice included:
- Save yourself time and reduce potential mistakes by automating your standard changes.
- Prioritize improvements based on cost and impact, to help work out where to focus efforts.
- When carrying out an ITSM assessment start with what you do well.
- Use a Kanban board to help to ensure that you don’t start too much at once.
Although all 1000 of the physical Back to ITSM Basics
boxes were snatched up at SITS (so sadly, if you didn’t get one, you’ll have to buy your own chocolate), all of the content is accessible on our Back to ITSM Basics webpage
. You do need to part with your email address to gain access though, but in return we’ll give you:
Three videos complete with tips and best practice advice on how to: automate, collaborate, and be more proactive.
Three audio blogs on: ITSM improvements, how to benefit from ITIL Practitioner, and how to become a business-focused organization.
Two workshops: one on “How to Start Collaborating” and a second on “How to Initiate Continual Service Improvement”.
Of course there was so much more to be learned at SITS. If we are lucky we will see other blogs sharing the nuggets of wisdom from the SITS sessions.