Tải bản đầy đủ
6 Change control actions 214

6 Change control actions 214

Tải bản đầy đủ

Measurement and control


◗ Overrun or underrun of a task estimated duration is not a change.
◗ Overrun or underrun of a task estimated cost is not a change.
◗ Project, feeding, and cost buffer action triggers may cause plan

changes to recover.
Your change control process should operate fast. You may have a
change control board, including your customer when appropriate, to
expedite change approval.
Keep in mind that you should focus on managing the project to the
plan, not on managing the plan. Do not, for example, make changes to
your buffers based on actual performance to date.



CCPM uses progress along the critical chain and buffer reporting as the
primary real-time predictive measurement tool. Consider clients and
project team members as customers of your project reporting and control
system. Buffer reporting has to be timely to be effective; you should status
and report buffers at least weekly and ensure that the information is
available to users within a day.
◗ Weekly project and feeding buffer monitoring and reporting pro-

vides a proactive real-time decision tool for project control.
◗ The resource buffer is a two-way communication device between

the project and resource managers to ensure resource availability
on the critical chain.
◗ Resources and resource managers use the buffer report for dynamic

resource assignment decisions.
◗ If cost is important, use the cost buffer to measure and control.
◗ Buffer management minimizes the negative impacts of excessive

project changes using buffer trends and triggers related to statistical
process control.
◗ Conventional project change control methods are necessary to

handle scope changes and impacts of special cause variation.


Critical Chain Project Management

CCPM users have found implementation of buffer management to be
relatively simple and very effective.


Goldratt, E. M., The Haystack Syndrome, Croton-on Hudson, New York: North
River Press, 1990.


Juran, J. J., Juran on Planning for Quality, New York: Free Press, 1988.


Shewhart, W. A., Statistical Method from the Viewpoint of Quality Control, New
York: Dover Publications, 1986 (originally published in 1939).


Ireland, L. R., Quality Management for Projects and Programs, Upper Darby, PA:
PMI, 1991.


9.1 Implementation

Vision of the end

the change to
critical chain

9.3 Implementation
9.4 Goldratt’s
resistance model
9.5 To pilot or not to

Plan the change


Move ahead!

9.8 Measure and
control implementation
9.9 What if
progress stalls?




any companies that have never introduced change into their organization
successfully implement CCPM in a short
period of time. These successful companies
require less than three months to get all projects planned and synchronized and to begin
to see the benefits of improved project performance and reduced stress on project
teams. Success stories include all types of
projects and a wide range of organization size.
People report significant success implementing CCPM for single projects after having read an earlier version of this book
or having attended a two-day introductory
training class. Unfortunately, some organizations that claim to have attempted critical
chain for one stated reason or another gave it
up. That has happened on both single projects
and in multiple-project organizations. The



Critical Chain Project Management

following presents a process proven to work in both single-project and
multiproject organizations.


Implementation model

Figure 9.1 illustrates the basic project model to implement CCPM. Implementation is a project. The end vision requires operating to the critical chain paradigm. Implementation plans vary in content and scope
depending on the specific organization. For example, a single-project
implementation usually involves only the direct project team and usually
can be accomplished by the leadership of the project manager. Multipleproject implementation can be much more involved, requiring the active
support of all involved project teams and resources.
The first three steps of implementation are the same for all projects:
You have to charter the implementation project, gain endorsement of the
project stakeholders, and prepare the project work plan. Stakeholder
endorsement is the most important part of an implementation project.
People approach process change with caution. The record of successful change is not good. Dalziel and Schoonover noted, “Technocratic leaders … focus exclusively on outcomes without considering the concerns of
employees who must implement and sustain change” [1]. Many project managers (myself included) are technocratic leaders and therefore
subject to that blind spot. Dalziel and Schoonover go on to note that “this
perspective frequently results in short-term gains, unforeseen pitfalls,
and long-term resentments.”
The technical aspects of CCPM are not challenging to any organization that has basic project management capability. Many organizations



Prepare project

Measure and
control project to
buffer report

Figure 9.1



Perform project



Implementation process flowchart.



Implementing the change to critical chain


