How to Meaningfully Measure Queue Performance and Waiting Times

August 23, 2018 by Stacey Barr

To improve any business process with long wait times, or a backlog of unprocessed work, we need to meaningfully measure queue performance.

https://www.staceybarr.com/images/waitinginaqueue.jpg

Queues are essentially buffers to handle variability that is natural and normal in any dynamic system or process. Queues are in all kinds of business processes, and they can be visible or virtual:

  • Customer queues at the checkout in a supermarket
  • Vehicle queues at red traffic lights or intersections
  • Patients waiting until a specialist has an available appointment
  • Development applications waiting for council officers to approve them
  • Aircraft waiting to take off in a busy airport
  • Software bugs waiting to be investigated and resolved
  • Sugar in a storage silo waiting for train wagons to freight it to the port, for export

Fundamentally, we have a queue when someone or something needs service of some kind, and there are a limited number of servers at any point in time. Whenever there is waiting, there is usually a queue.

Very few people enjoy waiting. But abolishing queues entirely is not a solution.

We need queues for many processes to perform well, overall.

A flowing queue will have low wait times, but won’t always be empty. If queues are empty 100% of the time, it can be a strong sign that the system or process has been over-engineered. It can mean that there is low capacity utilisation of the servers, and therefore higher costs than might be tolerable.

So queue performance is a real and important thing to manage. Therefore it’s also important
to measure and monitor and improve. But the measures of queue performance are not one-size-fits-all.

What are the results that define the performance of queues?

It’s easy to jump straight to possible or seemingly obvious measures of queue performance, but that’s a mistake. We want to first understand the specific results that matter to us, and to our queue-based process, before we give any thought to measures of queue performance.

We most certainly do not want to fall into the trap of measuring the first five queue-related KPIs we find in an internet search. That’s because the results that define the performance of our queue-based process will depend on our unique context, which includes:

  • the current performance of our queue-based process
  • what our customers value most from that process
  • higher-level goals, such as strategic goals or the organisation’s mission, that the process also impacts on
  • other goals that need to be traded off against queue performance, like the quality of the service that the queue is feeding into
  • feasibility of gathering the data we’d need from the systems and procedures we use for managing the queue-based process

So keeping in mind the context of our queue, the results that we might possibly want could be like the following:

  • waiting times within the queue are tolerable to customers
  • no customers have to wait longer than the promised longest wait time (this may vary depending on customer priority)
  • server time is as quick as possible
  • the queue doesn’t get too long or full, or completely backed up
  • the servers’ capacity is not wasted (they are not idle for too much of their working time – like cancelled appointments or oversupply of servers, their utilisation is high)

No doubt there are more possible results that define queue performance, and that’s why it’s worth taking the time to craft your own goals or result statements to define your queue performance priorities.

With clear results, we can set meaningful measures of queue performance.

The brilliant thing about defining your results for queue performance is that it makes finding the right measures much easier. Now, the temptation will be to jump straight to the data you have, or can easily get, and base your measures on that.

But it’s a mistake to focus only on the data you have. How will you get the data you need unless you are honest about the information (that is, the measures) that you need? And I cannot tell you how many times I’ve see people discover new ways to get data for measures they first thought would be impossible to implement.

So we forget about data until we clearly defined the measures of queue performance that will be the most useful to us. And using a technique like this PuMP Measure Design template, we can design potential measures of queue performance for each of the results (from above) that matter to us.

The following are just a sample of possible measures (with suggested names and descriptions), for a healthcare clinic. Patients join a virtual queue – basically a booking system – waiting for appointments to become available. Potential measures, for results like those listed above, might include:

  • Queue Length: Average number of patients currently waiting for an appointment
  • Queue Fluctuation: Variance of the number of patients in the booking system
  • Waiting Time: Average number of days that patients wait until they get their appointment
  • Waiting Time Variation: Variance of the number of days that patients wait until they get their appointment
  • Waiting Time Promise: Percentage of patients that wait longer than 5 business days until they get their appointment
  • Appointment Time: Average minutes that actual patient appointments take
  • Doctor Downtime: Percentage of working hours that specialists are not seeing or treating patients

