Enterprise Service Management Is Not Just for Service Requests

Enterprise service management (ESM) is the use of IT service management (ITSM) tools and processes to support other lines of business within an organization. It’s a term that’s generally used by IT people, who know and understand ITSM, but may be off-putting to those less familiar with IT.  In fact, I enjoyed a presentation by Elina Pirjanti at the itSMF conference in Estonia last year, where she asked us to stop calling it “enterprise service management” (in fact, she wrote a blog about it too). Everyone else in the organization thinks of this way of working as “digitalization” or “digital transformation” and we should use their language, rather than trying to force IT language on the rest of the organization. And this is fair enough, at least up to a point; particularly when I know that all the articles I’ve read about ESM recently have a focus on using ITSM tools to help manage service requests from business units such as HR, legal, or facilities. This is certainly an important use case, and is something that almost every organization should be doing. ITSM tools are great for logging and tracking service requests, as well as supporting automation of request fulfilment, and providing reporting so that you know how well you’re doing.  Why would we not choose to take advantage of these capabilities that are already at hand? Here are my thoughts on how you can take advantage of ITSM to help other areas of your organization…

Providing a Single Portal for All Service Requests

Today, we’re seeing cases of ESM that go a little bit beyond just managing service requests for different units within a business. For example, in some organizations, ESM now provides a single portal for employees to access all the business services they need, whether it’s ordering a new laptop, notifying the reception desk that a visitor is expected, or requesting a pension statement from the finance department. This improves employee experience, as well as providing greater efficiency for internal business units, and increased transparency and understanding of what work is being done by each team. The most effective organizations extend this portal outside their own organization, providing a way to work more effectively with suppliers, and with external customers.

Using Incident and Problem Management Outside IT

When people think of ESM as “digital transformation”, they are only thinking about request fulfilment, and this is all that they include in their ESM project. The trouble is that if those of us familiar with the possibilities inherent in ITSM tools and processes just stick to request fulfilment, then we are needlessly limiting ourselves. There is a huge opportunity for ESM – or whatever we choose to call it – to exploit the value of other ITSM capabilities across the enterprise. I have worked with organizations who are very good at managing their IT incidents and problems, but had never considered using the same approach for managing incidents and problems in other parts of their business. A few forward thinking organizations, however, have now started to consider this. Recently I was talking to a friend who was working as a management coach for a transportation company. This company provides drivers to take trucks on single journeys. Their key business metric is the percentage of trucks that arrive at their destination at the correct time, and they typically manage to get about 98.5% of the trips to meet this target. The CEO wanted to improve, but realized that achieving a very ambitious 100% success rate would require much better, and more detailed, understanding of exactly what was happening with the failing trips. Failures might be caused by breakdowns, unexpected traffic, drivers falling ill, and many other causes too numerous to list; and without good data it would be impossible to devise an investment strategy that would lead to improvement. The way forward is obvious, once you’ve thought of it. We suggested implementing processes based on IT incident and problem management – to help them deliver better service to their customers, and to supply the missing data. The transport company already use tools and processes for managing IT incidents. By using the same tools to implement an incident management process focused on truck movement, the organization will be able to:

• Understand the current status of all the trucks that have issues, providing management with transparency and enabling them to prioritize their resources where they will deliver the best value.
• Provide clear and accurate data about incidents to people who are helping to resolve them, reducing communication errors and improving incident resolution times.
• Access a knowledge base with information about how other similar incidents have been resolved in the past, allowing the organization to learn from experience, rather than depending on the knowledge of the person managing the specific incident.
• Categorize incidents so that they can see trends, and prioritize problem management activity.

If the organization also implements a problem management process, they will also be able to:

• Identify trends, based on incident management data, so that they know which incident types need a better way to resolve them.
• Research and document the best way to deal with different incident categories, to enable their best people to influence what happens throughout the organization.
• Understand the costs and benefits of different approaches to incident resolution, and make targeted investments that will improve business performance.

If you have been involved in IT incident and problem management, then I’m sure you can add to this list.

Design for Experience

But before you go off and implement ESM across your organization, I need to offer a warning. As I was writing this blog, I discussed the concept of using incident and problem management with a friend who doesn’t work in IT. Their immediate reaction was “I already waste too much time fighting my computer. I don’t want to waste even more time filling in forms for some IT manager when I could be getting on with my job.” If you want the benefits of ESM, then you’ll need to think about how people in your organization already view IT, what their current experiences are telling them, and what training they might need. You will need co-operation to get people to change the way they work, and if you don’t design your solution so that it works well for them, then your project is never going to succeed. So make sure you talk to all the stakeholders before you do anything. Understand their concerns and make sure you work with them to design a solution that works for everyone.

So What’s Next?

In this blog, I have given only one example of how incident and problem management processes might be used outside of IT, but I have seen similar approaches in use in many different industries, and I am confident that there are many more I have never imagined. So, have a think about your own organization. Perhaps you can see how an imaginative application of ITSM tools and processes outside of IT could benefit your organization?  If you can think of an ESM solution that will work well and give a great experience to all your stakeholders, don’t let the potential difficulties stop you.  You could end up providing your business with a real competitive advantage.

Back to ITSM Basics: The 9 Guiding Principles of ITIL Practitioner