with rudimentary project management capability have been able to use
critical chain implementation as the focus to improve overall project
success. CCPM is not so much an advanced project management method
as it is a different—and better—method.
CCPM is a management system change. Implementation must
address all aspects of the system. Figure 9.2 illustrates the so-called
seven-S (strategy, systems, staff, style, skills, structure, and shared vision
and values) model (which I understand was developed by McKinzie, but
which has been modified by many authors since). Dr. Stephen Covey
modifies the model to further emphasize the people part of it and calls it
the PS paradigm [2] (the P stands for people). These models provide a
system definition for change.
Consider the seven-S model for your organization as you plan
implementing critical chain. You mostly must make sure that your
change plan does not overlook some facts about your organization that
may block implementation or cause unintended consequences. There is
no reason to change the structure of your organization to implement
CCPM. Organizations ranging from full project to full matrix have successfully implemented CCPM.
The seven-S model is incomplete (deliberately so, as with all models). Deming emphasized the need for managers to consider elements
normally considered outside the business system, such as customers,
suppliers, and even competitors. Further, the seven-S model is static. All



Shared vision
and values




Figure 9.2 The seven-S model provides a system definition for
change planning.


Critical Chain Project Management

business organizations are complex, dynamic, and adaptive systems. That
means they are constantly changing. Management’s problem is to lead
the changes that will happen in a positive direction.
The process to achieve any goal requires effective feedback mechanisms to adjust actual performance to plan. Box 5 in Figure 9.1 shows
measurement and control. Buffer management works to determine if you
are accomplishing the implementation project relative to schedule, as in
any project. Also, as in any project, you need quality results measurements to ensure that the result achieved and passed on from one task to
the next satisfies deliverable requirements. In this case, quality results
include some soft measures, such as how people are feeling about the
change to CCPM and some real dialog on challenges people are having
making it work.
Most organizations require behavior changes to implement CCPM.
Which changes your organization requires depend on what behaviors your organization currently exhibits. Table 9.1 summarizes typical
behaviors and the behaviors demanded by CCPM. Use the tables as
criteria to judge how you are doing.
Table 9.1(a)

Senior Management’s Behavior Changes

Current Behavior

Future Behavior

Committing only to
feasible delivery

Sometimes committing to
arbitrary delivery dates
determined without
consideration of system
capability to deliver

Committing only to delivery
dates with a critical chain plan
and (if multiple projects), after
sequencing through the drum