Only after the measures are clearly articulated should we then evaluate their feasibility to implement. And now we can have a more motivated and informed discussion about the data needed for these measures of queue performance.

For the measures of queue performance that really matter, we shouldn’t rush the data decision.

If it’s a simple queue-based process we have, then collecting the data is relatively easy, even if we don’t already collect that data. Think about the last time you went to renew your driver’s license or car registration. You arrived, took a ticket, and waited until your number was called. You then arrived at your allocated server, and completed your transaction.

That ticketing system captures the data for most of the measures of queue performance. But it’s when queues get a bit more complex that we need to think more laterally or innovately about how any new data can be collected.

In the healthcare clinic, it’s more complex:

  • patients have different priorities based on the urgency of their health concern, and so many need to jump the queue
  • some patients might book their appointments with a lot more lead time than others, which makes the waiting times look worse than patients are actually experiencing
  • some patients need to complete other steps prior to getting their appointment, such as having to complete tests before the specialist will see them
  • some patients will leave the queue before getting an appointment, or simply not turn up at their scheduled appointment
  • patients enter the queue from different sources, and the data about when they entered the queue and isn’t captured in a single system

Complexities like these are easier to work through if the queue-based process is flowcharted. This helps you see the various points or steps in the process where problems like those above exist. And it also helps you see new opportunities for how new data can be captured, or how proxy measures might be helpful.

Take this measure from above, Waiting Time: Average number of days that patients wait until they get their appointment. This measure needs a few items of data:

  • the time and date the patient entered the queue
  • the time and date the patient had their appointment

But in the healthcare clinic, the first data item isn’t available easily, from the multiple systems. But the information can be found out in other ways. For example, when the clinic books the appointment with the patient, they could ask the patient to tell them, or estimate, when they found out they needed to see the specialist. And then log this as the date the patient entered the queue.

Doing these, even for a random sample of patients, can still give better information than nothing at all. And that’s the advantage of performance measures: we are more interested in how performance levels change over time and so the precision and accuracy of each data point is not that critical.

It’s more critical that we have information to help us improve queue performance.

Improving queue performance is a well-researched discipline.

Simple queues can be analysed with static information, like performance measures. We can see that waiting times are too long, or server capacity isn’t being utilised, or queue lengths are backing up. And we can quickly find ways to make improvements, and free up the bottleneck.

But more complex queues might need dynamic information, the kind you can collect
through a simulation model of your queue-based process. There is an entire field called
queuing theory, and many technical books that cover it (I recall learning about stochastic processes and Markov chains in the third year of my maths and stats degree). For this, you’ll want some professional help.

At the very least, take a deliberate approach like the one described above, and get a clear understanding of what queue performance means to you, and how you can measure and monitor it.

To improve any business process with long wait times, or a backlog of unprocessed work, we need to measure queue performance. [tweet this]

DISCUSSION:

Where are the queues in your business processes? What are the results that matter most about their performance?

Facebooktwittergoogle_pluslinkedinmailFacebooktwittergoogle_pluslinkedinmail

Speak Your Mind

