CHAPTER 35

Multi-Project Constraint Management

The “Critical Chain” Approach

FRANK PATRICK

Every organization also has constraints limiting what it can accomplish. With finite time and attention available from the human and other resources that make up the organizational system, it must provide an appropriate answer to the questions, “What should I/we be working on today?” and “How should I/we organize and perform the mass of work facing me/us?” These are the critical questions for which project management is meant to provide answers.

The literature on project management until recently had focused on project management related to the delivery of individual projects. While it is necessary—and nice—to be able to deliver a single project as promised, it is not sufficient to ensure the ability of an organization to address its multiple needs.

ORGANIZATIONS ARE MULTI-PROJECT SYSTEMS

Let us assume that the goal of an organization is to sustain itself so that it can profitably deliver products or services—not only today but also in the future.¹ If that’s the case, then because its market environment—the demands of its customers and the responses of its competitors—cannot be reasonably expected to remain static, the organization must efficiently deliver today’s business and effectively change to address its future circumstances.

Projects as the Business

There is a distinction between production-based organizations and project-based organizations, in that the former is usually dependent on delivering a lot of copies of identical (or at least very similar) units of a product or service, with minimal or easily manageable uncertainty and variation of process. In production environments, the “touch-time” associated with an individual piece of output is usually very small compared to the total duration of building that output, as components tend to spend most of their time in queues awaiting attention or the setup of the machinery that will transform it in some way.

Project environments, on the other hand, are characterized more by uncertainty of expectations and greater variation in the performance against those expectations. Projects also involve larger chunks of “touch time” as a proportion of total project duration. If one’s business is based on directly “selling” the outcome of projects developed with a shared pool of resources, as it is in industries such as custom software and information technology (IT) systems, consulting, construction, maintenance and repair, and engineer-to-build custom manufacturing, projects are “the business.” In such arenas, the ability to maximize the throughput of multiple completed projects is directly related to both current and future success.

Projects Supporting the Business

The ability to effectively implement change is clearly related to what most would recognize as projects and project management. Such efforts are typically temporary efforts, with a reasonably finite span of time between launch and completion. In this context, change projects are related not only to tactical, local process improvements or highly visible strategic initiatives, but also to the ability to redefine one’s offerings to meet future needs—research and new product/service development and deployment. Regardless of whether the business of the organization is production-or project-based, its future success needs to be supported by effective delivery of change.

ORGANIZATIONAL EFFECTIVENESS IS RESOURCE EFFECTIVENESS

The old saw defining efficiency largely as “doing things right” and effectiveness as “doing the right things” definitely applies to multi-project systems. Understanding the importance of getting the right things done at the task level, and behaving accordingly, are significant contributors to efficiency as well and are the basis for multi-project resource (organizational) effectiveness. Unfortunately, too many organizations overlook this and instead emphasize control of costs to the detriment of what they are trying to accomplish.

Maximizing Throughput or Controlling Costs?

Many managers look on the twin pressures of maximizing throughput and controlling costs as conflicting requirements, because pressures to keep expenses down have the potential to threaten the ability to deliver more completed projects quickly and with quality.

This sense of conflict comes from confusing organizational effectiveness with efficiency, and even worse, with resource utilization.² Ensuring that everyone is fully utilized all the time may seem like a reasonable strategy for getting the most out of the individual resources, and, by extrapolation, out of the organization. On the surface, this feels like it makes sense. However, if a system wants to maximize its throughput, keeping resources fully loaded across the board actually hampers that objective for several reasons.

The first reason to avoid striving for full resource utilization is that if everyone is fully loaded, there is no slack to deal with the inevitable run-ins with Murphy’s Law. Given the uncertain nature of projects as unique endeavors, any negative deviation from planned expectations will require the capacity to recover. If that protective capacity is not available, problems in a project will result in either cascading problems that will threaten the promises of other projects, or burnout of resources, or both. In either case, future throughput is threatened.

Similarly, without protective capacity set aside, there is no ability to capitalize on new opportunities that arise. Potential throughput is lost.

Multitasking Multiplies Time to Complete Projects

