3 TOC concepts that will instantly make you a better manager


Recently I was working with a group who are responsible for the installation of software and hardware, which they then train end-users to use.  This work was  being scheduled by a project manager.  Unfortunately, there were many dependencies and uncertainties in the installation, which often upset the project schedule.  As you can imagine, this resulted in late projects, unhappy staff, and very, very, unhappy managers indeed.

I suggested using a managed queue, that the installation group could pull from in sequence.  It wasn’t until I was told rather emphatically that the business “needed to be able to prioritize customers, and that some sort of FIFO queue just was not going to work at all around here” that I realized that I needed to explain more about queues.   Here, therefore, is a quick primer about queues and processes, and how they work together.  Three three concepts that will instantly make you a better, happier manager are:

  1. Managed and Unmanaged Queues
  2. Pull and Push Processes
  3. Protective Buffers

1. Managed and Unmanaged Queues

A queue is what process engineers call any backlog of work that is not currently being worked on. The group that I was working with actually already used a queue, in a spreadsheet.  They just didn’t think of it that way.  Actually they already had several queues – the list of prospect customers, the list of customers that have been contracted, but not started, and I bet they had others too.  Queues themselves can be categorized as being managed, or unmanaged.

  1. Unmanaged – an unmanaged queue is not prioritized, and we have no control over how long the queue is. The line for a Disney World ride is an unmanaged queue.
  2. Managed – a managed queue often has rules which dictate how much work can sit in the queue, and how that work is ordered.   Work can be ordered by using a schedule – a doctor appointment is such a queue, or it can be ordered using a priority system. ED triaging is an example of that.

2. Pull and Push Processes

Queues exist to feed processes. There are two types of processes. Processes can be either pull processes, or they can be push processes.

  1. Push Process – a push process has to deal with all the work dumped on it. A firehouse is a push process. If there are two fires at the same time, the fire department can’t just say, “ we’ll get to that those others tomorrow”. So you can see that if the demand is too high or too variable, push processes can easily become overloaded.
  2. Pull Process – a pull process gets to choose what work it starts. The Disney ride is a pull process. Only so many people are allowed on the ride at once.   Pull processes are self-regulating. They do not become overloaded, because they only take on the work that they can safely achieve.

3. Protective Buffers

Buffers are spare capacity/capability that are built into the plan to protect it from failure.  Sometimes confused with padding, buffers are actually an essential part of the plan, because they help account for the variability that we expect, but cannot predict.  There are several types of protective buffers employed by processes, which protect them from overloading. Let’s look at three such buffers. These three together can be used to protect the “triple constraints” of schedule, cost, and scope.

  1. Resource Buffers – having idle machinery, people, or other resources that can be flexed in to help when there is excess demand. The fire station utilizes resource buffers by having crews on duty 24/7, even when there is no fire.
  2. Schedule Buffers – having a time cushion built into the schedule to allow for the fact that tasks will sometimes be late. Project management often have internal and external dates for this reason.
  3. Scope Buffers – having work in the project that is optional, and that can be jettisoned if needed. Agile, when it works, works mainly because of successful scope buffering.

Putting It Together

Of course, managed and unmanaged queues, buffers, and push and pull processes, are not necessarily good or bad things – it just depends on how and why they are being used. Let’s examine some examples

…feeding a Push Process …feeding a Pull Process
Unmanaged Queue

A Fire Station

Suitable if the demand is very predictable, and/or the process is highly buffered, so resources can be added in order to cope with unexpected demand. This is why firemen sit around cleaning their equipment and trucks for most of the day.

A Disney Ride, a Bank Teller, or a Call Center,

The demand for the service, and the capacity of the process, determines the length of the queue. As customers, of course, these are the queues we hate!

Managed Queue

A Doctor’s Appointment, or a Schedule-Driven Project

The process that is being pushed to, unless it is adequately buffered, or the queue is well managed, can become overwhelmed. This is especially the case where variability/uncertainty exist in processing time. The queue therefore has to be carefully managed. This is one reason why projects are often late, and why waiting rooms exist at doctor’s offices.  As workers, these are the work environments that we hate!

Airline Passenger Bookings, or a Agile Development Backlog

The length of the queue is still influenced by the demand, and the capacity of the process. However, now the queue can be limited, or reordered, to ensure that the maximum business value is being achieved, given the capacity of the process. It is why airlines have variable fares, and stand-by passengers.  Done well, both customers and workers can be made happy!

Lean process engineers often believe that a pull system, being fed by a managed queue, is the most appropriate for variable or uncertain knowledge work.

Agile Development Process

By way of example, an Agile Development Backlog is a pull process, being fed by a managed queue. The business, normally represented by the Product Owner, determines the most valuable work, and ranks it into a backlog. The backlog can be prioritized at any time as long as the team hasn’t started to work on it. In each Sprint, the Agile team takes work off the top of the queue and works on it until it is complete. They then take the next most important thing, as defined by the business, and work on that. Agile teams work steadily of increasing their capacity (or ‘velocity’), and the product owner works steadily on making sure the most valuable thing is being worked on at any given time. It is a well-regulated system.

If you would like to learn more about how I can help you and your company get better control of your projects,  contact me today!

Paul Osborn


  1. […] tasks only when it is possible to generate flow. Our project portfolio should be managed as a pull process in order to avoid overloading […]

Leave a Reply

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