In a previous blog I talked about “starting where you are” as a guiding principle for people who want to improve outcomes for customers. I talked about how this means not throwing away everything you already do and starting again from zero, and how following this principle can really help you to do a great job when you’re planning IT service management improvements. What I didn’t mention was that “Start where you are” is one of the guiding principles in the new ITIL Practitioner Guidance, which was launched in February 2016. I was delighted to be included as one of the authors of this publication, and I want to tell you a bit more about it. The ITIL Practitioner Guidance describes nine guiding principles, and I believe everybody in service management should think about all of them, because if you follow these guiding principles, they can really help you succeed. In addition to Start Where You Are, the other ITIL guiding principles are as follows:

• Focus on Value: Everything you do should be based on maximizing value for your customers.
• Design for Experience: Think about, and manage, how your users and customers experience your services and their interactions with you.
• Work Holistically: Consider the end-to-end value chain, and how all the bits fit together. Don’t optimize one process or activity at the expense of the overall service.
• Progress Iteratively: Make a series of small improvements, rather than trying to create one enormous project. Agile works really well as an approach to ITSM improvements.
• Observe Directly: Don’t just rely on reports and metrics, go to where the work happens and see what people actually do.
• Be Transparent: Make sure everyone knows what’s happening, engage them early, and make sure they understand organizational goals as well as the actions you’re taking.
• Collaborate: It takes a lot of people to deliver IT, which makes it all too easy for IT teams to have too narrow a focus without due regard for the bigger picture. IT that runs in silos is often the cause of our problems, but if we collaborate across teams then we can do a much better job.

And finally

• Keep It Simple: Eliminate everything that you don’t need, so that you can focus on the things that are really important.

We should remind ourselves to think about all of these guiding principles whenever we plan any ITSM improvement. If we could all learn to focus on these things instead of on our processes and technology, then we’d do a much better job for our customers, and we’d create more value for everyone.

Combining the Guiding Principles

Each of the guiding principles I’ve talked about has a lot of value on its own, but the real benefit comes from combining them. For example, you could combine the ideas of Observe Directly, Be Transparent, and Collaborate when you’re carrying out an ITSM assessment. I’ve done this and it leads to great results. For instance, on one assessment I invited the customer to join me when I interviewed the IT people responsible for planning changes and releases. Not only did this give the customer great insight into the issues that IT were dealing with, but it also helped me to create a report that really did focus on customer value. That made for a better result all round. Another very powerful combination of principles is Focus on Value, Design for Experience, Work Holistically, and Keep It Simple. I used all four of these principles to make absolutely sure that the new incident management process one customer asked me to design really did work for both the customer and the IT organization involved. Actually, this was another occasion where I engaged the customer in helping to design the process — after all the process was there to satisfy their needs —  so, in fact, we also used Collaborate, Be Transparent, and Observe Directly. And really, now that I think about it some more, we also used Start Where You Are to make sure we didn’t waste the great work that had already been done in this area. That’s eight out of the nine principles right there in just this one example! And here’s another example of how I’ve used these guiding principles in practice. This story is based on a real client but I’ve changed some of the details for privacy reasons. The organization operated in many countries, and had lots of separate service desks. Some of the service desks supported just a few users, others supported users in four or five different countries. Some of the service desks were managed in-house, others were outsourced. The organization wanted to improve the service offered to roaming users, and to provide a more consistent worldwide service, but they didn’t even have any consistent metrics that they could use to compare quality of service in different locations. They had an “ITIL Consultant” who proposed to create a new process, which could be deployed to all locations. The consultant had told the customer that it would take about nine months to write the documentation for this new process. I worked with the customer to understand the situation, and then proposed a different approach that would deliver value much faster. This is what I recommended:

• Break the work down into a number of activities, each of which would deliver some value — [Progress Iteratively]
• Talk to customers and users, and agree on a small number of business-focused metrics that we would measure for each service desk — [Collaborate], [Focus on Value], [Design for Experience], [Observe Directly]
• Select the two or three best performing service desks and investigate how these could expand to provide support to more locations, replacing poorly performing desks — [Start Where You Are], [Progress Iteratively], [Be Transparent], [Keep It Simple]
• Continue to measure the agreed metrics and allow the best performing service desk to take over gradually over a period of time — [Progress Iteratively], [Start Where You Are]

Whatever you’re responsible for in IT, I think that the ITIL Practitioner guiding principles can really help you to focus on what’s important, for you and for your customers, so please read about them, and think about how you could incorporate them into your work. You can buy the ITIL Practitioner Guidance from AXELOS, or from TSO or from other online bookstores.  Consider each guiding principle in turn and think about how you could use it to improve what you’re doing, whether this is an improvement project or just doing your normal work. As always, please let me know how these ideas work out for you. You can contact me easily on Twitter at @StuartRance.

Using the Knowledge from Within (Your Help Desk)

Having an external perspective is valuable, and even essential, for an organization to establish improvement ideas. That ability to ”see the wood for the trees” coupled with knowledge of the broader world outside your organization can be helpful. That’s why consultants are often worth the money: to deliver that outside world view and help an organization adopt approaches that have proven to be helpful to others. This is often referred to as following best practice, and getting external help to do so – a traditional IT service management (ITSM) approach taken by many CIOs and IT managers. But there is another, often equally important, perspective (aside from the wider world view) that an organization should be aware of in pursuit of continual improvement. And that’s the perception based around familiarity, local knowledge, and shared experience, which is available to companies that want them. These are far cheaper than the external consultant path, and will complement and refine best practice approaches. The most powerful concentration of useful knowledge and awareness in many organizations resides right inside their help desk – especially true if that help desk is internal and local to the user community.

Let Your Help Desk Help You

