Identify the Multiproject Constraint

The critical chain is the constraint for a single project. What is the constraint of an enterprise that performs multiple projects? How do you put the critical chains of multiple projects together in a way that identifies the constraint of the enterprise to produce projects that meet the three necessary conditions, and do it in a way that allows focus on increasing the project throughput of the enterprise? What is it that constrains the enterprise from completing more projects or completing the existing projects more quickly?

Consider a reference environment that most people are familiar with: mowing a lawn. Consider the amount of grass cut as the counterpart to completed projects. What happens when the grass is too long or when you try to push the lawn mower too fast? It bogs down and often stalls.

The same thing happens when you push too many projects into a multiproject environment without considering the capability of the constraint to perform the projects. If you push too many projects into the system, it will bog down and stall. People will work very hard, but projects will take a long time to complete (the engine is stalled much of the time), and a lot of management effort goes into restarting the engine and cleaning out the debris. It will seem like there are never enough of the key resources necessary to complete the projects.

With the lawn mower, you use the feedback from the system to adjust the rate of processing. You listen and slow down the lawn mower as the engine begins to slow down. Alternatively, you raise the cutting height to match the processing rate to the feed of the work. Normally, you do not run right out and purchase a new lawn mower or rebuild the one you have. The organization counterpart to buying a new lawn mower is hiring more staff, and efforts such as reengineering are similar to rebuilding the one that you have. A simple adjustment (raising the cut height of your lawn mower) gets you back in business. Likewise, a simple adjustment to how your organization plans and releases projects can have a huge impact on the bottomline result.

Figure 7.1 illustrates an example critical-path multiproject scenario. Common project activities share the same resources. Using conventional low-risk activity estimates and considering three-project multitasking, each activity duration is 90 days.

Considering this and the project in Figure 7.1, assuming these projects are all the same, the resources have to be divided between the three projects, even if you

ID

Task Name

Qtr 1, 1 998

Qtr 2, 1998

Qtr 3, 1998

Qtr 4, 1998

Qtr 1, 1999

Qtr 2, 1999

Qtr 3, 1999

Qt

Jan Feb Mar

Apr May Jun

Jul Aug Sep

Oct Nov Dec

Jan Feb Mar

Apr May Jun

Jul Aug Sep

Oct

1

Activity 1

tj

2

Activity 2

3

Activity 3

'k—

ll

4

Activity 4

1—

i

5

Activity 5

f

1

7

Activity 1

8

Activity 2

-1

9

Activity 3

t

tl

10

Activity 4

i

11

Activity 5

1

13

Activity 1

14

Activity 2

-i

15

Activity 3

t

t]

16

Activity 4

1—

1

17

Activity 5

f

1

Figure 7.1 Three projects in a multiproject environment.

Figure 7.1 Three projects in a multiproject environment.

have only one resource of each type. Thus, either the project plans assume that the resources will multitask across projects (i.e., are working only a fraction of the time), or the projects are not going to complete on time due to the reality of multitasking. In the case of identical projects, it is easy to understand that one resource is likely to be overloaded more than the others are. That resource is the capacity constraint of the system (i.e., the whole organization cannot complete projects any faster than the most loaded resource can complete its project tasks).

Some companies do check resource availability across all projects. They then argue to increase resources (buy more lawn mowers). This is moving to the elevate stage of the TOC before completing the identify, exploit, and subordinate steps. This is a very expensive strategy.

To improve throughput you have to first identify the company capacity-constraint resource. This is most often a certain type of person but may be a physical, or even a policy, constraint. The company constraint resource becomes the drum for scheduling multiple projects. This terminology comes from Dr. Eliyahu Goldratt's production methodology, where the drum sets the beat for the entire factory. Here, the drum sets the beat for all of the company's projects. Think of the drummer on a galleon. What happens if even one rower gets out of beat?

The project system becomes a "pull" system because the drum schedule determines the sequencing of projects. You might recall this major precept of the Lean approach to manufacturing. The system should pull projects forward in time if the drum completes project work early. The system should delay subsequent projects when the drum is late. For this reason, projects in a multiproject environment require additional buffers to protect the drum, to ensure that the system never starves the capacity constraint for work. You must also schedule projects to ensure that they are ready to use the drum resource, should it become available early.

Figure 7.2 illustrates the CCPM method. Compared to the previous critical-path case, CCPM reduces each activity time to 15 days to eliminate the three times multitasking (i.e., resources splitting their time between tasks, one on each project) and to use 50% probable duration estimates. The CCPM approach identifies the resource supplying activities 2 and 3 as the capacity-constraint resource. CCPM exploits the resource by synchronizing the projects using this resource as the drum. CCPM subordinates to this resource by adding capacity buffers between the projects. The capacity buffers ensure that the capacity-constraint resource is available for the subsequent project.

Figure 7.2 shows the CCPM plan completing the three projects (including the project buffer) near the end of August 1998. It shows the first two projects completing even earlier. Contrast this to the critical-chain multiproject plans of Figure 7.1, all of which are scheduled to complete in May of 1999. Based on what you have learned for single projects, you can expect the CCPM projects to be early. Based on experience with critical-path projects, we can expect them to be late even for these extended schedules.

Also note that synchronizing the projects this way reduces resource contention for all resources, not just the drum resource. This happens in the example because the projects are identical. While most multiproject environments do not have identical projects, synchronizing projects to the drum usually eliminates some, if not all, resource contention. Resource manager's prioritizing resource assignment to

Qtr 3, 1998

Task Name

Qtr 3, 1998

Task Name

"32"

Qtr 4, 1998

Qtr 1, 1999

Qtr 2, 1999

Qtr 3, 1999

"32"

Figure 7.2 CCPM multiproject plan reduces project duration and increases project throughput.

work on tasks according to the penetration of project buffers resolves remaining resource contentions.

This is a major simplification compared to attempts to micromanage a whole organization. These attempts never work. I hope that by now you understand the reason why this is a hopeless exercise: all of the activity durations are estimates. None of the activities should take the exact amount of time planned. Any schedule produced for all resources across all projects is a fiction. It is only one possibility out of millions of possible combinations of project status and resource availability. Instead, the critical-chain process provides a dynamic process to allocate resources: buffer management. CCPM allows for this variation with the project and feeding buffers within each project. This process also includes the ability to absorb the natural variation in the buffers. It is a real-world control system.

The TOC leads to an understanding that all resources other than the constraint must have excess capacity. Those upstream of the constraint resource must have excess capacity to ensure that the constraint resource is never starved for work, as this would waste its capacity. In a project, this means we have to buffer to ensure that we provide the constraint resource with the input it needs. Resources downstream of the constraint must have capacity more than the constraint in order to deal with fluctuations in their own output and that of resources between themselves and the constraint resource. They must ensure that they always deliver the constraint-resource-processing rate to the completion of the project(s). This is the concern of the project, not of the constraint resource.

While projects theoretically can have resource demands in any order, there tends to be a similarity in the order within a company, based on the type of projects they operate. For example, many projects will have a design phase, procurement phase, construction phase, and initial operation phase. Thus, the sequence of demands on resources tends to be similar, although the usage may vary substantially from project to project. The general idea carried over from manufacturing is that the further a resource is from the constraint resource in the plan sequence, the more excess capacity and/or the larger buffer it needs to not influence the overall lead-time.

Was this article helpful?

0 0
Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook


Post a comment