Abstract and Introduction
This paper focuses on finding queues and watching queues with the goal of improving project management practice.
It all starts with identifying queues in your project environment.
“See queues” are words of encouragement for project managers. If you are able to overlay a queue structure onto a project challenge, you automatically gain the benefit of years of research, metrics, and examples upon which to draw ideas for improvement.
Keeping it Simple
A queue is best known to most of us as a line or, more to the point, waiting in line. Examples are everywhere and often frustratingly so.
Queues are an example of systems of flow1; a commodity, a request, a person, or an idea moves from one point to another through one or more channels. Systems of flow examples:
Autos flow from city to city over the roadways. Autos are the commodity, cities are the points, and the roadways are the channels.
In an IT domain, a request arrives for a new laptop via the web request system and the laptop is a commodity provided by a fulfillment team. The request is transmitted via the online system, the channel. The fulfillment occurs at the endpoint.
In a project, units of work (pieces of the scope) are the commodities, which flow via the schedule (channel) to pair up with resources (points) to complete the project.
If the flow through a system is constant and predictable and the system has only one channel, you are seeing a simple queue, the first class of a system of flow. It is a queue where the channel capacity and the capacity of any service at the end of the channel are always greater than any demand. This queue is of little theoretical interest,2 but as a basic system of flow you may encounter it in a project setting.
The second class of flow systems are queues that are not predictable; it is these queues that involve guessing and the use of probabilistic thinking. These are random flow problems, and are the kinds of queues you see most often in project environments (in fact, just about everywhere). The single channel, single endpoint problems become complex and difficult to solve in the random environment.
Such are the queues that are experienced by project managers. For the rest of this paper, the word “queue” is defined as a project queue. It is a random, single-channel queue, with a single endpoint (sometimes called single service).3 Often these project queues are strung together in sequences that result in the frequently complex scheduling problems most project managers are asked to solve.
Watch out for the mathematics cliff
Modern queuing theory is strongly rooted in the mathematics of probability, known as stochastic processes. You only have to spend a few moments reviewing literature on queues before you are deep into some fairly advanced math. This paper avoids the advanced math. A problem that looks complex may break down into several smaller connected single channel/single service types of problems.
II. Finding Queues in Projects
Work Breakdown Structure – Scope Waits in Line
Decomposing project scope into a work breakdown structure4 (WBS) is the first place to recognize a queue in your project. Each of the smallest work units in the WBS is a unit of scope known as a work package; the work package describes a deliverable or a result of effort, not the effort itself.5 The work packages are “waiting” for a resource or a series of resources to do the work and create the deliverable(s).
Depending on the complexity of the project scope, and the amount of decomposition, the lowest level of the WBS consists of work packages (WP). A project with many WP may result in some long lines for resources.
As a project manager, begin at this early step in your project to look at some simple aspects of the queues created by your WBS.
- Are there a large number of work packages waiting for one resource?
- Are the deliverables described by the work packages of the same general size? Will some work packages overwhelm their assigned resources?
- Which work packages require several resources to complete the deliverables?
- Are the completions of multiple work packages dependent on each another?
- Which work packages are likely to be ready for resources at a random time? In other words, are some work packages only available at certain times in your project? Are work packages and resource availability times predictable?
II. Finding Queues in Projects
Scheduling — Tasks Get Resources Assignments and Time Assignments
Baker and Trietsch6 offer some basic definitions of the science of scheduling in the first chapter of their comprehensive text, Principles of Sequencing and Scheduling. Planning is defined as determining the tasks and the resources; with the WBS we have half of this phase completed. Scheduling is defined as a two-step process: (1) Sequencing, finding the order of tasks and (2) Scheduling, selecting the times for tasks.
Resources define the boundary of a scheduling exercise.7 Assigning start times, durations, optimal end times, and information about uncertainty to tasks is part of the scheduling step in project management. A project manager will begin to see queues clearly emerging during scheduling. It is clear that work packages are waiting in line for resource availability, it is clear that there is an ordering of work packages, and it is starting to be clear that time constraints on resources will have an impact on the overall completion of work packages.
At the end of scheduling, a project manager should have answers to these two key questions: (1) which resources should be allocated to perform each task (work package)? And (2), when should the work on the task be performed?8
At this step, PMI's Practice Standard for Scheduling recommends a project manager determine whether the schedule is deterministic or probabilistic.9 Deterministic models present a fully populated schedule (with dependencies, fixed activity durations, and a firm end date) that assumes everything will go according to plan. A probabilistic schedule is the same as a deterministic schedule except that activity durations (the amount of time the resources will spend on the work packages) are random, and the end date is not firm.10 Random durations may signal the presence of queues in a project.
Donald Reinersten, in his excellent treatment of queuing theory and its impact on product development,11 points out that queues on the critical path of a development project are the most “expensive.”12 A queue represents a delay in the sequence of tasks that could bring the project to completion in the shortest possible time, the critical path. If the project manager can recognize the critical path, then removing queues or preventing queues from forming on the critical path will keep the project on time (see the section on Critical Chain later in this paper). The project manager can see queues, but must be skillful in optimizing them and insuring the best sequence of work packages to finish the project on time.
II. Finding Queues in Projects
Product Development Efforts — Borrow from Lean/Agile
Project managers can borrow freely from the Lean and agile successes in product and project development. Craig Larman and Bas Vodde13 compare the evidence of physical queues with evidence of invisible queues in traditional development shops. In the physical world, you see stuff piling up all over the place: inventory, partially completed product, and bins of defects are all physical evidence of queues and evidence of lost productivity and stalled throughput. Spinning around on the disks in the back room are the piles of development stuff: documents, bug reports, and partial code trees. All are the invisible evidence of queues and all represent lost productivity, lost opportunities, and stalled throughput similar to the negative impact of physical queues.
For the project manager trying to manage a deployment methodology, invisible queues of information and documents lost in the development department might provide the key to more successful release and deployment. There might be evidence of some useful failure; a clear set of steps, directed toward a testing goal, which resulted in a failure. Preston Smith14 defines a failure as an unexpected outcome that provides invaluable information. This information could assist in future development efforts and/or product deployments.
A Guide to the Project Management Body of Knowledge (PMBOK® Guide) recognizes the formal and informal collections of knowledge that exist in an organization, which may be helpful to future project managers.15 Project managers can use these assets, such as lessons learned, discarded WBS, old schedules, and issue and defect management checklists. These resources may be a store of unpublished information, loosely organized as queues. You may be able to use this background of forgotten bits and bytes to begin to chip away at the barriers to effective project delivery. Remember that these forgotten bits were once goal directed, there was an endpoint. An endpoint can be an indicator of a queue.
A queue is not just a non-directed list of leftover documents and source code. Add a goal to a non-directed list, and it starts to look and behave as a queue. Move some source code into a set of Scrum stories and load the stories into a backlog; this is a classic Lean and agile development queue.
Iteration backlogs, product backlogs, and release backlogs are all queues that are integral to a well-oiled Scrum team. These queues help the teams manage their workloads, focus on the tasks ahead of them, and file tasks for later, more appropriate time boxes in their development cycles.16
Donald Reinersten17 presents queuing as one of the set of “thinking tools” for the agile development processes. Thinking tools help us understand why we must change or why we must continue a certain practice. Queue analysis joins (1) Focus on Products/Profits, (2) Information Theory and, (3) Feedback Mechanisms as the major thinking tools for development transformation. As a project manager, start with queue recognition as the first tool in your toolbox.
II. Finding Queues in Projects
One of the strongest and most compelling bodies of applied queuing theory and methods comes from Eliyahu Goldratt and his development of the Theory of Constraints (TOC).18,19 If you have not read or re-read The Goal or Critical Chain, do so.
TOC uses the idea of a bottleneck as the key unit of observation and discovery. The notion is to find that process that is stopping all progress. TOC then offers several tools to treat the bottleneck and begin to heal your process (see Section III for more on this).
Chains (and all of the associated tools in TOC) are queue tools. If you are using TOC, you are likely looking at many dependent queues and sometimes you may need to dissect the chain and focus on just one queue.
Critical Chain is a formal and non-trivial discipline in project management; to try and oversimplify the practice does it and the reader disservice.20 However, in this paper, the goal is to help project managers recognize queues; the recognition may be just a glimpse.
The Critical Chain starts with a Critical Path baseline schedule that is optimized for
- median durations,
- no due dates,
- no multitasking,
- minimized time to completion,
- minimized work in progress,
- realistic precedence, and
- resource feasibility.
The process of creating this Critical Chain has freed up many small blocks of time that are collected into buffers. The work of the project aggressively follows the Critical Chain, and when problems arise, the buffers are raided. The sizes of the buffers are then used as early warning signs of the project health during execution.
Where are the queues? The genius of TOC and Critical Chain is it shifts the management of projects from a time-oriented to a resource-constrained point of view. It recognizes the fundamental queues inherent in our projects — the work packages waiting for resources. In addition, Critical Chain moves much of the uncertainty into a single place, the buffers.
II. Finding Queues in Projects
Handoffs, fence tosses, and flows
As work gets done in a project, there is a need for handoffs and transitions from resource to resource. For example, testing and acceptance of service functions may not be best done by the developers, hence the handoffs to QA teams. One project resource may have to wait for the answer to an inquiry of another project resource. Queues are easy to see in handoff situations.
A fence toss is the kind of handoff that may provide some information for the project manager. A resource that feels like he or she has been the recipient of a “fence toss” may be feeling disrespected. If a handoff is perceived in a negative fashion, look at the series of queues that have led up to the handoff.
Queuing models can show the project manager how work is moving from resource to resource through the project. There are automatic metrics that are available with queues (see Section III, Simple Observation and Measurement of Queues). The project manager can work with the recipient resources to define when, how, and why they expect to receive tasks. Perhaps the project manager can adjust the resource/queue interactions using metrics as a guide.
Effective flow of work through the project reflects a shared goal of throughput that will contribute to project success. Share the interactions of the project queues and the resources with the project team as a way to help the team understand and commit to a maximized flow of work through the project schedule.
II. Finding Queues in Projects
Telltale signs—the summary section
This section is a quick review and provides some key characteristics of queues that may help you see them in places where you have not looked before.
- A work breakdown structure may be your first look at the line forming up for resources.
- Schedules match resources and tasks, matching endpoints with requests
- Look at challenges in the areas of development and product deployment
- Examine situations where work packages, people, or tasks are waiting
- Examine situations where people or tasks are requesting services at random intervals
- Examine situations with endpoints or goals, even those that are not explicit
- Find hidden repositories of information that might contain information in queue formats.
- Look at dependent events and tasks that may signal chains and queues
- Handoffs and project throughput can be managed via queuing models inherent in a project schedule.
III. Simple Observation and Measurement of Queues
Watching and measuring in a queue setting
You know queues when you see them, and you can learn to recognize queues. Beyond simple recognition, there are basic measures of queue performance and basic methods for queue observation.
The project manager is urged to add queues to her arsenal of tools and experiment a bit. Preston Smith21 reminds us of a central tenet of experimentation, which consists partly of “…the process of an action followed by an observation.”
The PMBOK® Guide specifies the project management Knowledge Areas, and first mentioned among these is “Project Integration Management” or, putting it all together. The project manager is urged to “Monitor and Control Project Work.”22 The project manager and his or her team should monitor the health of the project, and use those health data to pay special attention to the areas of the project that need adjustment. Watching queues and queue behavior can help assess performance, alert the team to risks, suggest corrective actions, and provide some simple progress metrics.
Randolf Hall23 offers an excellent treatment of observation and simple measurement tools. The basic measures are:
- Arrival time in the system
- Departure time from the system
- Queue departure time
- Time in the queue
- Time in service
- Total time in the system
Often, these basic measures are summarized with simple average and standard deviations for each measure.
In some cases, Hall recommends a simple graph of the observed or empirical data as the best summarization tool. In fact, some of the advanced mathematics of queuing derives from the graphical representation of queue characteristics.
For projects, it is the work packages' time waiting for resources, or time with the resources. Or it might make sense to note that one particular resource is chronically late or overloaded.
There are other measures, and there are different points of view for the same measures. For example, the customer or sponsor point of view may name “time in queue” as “waiting time.” The resource point of view might look at “time in service” as “efficiency of servers.” In all cases, the measures and the summarizations will be of help to you as you observe the queues in your projects.
Reinersten24 introduces a way to calculate the economics of queues. In today's project environments, it is invaluable to be able to assign costs to component process and show the value of tools. Reinersten combines the costs of providing service from a project resource (capacity) with the cost of delay while waiting to “get” that resource. The combination creates an easy to use economic measure, a monetary queue metric. A project manager might push for this metric to be included with other traditional monetary metrics to aid in an enterprise decision making.
Professor Hall25 reminds us of the true value and purpose of measurement and observation. “Ideally, when evaluating queuing alternatives, one would like to measure directly the impact of the alternative on the overall goal…The measures of performance are proxies for the overall goal.” This alignment with goals is central to all project management.
III. Simple Observation and Measurement of Queues
Energizing staff around queues
Most of this section relates to a real-life situation at Stanford University's IT Services.26
We were faced with a tactical project to improve fulfillment and delivery times from IT Order and Operations staff. IT Services Staff who are employed in service delivery work in a pressure cooker of deadlines and requirements.
In almost all cases, there are underlying systems of records that deliver daily work queues to the staff. After several months of some long service delivery times, some large queues, and not infrequent escalations and complaints from customers, we deployed some basic queue training.
We used a variant from the Theory of Constraints (TOC) “boy scout” game from Chapter 14 of Goldratt's The Goal. 27 Our local game was led by agilists Steve Bockman and Chris Sims.28Teams immediately felt and acted engaged; they were brainstorming, and quickly thinking about how this might be applied to their daily work.
Preston Smith29 offers great advice on bottlenecks (a major TOC construct and something every project manager has seen). The first hint: “watch for them,” watch for the work items that have the longest time in queue. The second hint: challenge your team for a quick turnaround, and listen carefully to the reasons/excuses why they cannot meet the request. If a pattern emerges in the “can't do it” reasons, that is the bottleneck. Simple advice for powerful diagnosis: watch and listen.
As a follow-up, a subset of the staff from the workshop met and looked at the basic ideas from TOC: (1) identify the bottleneck, (2) exploit the bottleneck, (3) subordinate the other steps in the chain, (4) elevate the bottleneck, and (5) repeat. The team needed to create a baseline of queue metrics; in this case, they used the average length of time a request was in the queue, along with the maximum and minimum times a request was in the queue.
These metrics have become parts of a monthly report and baseline from which the team can make ad hoc decisions on their own. There are certain times that work has seemed to pile up, or staff shortages have overtaken the group. In these cases, the group turns to its metrics as a starting place to make changes, ask for help, or otherwise address the problem.
Staff in Stanford's IT Services have become energized by owning their own queues, their own priorities, and their own metrics. Upper management have been pleasantly surprised to see a group of individual contributors gel as a team around a set of metrics, a chain of queues, and an overall process that has a goal of throughput in favor of the client.
III. Simple Observation and Measurement of Queues
Beginning and end?
As witnessed at Stanford, the simple act of naming and observing queues may be all you need to start to see positive changes in throughput — whether in a project in trouble or in an operations setting. It is difficult to say whether the actual math and science of queue measurement were as important as the energy and commitment of an empowered team with a common framework for communication and action.
The most fortunate project managers among you will have both the beginning (a new tool with which to examine project challenges) and the end (desired results from applying the tools; finding, watching, and measuring queues). Try learning discovery and observation of queues with a small group of project team members. Re-connect with this project group during observations of the project queues over time.
When we see queues, we already have some intuitive notions of what to ask about the queues. We ask the same questions that we ask when we come upon a queue at a toll booth or a bank. We apply the same judgments to “our” queues as we do to the queues we are forced to join in the real world.
Project managers are encouraged to continue to study queues, and dig a bit deeper. Some of the intuitive notions do not bear up in reality (especially those notions about capacity in situations where there is random arrival for service). Other advantages to more formal education come from orderly presentation of metrics and the ability to gauge the impact of one set of actions over another in a queue problem area.
Please take some time to read and/or skim some of the items in the bibliography. Create a book club for Goldratt's The Goal or Critical Chain. Brush up on queuing skills for those projects in which you are trying to directly improve time to project completion.
In the beginning, simply see queues. In the end, you may be surprised at the orderly progress you make on some of your toughest project issues.
Betz, C. T. (2009). Architecture and patterns for IT service management, resource planning, and governance: Making shoes for the cobbler's children. Elsevier Inc.
Baker, K. R., & Trietsch, D. (2009). Principles of sequencing and scheduling. John Wiley and Sons. Goldratt, E. M. (1997). Critical chain. North River Press.
Goldratt, E. M., & Cox, J (2004). The goal—Third Revised Edition. North River Press.
ITIL V3 Foundations (2009). Pink Elephant, V4.3.1 (January, 2010), ITIL is a Registered Trademark of the Office of Government Commerce, United Kingdom.
Hall, R W. (1991). Queuing methods for services and manufacturing. Prentice Hall.
Kleinrock, L. (1975). Queuing Systems, Vol. 1, Theory. Wiley.
Larman, C., & Vodde, B. (2009). Scaling lean and agile development, thinking and organization tools for large-scale scrum. Addison-Wesley.
Project Management Institute (2008). A guide to the project management body of knowledge (PMBOK® Guide)—Fourth edition. Newtown Square, PA: Author.
Project Management Institute (2011). Practice standard for scheduling—Second edition. Newtown Square, PA: Author.
Reinersten, D. G. (1987). Managing the design factory: A product developer's toolkit. Free Press.
Sims, C., & Johnson, H. L. (2011). The elements of scrum, Version 1.01. Dymaxicon.
Smith, P. G. (2007). Flexible product development: Building agility for changing markets. Jossey-Bass.
1 Kleinrock, Leonard. Queuing Systems, Volume 1: Theory, pp 3–4
2 Kleinrock, pp 3–4
3 Kleinrock, p. 6
4 A Guide to the Project Management Body of Knowledge (PMBOK® Guide)— Fourth Edition, Project Management Institute, pp. 116–122
5 PMBOK® Guide— Fourth Edition, p. 116
6 Baker, Kenneth and Trietsch, Dan. Principles of Sequencing and Scheduling, pp 1–6
7 Baker and Trietsch, p. 2
8 Baker and Trietsch, p. 4
9 Practice Standard for Scheduling—Second Edition, Project Management Institute
10 It may be that the critical path leading to the project end date is not yet evident immediately upon finishing a probabilistic schedule.
11 Reinertsen, Donald. Managing the Design Factory, pp 42–67
12 See Section III, Watching and measuring in a queue setting, for further discussion of Reinertsen's queue economics.
13 Larman, Craig and Vodde, Bas. Scaling Lean and Agile Development, pp. 111–113
14 Smith, Preston G. Flexible Product Development, pp. 87–94.
15 PMBOK® Guide—Fourth Edition, pp. 32–33
16 Sims, Chris and Johnson, Hillary Louise. The Elements of Scrum, various sections.
17 Reinersten, Donald G. Managing the Design Factory, pp. 42–67
18 Goldratt, Eliyahu M. Critical Chain
19 Goldratt, Eliyahu M. The Goal
20 Herroelen, Willy, Leus, Roel and Demeulemeester, Erik (2002). Critical Chain Project Scheduling: Do Not Oversimplify, Project Management Institute, Project Management Journal, Vol.33, No.4, pp. 48–60
21 Smith, Preston G. p. 85
22 PMBOK® Guide—Fourth Edition, pp 89–93
23 Hall, Randolf W. Queuing Methods for Services and Manufacturing, pp 19–51
24 Reinersten, pp 47–49
25 Hall, p. 22
26 Many thanks to the staff at Information Technology Services at Stanford University, Stanford, CA; CIO William Clebsch; Executive Director Sam Steinhardt; Directors Kathy Pappas-Kassaras, Bob Moya, and Nancy Ware. its.stanford.edu
27 Goldratt, Eliyahu. The Goal, Chapter 14, pp 103–112.
29 Smith, Preston G. Flexible Product Development, pp. 222–223.
© 2012, Steven J. Loving
Published as part of the 2012 PMI Global Congress Proceedings – Vancouver, Canada