Collecting and analyzing data is an important and valuable exercise. At the heart of good problem management is working with the collected incident data, seeking trends and patterns, and initiating corrective or, better yet, preventative actions. Don’t stop doing that, but remember also that users are people, and the heart of the help desk role is people-to-people communication. So… along with looking at the cold, hard statistics, it makes good sense to collect information on how your users actually feel about the services you deliver, the things you get right, and the things you get wrong. In fact, what exactly do they see as right and wrong? Their ideas may not line up with yours. A good help desk offers IT management a quick, simple, and reliable route towards understanding how their users actually feel about the services delivered. But how often do those IT managers do the simple and obvious thing: go and talk to the help desk staff. So much can be gained from opening channels of conversation, no need for anything too formal, just go and talk to them, maybe over coffee or even a beer?

A Conversation Is Worth a Thousand Statistics

In fact, talking with front line staff is, and always has been, a good plan for most organizations. As mentioned earlier, this shouldn’t be seen as an alternative to formal analysis but as a human-oriented complement to statistical and factual analysis. A whole range of subtler nuances are available from ongoing dialogues with help desk staff, and even more from sitting down and watching them in action. For example, here are some things that might be learned/discovered:

• How often do they need to calm users down before they can capture relevant information? Is it clear why the users get upset? Is it just that they need their services fixed, or is the mechanism you have for calling the help desk part of the problem? Features that are attractive from a supplier perspective – like menu choices (the press 1 for complaints, press 2 for requests kind of thing) – may cause users to get even more upset than they initially were when they decided to call the help desk!
• How much user self-help is going on out there? The conversations that help desk staff have are likely to expose how often users have tried to fix things themselves, and how often they have discussed and tried approaches with colleagues before calling the help desk. This kind of information is rarely captured by any formal mechanism but should have influence over how services are built, maintained, and supported.
• And, crucially, how happy are the help desk staff? That might not sound like a top priority but consider how expensive staff turnover can be – recruitment, training, security clearance, etc. before a new staff member is fully contributing. Keeping staff happy is key to reducing those kinds of costs.

Keep the Conversations Going

Of course, the help desk people are not the only staff a manager could usefully spend time with. Second and third line support personnel have their own tales to tell, as do service level managers. In fact, just about every one of them offers information and early warning signs about possible future issues. Therefore, don’t just rely on measurements and numbers – remember that service is about people, so take the time to talk to those people who are out there delivering those services on your behalf. Image credit

Major ITSM Improvements Should Start with Small Steps

I visited two very different customers recently.  They had very different problems and the solutions I suggested for them were also very different. But there was one thing that they had in common — they had both delayed starting the improvements they knew were needed because the costs and risks were too high. Instead, they had done nothing and so allowed their problems to continue completely unchecked. For both these customers, the solution was very similar. Both needed to “Start where you are”, “Keep it simple” and “Progress iteratively”. These are three of the guiding principles from ITIL Practitioner, and between them they encourage IT service managers to adopt an agile approach to resolving issues, rather than taking on big, risky, expensive IT service management (ITSM) projects. I created a few podcasts on these topics for SysAid’s Back to ITSM Basics project, so please do listen to those if you are interested. If you also need improvements that seem too expensive, or too risky, then read on to learn how you can get started.

A Big Organization with a Big Problem

One of the organizations that I visited is very large. It provides support services to many external customers all over the world, and has lots of service desks. Some of these service desks are dedicated to a single customer, others support multiple customers, and some are for internal users. Some of them provide logging and dispatch only, others provide level 1 support as well. While many of the service desks use the same ITSM tool for logging and managing incidents, there are quite a few other tools in place as well. Almost all of the customer communication, for all the different service desks, takes place by phone. The organization would like to shift to more efficient channels, e.g. text-based chat and a self-service web portal, but because the company is so big, the implementation costs would be enormous. IT has, in fact, identified a tool that could provide chat for all of their complex environment, but since they can’t be confident that an implementation project would run smoothly or that the returns would justify such a big investment, they can’t get the funding for this. As I talked to the IT department, the solution to their problem became obvious. Instead of trying to implement chat for all of their users, which would be a very big and expensive project, they could start where they are, start small, and grow in small steps. The organization’s users already have a tool that supports chat, although it is not currently used for IT support. So it would be quite easy for IT to start there. Here’s what they can do: Find a small group of users and offer to use this existing tool to provide them with IT support. Monitor carefully to reveal any issues for the service desk or the users, and resolve them before scaling up to support more internal users. Eventually the IT department will reach the limits of how well this tool can scale in their environment, but by then they will have:

• Identified and resolved many issues relating to how the service desk works when handling chat-based interactions
• Understood which types of incident are best handled by chat, and which are better managed using phone or other channels
• Discovered what communication and support works best to encourage users to migrate from phone to chat
• Collected data about how many calls each service desk agent can manage using chat, and how much this could save if scaled up to the whole organization

This gradual implementation of chat would be very low risk, and, by starting with a tool that is already in use and familiar, would not involve much cost. By the time the IT department has scaled up to supporting a large number of internal users they will know whether a full implementation using an expensive tool will be a cost-effective investment, and they will also have learned what needs to be done to ensure success. If they wish to go ahead with an expensive new tool, this will give them everything they need to create a business case for the next stage.

A Small Organization with a Security Problem

