More Than Just a Pretty Face:<br />Finding Value in ITSM for Smaller Service Desks

Recently I wrote an article about being non-technical in a technical industry, and another about having no metrics in a metrics-rich industry. It got me thinking about how many paradoxes ostensibly exist within IT and how that might affect IT service management practices.

IT is full of processes, frameworks, and practices. These all exist happily in theory, and truly, they can be implemented without making many customizations or changes and be considered successful. In my experience, however, the level of success decreases proportionately to the size and complexity of a service desk. Applying out-of-the-box ITSM processes to a service desk within a smaller business can show up in areas like increased effort and time to resolve. Consider how mandatory approvals and tier escalations could impact a four-person technical team. At face value, “the old way” is appealing when managers see that a technician could have executed the task before the ticket was even assigned to them. A business can look at this and conclude at a high level that ITSM practice isn’t worth it, or that supporting processes don’t work. And so, paradoxically, service management frameworks appear to kill the very things they are there to support, and a team can continue to struggle under the weight of doing “what we’ve always done.”

Over my career, I have joined several companies during a growth phase. Consistently, they had found themselves in position where they couldn’t keep up with the increase in support needs, capital projects, stakeholder engagement, you-name-it. Bringing in extra staff didn’t seem to solve the impending burnout problem. In fact, the increased capacity or specializations of the new staff seemed to draw even more work out of the shadows! Managers put daily quotas on ticket closures, but that resulted in customer complaints, increased re-opened tickets, and caused rework. Stakeholders began to question the cost of the IT department compared to the value they felt they were getting.

Sound familiar?

I have learned that the value of ITSM is realized over time, and its OK to start with just a little. I’ve also observed that working with more formal ITSM process means you have to trust it—trust that there’s a reason that ITIL, DevOps, ISO, and others are considered best practices, and that you and your service execution can be better.

There’s a reason that ITIL, DevOps, ISO, and others are considered best practices and that your service execution can be better.

You might be just starting to formalize your ITSM process for your service desk, or you might be planning how to take your next steps. I’ve found that getting ready to do this is a lot like painting a room in your house: 80% of the work is in the preparation! I’ve put together a list of some of the items that have helped me in my ITSM work. I use them a bit like a checklist, and by the end, I’m confident in how I’m going forward.

Getting Ready

Know your stakeholders. Who holds the key to your success? It’s not always the people using our products or services. But we are accountable to them, and we must know what they need and want.

• Are you serving internal departments and/or external customers?
• What do they need vs. what do they want? Knowing the difference allows you to make strategic decisions regarding your focus, in order to deliver more comprehensive value.
• Don’t forget your own business. Who needs to know about how your service is doing and the value your department/team is creating?

Know your services. If you haven’t formally identified your services, make it a priority. Once you are clear on what you do, you can focus on how you do it.

• What do you offer your business (tech support, company intranet, multi-location wi-fi)?
• How do you provide your services (on-prem/off-prem storage, application suites, hardware, etc.)?

Document your current state. You may or may not be collecting metrics, but you should document what you’re currently doing in your services areas.

• If you don’t have metrics for any or some of your services, don’t worry! You can use a simple red/yellow/green status; just be clear on how you determined that. This could be customer feedback, team input, or your gut feel. Give yourself a place to start! 
• If you haven’t documented your processes, do it before you make changes. This will help you home in on which changes have worked and what has not.

Know your desired results. Be clear on your results; don’t build a red cup if you’ve been asked to build a blue cup. The red cup might be beautiful, but it won’t satisfy the desire for the blue one.

• Talk to stakeholders to find out what satisfaction with your services means to them and what it looks like to them when you are performing well. Some groups will look for technical stats while others are looking for financial results, while still others are looking for more intangible results like “Pleasant engagement with your team.”
• Talk to your teams to identify what they want and need.

Making Changes

Use what you’ve learned. Reflect on what you’ve learned about your stakeholders, customers, and team.

• Consider these things with everything you do, because what matters to them is what matters to you. This can take the form of a motto or mantra that helps you keep your focus. For example, if you were serving a group of office assistants, your mantra could be “Reduce administrative effort.”
• Use the “desired results” list you built to create a prioritized “to do” list.

