Exploiting the Constraint

Having defined the critical chain as the constraint to performing the project faster, we now look to exploit the constraint. This means reducing both the planned time and the actual project performance time. CCPM exploits the critical chain using an understanding of variation. This is where Goldratt's unique focus on statistical

Task Name

Component 1

Task 1

Task 2

Task 3

Component 2

Task 4

Task 5

Task 6

Component 3

Task 7

Task 8

Task 9

Integration

Assemble

Test

Project Complete

Al j^Betty

. Betty

Charlie

Charlie

Charlie

Edna

Edna

Figure 4.2 The critical path does not account for the resource constraint.

SSMTWTF SSMTWTF SSMTWT F SSMTWTF S SMTWT

Component 1

Task 1

Task 2

Task 3

Component 2

Task 4

Task 5

Task 6

Component 3

Task 7

Task 8

Task 9

Integration

Assemble

Test

Project Complete

I* j Charlie

Betty ..T Charlie

Betty

Charlie

Charlie

Figure 4.3 Removing resource conflicts usually creates gaps in the critical path.

SSMTWTF SSMTWTF SSMTWT F SSMTWTF S SMTWT

Component 1

Task 1

Task 2

Task 3

Component 2

Task 4

Task 5

Task 6

Component 3

Task 7

Task 8

Task 9

Integration

Assemble

Test

Project Complete

"L^ Betty

Charlie

I Betty b

Charlie

Betty

Charlie

Charlie

Edna

Figure 4.4 The critical chain includes both the resource and task logic constraints to completing the project on time or sooner.

fluctuations and dependent events leads to a significant departure from most current project systems. Goldratt's recognition of variation is not unique; but his solution applied to the project-management system is an innovation.

Deming notes that managers often make many systems worse by not understanding the fundamental difference between common-cause and special-cause variation. He also notes, "I should estimate that in my experience most troubles and most possibilities for improvement add up to propositions something like this:

94% belonging to the system (responsibility of management);

6% special."

Projects have common-cause variation in the performance time of tasks. Although the times necessary to perform individual project tasks may be independent of each other, project-task networks define task dependence. By the definition of the project logic, the successor task cannot start until the predecessor task is complete (for the most frequent, finish-to-start task connection.)

The TOC improvements for production take advantage of (exploit) the reality of statistical fluctuations and dependent events. Figure 4.5 illustrates a typical project task-performance time distribution. The solid curve (left ordinate) shows the probability of a given time on the abscissa. The dotted line shows the cumulative probability of completing the task in a time less than or equal to the time on the abscissa. Note the left skew of the distribution and the long tail to the right; this is typical of the common-cause variation for many project tasks.

Fluctuations in the actual performance of unique project tasks are likely to be much larger than fluctuations in the time it takes a production machine or person to repeatedly process a part. The project-task network clearly shows the many dependencies that exist in a project. Comparison of nearly any project to a a a

0 TTTl-fm—i i i i—m—m—m—m—rm—m—m—m—m—iiiiiiii

0 0.3 0.6 0.9 1.2 1.5 1.8 2.1 2.4 2.7 3 3.3 3.6 3.9 4.2 4.5 4.8

Time, Days

Figure 4.5 Typical project task-performance-time probability distribution illustrates key features: a minimum time, a most likely time, and a long tail to the right.

0 TTTl-fm—i i i i—m—m—m—m—rm—m—m—m—m—iiiiiiii

0 0.3 0.6 0.9 1.2 1.5 1.8 2.1 2.4 2.7 3 3.3 3.6 3.9 4.2 4.5 4.8

Time, Days

Figure 4.5 Typical project task-performance-time probability distribution illustrates key features: a minimum time, a most likely time, and a long tail to the right.

production line shows that there are more dependencies in even a modest-sized project. For these reasons, the logic that improved production should also improve project management.

This common-cause variation in task performance is not an exceptional event, such as discrete project-risk events. PERT attempted to estimate the impact of this common-cause variation using three task-duration estimates, but for a variety of reasons, it did not succeed. The PMBOK™ Guide and literature still make mention of PERT in this fashion, although it is little used today. PERT diagrams, as referred to in much of the project literature and in many project software packages, simply show the project-network logic independent of the time scale; they are not an application of the three time estimates. Some projects use methods such as simulation and Monte Carlo analysis to assess the impact of task duration and cost uncertainty. While these methods propose a way to estimate uncertainty, they do not pose an effective systematic method to manage it.

CCPM accounts for common-cause variation as an essential element of the project-management system. The process removes identifiable special causes of variation, including resource unavailability and common resource behavior patterns, including the student-syndrome and multitasking (described in Chapter 3). CCPM project managers use prioritized task lists, resource flags, or other approaches to identify and ensure availability of resources for tasks.

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