Finally, in environments where full utilization of people’s time is valued, there will usually be timesheets to fill out, or measurement-and-reward systems—formal or informal—that drive people to keep busy. In addition, in such a situation, projects are usually launched with an eye to making sure that no one is starved for work. As a result, there are usually plenty of choices of things for everyone to work on. With many active projects expecting progress, there is pressure to work on several at one time, splitting one’s time and attention across them. Unless an effective multi-project management system provides clear priorities for resource attention, people will strive to make the “measurement” look good by keeping busy and keeping several balls in the air. This is multitasking—working on several significant pieces of work simultaneously, switching between them before any one piece is completed and before its output is handed off to the next task in the project.

What happens in this situation is that, as a result of trying to make sure that everyone is always fully utilized (a seemingly efficient means of controlling costs), the time it takes to convert a task input into an output that is usable by the next task is expanded because of the time it sits idle while another project gets the attention.³ In addition, the context switching cost—the time involved in answering the question “Where was I?” when returning to a set-aside task—adds to the actual work time, adding further inefficiencies to the project. Throughput associated with these projects is lost as their completions are delayed beyond when they could have been achieved.

Resource Efficiency Is Not Organizational Effectiveness

By striving to be “efficient” through high local resource utilization—by striving for cost control through avoiding “wasted” idle resources throughout the organization—the real objective is suboptimized. Throughput of completed projects and the benefit—paid invoices, improved processes, or new products that will ring new cash registers—associated with those completions is threatened, lost, or delayed.

CONSTRAINT-SAVVY MULTI-PROJECT AND RESOURCE MANAGEMENT

In order for a multi-project system to operate effectively for an organization, it needs to ensure that the project pipeline is not overloaded. Also, when there are decisions to be made between project tasks vying for the attention of a resource, the system needs to provide a clear priority that is aligned with maximizing the benefit from the total collection of projects so that the resource in question will pick up and work the “right” task without multitasking. The first of these requirements is directly related to understanding and managing the organization through its constraints.

Unless artificially forced otherwise, or unless mismanaged to the point of non-recognition by overload, systems put together for a purpose typically have one or at most very few constraints limiting their ability to deliver that purpose. Like the clichéd “weak link of a chain,” a potential bottleneck resource can usually be identified as a limiting factor associated with project throughput.

The capacity of the system is the capacity of this constraining bottleneck. It doesn’t pay to try to push more projects into launch mode than this constraint can handle. They’ll only back up waiting for it to attend to them, and they’ll distract and unnecessarily overload all the resources working upstream of the constraint. Rather than trying to tightly balance the load on all resources (and killing throughput in the process), a rational approach to managing such a system is to identify (or design in) a clearly understood constraint and manage that one piece of the system very closely.

Protective Capacity

The current constraining resource in a multi-project system could be located anywhere. By definition, other resources are nonconstraints and have more capacity than would be technically needed to support the possible throughput of the system. But to start cutting and slashing this extra capacity indiscriminately would be a mistake. At some point, that would merely shift the constraint from where it is to another, potentially unpredictable part of the system at the same or lower level of capacity, or, worse, set up a situation with hard-to-manage interactive constraints.

Instead, the means of managing the constraint for growth of throughput starts with stabilizing the system so that the extra capacity upstream of the constraint ensures that the constraint is not starved for work. The only resource that should be kept near high utilization (note “near high” is not “at full”) is the constraint, since the output of the system is tied directly to its output. Project launches that are synchronized with the ability of the constraint to deal with them will, if sufficient protective capacity is available upstream, flow smoothly to the closely managed possible bottleneck. Similarly, once through the identified constraint, no downstream resource should be so tight that it delays the conversion of constraint output to a complete accrual of project benefit. Again that implies a necessary level of protective capacity downstream as well.

Once stabilized and ridded of the effects of overload and multitasking, the true capacity of the system and of its components is far more easily identified. At this point, the organization can take rational steps to grow its capacity and capabilities by systematic constraint management.

Implications for Project Portfolio Management

Once the constraint of the system is understood, it will have implications beyond just project delivery performance. It will also provide useful input to the project portfolio process. If the organization is limited to taking on projects at the rate that they can pass through the bottleneck, then those projects that have a higher relative benefit value per time required of the bottleneck will be more valuable to the organization than those that require more bottleneck time, all else being equal.⁴

