Tải bản đầy đủ
2 Current reality tree 273

2 Current reality tree 273

Tải bản đầy đủ


Critical Chain Project Management

with UDEs, which are those things that really bother you about the
current reality. For example, “It really bothers me that projects overrun
the schedule.” (Chapter 3 described UDEs for project management.)
You then select three of the UDEs to develop a core conflict. You do
that by developing each UDE conflict and then combining the three conflicts to discern the underlying generic conflict that leads to all three.
Chapter 3 also illustrated the combination of evaporating clouds for project management. The CRT drives the cause to a core conflict that leads to
most (and usually all) of the UDEs. A core conflict is not the core conflict. It
is an important conflict and therefore a good high leverage place to focus
on changing the system.
Figure 11.1 illustrates the base of the project system CRT, containing
the core conflict developed in Chapter 3 (see Figure 3.9). It illustrates the
cloud in sufficiency tree format, highlighting the assumptions that lead to
the conflict. Reading from the bottom, “If everyone wants projects
to succeed, and if increasing competition drives managers and clients to
demand projects to get the most scope for the least cost within the shortest
schedule, then successful projects must deliver increased scope and
reduced cost and schedule.” Continuing up the tree, “If successful projects
must deliver increased scope and reduced cost and schedule, and if the
only way to reduce the schedule of critical path plans is to reduce the
duration of tasks on the critical path, and the only way to reduce cost is to
reduce task cost, then there is pressure to reduce each task estimate.”
You can read the right side of Figure 11.1 up to entity 9, which states,
“There is pressure to include contingency in each task estimate.” Including contingency conflicts with reducing task estimates, thus leading to the
fights that surround project planning.
Note that I left out the “more and more” statements. They come
about as you traverse the tree over and over in the same organization.
Note where some of the UDEs, which are conclusions farther up in the
tree, feed into the entities at the base of the tree, such as UDE-1, 2, and 3
feeding all the way down to entity 9.
Figure 3.10 illustrated the notional connection of the UDEs that
flow from the base of the tree. The logic of the tree is not evident at this
summary level. The actual tree includes many steps of intervening logic
that describe how organizational beliefs and actions lead from one UDE to
the next. The key point of Figure 3.10 is that all the UDEs in the tree are
causally related and derive from the core conflict.

The TOC thinking process applied to project management


There are fights over
the estimates to include
in project plans

There is pressure
to reduce each
task estimate

There is pressure to
include (more and
more) contingency in
each task estimate



The only way to reduce the
schedule of critical path plans
is to reduce the duration
of tasks on the critical path,
and the only way to reduce
cost is to reduce task cost

Resources know they have to
account for uncertainty in task
estimates due to common cause
variation in task performance

Successful projects
must deliver increased
scope and reduced
cost and schedule

Each resource must
complete its task to scope,
cost, and schedule estimates


Increasing competition
drives managers and clients
(more and more) to demand
projects to get the most scope
for the least cost within the
shortest schedule

Figure 11.1


Everyone wants
projects to suceed

Most companies
judge project resource
(including subcontractors)
performance based on
delivery of full scope within
cost and time estimates

The project management CRT base identifies the core

The generic project management CRT cannot represent your environment. I have worked with companies that have started from very
mature project management systems as well as with companies with a
simplistic approach to project planning and control. Interestingly, it
seems that organizations with the simplistic approaches are more able to
adapt to CCPM. (Some argue that any degree of discipline would have
helped as much. I dispute that claim because these are all highly multitasked environments, and conventional project management would only
exacerbate that problem.) It is not unusual to find people whose idea of a
project plan is a Gantt chart with no task logic, and only a final due date
demanded by someone outside the project organization. In a few months,


Critical Chain Project Management

it is possible to lead those people to have effective critical chain project
plans, buffer management, and a growing sense of success.
On the other hand, I have worked with organizations that have very
detailed project plans (with thousands of activities) that, after six months,
are still unable to resource-load their plans. In one case, the organization
neglected to address the fact that the parts of the organization necessary
to develop the complete project reported (collectively) to 13 different vice
presidents in the organization, 12 of whom were not bought in to the
changes necessary to implement CCPM. Guess which VP was replaced
three months into the process. I think you can predict the result.

Policies, measures, and behavior

It is often useful to explicitly consider the impacts that policies and measures have on behavior and how that behavior affects current reality.
Policies and measures are often the constraint of systems like project
management. For example, entity 4 of the CRT, “Most companies judge
project resource performance based on delivery of full scope within cost
and time estimates” may be reflected by performance appraisal policies
and measures. Very often, companies have efficiency measures and policies that reinforce multitasking. You should consider your company’s
policies that may reinforce the generic CRT.

Feedback loops

The detailed CRT logic contains feedback loops. For example, Figure 11.1
illustrated UDEs 1, 2, and 3 feeding into entity 9 at the base of the CRT.
That circular nature of real systems bothers some people, who think in
terms of cause-effect reasoning and want to know, “Which comes first,
the chicken or the egg?” In the real world of dynamic systems, it is an
ongoing circular pattern that evolves over time. That is one reason that
people looking for root cause often get the wrong answer; the cause is the
overall structure of the system, not an individual entity. All variables in
the system change in a correlated way (although often with time delays).
The feedback loops are often where you can find the most leverage to
change the system and thus are worth considering explicitly. Your
measurement systems almost always constitute a feedback loop (if they
do not, why are you making the measurement?). The primary feedback
key to CCPM is management’s reaction to task performance relative to