The other organization that I visited is MUCH smaller. They have just two staff working on their in-house service desk, supported by a manager who carries out other roles as well. They have a few thousand users in a small number of offices, all in a small part of one country. They are finding it difficult to manage user access controls. When a new user joins the organization, they ask about what access this user needs, and then grant individual rights to the specific applications and data. When people change jobs or leave the organization, it’s difficult to find all the access rights that have been granted, so these are often left in place – and this creates a significant security risk. The support manager knew that the solution to their issue was to move to role-based access controls (RBAC), where all access rights are granted to roles, and then those roles are assigned to users. But there had been no attempt to migrate to RBAC because of the risks involved. Sometimes things go wrong during even the best planned migrations, and this could cause significant cost and risk to the business. The solution for this customer was also to take an agile approach. Instead of attempting to change everything at the same time, the organization could start where it is, keep it simple, and do it a bit at a time. Here’s what they can do: Next time a new employee joins the company, grant all the rights that user needs to a newly created role, and then assign this role to the new user. This should be no more work and no more risk than would normally be involved in providing appropriate access to a new user. Once confident that the role works well, and that no changes are needed, go on to migrate one existing user to the role, removing the current rights that user has. Again, this would carry only a small amount of risk, and the change could be undone quickly and easily. Next, continue adding users a few at a time.  Once confident that there are unlikely to be any issues, move over everyone else who should be assigned to that role. When the opportunity arises, create a second role, and migrate users in the same incremental, low-risk, way. This approach means it will take quite a long time to completely move from the current situation to a well-managed RBAC implementation.  But the one improvement that you can guarantee will never be finished is the one you think it’s too risky to start in the first place.  By starting where you are, keeping it simple, and progressing incrementally, the improvement this company wants will eventually be achieved, with little risk, and without a big project that keeps its two support staff tied up and unavailable for long stretches of time.

Summary

Many organizations use agile software development to reduce risk and speed up time to market. The same ideas apply equally well to ITSM. Almost every ITSM improvement can be carried out in an agile way, and there really is no need for huge, expensive ITSM improvement projects. If you’ve been putting of improvements that you KNOW you need, because of the cost and risk, then why not think about how you can “Start where you are”, “Keep it simple” and “Progress iteratively”?

How to Deliver More Value from Your Help Desk

In my previous blog, What’s Essential for an IT Help Desk?, I discussed the things that every help desk should do. These were:

• Log and manage calls from IT users
• Resolve incidents
• Generate useful reports
• Continually improve

If you’re not already doing all four of these, then please go and read that blog to help you initiate some of the changes you need to make.

---

If you’re already doing all the essentials, then you might want to think about ways of using your help desk to create more value for you, and for your customers. A great help desk can do a lot more than just the essentials. Here are some things to think about if you’re ready to take the next step.

Identify and Manage Problems

The trouble with excellent incident management is that incidents keep happening. No matter how good you are at managing incidents, and how grateful users are for the service, they still suffer from the disruption to their work and wish they had not needed to call you in the first place; you are using up valuable resources managing something nobody actually wanted to happen. This is where problem management comes in. Problem management can help you to:

• Stop incidents from happening, or at least make them less frequent.
• Reduce the impact of any incidents that you can’t prevent.

This means that your users get a better service, and your help desk has less work to do. That’s a win-win for you and your customers. A small help desk could easily be put off by the idea of doing problem management because they may fear it’s too time-consuming or too difficult, but in fact it’s straightforward. If you don’t already do problem management and want to start, just follow these simple steps:

• Identify some problems. You can do this by looking at your incident records to look for incidents that keep happening, or asking anyone who works on the help desk to log a problem whenever they notice repeat incidents.
• Pick one or two problems to investigate. You don’t have to investigate every problem that you identify. Start with the ones that happen the most often and the ones that have the biggest impact on the business, because these are the ones that cause the most pain.
• Fix the problem if you can. The best response to a problem is to identify why it happens and remove the causes.
• Document a workaround for problems you can’t fix. If you can’t remove the cause of a problem, then think about how you can reduce the impact when it happens again and document this.  Put your plan into action next time the problem occurs, and review what happens, so you can document anything that you need to change, to improve the outcome.
• Pick some more problems to investigate. You will find that you free up resources each time you fix a problem, and this means that you can start working on some more problems. If you do this consistently, you can create a cycle of continual improvement that is of enormous benefit to you and your customers.

Provide Self-Help

When you provide your users with the information they need to help themselves you can get much faster incident resolution, with less effort and reduced costs.  At a minimum you can simply allow users to log their own incidents via a web interface, and then provide them with status updates via the same channel so they don’t need to keep phoning you. Ideally you should do a lot more than this, by using the same web interface as a channel for providing accurate and accessible information about common issues and how to resolve them. Self-help and problem management can work well together.  You use problem management to identify the common types of incidents and document how to resolve them. Then you provide this information directly to the users, rather than making them phone you to ask for help each time a common incident occurs.

Proactively Communicate with Users

One of the help-desk essentials I described in my previous blog was managing incidents, and this includes providing users with status updates. Users value regular and timely status updates on their incidents, but a proactive help desk can provide much more user communication than this. Examples of good proactive communication that the help desk can provide include:

• Telling users about new and changed services, to ensure they are properly prepared for them
• Making sure people know when the service is going to be unavailable for scheduled maintenance or other activities
• Letting users know that you are aware of and working to resolve any incident that impacts many users before they all phone to tell you that something’s wrong
• Encouraging users to adopt practices that help protect your valuable information; you can do this by sending routine security reminders

There are lots of different ways that the help desk can communicate with users. For example:

• Messages displayed on screens when people log on
• Messages displayed on a self-service portal or service status page that users can review when they need to know what’s happening
• Announcements over office loudspeaker systems
• Posters on walls and office doors

I’m sure you can think of many more ways to communicate with your users, but the important thing is to get the balance right. Too much communication can be as bad as too little, as people will eventually stop paying attention. So, make sure you get feedback from your users on how well your communication is working.

Conclusion

This blog has described some of the ways your help desk can help to create value. You do need to ensure that you start with the essentials first, but if you want a great help desk, you should not you limit yourself to that. A great help desk will use problem management to help reduce the number and impact of incidents, it will provide self-help so users can resolve their own incidents, and it will proactively communicate with the users to help keep them informed. How many of these things does your help desk do? I do hope these blogs have given you some ideas of things you could do to provide a better help desk for your customers. Please let me know which things you try, and how well they work out for you.

Back to ITSM Basics: Start Where You Are

If you’re involved in ITSM improvements, and especially if you’re fairly new to the field, it’s easy to feel overwhelmed. One thing that can really help you to focus is to follow the principle “Start Where You Are”. It sounds obvious, doesn’t it? Of course you should start where you are. After all, where else could you possibly start? But this principle captures some very important ideas in a really simple phrase, and by following it, you can avoid many of the mistakes that can cause IT service management projects to fail. What “Start Where You Are” really means is don’t throw away everything you already do and start again from zero. If you try to impose a completely new way of working, without building on what’s already in place, you will inevitably waste time, money, and effort. AND you will alienate the very people you need to have on your side. When you tear up everything that people are doing and tell them to start working differently, you’re bound to stir up opposition – and sometimes outright resistance. If you do this, then it can become really difficult to integrate the changes you need into your organization and culture. It’s much better to start by looking at how people currently work and talking to them about it.  If you can engage them, then you can actively involve them in thinking about how to build on what they do now so they can deliver better outcomes in the future. And this means you can focus all your efforts on putting the changes you need into effect, rather than into managing reluctant, resistant, or even hostile staff.

How to Carry Out an ITSM Assessment

I’ve carried out IT service management assessments for many different organizations over the years. These ITSM assessments have usually been a first step in a program to improve how the organization delivers value to its customers. As you can probably guess, I’ve rarely been welcomed with open arms. After all, nobody likes an outside consultant to come in and tell them all the things they’re doing wrong. And yet, this is what people (and organizations) expect consultants to do. My clients expected me to come in and look for the things they were doing wrong, and to write a report listing these things and saying what needs to be changed. But if I did that, I knew that my assessments would be of limited value. They would probably be resisted and might even be ignored, no matter how much the organization had paid for them. Fortunately, I discovered that there was a much better way to approach assessments. I could begin by identifying the things that were being done WELL. Things that are being done well in one part of an organization are great opportunities for improvement across the organization – they can usually be replicated without meeting much resistance. After all, people are copying best practice from their peers, rather than listening to some external consultant. What’s more, when people know that their strengths have been recognized and validated, they are more likely to accept suggestions for improvements in areas where there are weaknesses.

Ask People What Needs Improving

The other thing I discovered was this. If you want to know what isn’t working properly and how to fix it, ask the people doing the job. It’s amazing how many people in an organization know exactly what needs fixing, if only someone would listen to them. I learned that if I took all the ideas from staff working in an organization and combined them with my independent assessment, I could come up with a plan to help deliver better outcomes for customers. AND it was a plan that started where my customer was. So if you’re planning an IT service management improvement project, please don’t throw away all the good things you’re doing. Look to see what you do well and think about how you can start where you are. Best of luck to anyone who’s listening, and if you are planning improvements, drop me a line to let me know how it goes! You can find me on Twitter as @StuartRance. (This blog was originally published as a podcast by Stuart Rance, as part of SysAid’s "Back to ITSM Basics" program.)  

The Case of the Ignored Business Case

“What advice do you have when your business case for ITSM is created but ignored?” This is what @sysaid tweeted to me in reply to my tweet regarding my blog The Case of the Missing Business Case. https://twitter.com/sysaid/status/803235463532265473 What a great question! As I talk about in my original blog, every IT service management (ITSM) implementation should begin with the development of a business case. The business case provides IT with an opportunity to demonstrate its understanding of the business it serves by objectively discussing the opportunities, risks, benefits, and deliverables of the ITSM implementation – in business terms. A well-written business case articulates the needed investments, in terms of people, time, and money, as well as how ITSM implementation supports business goals and objectives. It helps make the ITSM implementation a business initiative, enabled by IT, and not just another “IT project.” But most importantly, the business case secures the first critical deliverables for any ITSM initiative – senior management investment and support.

”Yes, I did all of that, but…”

