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.
Posted by Roy Eldar
on June 7, 2016 in Service Desk
I was trying to get support from a supplier recently and, after considerable delay in reaching a service desk agent, I was upset to be able to hear the boredom in his voice. It was a routine call perhaps, but I was having a domestic crisis and needed something fixed that day. Why was this guy sounding so uninterested?
In the ITIL®
Service Transition book, the authors made up a term to describe this: “Emergency Room Syndrome”. In that book the term is used to describe the need to remember – as a front-line service agent – that however routine the job and the situations become to you, it is essential to remember that many customers are experiencing disruptive events for the first time. They will be upset, possibly frightened and probably tense and stressed. Good agents will not only be aware of that, but will respond and support that level of crisis, offering calm but interested support and prioritizing in accordance with the customers’ needs, not their vision of routine.
Common to You but Unique to Them
The Service Transition book analogizes this attitude to that needed in a hospital emergency room, where the doctors and nurses have seen it all before but for each patient, it is new and frightening. The service desk agent I spoke to on the phone that day did not act in this way, so I had no choice but to calm down and let his routine approach lead (eventually) to getting my crisis assigned to an engineer….who luckily came and fixed things for me.
Intrigued by the term “Emergency Room Syndrome”, which I hadn’t seen used for a while, I Googled it to see how common it is. To my surprise, it seems different people had each invented the same phrase to mean different things. Even more entertaining was that other meanings also make sense and have value in a service management and customer care situation. So I thought it was worth looking at, and sharing in this blog, as it can help you deliver good service management, just like the kind of Emergency Room Syndrome that ITIL talked about. Here are two uses of the term with lessons for us in IT service management (ITSM).
Talking to Angels
Perhaps the least expected example is found in a book
that is about talking to angels to ask for help. Many people tend not to seek outside salvation until faced with damaging emergencies. But it is an aspect of customer behaviour we are familiar with in service management. Instead of alerting us when things start to look wrong, or while there is time to correct it routinely, we don’t hear until the situation is extreme, when it has to be fixed immediately or cause business damage. Avoiding this, mentioning things early or at the first warning sign can make a major contribution to keeping services going rather than having to react in an emergency – which is rarely efficient, and always risk laden.
Going with the Adrenalin Flow
Another disparate use of the term is featured, among other places, in a professional book
on global health governance
. What the author refers to here is how it seems easier to wait for a crisis and respond than to put effort into preventing a crisis. That is a message close to the heart of every competent availability manager. Amazingly, it seems customers/users are more impressed when we fix things than when we prevent things from going wrong. Skill in the emergency room is more valued than keeping folks healthy, when all logic says we should feel the opposite.
What’s the Message?
Just a bit of fun with words maybe, but it does show some things of value to us:
- Be sure that others have the same understanding as you when you use a phrase.Technical and business jargon, for example, can be a source of misunderstanding. ITIL terms like incident, problem, utility and warranty might have clear meanings to IT staff, but will be used to mean different things by the rest of an organization. The IT department supporting a police force might find the term ‘incident’ has a precise meaning amongst their users – a situation requiring the attendance of a police officer!
- Emergencies have multiple influences on our behaviour.Understanding the diverse impacts of emergencies is, or at least should be, important to us in service management. Planning and agreeing courses of action to take, during an emergency, is sensible preparation. Realizing that things may feel like emergencies to others, even if they don’t to you, is important too.
- Customers have an important role to play in avoiding emergencies by reporting initial symptoms rather than waiting for major issues to manifest.Try to encourage this proactive behaviour by ensuring there is a simple mechanism for communicating concerns, and that customers are not blamed or ridiculed by IT for raising concerns. Adopting the approach used by airlines and air traffic control of reporting and investigating ‘near misses’ is an idea worth considering within many ITSM environments.
Stopping the Fire Is Better than Putting it Out with Style
The lesson for us in ITSM could be as simple as this: avoiding emergencies is better than solving them. When you see emergencies as routine and normal, then you can unconsciously be delivering bad customer service.
Does your organization reward the fire-fighters more than fire preventers? If so, perhaps it’s time to question that.
Posted by Stuart Rance
on May 31, 2016 in General IT
DevOps is currently very fashionable, and so I hear lots of people talking about how their IT organization will be doing DevOps over the next year or so. The trouble is, as soon as I hear this I cringe, because I can’t help thinking about all of the failed improvement projects these same IT organizations have run in the past. Their stories are remarkably similar and they go something like this…
”We Tried That and It Didn’t Work”
When ITIL was the new approach that everyone wanted to use, these organizations decided that they were going to “do ITIL.” This tended to involve devoting lots of resources to a huge, tool-based, monolithic project, with a team of hard working and technically expert consultants who spent many months – sometimes even years – buying tools, creating process documentation, and configuring the tools to match. The IT organization was then tasked with attempting to follow these new processes. All too often they had virtually no understanding of the reasoning that underpinned the new processes, very little focus on their customers, and even less focus on creating value
. The results of these projects were predictable; lots of money was spent but no value was created. These organizations later said, “We tried ITIL a few years ago, and it didn’t work”.
Some of these same organizations next tried to implement COBIT
. As you may know, COBIT
is a framework for the governance of enterprise IT, and like all governance approaches it must be driven from the top down; to ensure that IT is aligned with the rest of the business, it is essential for governance to come from outside the IT organization. Unfortunately, these COBIT projects were often owned and managed by the IT department, and this again resulted in a technical focus that couldn’t deliver. “We tried COBIT and that didn’t work either.”
Now some of these same organizations tell me that they are going to “do DevOps” and I know that in a year or two they will be telling me: “We tried DevOps and it didn’t work.” And they will certainly be right about it not working, but not because there’s something wrong with DevOps.
How You Should Adopt DevOps
What’s wrong is the approach these organizations take to planning improvements. You should never implement a best practice, a framework, or a standard as an end in itself. Things like ITIL, COBIT, and DevOps are resources. They are sources of excellent ideas that you can use to help improve how you deliver service to your customers. But until you understand that the entire purpose of an improvement project is to increase the value of whatever it is you deliver to your customers, your project is bound to fail. A new practice may be fashionable but it’s the way you implement it that decides whether or not it delivers value. And any new practice that doesn’t deliver new, improved or additional value is not worth the effort you expended on it.
So, if you are thinking about whether DevOps is right for you, you should start by thinking about your customers, and how you create value for them. Some of the questions you might think about are:
- How long does it take us to respond when our customers ask for new services or new features?
- How quickly can we test and release software in an emergency, e.g. for a security patch or a regulatory requirement?
- How often do our changes go wrong, either taking too long, costing too much, causing incidents, or simply failing to deliver the expected business value?
If the answers to these questions show that you need to make improvements, then sit down with your customers to talk about what they need. Get a feel for what they would really like from IT if you could deliver everything they dream about. Then agree on a vision, and share it with all your stakeholders.
Once you’ve done that, it’s time to have a look at some of the great DevOps ideas to see how they could fit into your environment and help you deliver what you have agreed you want to achieve. You’ll almost certainly find many ideas you’ll want to use. But don’t try to change everything at once. Think about incremental improvements you can make that will take you towards your vision. Maybe you can automate testing for some of your services, to reduce errors and increase change throughput. Or maybe you can improve collaboration between your developers and your operations teams, so there is less conflict and more success during handover. You should certainly attend some DevOps conferences to get a feeling for what other people are doing, and see if there are any ideas that you could adopt. You should also read this blog
about how the service desk can help you succeed with DevOps.
Just remember that even if your vision is to have a completely integrated set of tools that will automate your entire software delivery pipeline, these tools are not the goal. Don’t be distracted by the shiny toys and forget about value creation and customer experience. And, please, don’t just “do” DevOps!
Posted by Sarah Lahav
on May 24, 2016 in Service Desk
Leading and managing an IT service management
(ITSM) team can be tough. Not only do you need to think about your own performance, how you feel about your job, and your motivation, there are also the perspectives on the team as a whole and of the individual team members.
Team dynamics are an interesting thing – I guess that anything that involves people and the unpredictability of human behavior always is. Even if you’ve handpicked each team member from the crème de la crème
of the ITSM industry there will still be times when day-to-day operations are adversely impacted by personality clashes, personal issues spilling over into work, and general slumps in performance. Sadly, it can be even more difficult in the real world, where your ITSM team might be an “inherited” mixed bag of great people – some brimming with potential but have yet to deliver on it, and maybe the odd one or two who think that they are paid to attend work rather than to actively embrace and participate in work.
So what can you do to make your ITSM team, and its members, work together better and reach their full potential?
1. Allow for Suggestions, Comments, and Complaints
How you encourage, react to, and deal with all feedback makes a big difference to team dynamics, team performance, team motivation, and your standing as the team leader.
Suggestion schemes, especially those that offer rewards for useful suggestions, are a good example. They are often set up to not only seek out the best ideas and improvement opportunities but also to help make team members feel more included in team and business decisions. And they can be great provided they have a transparent and fruitful “backend.”
So if a team member goes to the trouble of putting together a suggestion for how something could be improved, then the least they should expect is a reasoned response, and I don’t mean an auto-reply that the suggestion has been received. Even if the suggestion is completely hair-brained, feedback should be given as to what, if anything, will be done with the suggestion.
In terms of comments and complaints, if they are about how the team is being managed then you really do need to encourage openness and frankness. Regular one-on-one performance review sessions can be a great opportunity to go beyond the team member’s performance to ask questions such as:
- Is there anything making your work harder than it should be?
- Is there anything that I’m doing, or not doing, that you think I should change?
Such questions and how you respond (including how you act) can have a big impact on your relationship with the team member and the overall team dynamics.
2. Set Aside Time to Connect with Your Team
There’s a fair chance that as a team leader you are busy most of the time. And the issue with being the leader of an ITSM team is that it’s likely that the only time you “connect” with your team is when something is wrong.
If you dread seeing a team member at your office door or hovering at the end of your desk, then you are probably not making, and taking, the time to connect with them on the day-to-day things that make them tick. Unfortunately, you have created an environment where the only time you spend time together is when something has “hit the fan”.
This can cause you to feel resentment – because you associate the approach of team members with bad news – which your team may be able to detect, hence making things worse as they will want to approach you only as a last resort. So make time for the individual performance review sessions mentioned earlier, as it’s a great opportunity to learn more about team members and for them to learn about you. Plus, you can better understand what your team enjoys and dislikes about their work. Of course you can always have less formal conversations around the office as, and when, opportunities arise.
3. Make it Clear that Success Is a Team Game
Personality types dictate that you are likely to have (at least) one person in your ITSM team who thinks they’re the star player, and that everyone else is just there to pass the ball so they can score.
However, work is often best done by teams, groups, and collectives; and letting the “team superstar” take the limelight can be extremely damaging to other individuals and the team as a whole. Recognizing and rewarding those who snatch the spotlight can demean the efforts of those who work tirelessly in the background, harmoniously with other team members; this may dissuade these “hidden” stars from continuing on the right path in the future. If you are only seen to recognize and reward the star player, then you’ll most likely end up with a disengaged team. Or, even worse, multiple team members competing for superstar status – which is neither good for team dynamics or achieving team goals.
So make sure that everyone knows that, although each team member might have their individual areas of expertise, there is no one person responsible for the team’s successes, or failures for that matter.
It’s All About Communication
You might have noticed that these three tips all have one thing in common: communication. Open communication can help to build transparency within the team and to create feelings of value and trust between team members. It helps individuals to feel able to express their ideas and to voice their concerns – both of which are vital for a smooth-running and cohesive team.
You don’t want anyone sitting on an idea that could transform the way you do things for the better. Nor do you want festering issues that are likely to get worse in the long run and threaten team stability.
So there you have my three quick tips. What do you do to keep your ITSM team working together?