The TOC thinking process applied to project management


estimated 50-50 durations. Management’s response to buffer reporting is
also critical.



Scrutiny critically reviews the products of the thinking process. It is the
primary way to determine if the hypothesis of the thinking process
connects with reality better than alternative processes. (The secondary
method is the tried-and-true method of scientific experimentation, something that is difficult to do with systems as complex as projects.) Chapter 2
described how, using the scientific method known as the TOC theory of
knowledge, you can never prove the truth of any assertion or hypothesis.
The best you can hope to do is, through critical review, assure yourself
that one hypothesis describes reality better than another.
Scrutiny provides the thinking process critical review. You do it by
subjecting each product of the thinking process to the categories of
legitimate reservation. I learned these categories from the partners and
associates at AGI, but I suspect they have some prior source in logic.
Unfortunately, Dr. Goldratt does not use references in his books, and AGI
does not reference the source of much of their material. Dettmer [7] is the
only source I am aware of who has published these categories, but he
refers to AGI as the source.
The categories of legitimate reservation are these:
◗ Clarity. Does everyone understand the meaning of the words in the

◗ Entity existence. Is there evidence to support or refute the existence of

the entity in reality?
◗ Causality existence. Is there evidence to support the claim of causal-

ity? (This evidence is usually of the form that the effect always exists
when the cause is present and never exists when the cause is not
◗ Cause insufficiency. Do other entities also have to be present to cause

the stated effect?
◗ Additional cause. Can the effect exist without the stated causes but

instead in the presence of other causes? (The good enough TOC


Critical Chain Project Management

principle suggests you limit your model to causes that represent at
least one-third of the effect instances.)
◗ “House on fire” (or cause-effect reversal). “If there is smoke, then there

is fire” is a common expression that does not reflect causality, even
though it is expressed as “If-then.” The accurate statement is, “If
I see smoke, then I know that the house is on fire.” The smoke,
however, does not cause the house to be on fire.
◗ Predicted effect. Would the existence of the entity also cause some

other effect? Does that other effect exist in reality?
◗ Tautology. Ayn Rand’s famous “A is A.” Or, as the story goes,

Joe: “Blowing a horn every day keeps elephants out of my living
Dan: “How do you know that?”
Joe: “Do you see any elephants in my living room?”
Detecting the logic error is sometimes hard. How many people call
those psychic hotlines?
Jonahs subject each thinking process tree to critical review for compliance with those criteria. If you think getting people to think through
the trees is difficult, try going through the review process on each entity
and causality in the tree. Most people find it agonizing. Unfortunately,
there does not appear to be a better alternative.


The people who will deploy the results of the thinking process have to
agree with it to the extent that they are willing to make or tolerate
(depending on their location and effect on the system) the changes it
requires to move to future reality. Unfortunately, experience demonstrates that logic rarely influences people’s beliefs. As Chapter 9 described,
if you do not change beliefs, you are unlikely to succeed in changing
behavior for the long term. You may cause a temporary effect, but the
system will, over time, swing back to where it was before you started.
Buy-in seeks to achieve sufficient agreement to make the injections
necessary for future reality. You will not achieve complete changes in
belief at the outset, but if the future reality contains sufficient positive
feedback to meet the real needs of the people who influence the system,

The TOC thinking process applied to project management


the feedback will take over driving the system. You can achieve that with
some people by leading them through the thinking process. Experience,
however, demonstrates that it is the rare senior manager who will focus
long enough to follow that through. Thus, you will need to use specially
designed tools, presentations, and dialog to reach those people.
I have found that most people intuitively appreciate the logic and use
of the evaporating cloud. You can even get senior managers to listen to
the three clouds that lead to CCPM and to buy into the core conflict and
then to the necessary injections.
A powerful method to enhance buy-in is to first solicit the UDEs of
those you need to agree and include one or two of their UDEs into your
CRT. Demonstrating how the system causes their UDEs usually succeeds
in bringing about buy-in, not only to the CRT but also to the injections
you propose to create future reality.


Future reality tree

The FRT describes what to change to. It is your vision of the future. Future
reality does not exist when you start to make the changes to eliminate the
UDEs of current reality. The outputs of the FRT are the injections we have
to create for future reality to exist. Injections are effects that, if in place,
will cause future reality. Injections are not (generally) actions; you
develop actions as part of how to cause the change.

Desired effects

Start the FRT by changing each UDE into its opposite desired effect (DE).
Figure 11.2 illustrates the map of DEs for a successful project management system, including an indication of where the injections tie in.


Injections are the changes you will make to the system. The FRT connects
your injections to the desired effects of future reality. You then methodically work through the tree, determining where injections are necessary
to create the future reality. Developing effective injections is the most
creative stage of the thinking process. Experienced TOC experts like to
word injections as completed effects, knowing that they will often have


Critical Chain Project Management

Project work creates
win-win solutions for all

All projects complete

Projects have few
Projects complete
for or less than
the budget

Projects always
deliver the full scope

Projects always
complete on or
before the scheduled
completion date

Project durations get
shorter and shorter

Resource has needed
resources without
internal fights

Figure 11.2
the FRT.

The DE map illustrates the relationship of the DEs in

to develop a number of actions to achieve the injections. Collectively, the
injections will create a future reality in which all the DEs exist.