Tải bản đầy đủ
3 Success with critical chain 23

3 Success with critical chain 23

Tải bản đầy đủ

24

Critical Chain Project Management



Multiple project durations reduced by larger amounts;



Project changes reduced;



Early returns for commercial projects;



Reduced payback periods for investment projects.

◗ Increased project team satisfaction:


Reduced confusion from multitasking;



Ability to focus on one task at a time;



Reduced changes;



Reduced rework;



Reduced pressure from multiple project managers;



Win-lose task completion (date-driven task pressure) eliminated;



Buffer reporting used by individuals to decide task priority;



Reduced insertion of new priority tasks.

◗ Simplified project measurement:


Quick and easy plan status;



Real-time project status; no need to wait for financial reports;



Immediate focus by buffer, chain, and task provided by status;



Decisions defined by buffer report;



Focus of buffer reporting on management priority decisions
(reflected in the buffers by staggering project start).

◗ Simplified project management:


Clear focus for project manager (critical chain, reduced early
start);



Simplified project plans reduce paperwork;



Simplified project status reporting;



Whether to plan or act decided by measurement;



Resource priorities decided by measurement.

Begin at the beginning

25

◗ Increased project throughput with same resource:


Reduced resource demand conflicts;



More projects completed faster for the same level of resources;



Less need to hire new critical resources;



Less delay due to resources;



Improved project cash flow;



Improved ROI.

Evidence of other users often gives people confidence to try new
ideas. The present CPM project paradigm has been in force for over
40 years, making change hard for many people to accept. More and more
companies, small and large, are demonstrating success with CCPM.
Several examples illustrate that success. (As will be discussed later, these
success examples do not “prove” the new theory; they only provide
confidence that it is not fatally flawed.)
◗ Honeywell Defense Avionic Systems (DAS) is experimenting with critical

chain. A recent internal article noted the following for a project they
named RNLAF. “The RNLAF team was asked by the customer to
deliver something we originally scheduled to take 13 months
to deliver—and the team did it in six months … The team is experimenting with a new way of scheduling the program using critical
chain concepts. Boeing has read the book, and is supporting the
concept.” [13]
◗ Lucent Technologies. Lucent Technologies has adopted CCPM as

their primary tool for project management. (The author provides
Lucent training and implementation assistance.) “In 1996, Lucent
Technologies Advanced Technology Systems, now part of General
Dynamics, was told by a sister organization that the yearlong
project being considered was an impossibility … The project was
used as a pilot effort, to evaluate TOC project management. The
project was completed in June, 1997, with buffer to spare.” [14]
◗ Harris. Harris recently decided to use CCPM to build a new eight-

inch semiconductor wafer plant. The largest previous wafer was
6 inches in diameter. Total investment for a plant that size is in the

26

Critical Chain Project Management

range of $250 million, and revenue for such a plant is in the range of
$2 million per day! (Raw material cost is very small.) The industry
standard to build a 6-inch plant was 30 months up to the time the
equipment was qualified, that is, no production quantities. The
industry standard to get the plant up and running to 90% of capacity is about 46 months. The plant was recently completed and up to
90% production in 13 months. Harris presented their results at a
recent conference hosted by the Avraham Y. Goldratt Institute. See
their Internet page [15].
◗ Israeli aircraft industry. The Israeli aircraft industry employs about

15,000 people. A major function is to maintain jumbo jets used in
passenger service. A particular type of maintenance, type D maintenance, normally takes 46 days in the industry. The penalty for
nonperformance to schedule is steep—$60,000 per day—because
the airlines need the planes back into scheduled service. The
company had been paying up to $25 million per year in penalties.
A letter from the manager to Dr. Goldratt noted that “we succeeded
to drop our average turn around time per aircraft visit from three
months to two weeks and to increase our backlog from two months
to one year” [16].
◗ BOS. According to Izzy Gal, president of Better Online Solutions

