WORK VOLUME METRICS

Filling a container ship for maximum efficiency is a calculated effort. There are many factors to consider, and once complete a number of standard metrics available to measure the performance of the voyage. A standard mistake I see made in measuring the performance of a support or service based team is missing work volume. We tend to look at number of tickets, length of time on the ticket, but not the work performed by the agent to complete the ticket. Missing this key metric is like measuring the container ship for only number of containers without concerning yourself with the weight of each. The total weight makes up a much more realistic idea of performance in both cases. By neglecting this metric you may be over or under working your team, misevaluating agent performance, and missing opportunities for improvement.

BACKGROUND

I have worked in a wide variety of service support teams both small and large, from a basement bank vault, to world class data centers. During my tenure in IT I’ve also managed several teams and accounts in various support capacities. In this time a diverse series of ticket systems (work management systems) were used, and each organization required unique types of reporting. It wasn’t until I got into the data center environment that the concept of work volume reporting became very clear. The account team was challenged to balance the number of resources we employed in the data centers with a very demanding client. It became clear over a series of reporting iterations that the data was not the issue, but the metrics we were using to measure it. At the time our ticketing system supported the ability to add tasks and quantities of these tasks to the ticket once completed. By looking at the overall effort it took to complete these tasks over a period of time we discovered the beginning of true work volume reporting.

Over the next few months my team and I started to measure task times of these tasks, with a stopwatch, while focusing on following our documented processes perfectly. We took into consideration walking distance averages, time to gather supplies, administrative overhead, and came up with global averages. These averages were used as a key against a months worth of tasks added to tickets by our agents. Needless to say it started to paint a very clear picture. Both from an account management perspective with the customer, but also internally about performance of the agents. It became clear that in some cases who we thought our highest performers were may not have been, we had underestimated others, and generally not been managing the team the best way possible.

A year later, work volume reporting was highly utilized, and global averages were revisited quarterly to ensure business process had not impacted time. We measured team members performance on work volume over months and using averages over the course of a year. Not only did our team management become better, but we got a much more accurate view into the work volume of the facility and could staff accordingly. Several versions later and it was the global standard. The team took it several steps later as I handed it off, predicting work volume based on incoming projects and measuring the delta between predicted and actual to revise the averages and better staff globally.

Thought Experiment - Shipping Example

As mentioned above, let’s consider the example of the container ship. Many different factors come into loading a ship for maximum efficiency by the shipper. How many containers can the ship hold, distribution, loading times, and probably most important, weight. And not just the weight of any shipping container but the combined weight of all loaded containers. This is crucial as it effects the maximum amount of displacement the ship can undergo, and fuel needed. By underestimating weight you could sink the ship or run out of gas before your journeys end. By underestimating is you run the risk of not reaching your most efficient sailing weight and missing opportunities to haul more cargo and make more money. This example plays out in the same spirit through different support or service based teams, let me explain.

Service Desk

Your Service Desk performs on average 1000 tickets per month, wow! The average time to resolve varies drastically, from 5 min to several hours. With that big of a range how are you supposed to figure out how much work is being done? You could add up all the time it took to complete the tickets, and you’d get a number of hours. You could use this, and a lot of management teams do. The issue I have with this is, what happens when it’s taking twice as long as it should to complete a process due to inconsistent training? Or perhaps the ticket is covering a number of tasks not efficient to be done together? Or out of scope for the current team? There are several ways to poke holes in this approach. Only by standardizing the task list, and measuring it’s team average based on stopwatch of the process will you have a proper measuring stick to compare each ticket to. Your 1000 tickets each averaging 10 min per ticket in one month would be 166.6 hours of effort, but could be 20 min per ticket the next month going up to 333.3. How is your team supposed to flex to handle this? How do you staff for this? Also take into consideration that by looking at the total time you miss each individuals performance against a common measuring stick. You may be missing that one person does twice as much work for less money. By ignoring these factors you impact your team by unnecessary turnover, lower overall tenure rate, and stress on the team.

If you put in the extra effort to move to task based work volume, you will not only have a clearer picture of the teams overall work volume but that of each person. Your overall work volume can be divided up between what you determine to be an acceptable level by each resource. Then you can see if you’re properly staffed. Next start to measure each person to a standard level. You’ll see a spectrum emerge. Look at each of your folks on the low end first, ensure they are following the processes correctly, adding the right tasks, and the right quantities. It could be that all this time they’ve been performing the administrative overhead wrong. With all that sorted out you should be able to see if you have anyone that isn’t a good fit for the type of support you are providing and can make accommodations. You should also be looking at your high performers to see how they are accomplishing the large numbers. We found that occasionally high performers would innovate and find cleaver ways to get things done quicker. Bake these into your processes, share them with the team, include them in your training.

Support Teams

