Tải bản đầy đủ
3 Toward desired effects 90

# 3 Toward desired effects 90

Tải bản đầy đủ

The direction of the solution

91

boy scouts on a hike through the woods. The trail is narrow, so no scout
can pass the scout in front of him. As they hike, the line grows longer and
longer. Alex Rogo, our hero in The Goal and the troop leader for this
weekend, realizes what is happening. The speed of the scouts is not the
same. There are statistical fluctuations in how fast the scouts walk. Each is
dependent on the scout in front of him and the one behind him. These
fluctuations cause the length of the line to grow continuously. Herbie
turns out to be the slowest boy scout, the constraint. The gaps in the line
compare to inventory in a manufacturing plant.
For a project, the gaps in the line of boy scouts compare to time. If the
next resource is not ready to start when a predecessor activity completes
early, the project loses time. We lose the positive variances in statistical
fluctuations. That is like a faster boy behind a slower one; he can catch up
but not pass. The line grows in length. This is worse in a project than in a
manufacturing case. In manufacturing, the inventory is used eventually.
In a project, the time is lost forever. There is no conservation of time.
The direction of the solution Goldratt proposed follows from his TOC
production solution. The first step is to identify the constraint of the
project system. His focus on throughput led him to focus on the time it
takes to complete the project. The longest path through the project is the
evident constraint. At first look, this is the critical path.
How then to exploit the critical path? Dr. Goldratt, who holds a Ph.D.
in physics, knows statistics and knows a lot about the cloudy behavior of
much of reality. He knows that the only way to take advantage of statistical knowledge is through dealing with numbers of events. Deming and
Shewhart before him had pointed out that science cannot make predictions about a single instance of a statistical event. That leads to a simple (in
retrospect) insight: Concentrate the uncertainty for many of the tasks of
the project at the end of the project in a buffer. The buffer has a direct
counterpart in his production solution, where buffers of in-process
inventory are strategically placed in front of machines to prevent them
from running out of work.
Concentrating contingency in the buffer brings along two significant
bonuses. The first bonus is a shorter plan. It is a mathematical fact the
variances of the sum of samples from a series of independent distributions
add. The variance is the square of the standard deviation. The standard
deviation is proportional to the amount of variation in a single task. In
other words, the uncertainty in the sum of tasks is the square root of the

92

Critical Chain Project Management

sum of the squares of the individual variation. While attempting to protect the completion date of each task in a project, each task had to include
its own allowance for uncertainty. Those allowances add up down the
path. When we take the allowances out of each task and put them at
the end of the path, they add as the square root of the sum of the squares,
a much smaller total amount. Figure 3.11 illustrates how that works
for a very simple case. The reason is evident. Some of the tasks should
overrun, some should underrun. The distribution of the sum need not
be as large as the sum of the individual variations because some will
cancel out.
A second statistical fact comes into play with this strategy. The central
limit theorem of statistics states that the distribution of samples from a
variety of independent distributions tends toward a normal distribution.
A normal distribution is a symmetrical distribution. It does not have the
long tail to the right that many individual task distributions may have.
That means concentrating contingency at the end of a path reduces the
likelihood that it will be overrun by a large amount.
A key part of the direction of the solution Goldratt proposed, then, is
to use average task completion times in the plan and to add an aggregated
buffer at the end of the plan for overall project contingency.
3.3.2

The resource constraint

Eliminating contingency from the individual task estimates and controlling it at the project (path or chain) level appears to directly resolve

We need less time this way, because of our profound
knowledge understanding of variation!

Figure 3.11 Concentrating contingency at the end of the path
requires less total project time.

The direction of the solution

93

the first two conflicts that led to the core conflict. It does not resolve the
have to eliminate demands on the resources to multitask. To avoid multitasking in an environment with multiple projects, you have to either
eliminate the demand or give the resources a way to handle the multiple
demands without multitasking and without negative reinforcement.
In the past, I never questioned the proposition that an acceptable way
to remove resource contention is to first identify the critical path and then
level resources. Resource leveling moves around tasks in the plan to
match the resource demand for each resource (e.g., engineers) to the
supply. My literature search did not reveal the basis for the proposition
that you can first find the critical path and then level. I suspect—but have
no proof—that may be a result of technological evolution. It is possible to
calculate a project manually to find the critical path. There is no simple
algorithm to create an optimum resource-leveled critical path. Thus, it is
difficult to resource level even a modestly complex project plan manually.
The relatively expensive and slow computers that existed at the time of
the growth of CPM and PERT did not lend themselves to doing a lot of
calculation. The idea that you could use the computer to calculate the
critical path, lay out the network, and then deal with the potential
resource constraint seems logical enough. It may even have been that,
for projects using CPM and PERT, resources were less often a constraint.
They could find the critical path and then determine and satisfy the
resource demand.
Current project management software operates by starting with the
activity structure (critical path) and only then considers the limited
resources available for the project. Project management software identifies the critical path by linking the project activities in a logical way and
then measuring the longest time through the network of activities,
assuming no resource constraints. The project manager inputs resource
availability. The software then allocates the resources through various
schemes but usually first to the critical path and then to the paths that are
nearest to the critical path in time duration (minimum slack activities
first). People who have studied resource allocation know that this does
not always give the optimum schedule. People have proposed various
heuristics, and some programs provide a large number of selections. The
only way to find the optimum among those options is trial and error.
Critical chain scheduling resolves the dilemma.

