How To Pair Your Data and Instincts for ITSM Success

As we continue with our discussion on the The 4 Deadly Sins of Service Management, it’s important that we focus not just on recognizing our lines of thought, but on the steps we can take to combine our data and instincts for maximum results.

With each post in the series so far we’ve provided some tips and tricks, but in today’s post we’re presenting a more comprehensive list of How To’s!

So here we go....

How To: Use Emotions As Action Triggers

When you’re balancing instincts and data you’re going to have, at best, a 50/50 mix of emotion and logic so the key is to embrace emotions as triggers to logical actions.  Here are a few tricks you can start using right away:

• When an IT emergency rears its ugly head it’s easy to get caught up in the panic of the moment.  Focussing on solving the issue at hand is obviously the most critical, but ensure to document literally everything you can along the way (this will come in VERY handy later for activities such as Problem Management).
• Track time spent by every member of the team that was involved in providing a fix.  If your responders aren’t already in the habit of putting down their time spent - fix that right away!  Accurate logging of time is paramount when it comes to planning out your future ITSM decisions.  Remember, if you aren’t measuring it, you shouldn’t do it!  
• Here’s where your documentation comes into play.  Perform a post mortem on these emergent issues (but don´t wait too long... see why here). During every post mortem, recognize what your team did well but also recognize where you could have performed better.  You’ll find that you can learn more from your teams mistakes than you do from their successes.  

How To: Run Reports That Identify Weak Spots

A common problem for most service managers is that their canned dashboards and reports rarely paint the entire picture.  Thus, you’ve got to get creative on your custom metrics analysis to help your decision makers see the truth of things.  In my opinion, the best way to start is, at the beginning.

Here are 3 reports that every service desk manager should run to diagnose the health of their service desk along with some forward looking actions you can take after running them.

1. Resolution time by request type
   1. Dig into your top 5 “quickly” resolved request types and review for insights
   2. Can automation be brought into the mix?  What other ways can you eliminate the low hanging fruit?  
   3. Bolster your FAQ’s, it’s the easiest way prevent the common requests from coming into your system
   4. Take a closer look at the requests that take the longest to resolve too.  Diagnose and document their causes and anything that’s causing hiccups in your process - you’re going to use this information later on.
2. Resolution time by technician
   1. Take a closer look, are your “rock star” techs being handed the lionshare of the work?
   2. Are your most skilled techs showing resolution times that are impacted by being assigned toughest problems that take the longest to fix?  
   3. You will always have techs that struggle to keep up and this report will show that.  Can you offer them additional training?  Perhaps you can “apprentice” a struggling tech with one that performs at a high level.  Look for ways to help bridge the gap!
3. Most commonly requested problem
   1. Make sure that you’re dedicating enough resources to the items that get requested the most.  
   2. You need to scrap un-requested problem types and build out your parent/child requests on the ones that get requested the most.
   3. If you have requests that are seasonal in nature (i.e. Facilities requests for A/C issues in the middle of summer), be sure to weight these differently.

(If you´re looking for a more comprehensive list of metrics for Incident Management, we recommend checking out this post)

How To: Navigate Internal Requests

Once you start tweaking the chemistry, you’re going to get push back from your team.  Don’t let this dissuade you from your purpose, though.  If you incorporate some Agile principles that promote self management, you can turn that push back into something positive.  

Here’s one example that uses Scrum to organize your service management team

• Product Owner:  This is the person that is ultimately responsible for vision and direction.  In our ITSM case, this would be someone like the IT Director or the CIO.  Keep in mind, this role can only be filled by one person - no committees here!
• Scrum Master: This person is responsible for facilitating everyone involved in the project.  It’s easy to assume that this person is ultimately a project manager but they aren’t.  Your Scrum Master is the cog that holds everything together.  They are responsible for seeing that the Product Owner’s vision is being implemented on a daily basis but they’re also responsible for documenting feedback from the rest of the team and sharing it with the Product Owner.  
• Scrum Team: Think of your Scrum Team as your techs and other front line responders.  These are the people at your organization that have the closest relationship to your end users and they’re the face of your Product Owner’s vision!

If you follow the Scrum method with your service management team, here’s what it should look like in action:

• Sprint Planning
  • Start with 2 week sprints (a fixed period or iteration with a given set of objectives, eg. improving resolution time of critical incidents).  Any shorter and you’re not giving people enough time to execute.  Any longer and you’re limiting your ability to stay agile.
• Daily Stand-up
  • Give each of your techs a couple of minutes every day to express what they’re seeing on the front line and let them self organize to fix the day to day issues.
  • Product Owner’s should attend at first but they need to listen more than talk for the time being.  Allow your Scrum Master to direct the flow, that’s what they’re there for!
  • Scrum Masters need to document any non emergent pain points - this will come in handy later.
• Demonstration
  • At the end of each 2 week sprint, let your Scrum Team demonstrate their individual contribution to the Product Owner’s vision.  
  • Product Owner’s need to be ready to ask hard questions but not just for the sake of putting techs on the spot.  Orient your questions around the question “is there a better way that we can do this?” and you’re on the right path.
• Retrospective
  • Openly discuss what went well, and what didn’t.  When talking through the things that didn’t go according to plan, gather everyone’s opinions as to why.
  • Remember those non emergent pain points?  The Scrum Master needs to bring them up and the team needs to decide how important they are.  The most important items need to be addressed in the next sprint while lower priority items get put back on the shelf.

Repeat this process and you’re well on the way managing the balance between ITSM instincts and your data!

How To: Craft ITSM Policies

Issues that are potentially systemic in nature can put a wrench in the works for your broader business goals so coming up with a well crafted set of policies is a logical next step.  If you’ve followed the steps above, you’ve got a solid idea of what works and what doesn’t.  You’ve also already fixed the easiest problems.  

Now is where the value of your decision making committee comes in.  At least once a month you need to host a policy creation meeting with your high level decision makers, Product Owner, and Scrum Master.  It’s tempting to include your Scrum Team as well, but don’t!  They need to have their energy directed on execution as much as possible.

Repeat the policy discussion every quarter to stay on top of things.  The first few meetings will likely be more involved but that’s OK.  As your team executes and solves problems, you will be in a better position to plan for the future versus having to deal with daily emergencies.

Conclusion

We have 2 posts left in this series but we’re going to continue the conversation with a Live Webinar in the coming weeks.  Make sure to share your thoughts with us on social media, we may include your insights in our presentation!

If you haven't already had the chance, check out our first, second and third posts in our blog series on the 4 Deadly Sins of Service Management!