Basics of Queuing Theory in Lean Product Development

I’ve been studying and researching Queues and Queuing Theory in Product Development for the past 2 years. I finally felt comfortable enough with the topic to attempt to write about some of the basics. This is the 1st article in a series of posts related to Queues.

In this post I attempt to go through the basic math of Queuing Theory and some examples of Queuing Theory in Lean Product Development.

Waiting in Queues

We have all waited in different types of queues in our lives. We wait for the cashier at the grocery store or we may wait to check-in our bags and get our boarding passes at the airport. And if there’s one thing we all agree on, it’s that we hate waiting in long queues.

The minute you walk into the airport and see about 25 people in line in front of you, you immediately know you’re going to be waiting a while to reach the front of the line. Then, throw in the variability of

• The people in front of you with different passports and nationalities, different visa requirements. The gate agents have to check the travel and visa requirements of each passenger’s nationality which could take different times.
• Different number of bags to check in (some overweight, some not). If bags are overweight, passengers have to either pay extra, or discard weight from their luggage on the spot. Who knows how long that will take?
• The limited number of airline check-in agents at the counters. Each gate agent could be working at a different pace based on the passengers they are servicing, and also based on their training.

So, there’s absolutely no way of knowing how long it will take to get to the front of the queue. Meanwhile, more and more people are joining the line behind you.

So, when we instinctually know how queues work and why we hate them, why do we ignore them for Product Development? Most companies will brag about the size of their Product Development pipeline. But, at the end of the day, the pipeline is just a queue of product development work waiting to be done. The larger it is, the longer the work takes to get done.

What are Queues and Queuing Theory?

• The Queue is the work waiting to be done
• The Server is the resource that does the work when the work reaches the front of the queue
• The pattern with which the work arrives is the Arrival Process. The arrival process is usually unpredictable i.e There is no pattern or predictability to the way the work shows up at your desk
• The time it takes for the Server to complete the work is called the Service Process. This is also unpredictable.
• The sequence in which these activities take place or the order in which the waiting work gets performed is called the Queueing Discipline. Ex: First Come, First Served, Last In First Out, First In Still Here etc.

Measuring Cycle Time using Little’s Law

The next step is measuring the queue size, or calculating how long it takes a job in the queue to be completed. This is done using a cool formula called Little’s Law. Little’s Law describes the relationship between the Queue Size, Queue Wait Time or Cycle Time and Processing Rate or Throughput.

The formula states that – Queue Size (number of items in the queue) is equal to the Processing Rate (Time to process a job in the queue) multiplied by the Queue Time (time spent waiting to be processed).

Little’s Law is a crazy cool formula and extremely versatile. You can use to calculate WIP and Inventory in manufacturing environments. You can also use it in Product Development environments to calculate Queue size and Wait Times for Arrival Queues and Departing Queues. It can be applied to just one Queue or to an entire system of interlinked Queues.

When starting Lean Product Development efforts, you usually can’t figure out whether an item is waiting in a queue or if it is being processed. When people learn that Queues are bad, they will say that there is no queue because everything is being worked on. In this situation, you can use Little’s Law and just ignore the portion in the queue and focus on total WIP and processing time. This allows us to calculate the cycle time.

Examples of Product Development Queues

Let’s say you have a CAD Technician who can process a packet of CAD Drawings per Project in about 10 days. There are 4 projects waiting in the queue for him to work on. So,

L = Queue Size = 4 projects

Processing Rate = 1 Project / 2 weeks = 0.5 Projects/Week

Therefore, Cycle Time or Queue Time = L / Processing Rate = 4 projects / 0.5 projects per week = 8 weeks.

Here’s another example at the System level. If your Product Development process has 25 projects in process (L) and completes an average of 10 projects a year (Processing Rate), it will take an average of 2.5 years to complete a project.

Why are Queues important?

Queues are very important in the management of Product Development, especially from an economic standpoint. Because queues in Product Development aren’t physically visible, they go unnoticed and are very poorly managed.

Queues cause projects and tasks to sit idle waiting to be worked on by busy engineers. And as the queues get larger, those busy engineers only get busier, reducing the chances projects in the queue will get worked on quickly. This idle time increases the Work-In-Process inventory which is the root cause of many wastes in Product Development.

Read my next blog post, in which I talk more about the long-lasting effects of queues and why we tend to not manage them well.