Tải bản đầy đủ
1 Deciding what to change 75

1 Deciding what to change 75

Tải bản đầy đủ


Critical Chain Project Management

procedures—but project performance remained about the same. (Of
course, there was also a lot of changing out the managers.) TOC taught
me that that can only mean that the solutions did not attack the system
constraint. The one experience I had that did result in significant change
included many of the features of the critical chain solution. In retrospect,
that change would have been much more successful if it had had the full
theory and process of CCPM.

Defining the project management system

The goal or aim of the project system is to deliver project results that satisfy all project stakeholders. That requires delivering the promised scope
on or before the promised delivery date and at or under the estimated
cost. Figure 3.1 shows a black box view of the project system that clarifies
the system goal, identifies the system inputs and outputs, and leads to the
measures that aid controlling the system to achieve the goal.

Project failure as the undesired effect

The theory of knowledge leads us to define a new problem to improve
the project system. Comparing predictions of the current project system
(the theory) with reality helps to define the problem. Undesired effects
differ from the desired effects necessary to support the goal of successful







Figure 3.1 The black box view of the project system processes
inputs to produce outputs that satisfy the system goal.

The direction of the solution


UDEs are the things we do not like about the current system. A good
way to check them is to use this lead-in: “It really bothers me that ….”
Your list of UDEs may not include some of these, and it may include
others. Feel free to add or delete as necessary.
◗ Projects frequently overrun schedule. (If they could put a man

on the moon in less than 10 years, how come my projects always
◗ Projects frequently overrun budget. (How hard is it to control cost

to what we know we have?)
◗ Projects frequently have to compromise on scope to deliver on time

and within budget. (Wouldn’t it be nice just once to complete a
project right the first time?)
◗ Projects have too many changes. (Look, the result we want has not

changed, so why am I always signing change approvals?)
◗ In a multiproject company, projects frequently fight over resources.

(You want who, for how long, to work only on what?)
◗ Project durations get longer and longer. (See first item.)
◗ Many projects are canceled before they are completed. (A billion

here, a billion there, and before long we are talking a lot of money.)
◗ Project work creates high stress on many participants. (The XXX

project brings you greetings.)
TQM and TOC help us to understand that UDEs are a direct result of
the project system we are currently using. Even though they are not
intended effects, persistence of the UDEs for some time demonstrates that
they are robust effects of the system. That means things elsewhere in the
system are causing the UDEs. Because the UDEs are observed on all types
of projects in all types of businesses in many types of cultures, we can conclude that project type, business type, and culture are not primary factors
or influences that cause these results. TOC leads us to suspect that there is
some underlying conflict or dilemma that is common to all the environments that exhibit these effects. To decide what to change, you first have
to identify this dilemma: the constraint of the current system.
A common practice is to tighten the screws when performance fails to
meet expectations. That is, do whatever you were doing, only harder.


Critical Chain Project Management

(Insanity has been described as doing more of what you have been doing
and expecting a different result.)


Toward a core dilemma

The original TOC thinking process method went directly from the UDEs
to create a CRT, a system model of the current reality that was causing the
UDEs. The procedure started with any two UDEs and built a logical connection between them. It then added one UDE at a time, filling in the logic
until all the UDEs were connected in a system representation of current
reality. After a process of what Popper would call critical discussion, the
analyst would select an UDE as the core problem and proceed to analyze it
as the result of a conflict. That led to an initial change to begin the design
of a new system, which no longer created the UDEs and in fact created
their opposing desired effects. The process worked, but it was hard and
A recent innovation, which Dr. Goldratt indicated was suggested to
him by someone else (but whom he did not identify), made the process
more direct and seemingly easier to operate by more people. The revised
method selects three of the UDEs and analyzes each of them as stemming
from a conflict. It then considers the three conflicts together, to define an
underlying core conflict. Finally, the revised method uses the core conflict
to construct the model of current reality, showing how the core conflict
leads to all (or most) of the UDEs in the system. The process concludes
with identification of the initial change necessary to begin to revise the
system to a future reality free of the UDEs. The following discussion
follows this model for three of the project system dilemmas.

Longer and longer project duration

Most people agree that projects seem to take longer and longer. I ask
students, “Does everyone know what contingency is?” All participants
usually signal that they do indeed understand it. Then I ask someone to
define it. A lot of wiggling in place usually follows the question, but eventually someone offers an answer along the lines of “extra time or money
to handle the unexpected.” I then ask, “Extra compared to what?” More
puzzled expressions. I refer to Figure 3.2 as an example of the variation in
task performance (which they have seen during a previous estimating

The direction of the solution









Scheduled duration



Figure 3.2 Variation in estimates for the time to perform a task helps
define contingency.

exercise) and ask, “Isn’t it a huge difference if you add contingency to the
50% probable task estimates, as compared to adding it to the 90%
probable task estimate?” They all agree and understand that the word contingency can have a vast difference in meaning, depending on how you
choose to interpret the base. I offer an operational definition: “Contingency
is the difference between a 50% probable estimate and a 90% probable
estimate.” If you do not like that definition, you are welcome to change it.
Just be sure that the people you are dealing with use the same meaning.
Everyone wants to have a successful project. One necessary condition
to a successful project is to have the project complete on schedule. To
have projects complete on schedule, every task on the critical path must
complete on schedule. To have every task on the critical path complete on
schedule, we must plan each task to include the contingency (as previously defined), because we know that there is uncertainty in task performance. That is the only way to do it with the current CPM. Further,
because you find out the critical path only by estimating all the project
tasks and connecting the network, you have to include contingency in all
the task estimates.
Project managers generally agree that they want people to keep their
commitments and deliver on their task delivery date. People generally