Tải bản đầy đủ
5 Determining what to change to 97

5 Determining what to change to 97

Tải bản đầy đủ

98

Critical Chain Project Management
◗ Projects complete within or for less than the budget;
◗ Projects always deliver the full scope;
◗ Projects have few changes;
◗ Projects have needed resources without internal fights;
◗ Project durations get shorter and shorter;
◗ All projects complete;
◗ Project work creates win-win solutions for all stakeholders.

The changes to resolve the core conflict provide a method to manage
uncertainty and acknowledge the reality of the resource constraint that
affects many projects. The changes by themselves are not sufficient to
create all those desired effects. While the solution to the core conflict
explicitly considers the project system and addresses variation, it does not
address all the psychological elements that affect project performance.
Subsequent chapters provide the complete solution leading to all these
desired effects, and Chapter 11 provides the complete logical development of the full solution.

3.6

Summary

This chapter identified the core conflict for project management system improvement as the way the project system manages uncertainty.
Specific points made in developing that theory are:
◗ Undesired effects define the problem with the present project

management theory.
◗ The core conflict for the current project management system is the

conflict between protecting each task duration in the project versus
protecting the entire project.
◗ The project system solution (new theory) must overcome the core

conflict of the existing project system by attacking a key assumption
in present systems: how to manage uncertainty.

The direction of the solution

99

◗ A method to manage uncertainty using ideas similar to those that

succeeded in improving production performance may provide a
direction for the solution.
◗ The direction of the solution should be to manage uncertainty by

concentrating contingency into buffers at the end of chains of tasks.
◗ Because the resource constraint is equal to the task logic constraint,

the longest path through the project, the critical chain, should
include both.
◗ A growing body of empirical evidence demonstrates the feasibility

of the critical chain project management method for all types of
projects.
Note that managing uncertainty is not the same as knowing about
uncertainty or analyzing uncertainty. People knew about uncertainty
long before projects began. There are many methods to analyze uncertainty. Both knowledge and analysis are necessary to manage, but they
are not sufficient. You are managing only when you take actions that
drive the system to the goal. Chapter 4 derives the full system to do that.

References
[1]

Marris, P., The Politics of Uncertainty, London: Routledge, 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]

Goldratt, E. M., Theory of Constraints, Great Barrington, MA: North River
Press, 1994.

CHAPTER

4
Contents
4.1 From system
requirements to
system design

The complete single-project solution

The complete singleproject solution

4.2 Developing the
critical chain solution
4.3 Exploiting the
plan using buffer
management
4.4 Features (more or
less) from PMBOK
4.5

Summary

References

T

his chapter describes the process to
develop the single-project management
system to satisfy the system requirements
identified in the previous chapters and further defined herein. Although presented as a
forward moving process from requirements
to design, the actual process, as in nearly all
designs, was iterative. That is, various design
solutions were proposed and tested against
the requirements until a suitable working
system resulted.

4.1 From system
requirements to
system design
4.1.1

Requirements matrix

Table 4.1 illustrates the requirements for an
effective project management system, following the method of Joseph Juran [1]. Table 4.1
presents the requirements in a hierarchy,

101

102

Critical Chain Project Management
Table 4.1(a)

Overall Requirements for a Project System to Convert the Input of a
Project Result Specification and Produce an Output of a Completed
Project Result
Primary
Requirement

Secondary Requirement

Tertiary Requirements

Define the
project system

Project system goal

Define the project system goal to
complete projects that make money for
the company, now and in the future (for
profit companies)



Project system boundary

Define the project system boundary
starting with customer needs and ending
with a satisfied customer



Account for understanding
of variation

1. Account for common cause variation in
1. project processes
2. Provide a means to separate and deal
1. with special cause variation



Use TOC to design the
system

1. Identify the project constraint
2. Exploit the project system constraint
3. Subordinate everything else



Include knowledge of
psychology in the system
design

1. Align project system needs with
1. individual psychological needs
2. Align individual rewards with project
1. system needs



Enable continuous
improvement of the project
system (a theory of
knowledge)

1. Define and standardize processes
2. Measure process performance
3. Assess process performance
4. Improve processes

starting with the top-level necessary conditions for project performance.
These conditions include the three technical requirements for the project
(scope, cost, and schedule) and the requirement for stakeholder satisfaction. The table is segmented to make it easier to read and understand: the
first segment provides general system requirements, the second segment
provides project necessary condition requirements, and the third section
provides stakeholder requirements. Project stakeholders always include
at least the project customer and the project team and may include many
others, for example, subcontractors, stockholders, regulators, neighbors,
or government. The second and third columns of the table illustrate the
second- and third-level requirements derived from the top-level requirements. Requirements at the lower levels may vary for different types of
projects; these are general requirements.