Keep the Spirit. Now that you know what you want to achieve, plan the “how” as it pertains to your environment. I think of it as keeping the spirit of a framework. For example:

• Say you’re experiencing issues with changes being introduced without your service desk’s awareness (new applications, unannounced outages). You don’t need full ITIL change management to make improvements. You can keep the spirit by being aware of the benefits of controlling changes, socializing them with your co-workers, and then start with a procedure that fits your situation. This could be as simple as receiving an email from another team or a regular meeting with team leads to discuss what’s going on. (See how I snuck an informal CAB in there?)
• It’s ok to walk before you run.

Don’t reinvent the wheel. Earlier I said you need to trust that these processes work. Sometimes you can shortcut by using tools that already support these frameworks. For example:

• Introduce a new ticketing system that already builds in ITSM practice and simple ITIL workflows to help you, and you can choose what you turn on or turn off to enable your maturing ITSM processes. If a ticketing system is overkill for you, then refer frequently to a high-level overview of the ITIL framework when you are working on a process or procedure. You will find that the more you reference an existing framework, the more smoothly your procedures and processes will integrate with each other to improve your services.
• Sometimes we fall into the trap of thinking our business is so unique that a standard practice or process will not work for us. But in my experience, it is the procedures that need to be modified to fit a business or team . For example,  try to make ITIL fit you…modify your procedure to support the spirit of ITIL, insofar as it helps you meet your goal or desired result. You don’t need to hire a new team of people to implement all aspects of problem management, but you can develop a procedure to group related incidents and assign a team member to focus on finding the root cause. Over time, when the value of your procedure is proven, this will mature into a larger problem practice.
• Use the HDI community to help you adapt! You are not alone.

Use a SMART methodology. Keeping your targets Specific, Measurable, Achievable, Relevant and Time-Based (SMART) will help you focus and report your results.

• Don’t bite off more than you can chew. Pick one or two things off your new to-do list that will make a difference in your service(s).
• Measure! Being able to measure any change you make is important for you to demonstrate what has improved or to provide evidence that you need to revert or make another change if things are not working as expected.
• Even if your goal is not measurable with metrics, find a way to demonstrate a result. Once I was asked to ensure that “the department looked good when a user engaged with the web portal.” I had to work with that stakeholder directly to get their agreement on some more specific items that made the department look good in their view. That way, I created tangible deliverables for a somewhat intangible goal.

Communicate. One size does not fit all! Refer to what you learned about your stakeholders’ priorities when planning your communication methods.

• You will need multiple messages and methods to report your results to your different stakeholder groups. Sometimes it is a report with stats; sometimes it is an email with a general update covering specific topics.
• Work with your stakeholders to approve the information in their communication (think of it like a template), and agree on frequency of delivery.
• Document your communication plan. This is a different type of success measure that you can incorporate into stakeholder reviews to determine their satisfaction with your service. Whenever you meet with a stakeholder group, include your communication template on the agenda so you can validate that it’s still meeting their needs.

Plan stakeholder reviews. It’s important that you validate that your services, communications, and reports are delivering the expected value.

• Refer to the timing in your SMART goals for your services and plan out when you need to review your results with your various stakeholder groups.
• Reviews also allow you to discover when your stakeholder requirements have changed. It’s OK to renegotiate what your stakeholders want to know and what you can provide; use it to help you prioritize what you work on next!

Bask in the Value!

Now you’re in the swing of it! You’ll undoubtedly see improvements in your targeted areas. But remember that when a change doesn’t provide the desired result, you’ve learned something valuable about your business. Use it as a way to move forward!

Good luck and great work!

Kristin Jones is a passionate customer support advocate with a focus on people and process, and has been leading IT teams with delight for over a decade. A lifelong learner who seeks to inspire others with fresh ideas, she is an active member of the HDI community and holds certifications in ITIL v3., HDI Support Center Manager and KCS Foundations. She strives to end each day having smiled more than frowned and having helped someone (or something!) work better. Follow Kristin on Twitter @kitonjones.