(BOS), “A project was originally planned to be released to the
market in August 1997 (there is no reason to believe that it would
have been on time—but who knows?). The TOC scheduling cut
four months from this timetable—so it was planned to be ready on
May 1, 1997. It was finished in [the] beginning of April, 1997,
almost a month before the corrected time. Almost five months
before the original time.” [17]

1.4

Summary

This chapter defined the problem that this book aims to resolve and
identified critical chain project management (CCPM) as a new theory
(hypothesis) to resolve the problem. Key points are:
◗ Projects success rate using the existing critical path paradigm is poor

for all types of projects in all types of cultures.

Begin at the beginning

27

◗ Hypothesized causes of project failure do not address the project

management system as the potential cause, most often leading to
remedies of working harder with the old system. That does not
seem to be the right problem.
◗ Evidence suggests that the right problem is in the design of the proj-

ect system itself; specifically, the system fails to properly manage
the reality of uncertainty.
◗ The right solution requires a project system that has a much higher

success rate and that is simple to use.
◗ A growing body of evidence does not contradict the hypothesis that

Goldratt’s critical chain method satisfies the necessary conditions
for project success.
Comparing the results of applying the critical chain theory to
the existing theory (i.e., the critical path theory as described in the
PMBOK) provides support for using the critical chain theory while we
continue to critically review and improve it.

References
[1]

Duncan, W. R., et. al., A Guide to the Project Management Body of Knowledge,
Upper Darby, PA: Project Management Institute, 1996.

[2]

Goldratt, E. M., The Goal, Great Barrington, MA: North River Press, 1984.

[3]

Popper, K. R., Objective Knowledge: An Evolutionary Approach, Oxford:
Clarendon Press, 1997, p. 144.

[4]

GAO/T-RCED-97-92, “Department of Energy: Improving Management of
Major System Acquisitions,” Testimony, March 6, 1997 .

[5]

GAO/T-NSIAD-97-262, “Space Station: Deteriorating Cost and Schedule
Performance Under the Prime Contract,” Testimony, Sept. 18, 1997.

[6]

Lewis, J. P., The Project Manager’s Desk Reference, Chicago: Irwin, 1995, p. 245.

[7]

Bromilow, F. J., “Measurement of Scheduling of Construction Time and Cost
Performance in the Building Industry,” The Chartered Builder, Vol. 10, 1974.

[8]

Chun, D. W. M., and M. M. Kummaraswamy, “A Comparative Study of
Causes of Time Overruns in Hong Kong Construction Projects,
S)263-7863(96)0039-7, Inter. J. Project Management, Vol. 15, No. 1, Feb.,
1997.

28

Critical Chain Project Management

[9] Leopold, A., Game Management, University of Wisconsin Press, 1933.
[10] Goldratt, E. M., Critical Chain, Great Barrington, MA: North River Press,
1997.
[11] Lambert, L. R., “Cost/Schedule Control Criteria (C/SCSC): An Integrated
Project Management Approach Using Earned Value Techniques,” The AMA
Handbook of Project Management, New York: AMACOM, 1993.
[12] Kahneman, D., P. Dlovic, and A. Tvershky, Judgment Under Uncertainty:
Heuristics and Biases, Cambridge: Cambridge University Press, 1982.
[13] Goldratt, E., “My Saga to Improve Production,” New Haven, CT: Avraham Y.
Goldratt Institute, 1994.
[14] “RNLAF Team Seeks Improvement,” Horizons, Albuquerque, New Mexico:
Honeywell Defense Avonics Systems, Vol. 5, No. 2, Feb. 20, 1998.
[15] Rizzo, A., “The TOC Solution of R&D and Multi-Projects Organizations,”
Whippany, NJ: Lucent Technologies, January 5, 1998.
[16] http//www.tp.semi.harris.com/raptor.html.
[17] http//www.Goldratt.com (Internet site for Avraham Y. Goldratt Institute).

CHAPTER

2
Contents
2.1

PMBOK