You wrote a strong business case. You addressed all of the pertinent topics.  And your business case gets ignored. Now what? Has all of the time developing and writing the business case been for naught? Don’t give up just yet. Here’s 7 things you could try. First, check yourself. Objectively review your business case from the perspective of senior management. Are your assumptions reasonable? Have you clearly articulated resource needs and anticipated benefits. Is the business argument strong enough? Have you demonstrated that you will be a good steward of the company’s funds? Engage your sponsor. If you identified a sponsor in your business case, get that person involved. Ask for guidance and support for gaining approval of the initiative. Engage key stakeholders. Identify and meet with key stakeholders. Discuss how ITSM can help alleviate pain points or enhance performance for their specific issues. Not only will you build relationships, you may even learn some things that may further strengthen your business case. Gain their support and ask them to advocate for your proposal. Publicize (really publicize) goals and measures. Assuming you have the ability to collect some of the measures regarding the goals defined in the business case, start publicizing them. Post goals and current measures on an intranet page, outside your cubicle or office, in the break area – anywhere where people will see. Explain how not meeting these goals is impacting the organization and how ITSM would help. In the words of Dr. John Kotter, you want to “establish a sense of urgency.” Using measures helps build credibility and a sense of urgency for the business case. Conduct an experiment. Can you “try out” a small part of the ITSM implementation? Take a current data sample to do a tabletop exercise to confirm assumptions or anticipated benefits of the implementation. Then, share the results with your sponsor and your key stakeholders to further enable their advocacy for the ITSM initiative. Execute the communication plan. As part of the business case, you most likely developed a high-level communication plan regarding the initiative. Execute it! Look for opportunities to talk up the benefits and risks that you described in the business case. Go to staff meetings; do a roadshow; publish an article on your corporate intranet site or newsletter. The goal is to attract attention and gain grass-roots support for the ITSM implementation. Sometimes the timing just isn’t right. Keep in mind that due to business influences beyond your control, sometimes even the best-written business cases aren’t immediately approved. Don’t take it personally. It doesn’t mean that the ITSM initiative wasn’t a good idea; perhaps there are other business priorities that must be addressed first. If you find yourself in such a situation, use it as a learning opportunity and ask for feedback from those senior managers who reviewed the business case. Doing so demonstrates that you care and are committed to the success of the business. Good ideas are good ideas – and including feedback from senior managers in the next version of the business case will make for a stronger business case!

Persistence Pays Off

I once had a former manager tell me “if you don’t believe in your story, then you can’t expect anyone else to either.” You’ve built a good business case.  Win hearts and minds through positive persistence – it will pay off!

Machine Learning – the Next Big Thing for ITSM in 2017

As 2016 ends and we look forward to another year in IT service management (ITSM), one wonders what we (ITSM pros) should be focused on in the next twelve months. There’s been a lot of buzz this year about things such as  DevOps, enterprise service management, customer experience and consumerization, and digital transformation. But I think there’s a wealth of opportunities for us and the businesses we serve in another area – automation. Not the process automation that we’ve benefited from since the early days of ITSM tools, or the orchestration that has made virtualization and cloud so much easier. I’m instead referring to a different type of automation, where we “cede power to the machines” and their ability to learn, i.e. machine learning – “the study and construction of algorithms that can learn from and make predictions on data” (source: Wikipedia), where: “Advanced machine learning algorithms are composed of many technologies (such as deep learning, neural networks and natural-language processing), used in unsupervised and supervised learning, that operate guided by lessons from existing information.” Source: Gartner IT Glossary And Gartner recently stated that: “Smart machines will enter mainstream adoption by 2021, with 30 percent adoption by large companies, according to Gartner, Inc. Technologies including cognitive computing, artificial intelligence (AI), intelligent automation, machine learning and deep learning fall under the umbrella term for smart machines.)” But I’m far more bullish about machine learning from an ITSM and IT support (or for any service and support scenario) perspective, as many opportunities, and possible solutions, to use machine learning in our everyday activities already exist. And I think we will quickly see ITSM tool vendors partnering with machine learning technology partners to deliver against them.

ITSM Is Full of Opportunities for Machine Learning

ITSM pros have spent much of the last two decades optimizing IT service delivery and support in the enablement of business operations. Different operational elements have been addressed – from the adoption of best practice processes, the recruitment and training of the “right kind of people,” to the exploitation of technology (in particular workflow and automation, knowledge management, remote control, self-service, and more recently business intelligence). Much of this has been done to improve efficiency and effectiveness – it’s what we seem to do in ITSM. But we still often place too much reliance on human effort, and human intellect, when we could cede the power – okay, some specific tasks – to the machines. For example, tasks where algorithms can be used to understand patterns and context to decide the best course of action without human input. The results and benefits being similar to the use of our existing orchestration-type automation:

• Greater speed/efficiency – machines can be quicker than the smartest of humans. They also work 24/7 including all public holidays.
• Reduced costs – people costs are still a large part of the overall IT department budget and, while technology isn’t necessarily cheap, the cost of automation should be more than covered by people-cost savings.
• Better people utilization – it’s as simple as freeing up time-poor staff from repetitive (and potentially mundane) tasks to allow them to focus on the more important things.
• Reduction in human error – people make mistakes and it doesn’t matter if they are inexperienced, rushing, or tired – these mistakes might have an adverse business impact. Automation makes far fewer mistakes, with these usually still people related.
• Greater ability to change – quickly changing ways of working, or even just responses to simple questions, can be problematic for people as they unconsciously flit between old and new for a while. Automation, on the other hand, just stops the old way and starts the new way.
• Better customer experience – while automation is often seen as a boon for the service provider, it also extends its benefits to the service receivers – whether it be speedier delivery, the passing on of cost reductions, greater probability of service delivery, or better support and customer service when things do go wrong.

A new AXELOS survey and report, “The ITSM Professional in 2030: A future full of opportunities” (January 2017), also shows that most ITSM professionals are already betting on automation and machine learning:

• Automation – 89% of respondents “think that an increase in automation will take over the repetitive tasks of IT, creating more time for service managers to focus on delivering more value to their organizations.”
• AI/machine learning – 77% of respondents “said they believed these trends would have a profound impact on the IT workforce, liberating ITSM professionals from routine tasks and free up time for responding to demands for more creativity and ‘human’ input.”

