Share:

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

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?