One project may seem to have small face value, but if barely involving the constraint, it will be able to deliver that value while barely displacing some other project and its benefit. It is almost a “free” project, taking advantage of the slack in the nonconstraint resources. On the other hand, if a project looks very valuable when complete but requires so much constraint time that many other projects are denied or delayed, it becomes a serious strategic decision to move forward with it. If, by the nature of a bottleneck or constraint, taking on one project forces us to forgo or delay another, then this metric of benefit per constraint usage becomes an important factor in the decision to launch.

MULTI-PROJECT AND RESOURCE MANAGEMENT: MANAGING THE PRESENT AND THE FUTURE

Once an organization understands the constraints associated with its ability to deliver projects, whether for customer-driven deliverables or for internal process improvements, it has the basis not only to avoid overloading its current capacity and capability, but also to smoothly grow the capability to take on more work in the future.

“How Much Should We Take On Next Month?”—Gating Project Launches

At the border of portfolio management and project management lies pipeline management. Nothing will bog down a project delivery system faster than the premature push of projects into a system that cannot really handle them.

Once the portfolio management or sales acceptance process determines the relative ordering of projects, the process for synchronizing project launches to constraint capacity is a simple matter of staggering them at the point of use of the constraint. Once it is known when the constraint can take on a new project, it is a simple matter of placing it there in the calendar, perhaps with a bit of buffer to avoid cross-project impacts at the constraint, and examining the resulting schedule to determine where it is appropriate to start the upstream activities.

If project launches are staggered in this manner, then the constraining resource will not be overloaded. And if the constraining resource is not overloaded, then the other nonconstraining resources will also, by definition, not be overloaded, thereby reducing pressures to multitask and simplifying the question of priorities when the occasional need to choose which task to work comes up.

“What Should I Be Working On Today?”—Clarity of Priority at the Task Level

If projects are not overloading the system, the question of which task to work on is simplified by the mere reduction of active tasks in play. In-boxes are less loaded. However, due to the vagaries of project plans, and of variation in task performance, occasionally it might occur that a resource faces the need to choose one task to pick up and finish before addressing another one that is waiting. There are several options to providing such guidance.

Assuming that the individual projects are being actively managed via critical path or Critical Chain processes, one consideration is whether any of the waiting tasks are on the critical path or critical chain of the project in question. If so, that task would most likely be the appropriate first choice over a competing “noncritical” task.⁵

If there is a choice of two or more “critical” tasks from different projects, the relative health of the projects in question can be easily assessed based on working one, then the other, and vice versa. The scenario that leaves the best combination of the resulting health of the projects’ promises in best condition (or maximizes the benefits associated with both projects) would be preferred. In an environment based on Critical-Chain scheduling and buffer management, project buffers not only provide the ability of projects to absorb such decisions, but also make the assessment process straightforward. Critical path–based projects, usually relying on smaller, if any, schedule reserves, might have to add some additional recovery activities. (Note that this constraint-based approach to multi-project management comes from the same source as critical-chain scheduling and buffer management; the theory of constraints and the two processes work together by design.)

If all queued tasks are “noncritical,” it is less of an issue, and while usually a first-come, first-served process will suffice, a consideration of the general health of the project promise, or in the case of a critical-chain project, buffer consumption, could also provide useful guidance.

“How Much Can We Work On Next Year?”—Current and Strategic Constraints

The previous section described the stabilization of the system around the organization’s current constraint. That constraint is the result of past actions and staffing levels; it may not be an ideal leverage point for maximum strategic benefit. Once the system is stable, the organization can manage itself proactively by designing a more appropriate system based on what one might call a “strategic constraint.”

An appropriate constraining resource would be one that is commonly and heavily used across a range of anticipated projects, but is also hard to augment. If it is easy to get more of it by acquiring more people or improving processes, then it is probably worth doing so to easily grow organizational capacity, assuming the protective capacity around it is also easily grown. If hard to augment, it becomes a matter of offloading or improving processes to grow capacity. A constraint that is hard to get more of while commonly and heavily required is a natural candidate for a long-term constraint against which to manage the organization.

