Tải bản đầy đủ
1 From system requirements to system design 101

1 From system requirements to system design 101

Tải bản đầy đủ


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

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

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

Include knowledge of
psychology in the system

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

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.

The complete single-project solution


Table 4.1(b)

Necessary Conditions 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

Deliver the project result
to the specification

Deliver all of the specified

1. Satisfy all the physical
1. requirements for the specified
1. features
2. Satisfy all the functional
1. requirements for the specified
1 .features
3. Satisfy all the operational
1 .requirements for the specified
1. features

Satisfy all the feature
quality requirements

Satisfy all the feature quality

Deliver the project result
on time (schedule)

Deliver the project result
on time (schedule)

Complete the project on the
quoted completion date

Complete intermediate
milestones on the quoted
completion dates

Deliver the project result
for the estimated cost

Total cost

1. Complete the entire project for
1. the quoted maximum cost
2. Do not spend more than
1. specified maximums on
1. subcategories of the total cost

Satisfy project cash flow

Do not exceed project estimated
cash flow requirements

It is unlikely that you would generate an identical list of project
requirements. The lists in Table 4.1 include elements of the PMBOK
elements from my own experience and elements specifically derived
from the solution we are about to present. This feedback of the solution to
the requirements is part of reality. Only by defining and critically assessing a proposed solution do we really understand the problem. In particular, before Goldratt and considering the basis of critical chain, I would not
have included accounting for common cause variation among project
requirements. Instead, I would have combined it with project risk management, as PMBOK does.
The table of project requirements is not—and never can be—complete. It is a conjecture, a basis for criticism and improvement. For
example, I am not satisfied that the requirements completely embrace
profound knowledge, especially a knowledge of psychology. I present it


Critical Chain Project Management
Table 4.1(c)

Stakeholder 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


Tertiary Requirements

Satisfy unique individual project
stakeholder needs, in addition to
those listed in (a) and (b)

Project client

1. Solicit and specify all
1. requirements necessary to
1. deliver a satisfactory final product
2. Provide evidence of meeting the
1 .project specifications
3. Provide information during the
1. project to enable decisions that
1. may affect the balance of the
1. project
4. Respond to requests for changes

Project team

1. Clear scope definition
2. Clear responsibility and authority
1. assignment
3. Project plan specifying who has to
1. do what by when
4. Feedback to control performance
1. to plan
5. Method to control interfaces with
1. other team members
6. Method to raise and resolve
1. issues during project
1. performance
7. Change control process

as a good enough set of requirements to bind together CCPM and start us
on a new path of project system improvement to address the difficulties
raised in Chapter 1.

Summary of single-project critical chain

Figure 4.1 illustrates the key features of the single-project critical chain
solution that satisfy the functional requirements for the project system.
The illustrated features highlight the differences between CCPM and critical path planning and management. Those essential features are:
◗ Defining the critical chain as the longest path through the project

considering both the task logic and the resource constraint;

The complete single-project solution


2. Resource conflicts removed
1. Reduced task times









3. Critical chain
5. Resource buffers



8. Buffer


4. Project buffer

7.‘Late’ start
6. Feeding buffer

Figure 4.1 Key features of the critical chain solution deliver
performance to the project system requirements.

◗ Removing resource contention from the project plan before select-

ing the critical chain;
◗ Developing the plan with 50-50 task estimates, aggregating uncer-

tainty into the buffers at the end of task chains (buffer illustrated as
a shock absorber);
◗ Protecting merging paths with feeding buffers (while continuing

the elimination of resource conflicts);
◗ Adding resource buffers to ensure that critical chain resources are

available when needed;
◗ Using the project and feeding buffers as measures to control project

The next section describes each of those features in greater detail.
Four essential behavior changes are required to use CCPM effectively:
◗ Management must encourage the use of 50-50 task times by not

pressuring people to perform to 50-50 estimated durations.
◗ Management must enable people to focus on one task at a time.


Critical Chain Project Management
◗ Resources must focus on one task at a time and pass on the results as

soon as the task is complete (roadrunner behavior).
◗ Everyone must use the plan and the buffer reports to decide what to

work on next.
Although those behavior changes are simple, they are not necessarily
easy to implement. (Chapter 9 covers implementation.)


Developing the critical chain solution

This section describes the single-project critical chain features in terms of
the TOC focusing steps (described in Section 2.3.3).


Identifying the project constraint

Defining the constraint of a project in terms of the schedule derives from
the impact that schedule has on project cost and project scope. Independent variables that influence a project result include the demanded
scope, the project system definition, and the resources available to work
on the project. The project system outputs are dependent variables (delivered scope, cost, and schedule). As schedule increases with fixed deliverable scope, cost usually increases. As scope increases with fixed cost (or
resources), schedule tends to increase. As scope increases with fixed
schedule, cost tends to increase. Therefore, it is appropriate to focus first
on delivering the project on time.
The evident constraint of a project is the chain of tasks that takes the
longest to complete. To perform any task on a project, two things are necessary: the task input from a predecessor and the resource to perform the
task. (The predecessor may simply be a start authorization for the first task
in a chain of project tasks.) The definition of the critical path does
not explicitly address the potential resource constraint. Section 3.3.2
described why the critical chain is the single-project constraint. The critical chain is simply “the sequence of dependent events that prevents the
project from completing in a shorter interval. Resource dependencies
determine the critical chain as much as do task dependencies.”
Figure 4.2 illustrates a typical critical path project schedule. The letters
represent unique resources. For this illustration, assume there is only one

The complete single-project solution


Critical path









Figure 4.2

The critical path does not account for the resource

resource corresponding to each letter, that is, only one A resource, only
one B resource, and so on. Evidently, we would fail to meet the schedule
on the project, because each resource can do only one task at a time.
Figure 4.3 moves tasks to eliminate the overlap of resource demands.
In a manner similar to many computer algorithms for resource leveling,
we first give the resource to the path with least float; usually with the initial critical path. Note that when we are done, all paths have float, so there
is no critical path defined as the path with zero float. (Computer software
packages treat that result differently. Some keep the initial critical path
definition. Some define only the last task as critical. I have no idea what
they do about the critical path as the project progresses and the critical
path is supposed to change.)
More importantly, the initial critical path is not the constraint to
completing the project. Because the resource constraint is often a significant project constraint, the TOC method of project planning always
considers it (Figure 4.4).
If your organization does not have resource constraints (or has
infinite resources), the critical chain will be the same initial task path as
the critical path. That is an important fact in verifying the integrity of the
critical chain method; it contains the critical path method as a special case,
at least in regard to defining the critical chain.