MULTIPROJECT CRITICAL CHAIN

by Richard E. Zultner, Senior Consultant, Cutter Consortium

Traditionally, project management has not offered much guidance for those tasked with managing a large set of projects -- beyond treating them as "sub" projects to an organization-wide "super" project. This approach assumes that there is no difference between managing multiple projects and subprojects.

With critical chain, we consider the entire set of projects in the organization as a system. Specifically, all the projects that you do this year will come out of the system that is your organization. These projects don't deliver any benefit to customers until they are delivered. So, what is the goal of your organization this year? Isn't it to maximize your throughput of projects? To deliver as many projects, as fast as possible, to your customers? To do so would maximize the benefits you deliver.

If our goal is to deliver as many projects as possible to our customers, then what is the worst thing we can do as a manager of multiple projects? In the theory of constraints, many aspects of managing multiple projects have been studied and simulated. Repeatedly, in all the analytic studies and all the simulations, one practice has emerged as the worst and most devastating project practice -- a practice that is not just poor project management, but evil project management: bad multitasking of resources. Unfortunately, it is very common.

Multitasking is "the practice of assigning one person concurrently to two or more tasks." Multitasking is also known as fractional head-count. One person is assigned to multiple projects simultaneously (or multiple tasks within a project simultaneously). Does your organization do this?

Even if you have "dedicated" project teams, you may still have multitasked resources. If your people are assigned to do multiple tasks concurrently within the project they are "dedicated" to and are expected to show progress on those tasks, then they are multitasked. (If this is your situation, when it mentions three projects in the examples below, just translate that to three "threads" of parallel tasks within a single project.)

We have known for a long time that there is some "set-up" time that happens when people switch their attention from one task to another -- especially from a task on one project to a different task on another. They have to re-familiarize themselves with the work before they are at "full speed" on the new task. Such task switching takes time and has some effect on errors, quality, and so on. But the effect is seen to be small, and the gains in resource utilization (and therefore productivity) from multitasking are seen to be large. That's why we multitask -- so resources can be fully utilized, right?

We assume that if every individual is busy all the time, he or she is as productive as possible. If everyone is as productive as possible, since the organization is made up of the people in it, then the organization must be as productive as possible. Is this true? Does local productivity really add up to global productivity? No. Not in a system, as we will see.

Critical chain can reduce the elapsed time for an entire set of projects by 15%-25% (and this is a conservative estimate) by eliminating bad multitasking. Let's look at an example to see how devastating the common practice of bad multitasking is to project throughput.

Consider three identical projects, with a project manager responsible for each project. Each project consists of 10 two-day tasks (letters a through j). There are three types of resources required:

1. Resource X is an analyst for analysis tasks a-c.
   
   
2. Resource Y is a designer for design tasks d-g.
   
   
3. Resource Z is a developer for development tasks h-j.
   
   

In this ideal case, since we have three of each type of resource available, we can dedicate one of each resource type to each project. No project will depend on another, and all three projects will be done in 20 days. All the benefits from all the projects would arrive in 20 days.

If we have only one of each resource, how should we proceed? Each resource will have to spend some time on each project. So, let's take our resources and multitask them. The project managers for projects 1, 2, and 3 each conscientiously insist that some progress be made on their project each week. After finishing a task on one project, the active resource switches to another task on another project, so he or she (and the project manager) will have "progress" to report each week. The toll on the resources from such "project switching" is demanding -- but we'll ignore it.

The result is maximum resource utilization. All resources are working all the time. All projects are making progress. Of course, it takes longer when you don't have dedicated resources because one person cannot do the same amount of work as three people in the same amount of time. The projects finish in 48, 50, and 52 days. Customers will wait more than twice as long before they receive any benefits -- at least 48 days. If they complain, what will we say? "Give us more resources! Everyone's working all the time already. There's no way we can deliver projects any faster than we are now with the people we have." (Is this a familiar refrain?)

Is there a better way? Let's see how critical chain manages a set of projects from a true systems perspective.

In critical chain, each resource completes all tasks on one project before switching to another project, avoiding bad multitasking. Each project is finished in the same elapsed time as with dedicated resources. No resources switch from one task to another and back and try to pick up where they left off. No resources are overloaded. This is how people prefer to work. This is how people do their best work, with the fewest errors.

The result is maximum project throughput. All projects finish sooner (20, 28, and 36 days). Even the third project, which waits 16 days to start, finishes 16 days earlier than the multitasking case. All projects are better off. The "efficiency" of multitasking is a myth. Just because a resource is utilized does not mean it is productive (or genuinely efficient). Here, we have lower resource utilization than with multitasking. Only the second resource, the designer, is working all the time. The first and third resources have a break of two days between each project -- they are only 80% utilized! Yet we achieve higher project throughput and earlier delivery. Everyone wins.

The best way to manage a set of projects is for high throughput, not high resource utilization. And the best way to do that is to eliminate bad multitasking of resources. So, instead of getting three projects done in 52 days with multitasking, how much could be done in that time without multitasking?

With critical chain multiproject management, using the same resources that were doing only three projects in 52 days (probably with some overtime), we can do five projects -- at no additional cost (and with lower utilization and therefore no overtime). This is real productivity, and we did this through changes solely in the project management domain. There were no changes to any aspect of software development methods or environment. We incurred no additional cost, hired no additional resources, and took no additional risks.

If you eliminated multitasking on all projects in your organization, you would reduce the elapsed time of all your projects by at least 15%-25%.

Do Silver Bullets Exist for Software?

Some people say the example here isn't real. "Surely, it is not possible in practice to significantly reduce the elapsed time on all our projects without making any tradeoffs or any changes to how we build software. That would be magic -- and we know that silver bullets don't exist for software." Well, the experience to date of more than 100 companies (software and otherwise) on five continents suggests that at least "silver BBs" (tiny silver bullets) do exist. Let's look at how such results are possible, without magic.

Start Later to Finish Earlier

By not doing bad multitasking, by staggering the projects, we accomplish more -- even though we have lower resource utilization. We got two-thirds more project throughput by starting projects later. We complete the three planned projects in two-thirds the time by delaying the start of the second and third projects. Starting projects later means we finish earlier, because we are managing a set of projects with shared resources. We have a system of projects.

Everyone can win, if we use a true systems approach to managing our set of projects. It is possible to eliminate bad multitasking very quickly. Would your customers, and your senior management, be interested in all projects taking less time and being delivered sooner without any additional costs or resources?

-- Richard E. Zultner, Senior Consultant, Cutter Consortium