Projects and Queues

A fact of life that we all experience but, little understand, are queues. Everywhere we go there are queues: at the supermarket, on the highway, at the ticket office, with development resources for our projects. Now some queues can be reduced by increasing capacity, for instance at the supermarket extra checkouts can be manned. In our world queues can be increased by reducing capacity, for instance developers are re-assigned to bug fixing for production and are no longer available to do development.

In many cases the capacity constraint occurs gradually. The highway was built for 10,000 cars per/hr and now we have 30,000! In the past this usually occurred over a long period of time. These days, given the time period to construct new infrastructure, the grace period is months, if not weeks! Basically the design capacity becomes obsolete by changing demographics, but at least the system was initially designed with spare capacity.

In our world, the project world the opposite is the case. Businesses are managed to maximize resource utilization: 100% utilization is the goal, 90% is the norm. In some industries utilization rates even ignore vacation time and holidays.

All this focus on maximum utilization of an individual resource ignores the impact that it has on system performance, or, as Goldratt put it, system throughput. We all know that if the bridge over the river is fully utilized then we can expect a very slow journey home. Throw in some entropy in the form of an accident and minutes turn into hours.

Now whilst this is glaring obvious to the average motorist, irrespective of educational attainment, and that the mathematical basis of queuing theory was determined as far back as 1909, we still have modern managers designing systems that are predicated on the sub optimal utilization of individual resources. The less elegant phrase is "sweat the assets". Yet queuing theory indicates that if as you increase utilization from 60 to 80% you double the queue, from 80 to 90% you double it again. Once you get near 100% the queue gets to be very large indeed. It follows an exponential growth curve.

The result in our world is missed delivery times, increased risk, more overhead, lower quality, and missed opportunity costs. All in the name of higher labor efficiencies. This is typically a case of managers wanting their cake and eating it.

How do you manage in an organization that has designed queues? Well it depends on what your role is in the organization. If you have some management control in the development area then you can start either changing the queuing management - Reinersten's book: The principles of product development FLOW lean product development, offers some good tips, or the utilization values. If you're a project manager then all you can do is try and enter some reality into your schedules by including queuing time and durations that reflect actual time on your work rather than just effort divided by the hours in a normal work day. One word of warning, managers know about queuing, but they don't like it to be advertised. The one thing you must do is detail all the slipped dates due to queuing. List them all, not just the latest one. That way people know that you were ready but the resources were not.

If anyone asks you to explain queues tell them to visualize the last time they where at the post office and head of them in the queue are people with large boxes, lots of parcels, lots of questions, and then the number of tellers is reduced to handle another tasks. How did that feel?  Well just because our queues are not as visible doesn't mean they aren't there.

Queues are a fact of life, even if they are denied by managers. We need to learn how to survive them since managing them in most organizations is beyond the wit of a mere project manager.