Your email address will not be published. Required fields are marked *

  1. Tom G says:

    Hi Stacey,

    Great article as always. As a process guy, I always encourage people to look at the capacity of their process end-to-end before taking any actions to improve individual pieces. Your comment of looking for where work is stacking up is insightful. If you think about water flowing through a pipe, it will bunch up at the points of least capacity. These are the constraints and should be the improvement points. We also consider peak demand periods, when designing capacity. Your admonition to use customer demand patterns and expectations is well founded and we all have to understand our systems as a whole to know the change levers because the next competitor to push our cycle time is just a project away…

    • Stacey Barr says:

      Thanks for adding your thoughts, Tom. The perspectives of capacity, constraints, bottlenecks, throughput and so on, helps us see just how the same dynamics affect so many different processes and businesses.

  2. Peter says:

    I like this post, and you’re right on about queuing theory! I’m always so sad to see the wasted time in the queue at a group picnic or potluck event where the organizers allow access to only one side of the food table.

    I work on queue issues all the time in transportation engineering/operations. Fortunately this is an area where we have decent measures (e.g., time, recurrence, length, person-hours, costs, extra fuel and emissions) and ample data from a variety of sensors and sources. Some queues regularly repeat, such as those at bottlenecks during rush periods, and most road users will be used to them and account for them in their decision-making, i.e., tradeoff on mode (car, bike, bus, etc.), time of day to travel (some people have more flexibility than others), and which route to take (especially with real-time traffic maps). However, there are also additional costs for the unanticipated queues that arise from work zones, special events, crashes, or other incidents. These costs include additional delay, unreliable trip time that must be allowed for, and an increased risk of crashes.

    My comment/question has to do with unintended consequences of measuring a specific queue. For instance, a queue in a process or network could be addressed by adding capacity or making some modification, only to flush the queue downstream to the next bottleneck. I assume when measuring a queue it is important to keep in mind what it is that folks are ultimately queued up for. What is it they’re trying to access? And given latent demand (i.e., those desiring something specific at a specific time but given the queue are taking the trade-off to accept something different or to get it at a different time), an improvement to the process generating the queue may not noticeably reduce the queue at the peak times even though access overall is improved. Pointing out that a certain wait is “tolerable to customers” is so important. I’m thinking of the infamous motor vehicle and drivers licensing counter – instituting a on-line option will take some people out of the peak queue, whose spots are then filled up by others willing to accept that wait. The overall service or access time is improved, but the peak queue may not change.

    • Stacey Barr says:

      Peter, firstly thanks for sharing some details about queues in transportation. It’s always helpful to see a few examples in different contexts to really bed in an idea.

      The point about the flow-on consequences of optimising one queue is important. I’m not sure many of us can really get our heads around an entire system until we learn more about parts of the system. Systems thinking is even more rare than good measurement thinking. So my response to that idea is that we take a continual iterative approach to improving our systems. Getting one queue to flow better will then have us thinking more clearly about where the bottleneck might have moved to, and deciding how to respond to that one next. Thoughts on iteration here: https://www.staceybarr.com/measure-up/the-steps-to-use-kpis-for-iterative-strategy-execution/

      And yes, maxisiming or minimising performance isn’t realistic. It certainly will be that waits in queues might be inevitable and we need to set targets that are realistic or tolerable. Again, I like to think of targets as one of the tools we use to learn what works, rather than just hitting them unthinkingly. Thoughts on absolute targets here: https://www.staceybarr.com/measure-up/should-we-have-0-and-100-targets/

  3. Mike Davidge says:

    Building on what others have said, I agree with flowcharting your process and I’d say it’s the first thing to do. It not only exposes what is really happening (including any rework loops that add unnecessary delay) but it also highlights where the data is collected, a very useful thing to know.

    Knowing the full extent of the process you want to get to flow is important too as others have mentioned. In healthcare where I work, we have the patient pathway as a guide. This is from when a patient first contacts a health professional to when treatment is complete. It’s the whole of that pathway that needs to be optimised. True we can chip away at individual sections but we should not lose sight of the overall goal.

    Finally I’d ask how many queues have we got and have we created too many? Stacey mentioned urgency and we do typically split demand that way. But there are many more ways to split up demand and many of them are counter productive. We speed up the experience for some patients at the expense of others. Simplifying the system by reducing the number of queues can by itself leads to shorter waits.

Connect with Stacey


Haven’t found what you’re looking for? Want more information? Fill out the form below and I’ll get in touch with you as soon as possible.



*We respect your email privacy.
Level 54, 111 Eagle Street
Brisbane, Qld, 4000
Australia
Stacey Barr Pty Ltd
ACN: 129953635
Director: Stacey Barr