Additionally, such hard-to-grow resources are often critical to the organization’s competitiveness. For example, a system architect who knows the ins and outs of the firm’s software products is far harder to replace, and is inherently more important to its capacity, than some “plain vanilla” developer skill that can be augmented with contractors. If there is some other, easily elevated constraint in place, it behooves the organization to develop plans to grow its capacity along with any others who might be limiting what can be gotten through the expert. Understanding this relationship also highlights and justifies the need to grow that expert skill as well, perhaps through shared work or by determining what it is in the work usually performed by the expert that really needs the expertise.

An interesting offshoot of effective constraint management is that if one considers a limiting factor—a constraint—to be a weakness, then the system’s strength—the resource and skill that defines its core competency—should probably be that weakness. After all, you don’t want any other aspect of the organizational system to limit the ability to maximize the benefit of that strength.

IT’S NOT HOW MUCH YOU START, IT’S HOW MUCH YOU FINISH

Too many organizations act as if by packing the pipeline and keeping everyone heavily loaded with work, a combination of filled queues and busy resources will result in rapid and reliable project completions. Instead, projects bump into one another, adding delays usually unanticipated in individual project promises, and resources burn out jumping between unfinished tasks that then further delay task handoffs and project completions.

Suggested exercise: Survey some of your project participants. Ask them how many different tasks they currently have open. How many different project reviews do they attend each week? Ask them how long they expect their current collection of tasks to take to complete. Then ask them if they set aside most tasks and just picked one and finished it as if it were the only thing they had to do, then another, and then another, when would the individual tasks and the total collection be complete? How much less time would it take them to complete them all if they focused on one at a time?

Constraint management suggests instead that projects only be launched at a rate that can be handled by the organizational system, and as its surrogate, by the system’s constraining resource. This constraint is easily identified as a heavily used resource, skill, or facility common to most projects in the portfolio. Once the pipeline of projects quickly settles down to stability through such an approach, it becomes a matter of systematic constraint management to grow the capacity and capability of the organization to meet strategic needs.

Suggested exercise: Consider your organization. Even if it is in a chaotic state in which every resource feels overloaded, ask this question: If you could double the capacity of one and only one resource, skill, or facility, where would it be most beneficial for the organization in terms of helping more projects move to completion quicker? In most organizations, it usually quickly narrows down to a consensus on one or two candidates. Those are your initial candidates for designation as project pipeline constraint.

Every organization needs to consider how it manages the collection of projects it requires to sustain itself. Whether the business is based on delivering project work or process improvements that require attention from a limited pool of players, or if the business depends on a steady flow of new product development, maximizing throughput of completed projects is critical to organizational effectiveness.

CONCLUSION

It’s not about how busy everyone is. It’s not about success with one major project that would have everyone’s attention anyway. It’s about how many projects you finish in a period of time. It’s about finishing many projects rapidly and reliably. It’s about maximizing the throughput of your project pipeline, and the key to moving more through a pipeline is not forcing too much through it, creating turbulence, leaks, and spills. It’s about understanding the bottlenecks and constraints, rationally loading them, and systematically growing their capacity.

REFERENCES

¹ Eliyahu M. Goldratt, It’s Not Luck (Great Barrington, MA: North River Press, 1994), pp. 270–278.

² Eliyahu M. Goldratt, The Goal, 2nd revised edition (Great Barrington, MA: North River Press, 1992), pp. 26–33.

³ Francis Patrick, “Program Management—Turning Many Projects into Few Priorities with TOC,” http://www.focusedperformance.com/articles/multipm.html, October 1999.

⁴ Gerald I. Kendall and Steven C. Robbins, Advanced Project Portfolio Management and the PMO (Plantation, FL: J. Ross Publishing, 2003), pp. 217–220.

⁵ Francis Patrick, “Program Management, and Weakness as Strength,” http://www.focusedperformance.com/articles/ut06weak.html, January 2001.

FURTHER READING

The “business novels” of Eliyahu Goldratt discuss the tenets of the theory of constraints in very accessible form. The author’s website, FocusedPerformance.com, contains a wealth of additional resources.