So where can machine learning help?

Five Examples of Machine Learning Use Cases in ITSM

These are all things that can be done or used now:

1. Identifying and predicting issues and problems. The technology can also offer up the most likely resolutions. It will reduce mean time to resolution (MTTR) and opens the door for predictive maintenance (and less reactive fixing).
2. Better understanding the risks of proposed changes. Not only understanding what will be impacted but what the likely impact will be.
3. Predicting what’s needed or even what will happen. From demand and capacity planning to understanding the future levels of customer satisfaction based on what’s happening or planned.
4. Greater access to information and known solutions. Machine learning improves search accuracy, with data-based recommendation capabilities similar to what people already get in their personal lives from companies such as Amazon and Netflix.
5. Easier and better knowledge management. The last two decades have shown that people aren’t great at knowledge management – or the knowledge article creation part of it at least. Machine learning can be employed to both identify “missing” articles gaps and to create new articles automatically from existing tickets, i.e. the already documented resolutions.

So what do you think of the possibility of machine learning becoming a staple of ITSM? Or are you already using it? I’d love to get your feedback in the comments section below.

How to Meet Customer Expectations

One of the biggest problems we have to deal with in IT service management (ITSM) strikes whenever we fail to meet the expectations of our customers and users. No matter how good the service, and no matter how well we support it, when we don’t deliver what people expect they’re unhappy. I’ve worked with lots of IT organizations who regularly failed to meet expectations, and who don’t accept any responsibility for this. There always seems to be an excuse, for example:

• “Their expectations aren’t reasonable.”
• “The business doesn’t give us the resources we’d need to do that.”
• “We’ve delivered what the service level agreement (SLA) says the users are entitled to.”
• “We didn’t prioritize it because the customers didn’t tell us it was important.”
• “We can’t introduce new functionality as fast as they want, we’re far too busy resolving issues as it is.”
• “We can’t make that change, it’s far too risky. They’ll have to wait.”

Perhaps you’ve heard things like this in your organization; maybe you’ve even said some of them yourself.  If that’s the case, then maybe it’s time for some serious reconsideration. If you want to deliver a great service to your customers and users, explaining why you can’t do things isn’t good enough.  What the most effective ITSM organizations do is to take responsibility for managing customer expectations.  Of course, this is easy to say, but not so easy to do.  Here are my suggestions. If you want to improve your organization’s ability to meet expectations reliably, then you need to do four things:

• Understand what people expect
• Communicate what can be achieved and try to influence expectations
• Manage your services to deliver what people expect
• Report your achievements to ensure that people know what you delivered

All four of these are important, and you’re most likely to meet your customer’s expectations only if you pay close attention to all of them. In the rest of this blog, I’ll be examining these four things in a bit more detail. But before I start, there’s an important distinction to bear in mind (see Users, Customers – What’s in a Name?). ITIL distinguishes customers (who negotiate, agree and pay for the service) from users (who actually use the service). If you’re not familiar with this distinction, then think about a toy shop. The parents buy the toys but the children use them.  When I talk about customer expectations I mean the expectations of both of these groups. Failing to consider the needs and expectations of users is just as bad as not meeting the expectations of paying customers.

Understand What People Expect

If you want to understand your customers and users’ expectations, you need to talk to them.  And you need to do it on a regular basis, because needs change over time, and expectations change in line with them. Many IT organizations rely on SLAs to tell them what customers and users need. Unfortunately, SLAs may have been negotiated months or even years earlier, and are, in any case, often written by the IT organization rather than by customers. You may know and understand the SLA, but what about your customers? If you use SLAs to plan and deliver services, then you need to discuss them with your customers AND USERS on a regular basis. Do they understand the targets? Are the targets expressed in clear business terms, or are they technical IT targets of little relevance to anyone else? Are the targets still right for their needs?  If you’re not yet in the habit of talking to your customers, please don’t wait for the next annual review to come round. Unless you happen to be in the middle of managing a major incident, the best time to talk to your customers about their expectations is right now.

Communicate What Can Be Achieved and Try to Influence Expectations

Sometimes customers do indeed have unrealistic expectations, and we can’t deliver what they expect because it would just be too expensive. For example, they may believe that you can deliver a service that responds in less than a second to thousands of transactions a minute, with all incidents being resolved within 2 minutes. Now how amazing does that sound?! If you know what they expect and you really can’t deliver it, talk to them about it now. Don’t wait until after you’ve failed to deliver. Be honest, explain why this can’t be done; show them the potential cost of meeting the unrealistic expectation compared with the benefits. Sometimes this will be all you need to do to help your customers understand why they need to modify their expectations. On the other hand, you might be surprised to discover that the customer really DOES need that level of service, and is prepared to accept that they’ll have to pay for it. One customer that I worked with told the IT department that they wanted a service that failed over instantly. The IT department assumed that the 20 seconds needed for recovery after a RAID disk or cluster member failed would be good enough, but when I checked with the customer they really were prepared to pay what it took to fail over within ¼ of a second – because after that length of time the costs to the business would be enormous. In any case, you need to agree what can really be achieved.  When you have agreed, write this down, preferably using the customer’s own words. Don’t hide behind obscure technical targets. For example, many IT organizations specify a goal for percentage service availability. This could be 99.5% or 99.9%, but however meaningful this is to the technical staff, customers probably have no idea what it means. It’s much better to specify how often the service is likely to fail and how long it will take to fix. For example, “Complete service failure will happen at most 4 times a year and will be resolved within 4 hours” is much more helpful than “99.82%”.