Inserting special requests into
the system with no assessment
of system capability to respond;
sometimes place demands for
routine administrative work
above project work (e.g., salary

Prioritizing all requests using
buffer report

Setting project priority
(only for multiple

Not setting clear project priority
or changing project priorities

Setting project priorities,
including the priority of new
projects relative to ongoing

Selecting drum
resource (only for
multiple projects)

Giving no consideration to
system constraint

Selecting the drum resource to
be used for sequencing the
start of projects and creating
the drum schedule

Implementing the change to critical chain


Table 9.1(a) (continued)

Current Behavior

Future Behavior

Selecting drum
manager and
approving project
sequencing (only for
multiple projects)

Starting each project
independently as funding is

Drum manager creating drum
schedule; senior management
approving; project managers
scheduling projects to the drum

Project status

Looking over shoulders

Buffer report

Table 9.1(b)

Resource Managers’ Behavior Changes

Current Behavior

Future Behavior

Setting resource

Assigning resources on a
first-come, first-served priority
or attempt to meet all needs by

Assigning resources using the
buffer report

Resource planning

Planning resources by name
and task

Planning resources by type and
assign to tasks as they come up
using the buffer report priority

Early completion

Turning in tasks on due date

Turning in tasks as soon as they
are complete


Ensuring resource efficiency by
assigning to multiple tasks at
the same time

Ensuring resource
effectiveness by eliminating
bad multitasking

Resource buffers

Resources planned far ahead
and not available when needed

Using resource buffers and
buffer report to dynamically
assign resources to tasks

Table 9.1(c)

Project Managers’ Behavior Changes

Current Behavior

Future Behavior

50% task duration

Project managers sending
message that they expect due
dates to be met

Project managers first getting
low-risk task duration and then
getting average duration; using
task uncertainty to size buffers

Date-driven to

Providing start and finish dates
for each task and monitoring
progress to finish dates

Providing start dates only for
chains of tasks and completion
date only on the project buffer

Feedback on task
duration overruns

Management providing
negative feedback when tasks
overrun due dates

Management providing
positive feedback and help if
resources perform to
roadrunner paradigm


Critical Chain Project Management
Table 9.1(c) (continued)


Current Behavior

Future Behavior

Project status

Varying; often using earned
value as the schedule measure

Buffer report (including a cost

Project changes

Varying; often submitted to
minimize minor variances

When triggered by buffer

Response to
management demands
for shorter schedule

Arbitrary task duration cuts

Adding resources or making
process changes to get a
feasible and immune schedule

Early start

Starting tasks as early as

Starting task chains as late as
possible, buffered by feeding

Sequence projects
(only for multiple

Starting project as soon as
funding is available

Scheduling project start using
drum schedule

Assigning resources
dynamically according
to critical chain priority
and buffer report

Getting resources as soon as
project funding is available and
holding resources until they
cannot possibly be used any
more on the project

Getting resources only when
needed and releasing as soon
as task is complete

Table 9.1(d)

Subcontractors’ Behavior Changes

Current Behavior

Future Behavior

Delivering to lead times

Delivering to due dates

Delivering to lead times

Shortening lead times

Delivering to due dates

Shortening lead times

Table 9.1(e)

Customers’ Behavior Changes

Current Behavior

Future Behavior

Eliminating project
scope changes

Customers spending little
time initially establishing
requirements and then
introducing late changes

Establishing requirements as part of
the project work plan; changing as
little as possible with formal change

Supporting use of
project buffer

Customers interpreting
contingency as fat

Customers understanding the need for
buffers to reduce project lead time and
ensuring project success

Eliminating arbitrary
date milestones

Demanding arbitrary date

Using plan to set milestones

Implementing the change to critical chain


Box 6 in Figure 9.1 is where you compare progress to plan and determine if you need to take management action. It includes both progress to
the work plan and progress to the soft measures. Some companies like
to put together a steering group to monitor progress and help the implementation project manager. Box 7 in Figure 9.1 is simply where you mark
tasks as complete.
Several features of CCPM make it easier to implement than many
changes people attempt to make in organizations:
◗ Nobody loses, because you take away the win/lose aspect of task

duration estimates.
◗ Many win, because of the reduction in pressure to multitask

and the feeling of accomplishment that follows successful task and
project completion.
◗ It is simple, compared with the more-and-more-detailed approach

or the implementation of complex earned value reporting systems.
◗ Results feed back rapidly in the weekly project meeting. You do not

have to wait for company cost reports.
◗ Unfortunately, not everyone will feel that there is enough of a need

to change anything, and others may fear that they have something
to lose. Section 9.2 describes some strategies for dealing with such
potential obstacles.


Vision of the end

If you do not know where you are going, you will not know when you get
there. Launching critical chain implementation without a clear picture of
success is like launching an arrow into the air; it will come to earth “you
know not where.”
You can represent the end vision in a variety of ways. A picture
usually helps; many people respond better to visual stimuli than to other
inputs. Consider putting together your own picture of your organization
operating to the critical chain paradigm. For engineers, that picture may
look a lot like a diagram. To project managers, it may be a picture of a
simplified Gantt chart, showing the features of critical chain plans. To
people-oriented managers it would include people. I prefer to describe


Critical Chain Project Management

the end vision in terms of the behavior necessary to operate critical chain
projects successfully.


Implementation theory

Change management theories abound. Much of the literature starts with
the reasons change attempts fail. Failure means that planned change does
not achieve some desired goal. Change goes on in all organizations. It just
is not the change wanted by the book authors or the people they asked.
The theories rarely agree on the reasons changes fail to achieve the goal.
As was the case with project management, that should give us pause to
suspect that the authors are missing a deeper systemic cause.


The rule of 3-4-3

The following anecdotal observations are examples of the parables that
form the basis for much management theory. A speaker at a recent
management conference brought up the rule of 3-4-3. He said he learned
it from a Japanese colleague when they were studying the application of
Kaizen (Japanese for “continuous improvement”), the subject of his talk.
The reference means that in attempting to introduce new ideas into any
organization, about 3 out of 10 people will catch on immediately and
begin to implement. Another 3 out of 10 will remain clueless and uninterested in just about anything and everything, forever. The middle 4 of 10
will behave in exactly the way you might expect middle-of-the-roaders to
act—they will wait and see and gradually come aboard, as the change
becomes the organizational norm.
The time for organizational change to take place depends, of course,
on both the change and the organization. For example, I read that it
took the British Army 125 years to accept the recommendation that foot
soldiers should wear asymmetric shoes (i.e., one for the left foot and one
for the right foot). Just imagine complaints of the supply sergeants: “Hey,
you guys want me to be efficient. And now you want me to double my
inventory! Think of how hard it is going to be to keep the left and right
shoes of the same size together, all the way from manufacturing, through
distribution and supply, to the soldiers. Costs will go up. Delivery will be
harder to maintain. And the soldiers will never be able to put them