94

Critical Chain Project Management

Consider, for example, the miniproject illustrated in Figure 3.12 and
determine the critical path through the project. The project has three
paths, all of which have two activities with different time duration, as
shown. What would we come up with as the critical path? The lower
path, that is, activity C1 followed by activity C2, is longest. The project
should complete in 65 days. We confirmed this simple calculation with
Microsoft Project.
Now, let us move from the world of unlimited resources to the world
of reality. Figure 3.13 shows the resources needed and for each activity.
There is only one clear resource and one crosshatched resource for the
project. When people work on the activity, they have to work full time.
What will our critical path schedule now say for the earliest completion
time?
If you came up with 160 days, you are applying resource leveling the
way most computer programs do. We tested with Microsoft Project and
got the same answer. You first apply a conflicting resource to the critical
path. You next apply it to the activity with the least slack, in this case, B1.

A1

A2(45)
B1(25)

B2(30)
C2

C1(60)

75

Figure 3.12

50

25

Example project shows resource conflict.

Critical path resource
allocate resources first to
path with “least slack;” this
means critical path first.

C1(60)

A2(45)

A1
B1(25)

150

0

B2(30)

C2

100

50

a schedule of 160 days.

0

The direction of the solution

95

Oh, did you check the crosshatched resource also? Does your solution
look like Figure 3.13?
Now, see if you can outsmart the computer. Look at Figure 3.14 and
see if you can find a better way to sequence the activities that will reduce
the overall project time. You are now considering both the activity logic
and the resource constraint.
Considering the resource logic with the task structure reduced the
critical path time to 95 days. Microsoft Project allowed us to move
the tasks to accomplish that and confirmed that it results in resource
leveling. Allocating resources using the common critical path method
can lead to excessively long schedules.
Thus, Goldratt’s second key insight is to define the project critical
chain instead of the critical path. The critical chain includes both the task
and the resource constraint.

3.4

Solution feasibility (evidence)

Using the scientific method as the theory of knowledge leads to selecting
the preferred theory through critical discussion and test. Comparing critical chain to critical path, we see more content in the critical chain theory
because it:
◗ Provides an explicit method to manage common cause uncertainty;
◗ Explicitly resolves the resource constraint.

Popper noted that a new theory should contain and explain the old
[3]. With unlimited resources, the critical chain is the same path as the
and intuition reduces the
schedule to 95 days.
(No changes due to many
aspects of Critical chain
schedules yet.)

A2(45)

A1

B1(25)

B2(30)
C1(60)

150

100

50

Figure 3.14 Using logic to work out the critical chain reduces the
project lead time to 95 days.

C2

0

96

Critical Chain Project Management

critical path. With a resource constraint, the critical chain is an acceptable
solution to the resource-leveled critical path. Thus, critical chain contains
the critical path solution.
Popper suggested that the primary method of testing a new theory be through critical discussion. Such discussion checks the new theory
against the old, looking for logical deductive reasoning and evidence
supporting the suppositions (assumptions) made in the new theory and
the old theory. Summarizing the reality of the scientific method, Popper
states [3]:

1. Induction, that is, inference based on many observations, is a
myth. It is neither a psychological fact, nor a fact of ordinary life,
nor one of scientific procedure.
2. The actual procedure of science is to operate with conjectures: to
3. Repeated observations and experiments function in science as
tests of our conjectures or hypotheses, that is, as attempted
refutation.
This chapter developed the reasoning behind the way Goldratt
defined the problem with the current theory. It does not explain the jump
to his proposed direction for the solution: improved management of
uncertainty. It is unlikely that others without his knowledge and experience could have made the same jump. The original PERT method and
subsequent work with project simulations are evidence that others were
aware of the uncertainty problem. The current knowledge base lumps the
uncertainty in predicting each project task in the area of risk management, adding evidence that people understand the need to deal with it.
However, none of the current solutions make uncertainty management
part of the basic project system in the manner of critical chain.
Critical chain explains the reasons for schedule overrun through the
reality of statistical fluctuations (uncertainty or variation), dependent
events, and human behavior. The CPM theory does not address that reality; it uses deterministic durations and start and stop dates for each activity in the schedule. Combining that technical assumption with human
behavior leads to schedule overrun. Schedule overrun leads to cost overrun and reduces the delivered scope. Perhaps most important, the new