Queuing Theory

Queuing theory is the study of waiting lines and is associated with business in determining resources needed to achieve service business throughput objectives, but it does not just apply to services and material handling.

Queuing Theory and Billable Hours

I have worked at companies that had a target for billable hours, that well in the 90%. That is, 90% or more of the hours the employee worked, had to be assigned to specific project work. The organization treated the time an employee was at work and available to work on specific projects, at nearly 100%, so for example, in a 40-hour work week, it was expected that 36 hours or greater were dedicated to specific project activities.  This was recorded in the project schedule.

Queuing Theory and Product Development

The impact of queues on product development and knowledge management in general is explained well in this Harvard Business Review article a snippet of which is found below:[i]

In both our research and our consulting work, we’ve seen that the vast majority of companies strive to fully employ their product-development resources. (One of us, Donald, through surveys conducted in executive courses at the California Institute of Technology, has found that the average product-development manager keeps capacity utilization above 98%.) The logic seems obvious: Projects take longer when people are not working 100% of the time—and therefore, a busy development organization will be faster and more efficient than one that is not as good at utilizing its people.

But in practice that logic doesn’t hold up. We have seen that projects’ speed, efficiency, and output quality inevitably decrease when managers completely fill the plates of their product-development employees—no matter how skilled those managers may be. High utilization has serious negative side effects, which managers underestimate for three reasons:

1.) Variation of the development work

2.) Incomplete understanding of queues and economic performance

3.) Lack of clear visibility into product development work in progress

We have discussed variation in the work in many other posts. Variation is everywhere, and experience suggests this is rarely accounted in the project task estimates and the recording thereof via the project schedule.  We will not go further into this please see our other blog posts on variation.

Figure 1 Harvard Business Review Graphic

Queuing theory has been applied to operations; that is for services and manufacturing, but that has not rippled down to product development and knowledge management based on observation.  This is likely the reason management works to ensure that the employees are booked nearly to capacity. In fact, on the surface, from a business perspective, the management is there to ensure the best use of the resources and employment of the talents of our team.  It probably looks like we should keep our people focused on our work, use of the time available out of the 40 hours.  The problem this does not work the way we suppose, consider the Harvard Business Review graphic above.

In conventional projects, the specifics of the work CAN get obscured, this happens when we think we can plan months out, and when we do not spend time with our team consistently and deliberately, to understand what is physically happening, what work is coming up, what is underway and what progress is being made on those work items.  In agile projects, the work is segmented or parsed in very controlled packages.  Work items are pulled from the product backlog in a very controlled manner.  In this way the queue of work items and the work in progress can be controlled and well managed.

Queuing Theory and Product Development Summary

The more we attempt to maximize the number of hours expected from our talent, the more problems we create regarding throughput. Variation of tasks, as well as how the work is staged and accomplished is likewise important.  We should study queuing theory and understand that we cannot book the hours of our team like we absolutely understand the task variation, along with the myriad of things we need to learn along the way while doing the work.  Time must be available for this unknown learning.

[i] Six Myths Of Product Development Stefan Reinertsen – https://hbr.org/2012/05/six-myths-of-product-development last accessed 10/3/2018