Can you believe it’s time to investigate our final ITIL case? In this closing installment, we’ll focus on the top myths surrounding ITIL Request Management—a process that if done well can make IT’s job easier while delighting end users. Vawns Murphy, ITIL/ITSM expert and Principle Analyst and Research Director at ITSM.Tools, will again be our guide to shining the light on commonly held ITIL falsehoods. Read on for ITIL Request Management truths and best practices that every IT organization should know and follow.
Myth 1: It’s just a ticket right?
Short answer: Incidents and Service Requests are two completely different types of records. Incidents are break/fix with the key being speed and efficiency. In contrast, Service Requests are enhancements, “how do I’s,” or added extras.
I hear over and over again: “Incidents and Service Requests are exactly the same thing, right?” No, no they’re not! For starters, they are totally different types of records. When something breaks or falls over unexpectedly, that’s an Incident and it must be handled right away. A Service Request, on the other hand, is when a user requests information, access, or a new asset. There are a couple analogies that I like to use for those who are having difficulty understanding the differences.
Iron Man vs. Jarvis
If you’ve read our previous post, you’ll know that Incident Managers are the super heroes of IT that swoop in to save the day when something is broken. It’s all about fixing the issue quickly and efficiently with as little adverse impact as possible. Think of Batman or Iron Man. When something goes wrong, Tony Stark swoops in with his fancy suit and saves the world.
Request fulfillment on the other hand, is like Jarvis, Tony Stark’s digital assistant sidekick. Jarvis is equally as awesome and important to the mission but he isn’t actively saving the world. Jarvis is doing the value add or the little extras. He’s asking questions, getting answers, going off and getting information, and coming back with the things and reports that are needed to complete the job. That’s request fulfillment.
The washing machine
Another example I use is a washing machine—mainly because with three kids I do so much washing in this house that it’s always top of mind! An Incident means the machine is broken and I can’t attack the growing mountain of dirty clothes comprised of sports uniforms, school play costumes, etc. So what do I do? I call the engineer to come out and fix it. All I want to know is: How quickly can you get here? How soon can you fix it? How much will it cost? How can I get the mountain of unwashed clothes under control again?
Whereas if I’m going out to the shop and buying laundry detergent, fabric softener, and maintenance tablets to keep the machine running effectively—that’s a service request because I get to choose the type, the brand, the price, and any optional extras. I have the time to decide on my options based on loyalty points or manufacturer recommendations.
Incidents are unplanned. You don’t plan for something to break and there’s never going to be a good time for it. However, as a user, you can plan Service Requests according to when it’s most convenient for you. You can take your time with it instead of ringing up the Service Desk in a panic. It can be done on your terms.
Myth 2: It’s too much red tape.
Short answer: If your users are complaining about red tape then chances are you’re doing it wrong. Service Requests should be easy to invoke, manage and process. Link your Service Requests to services linked in your Service Catalog if you have one so that it’s quick and easy for your users to find the right service.
A lot of people don’t want to submit Service Requests. They just want to see Bob or Dave at the service desk because they think it’s easier. If you’re seeing that happen, it means you’re not doing something right or you’re making it too complicated. It could be that you’re making people jump through too many hoops. The problem is that if people keep going to Bob or Dave at the service desk, requests could get missed because they are extremely busy and might forget to write something down or enter it in the system. Or maybe they get delayed with an Incident. Sooner or later a ball is going to get dropped.
The golden rule of ITIL
One of the tenets of ITIL is always make it easy for people to use your services. You need to make it easy for people to A) make requests and B) approve them. The quicker and easier you make the process, the more your users will engage with it and the less instances of Shadow IT that you’ll see. People won’t need to go around the Service Desk because they can easily follow the correct process. Otherwise you’re opening yourself up to risk from a compliance and licensing point of view, and even a duplication point of view. You might have already had the licenses for something and then users have gone out and bought more. Again, if you make it easy and get people to buy in and use it, word will spread.
Tips for making ITIL Service Request Management enjoyable for end users
Automation - Automate as much as possible. We’ve all heard of three clicks to nirvana and the logic is that if you have to go more than three or four clicks, people tend to lose interest and give up. Then they show up at the service desk to ask for help.
Templates - For example, give the Service Request Form a similar look and feel to the rest of your service desk and incident forms so it’s a consistent experience for the user. That way it’s very obvious what it’s for and how to use it.
Workflows - Have some sort of intelligent workflows in place. For example, if it’s under a certain amount, it can be pre-authorized but if it’s above that threshold it gets routed to the correct manager. Again this makes it easy and speeds up the process.
Mobile-friendly - Make sure the notifications that get fired off have clickable links and can be approved from different devices, whether it be a PC, laptop, or a mobile device of their choosing. I’ve even seen some apps that can work on a smart watch. I’m not saying everyone needs to be walking around with smart watches approving service requests (although that would be really cool!) but it’s about making it convenient and intuitive.
Incentivize users - Some Service Desks have prize drawings for those that raise a Service Request. Or it could be as simple as a “well done!” service request message. It sounds a bit cheesy but it’s fun and engaging to see a little cartoon character pop up to congratulate you on successfully logging a Service Request. It incentivizes users to come back and do it again when it’s a nice or happy experience.
Myth 3: It should be treated as a standalone process.
Short answer: No, nope, and no again! Request Fulfillment is a process that becomes more valuable the more integrated it gets. For example, Request Fulfillment could be integrated with your Software Asset Management (SAM) process so requests can be checked against available licenses. It’s a small thing but really important come audit time when we need to work with the software vendor to ensure the software we have is licensed and paid for.
Some people think it will be easier to do Service Request Management on its own. That’s a big no! I can’t stress enough that Request Fulfillment is one of those processes that brings more value the more that it’s integrated into other areas. When merged with other IT processes, it can streamline and automate while ensuring that your users enjoy a satisfying and productive experience.
How integration makes for happy users
During my time as a service desk manager, I saw how frustrated users would get when dealing with Incidents and Service Requests. The problem being that they didn’t know the difference between the two (see Myth #1). In their mind, they had done the right thing. They followed the process correctly—by phoning the service desk or taking the time to log the ticket themselves through self-service. Then the Service Desk investigated and came back saying, “Actually, we should have logged this as a Service Request so now we’re going to have to go through the process again.” If you can integrate those processes together by using the same kinds of categorization (hardware, software, etc.), forms, templates, and fields, then if something needs to be converted from an Incident into a Service Request, it can be done quickly and easily without the end user having to repeat the entire process.
Service Request Management and SAM
Another example could be building it into Software Asset Management. For instance, every time a user requests Project or Visio (because let’s face it, it’s always Project or Visio right?), a check could be carried out against available licenses to ensure that there are enough in place before the software is installed. The workflow to check for all available licenses is a minor improvement that can reap massive benefits. It’s a great way to make sure that you’re compliant and there’s less work to do.
Improving Service Catalog usage
You could also integrate Service Request Management with your Service Catalog. I once worked with an online-based sales company where they spent a fortune putting a Service Catalog in. They checked the usage and found that no one from the business was actually using it. What they had done was create a very nice menu of all their services but they hadn’t made it actionable so there was no incentive for users to go there. As soon as we made it actionable and users could raise Incidents and Service Requests from it, usage went up drastically over the course of just a few months.
Remember, ITIL Request Management is a process that lends itself really well to the enterprise service management ethos where we’re not just using ITSM in IT. It’s being used throughout the rest of the business in areas like facilities, HR, and Marketing. It’s something that can be scaled across the organization and the benefits and potential are huge so integration is crucial!
Next Steps
Read the entire ITIL Mythbuster Series!
- ITIL Mythbusting: Change Management Truths You Needed Yesterday
- ITIL Mythbusting: Incident Management Facts That Will Supercharge Your Processes
- ITIL Mythbusting: Problem Management vs. Incident Management? Think Batman vs. Columbo
- ITIL Mythbusting: Is Configuration Management too difficult for little gain?
- ITIL Mythbusting: Service Request Management Facts to Keep IT and End Users on Cloud Nine
Do you have an ITIL myth you want busted? Send it to us in the comments or reach out to us on Twitter @EasyVista and @vawns.
For more ITSM expertise, Follow Vawns Murphy on Twitter and check out her articles on ITSM.Tools and archives on TheITSMreview.com.