2.2

TQM

2.3

TOC

2.4

Summary

The synthesis of
TQM, TOC, and
PMBOK

References

T

his book approaches the problem of
improving project management from
the perspective of synthesizing three areas of
knowledge: PMBOK, total quality management (TQM), and the theory of constraints
(TOC). These three knowledge areas provide
different reality filters, or paradigms, for
understanding the project system. Three
perspectives enable deeper understanding of
the theory underlying CCPM. The underlying
theory enables you to deal with issues unique
to your environment or project.
Figure 2.1 illustrates how the three perspectives on the project system might look
at problems in project performance. The
PMBOK perspective compares actual project system performance to the PMBOK
model, which it assumes is correct. Therefore,
the PMBOK perspective is unlikely to
blame the PMBOK project system as the
cause of the problems. It is much more likely

29

30

Critical Chain Project Management

Project
management
body of
knowledge

Total quality
management

System
Psychology
Variation
Theory of knowledge

System definition
Knowledge areas
Framework
Processes
Project system

System
Focusing steps
Thinking process
Layers of resistance

Theory of
constraints

Figure 2.1 Three knowledge areas increase perspective on the
project system.

to blame performance problems on failure to properly execute the
(assumed) effective system. That is indeed the nature of much of the project management literature. Dr. W. Edwards Deming noted that we should
not expect significant system changes to come from within the system. A
natural consequence of solutions based on the PMBOK perspective is
to “do more better.”
The TQM perspective continually improves every process. It therefore tacitly assumes that the best way to improve a system is to improve
every process. A leading consideration in TQM (profound knowledge)
provides four subperspectives that lead to deeper understanding of the
potential causes of project problems. TQM provides specific tools to perform root cause analysis to identify the causes of problems and develops
strategies to remove those causes.
The TOC perspective identifies the system constraint and works to
improve its throughput. It provides a system view of projects and a
specific theory to predict project performance and the impact of changes
to the system. The TOC perspective differs from the PMBOK view by

The synthesis of TQM, TOC, and PMBOK

31

considering the project system as a dynamic process to create completed
projects. TOC looks at individual project tasks as the operation of a system
for producing the result or output of the tasks. It focuses on the fact that
the task performance process includes natural variation and that the
individual project tasks are interrelated.

2.1

PMBOK

Project management made a great leap forward in the 1950s and 1960s
with the advent of the CPM and the Program Evaluation and Review
Technique (PERT). PERT was developed in 1958 as a joint effort between
the United States Navy and the Booz, Allen, Hamilton consulting firm for
the Polaris submarine project. The method was enabled by the innovation
of computers and was successful in managing the Apollo project to put
people on the moon and many large defense projects.
Personal computers have brought sophisticated computer scheduling
techniques to everyone’s desk. CSCSs have increased the complexity of
these systems. However, there has been little progress in improving the
success rate of projects and even less innovation in the underlying basis
and system. People continue to work with project management assumptions conceived 40 years ago.
Figure 2.2 illustrates the related knowledge areas identified in the
PMBOK Guide. This text focuses on and proposes changes to the project
management knowledge elements to affect the necessary conditions for
project success: project integration management, project scope management, project time management, and project risk management. You must
address the other knowledge areas to varying degrees, depending on your
projects and the environment in which you work.
The PMBOK Guide describes general processes for each knowledge
area, collected into five types of processes:
◗ Initiating;
◗ Planning;
◗ Controlling;
◗ Executing;
◗ Closing.

32

Critical Chain Project Management

Project
management

*Critical chain impacts
*shaded blocks.

1
Integration

2
Scope

3
Time

4
Cost

5
Quality

6
Human resources

7
Communications

8
Risk

9
Procurement

Figure 2.2

PMBOK areas identify the project system.