This method is equally applicable for all teams providing service based support. Really portions of it can be applied to any service based organization. If you have a team of people, providing a range of services to clients, and you want to accurately gauge performance of the team as a whole and each individual. All you have to do is implement as suggested below in the implementation overview.

Common Rebuttal

The most common rebuttal to this method I’ve heard over the years is this: If resources are doing more than one thing in a ticket, it should be split, and worked separately. The benefit to this method is that in the end, each task is measured separately, and the true number of issues gathered. But do you not still have the same experience with task based? If the idea of breaking up a ticket into two for the benefit of measuring two different tasks independently is the goal do you not already get that when you create and maintain the task list? My argument is that every time you split a ticket, or create new tickets you are increasing the administrative overhead, and creating a less streamlined customer experience. The individual task ticket means your agents are having to manage multiple requests at once for the same customer, and duplicate administrative efforts. All this does is break your tickets themselves into tasks, which is what task based billing on a ticket does. The difference is your support or service agent doesn’t have to do anything over than focus on solving the issue, and working with the customer. In the end, add the various tasks based on work performed. I’ve found through years of experience this to be more efficient. Not only more efficient but to include all of the task based benefits I’ve covered.

Summary

While it is true you could live without this methodology, I would not recommend it. Not properly measuring the performance of your team and the individuals that make it up can have adverse effects on your business. Over performing individuals not recognized leave, under performing team members linger and drag down the performance of your team. Understaffed teams experience burnout faster, and this creates unnecessary turnover, which puts a strain not only on your team and your org, but HR, and other support teams involved in getting people on board. Overstaffed teams waste your resources, and do not give high performers a place to shine. You end up sacrificing the potential of your team and that of your organization.

IMPLEMENT WORK VOLUME REPORTING

e

Generate Task List

Your task list should be a good breakdown of all the different tasks your resources could perform on tickets based on the services you offer. In some cases the task may be a whole process, but if the process can contain multiple similar repeatable sub-processes it may be broken down into individual tasks. You can use your service catalog as a good starting point. If you don’t have a service catalog (consider drafting one) you can use a list of services your team offers or supports. You could also simply write down a list of all the responsibilities this team has and break it down from there.



Gather Task Times

Take each task, pull out the process document, and stop watch a capable person performing the task per process. You may even notice during this effort the need to tweak your processes, or there are missing components in your documentation.

In the end you should be left with a very realistic view of each task. Run it through a few example tickets to ensure there is only one way to perform the task, denote any variation, and make sure it is both covered in your documentation but also reflected in the task list.



Implement Collection Mechanism

Your team will need a way to report the tasks associated with the ticket. In some cases this will require modification of the work management system you are using. If your system does not support this, and there is no reasonable work around consider using a different product. Or consider working with your provider to implement this as an enhancement.

Some organizations use internally developed systems, work with your IT department, or development team to implement this method to your existing system.



Train Your Team(s)

This method can be a significant mental shift for some, you will want to ensure they understand the why behind this method. The benefits are going to be felt by the folks doing the work. Properly staffed, and staffed with folks capable of keeping up with an appropriate work pace, these are all value adds for the team. High performers are validated and can be recognised, low performers are trained, or repalced. Overall the level of responsibility for each team member is even. Teach them to learn the processes inside and out, and learn the task list. Once they begin thinking in terms of tasks per ticket they should have no issue properly recording work performed and translating that into tasks. In some cases systems can be configured to pre-populate based on ticket information and simply adjusted or acknowledged by the agent.



Design Reporting

You’ll need a method of reporting the outcomes of this method. Essentially you will need access to the raw data that the agents or users of the system are entering. A task output of everything done during a given time period, ticket number for reference, quantity, and a few others if you like for look up if you prefer. Then you will want to have a way of connecting your tasks list with the recorded amount of tasks, to get the total work volume in hours.

If your system does not allow for this you can build it in Excel and simply automated the import of the raw data. There will be an example workbook available for download below in this article. You will also want to ensure you create both team based views to ensure you are monitoring overall work volume of the team, but also individual views so you can work with your team to keep them on track.

T

Make Adjustments - CSI

Continuous Service Improvement means just that, revisit your task list, your processes, your teams performance and make adjustments where necessary to maintain optimal efficiency. This is where a classically trained ITIL/ITSM resource can come in handy.

Your task list stays current by ensuring you stopwatch the process at an appropriate interval, I do them quarterly. This will not only ensure your task list is up to date but that your process documentation is still good, and that current changes to the business have been planned for.

Work with your team, both upstreeam and downstream. Your management needs to be aware of the work volume of your team and the levels for which are agreed appropriate. That way if the time comes decisions can be made without a lot of time spent figuring it out. Your team needs to know where they are at, compared to the agreed upon level. Give them the means to monitor thier own work volume. That way if you ever need to check in it’s not news and you can get right into what’s going on.