Manage Your Services to Deliver What People Expect

It’s not enough to agree on targets with your customers, if you can’t achieve them.  You need to make sure that you put in place whatever measures are needed to do what you said you would do. Let’s take the example we’ve just used. If you’ve agreed that “Complete service failure will happen at most 4 times a year and will be resolved within 4 hours,” then you need to think about how you can manage both of these numbers. What might cause a complete service failure, and how likely is it to happen? How can you make it less likely? How would you recover from this failure? How long would it take? What can you do now to cut the recovery time? This is all fairly standard risk management activity, but if you don’t have a risk register and you don’t manage your risks, then you’re just waiting to fail.

Report Your Achievements to Ensure that People Know What You Delivered

Finally, you need to talk to your customers about what you have actually achieved. Again, you should do this in terms they find useful. Don’t provide customers with a 200-page report every month if they just want to know what exceptions happened, but don’t just tell them what went wrong. The most important thing to do in a regular report is to tell customers what you are doing to improve.  Explain what you are doing to make their experience better next week, next month, or next year. Discuss these improvements with them. Are you focusing on the right things? Will the proposed improvements actually make their experience better? Do they have suggestions to make?

And Finally

What do your customers think of the services you deliver? Do you have good feedback mechanisms in place so that you really understand how they feel? Mechanical customer surveys have a part to play, but nothing can replace getting out there and talking to your customers, AND your users. If you make sure that you understand what they want, that they understand what you can deliver, and that you are working together to ensure the best value from the IT services that you manage on their behalf, then you won’t have any problem with managing customer expectations. You can read more about customer experience in my white paper ”Back to ITSM Basics” Might Not Be What You Expect. Image credit

2017: When Old Trends Have Their Heyday

Most tech predictions focus on the next “big thing.” With our appetite for new and different, we tend to overlook the power of ongoing trends. 2017 is a year when existing innovations will settle down, mature, and have their heyday. Innovations are most powerful when they are taken for granted. Consider smartphones. When Apple released the iPhone in 2007, it was the world’s hottest technology. Over the past 10 years, smartphones have lost hype but gained influence. If at least 2 billion people own smartphones, they are not merely a technology but an institution of human society. Their ubiquity is power. In 2017, four ongoing trends will make strides towards that honor of being taken for granted:

1. DevOps – We’ll Do It Our Way

In 2016, every tech company seemed to experiment with DevOps. Organizations all want to release software daily or weekly without errors and downtime. Yet no one agrees on the definition of DevOps. Is it a culture? A set of processes and technologies? A philosophy? DevOps is probably all the above, and the definition is flexible by design. DevOps is not unlike “mindfulness” training, a hot trend from the health world. If you want to be more mindful, should you meditate, keep a journal, go to yoga classes, or do all three? Who knows until you try them out? Ditto with DevOps: the best approach is the one that works for your company. DevOps is destined for ubiquity. Companies will get beyond their DevOps identity crisis in 2017 by defining and applying the methodology in their own way.

2. Cloud Computing – Let’s Get Our Money’s Worth

In 2016, no one can dispute the cost-efficiency, convenience, agility, and other values of cloud computing. That doesn’t mean companies have saved money by switching to cloud services. Why? Well, when you start an expensive new sport, like skiing, it’s tempting to overbuy equipment. You might choose the heaviest, warmest coat at the store. A year later, when your skiing improves, the coat becomes unbearably hot and sweaty. You wish you had bought a lighter jacket and some layers for half the price of that wearable furnace. 2017 is the year when companies will downgrade, ditch, or replace the bulky, expensive cloud services they didn’t need in the first place. The cloud will finally save money.

3. Cybersecurity – The Internet of Things (IoT) Battle

On October 21^st of this year, a DDoS attack against Dyn, a major DNS host, showed us how vulnerable the Internet of Things (IoT) is. Some of the U.S.’s largest metropolitan areas couldn’t access Twitter, Netflix, Reddit, PayPal, and dozens of other popular web services. As security expert Brian Krebs explains, the attackers hacked Internet-connected digital video recorders (DVRs) and IP cameras and then used them to flood traffic towards Dyn’s servers. Commentators have raised alarms about the vulnerability of IoT for years. It’s not a new trend. Although the Dyn attack seems ominous now, it will force IoT cybersecurity to mature in 2017. IoT device manufacturers will make cybersecurity a priority rather than an addendum.

4. Help Desk – I’ll Do It Myself

A surprising number of people still email or call help desks directly. They don’t bother consulting the end-user portals, knowledge bases, and other self-service options. At SysAid, where we provide help desk and IT service management (ITSM) solutions, we’ve learned that Millennials do the opposite: they dread getting on the phone. They troubleshoot independently and then submit digital tickets if that fails. Frankly, they save time and money for help desks. In 2017, help desks will try to convince Gen Xers and Baby Boomers to use self-service. To that end, help desks will improve the quality of content in knowledge bases so that anyone can follow along. They will also make self-service more social. Historical issues from the community will constitute the bulk of knowledge base content. Will this work? Not in every case. I’m sure you know somebody who hates e-readers and says, “I just like to hold a physical book.” Likewise, a lot of end users say, “I just want to speak with a real human being.” That cohort of end users (maybe 20 percent) won’t change.

The Mark of Importance

Some forecasters ask you to ponder a hazy future; I ask you consider a more concrete present. In 2017, embrace the innovations that stop making headlines and start defining whole industries. Being taken for granted is an inglorious mark of importance – and power.