Tải bản đầy đủ
10 Frequently asked questions 177

10 Frequently asked questions 177

Tải bản đầy đủ


Critical Chain Project Management

likely to succeed? Can a project manager really manage thousands
of tasks? Does having thousands of tasks improve the ability
to manage, or does the system become so complex that it can
never have meaningful accurate data? How important can it be to
have tasks as small as a fraction of 1% of the total project? (With
100 tasks, the average task size is already down to 1% of the overall
project. Who can estimate that well?)
We recommend that you confine project schedules to a few
hundred tasks, at most. If major subassemblies (e.g., an aircraft
engine) require schedules of their own at a lower level, use that
approach. (We are working the project management system here,
not detailed designs or bills of materials.)
Experience demonstrates that the more detailed tasks there
are in the schedule, the more often the schedule has to be revised
and the greater the probability of error. That leads to long turnaround times for schedule updates and the loss of control.
◗ We are halfway through the project and have not penetrated the project

buffer. Can we cut the project buffer in half ?
Cutting the project buffer does not reduce the project actual performance time. It reduces the chance that the project will deliver
substantially early. Your project buffer status gives you dynamic
predictions of project completion time. There is no reason internal
to the project to reduce the project buffer.
If external needs require you to reduce the project buffer, you
can replan the project at any time. Remember, the project buffer
protects the whole project. All noncritical chains merge to the
critical chain before the project is complete. Before you reduce
the project buffer, check all CCFBs to make sure that the unused
feeding buffer length is at least 50% of each feeding chain uncompleted path length. If the feeding buffers are all intact by that
amount, there is no problem with reducing the project buffer to
50% of the remaining length of the critical chain. In essence, you
are starting a new project at the time of the update.
◗ We have tasks in our project plan over which we have no control. What

should we do?

Developing the (single-project) critical chain plan


Regulator or client review of project outputs often creates that
situation. You can control what you give them and when you give it
to them, but you cannot (directly) control their work processes.
In this case, working with your stakeholders, as described in
Chapter 1, will provide great benefit. You can influence how long
their review takes and limit potential rework by using the effort
necessary to ensure that you understand their requirements and
produce a quality product for their review. If you are a significant
part of their workload, you can help their focus by staggering your
submissions to help them avoid multitasking. Other unique situations demand unique solutions. In those instances, use the five-step
focusing process (see Section 2.3.3).
◗ Our management/client has specific intermediate milestones they want us to

schedule a date for and meet. What do we do?
This can occur for a number of reasons, including coordination
with other parts of a larger project. We know of cases in which project payment is tied to satisfactory completion of milestones.
If satisfying milestones creates throughput for your company,
we recommend planning milestone accomplishment as a project
of its own. You can then use the multiproject method to link the
If satisfying the milestones is simply a tracking tool, we suggest
you first try to convince management or the client that buffer
reports are actually a better tool. Failing that, we suggest you protect the milestones with a milestone buffer. Size the milestone
buffer as a project buffer, but do not use it for project control.
◗ Our client does not want our result early, because we are a subassembly

to their project, and they do not want to have to store our input. What do
we do?
Use the critical chain process to schedule the start of your activity
chains to satisfy the client needs. Usually, that will mean you can
delay some activity starts.
◗ What are the answers to the two exercises in Section 6.3?


Critical Chain Project Management

There are multiple satisfactory solutions to each exercise. If your
results come within about 15% of the project buffer to the total lead
times given below, they are good enough.
Critical Chain



Total Project
Lead Time

Small exercise




Large exercise





This chapter described how to create a critical chain plan for a single project. The steps up through creating a logic diagram with low risk duration
estimates do not change from the reference PMBOK approach. The
critical chain steps are as follows.
◗ Estimating task duration for the critical chain plan is often one of

the most challenging implementation problems. Be sure you create
a plan with conventional duration estimates before you ask for
50-50 estimates.
◗ The critical chain plan process is well defined and easy to use to

create a “good enough” plan.
◗ Project and feeding buffer sizing and trigger points determine the

degree of project protection and frequency of control action.
◗ Size resource buffers to send effective signals to resources on

impending need.
◗ The (optional) cost buffer provides aggregated cost protection in the

same way that the project buffer protects the schedule.
◗ You can use alternative methods to create and track the criti-

cal chain plan, ranging from manual methods to critical chain
◗ The TOC five focusing steps (identify, exploit, subordinate, elevate,

avoid inertia) provide a framework for resolving environment
and project specific issues.

Developing the (single-project) critical chain plan


Constructing a critical chain plan is a relatively small addition to
the work necessary to construct an effective critical path plan. It may be
less work and create a more accurate plan, if you significantly reduce the
number of activities in your plan. The extra investment is well worth
the gain.


7.1 Identifying the
multiproject constraint
7.2 Exploiting the
multiproject constraint
7.3 Features of
multiproject critical
7.4 Introducing
new projects to the


the enterprise
multiproject critical
chain plan
7.1 Identifying the
multiproject constraint
The critical chain is the constraint for a single
project. What is the constraint of an enterprise that performs multiple projects? How do
you put the critical chains of multiple projects
together in a way that identifies the constraint of the enterprise to produce projects
that meet the three necessary conditions and
do it in a way that allows focus on increasing
the project throughput of the enterprise?
What is it that constrains the enterprise from
completing more projects or completing the
existing projects more quickly?
Consider a more familiar reference environment with which most people are familiar: mowing a lawn. Consider the amount of
grass cut as the counterpart to completed
projects. What happens when the grass is too



Critical Chain Project Management

long or when you try to push the lawnmower too fast? It bogs down and
often stalls.
The same thing happens if too many projects are pushed into a multiproject environment without considering the capability of the constraint
to perform the projects. If you push too many projects into the system, it
will bog down and stall. People will work hard, but projects will take a
long time to complete (the engine is stalled much of the time), and a lot of
management effort goes into restarting the engine and cleaning out the
debris. It will seem as if there are never enough of the key resources
necessary to complete the projects.
With the lawnmower, you use the feedback from the system to adjust
the rate of processing. You listen and slow down the lawnmower as the
engine begins to slow down. Or you raise the cutting height, so you match
the processing rate to the feed of the work.
Figure 7.1 illustrates a critical path multiproject scenario. The colors
in the bars represent resources. Using conventional low-risk activity estimates and considering three-project multitasking, each activity duration
is 90 days. In most organizations, the managers of the three projects
would rarely work together. Each would work with the managers of
the resources to try to get the resources they needed. In this worstcase example, all the resource needs overlap. If there is only one of
each resource, each project has to schedule assuming one-third of the
resources time to work on its project. That situation is called the fractional
head count.
I have made a point of asking groups of project managers (many of
whom belong to the Project Management Institute, including certified project management professionals), “How many of you routinely
resource-level your project plans?” (Resource loading means identifying
the resources needed for each task; resource leveling is removing the conflicts in which demand exceeds supply.) My unofficial survey indicates
that only about 5% of project managers routinely resource-level their
plans. In other words, the situation is usually worse than I assumed
above: They do not even know where the overlaps occur. I then ask them,
“Why not?” Most need some prodding, but usually the answer is one of
two things: (1) It is not worth it, because management will change everything anyhow, or (2) it makes the schedule too long. Finally, I ask how
many of them have infinite resources at their disposal. So far, none has
infinite resources.