These process phases roughly correspond to the phases of a project,
but there is considerable overlap. The PMBOKTM Guide emphasizes that
there are relationships and interactions between most of the project
system processes.
Perhaps the most important element of successful projects is the project team. An able leader and an effective team can achieve project success
despite a flawed system. A weak team or leader will struggle with
even an excellent system. While the human side of project management
is extremely important to project success, it is not a specific topic of
this book.
2.1.1

Project integration management

Project integration management includes project plan development and
execution and overall change control through the life of the project.
2.1.2

Project scope management

Project scope management includes the process leading to initiation of
the project and scope planning, definition, verification, and change
control. Primary outputs of the scope management processes include a
project charter, the project work breakdown structure (WBS), detailed

The synthesis of TQM, TOC, and PMBOK

33

statements of work (SOWs), functional and operational requirements
(F&OR) or other definitions of the deliverable scope, the project assumptions, and a process for scope change control.
Project assumptions help planners develop a deterministic project
plan. The plan and control processes defined by the PMBOK do not
include a way to handle decision branches in a project plan. Assumptions
define uncertainty sufficiently to permit defining a deterministic scope,
cost, and schedule. For example, some of the research projects I have
worked on required unprecedented performance of technical parts. If the
parts succeeded in delivering the specified performance, we would follow
the path of building the units for installation in a larger system (in this
case, a nuclear reactor). If the part did not perform as specified, we had to
modify the design and test again. Yet I could have only one project plan. I
usually assumed we got it right the first time, even though I knew we
would not always succeed. That permitted building a plan and a cost
estimate. I then addressed the potential of failure to succeed as part of
the project risk management.

2.1.3

Project time management

Project time management includes defining the activities necessary to
produce the project scope, sequencing the activities, estimating activity
duration, developing the project schedule, and controlling the project to
the schedule. Schedule preparation requires the WBS and scope statements as inputs. The schedule development process identifies the activity
resource requirements and other potential project constraints. The guide
also discusses the need to level resources in the plan, that is, to adjust the
planned resource demand of the plan to match the expected resource
supply.
The PMBOK Guide notes that activity duration estimates should
specify uncertainty and refers the reader to discussions on project
risk management to handle that uncertainty. It does not differentiate
between common cause variation and special cause variation. Thus, it
includes all potential variation into the single category of project schedule
risk management.
The PMBOK Guide addresses cost management as a separate topic
from time management, but the processes are identical. The schedule and
cost control process includes updating the schedule and completng the

34

Critical Chain Project Management

project estimate, planning and executing corrective action, and assessing
the lessons learned at the close of the project.
2.1.4

Project risk management

Project risk management includes identifying and quantifying risks and
planning and controlling response to risk. Risk includes both the likelihood and the consequences of adverse impacts to the project. The
PMBOK Guide does not distinguish between common cause and
special cause variation but appears to lump them together in the performance of risk management.

2.1.5

Other PMBOK areas

The other PMBOK knowledge areas, including quality, human
resources, communications, and procurement management, are all
important to projects. They are important to any type of business. The
scope of this text does not explore those areas.

2.2

TQM

The popular literature may lead you to believe that TQM was a management fad that failed to deliver on its promise and had outrun its applicability by the end of the century. Nothing could be further from the truth. At
the February 1999 award ceremony in Washington, D.C., President
Clinton noted that previous winners of the national Malcolm Baldrige
quality award from 1988–1997 posted an impressive 460% return on
investment, compared to a 175% increase for the S&P 500 over the same
period. Hendricks and Singhal published results in April 1999 demonstrating performance measures for TQM award-winning firms outstripping comparison control firms by two to one [1]. For example, the TQM
firms posted a 91% (vs. 43% for non-TQM firms) increase in operating
income, a 69% (vs. 32%) increase in sales, and a 79% (vs. 37%) increase
in total assets.
Dr. W. Edwards Deming, the man most people consider the father of
TQM, never defined TQM. Deming described his approach in seminars
and books [2,3], and though a great advocate of operational definitions,
he chose to never offer one for TQM. Instead, he preferred to discuss the