Tải bản đầy đủ
9 A planning and control policy 145

9 A planning and control policy 145

Tải bản đầy đủ


Critical Chain Project Management

2. WBS
3. Organization, responsibilities, and authority
a. Interorganizational
b. Intraorganizational
c. Temporary organization
4. Schedules
5. Budgets and cost estimate basis
6. Resource management
a. Labor
b. Equipment
c. Materials and supplies
d. Physical facilities
7. Materials management
8. Quality
a. Codes, standards (e.g., ISO 9000), and regulations
b. Authorities
c. Procedures
d. Records
9. Safety
10. Security
11. Management control
12. Reporting requirements
a. Management reports
b. Technical reports
c. Public information

Starting a new project


13. Configuration management
14. Change control process
15. System engineering
16. Environmental protection
17. Data quality
18. Operational definitions
19. Appendixes
a. Technical data
b. Support exhibits
c. Work package documentation
d. Procedures
e. Change control board charter
Because the project plan on a large project can get quite large, consider keeping it in an electronic version, available to all team members.
Always keep the up-to-date project schedule printed in hard copy and
readily available throughout the project work areas.


Change management

Change management ensures that only changes approved by the project manager are implemented on the project. The most important
function of change control is to ensure that everyone working on the
project is working to the same plan, including the same scope of work
and detailed project requirements. Other functions of change control
◗ Making sure people work on only approved changes;
◗ Assessing the impact of changes on cost or schedule before deciding

to implement them;
◗ Enabling billing of the customer for customer-directed changes;


Critical Chain Project Management
◗ Providing a record of changes;
◗ Providing traceability to the original project baseline.

For larger projects, change control may be part of your project quality
system. For smaller projects, it may be a memo from the project manager
approving the change and identifying the latest version of the specifications and project plan.


Project closure

Project plans often neglect closure of the project. Project closure includes
dealing with the entire project administrative, facility, and personnel
issues as the project is finally completed. It usually involves final billing, disposition of project records, and closing the project office. For
organizations that perform multiple projects, it also should include a
“lessons learned” assessment, to improve processes on future projects.



This chapter provided the process and tools necessary to create an effective project work plan.
◗ The project charter is a necessary precursor to a successful project

plan that effectively meets all project stakeholder requirements.
◗ The work breakdown structure logically defines the general project

work scope and provides the framework for responsibility
◗ The stakeholder endorsed project work plan defines the scope,

schedule, responsibilities, and budget for the project.
◗ Project networks should be as simple as possible to perform the

◗ The project plan requires a correct, resource-loaded logic network

to develop the schedule.
◗ Dates are outputs from the logic network, not inputs.

Starting a new project


◗ If cost is important to your projects, include a cost buffer in the cost

◗ Request task duration estimates initially, just as you have in the

past, and then go back to request average times for the critical chain
◗ Most projects require a change control process.
◗ All project plans should consider project closure as part of the plan.

Adjust the degree of detail you put into the project plan and the
degree of formality you put into the project documents to match
the stakeholder and team member needs. In general, larger, longer,
and government projects require more detail and more formality. Less
experienced teams may also require more documentation and training.


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


CH2MHILL, Project Delivery System: A System and Process for Benchmark
Performance, CH2MHILL, Denver, CO, 1996.


Goldratt, E. M., It’s Not Luck, Great Barrington MA: North River Press, 1994.


Dettmer, H. W., Goldratt’s Theory of Constraints, Milwaukee, WI: ASQC, 1997.


Kerzner, H., Project Management: A Systems Approach to Planning, Scheduling, and
Controlling, 4th ed., New York: Van Nostrand, 1992.


Kerzner, H., Project Management: A Systems Approach to Planning, Scheduling, and
Controlling, 6th ed., New York: John Wiley & Sons, 1998, Table 14-12, p. 745.


Kiley, M. D., and A. Marques, 1997 National Construction Estimator, Craftsman
Book Company, 1997.


Vigder, M. R., and A. W. Kark, “Software Cost Estimation and Control,”
NRC-CNRC (National Research Council Canada), NRC No. 37166, Feb. 1994.



The process

6.2 The “good
enough” concept

Developing the
critical chain plan

6.3 Examples and
6.4 Buffer and
threshold sizing

Cost buffer

6.6 Methods to create
the plan
6.7 External
6.8 Reducing planned
time (a.k.a. dictated
end dates)
6.9 Enterprisewide
resource planning
6.10 Frequently asked



his chapter first presents the overall
process to create the single-project critical
chain plan and then takes you through examples and exercises to practice the ideas. It
is important to understand the ideas before
you begin to use computer schedule aids to
develop critical chain project plans.


The process

The basic steps of the process to create a
single critical chain project schedule follow.
We have written the procedure assuming
that you are not using a critical chain
computer scheduling tool such as ProChain
or Concerto. Working some networks by
hand helps you to understand the problem
the computer is solving. That will aid greatly
when you are diagnosing unexpected results.



Critical Chain Project Management

1. Identify the critical chain.
a. Lay out the late-finish network of tasks. The tasks must identify the time duration estimate (50-50 time) and primary
resource requirements. (For tasks with multiple resources,
identify the primary resource you believe will be a constraint.
If there are several constraint resources, break the task up for
each primary resource.)
b. If you do not have resource contention in your project, go to
step 1(f).
c. Identify the contention you will resolve first. That should be
the contention nearest project completion or the one that
shows the most conflict. If several contentions show about
the same amount of potential conflict, choose the first one
you come to working backward from the end of the schedule.
d. Remove resource contention by resequencing tasks earlier in
time. (Do not worry about creating new conflicts with this
step; you will resolve those in sequence.)
e. Return to the end of the schedule and follow step 1(d) for the
next resource. As you resolve conflicts for the next resource,
you must maintain the lack of the conflict for the resources
you resolved earlier. Repeat until all identified resource types
are resolved.

Identify the critical chain as the longest chain of dependent

2. Exploit the critical chain.
a. Review your plan to determine if there are obvious ways that
resequencing can shorten the overall project duration. If so,
do it. Do not spend a lot of time trial and error testing various
solutions. You will usually get a good enough solution on
your first or second try.
b. Add the project buffer to the end of the critical chain.
c. Add resource buffers to the critical chain.

Developing the (single-project) critical chain plan


3. Subordinate the other tasks, paths, and resources to the critical
a. Protect the critical chain by adding CCFBs to all chains that
feed the critical chain. Size the buffers using the longest
preceding path. (Note: All noncritical chains feed the critical
chain to complete the project. If chains go directly to the
project buffer, they also need CCFBs.)
b. Resolve any resource contentions created by adding feeding
buffers through resequencing tasks earlier in time.
c. Move earlier in time any dependent tasks preceding those
4. Elevate (shorten) the lead time of the project by using added
resources for certain windows of time to break contention.
5. Go back to step 1, identify the critical chain. Do not allow inertia
to become the constraint.
A critical chain plan schedules (i.e., assigns dates) only to the start of
the chains and the completion of the project. Avoid publishing and
discussing individual task start and complete dates—they are meaningless. For that reason, you may want to consider talking about the critical
chain plan, rather than the critical chain schedule.


The “good enough” concept

“Good enough” is an important idea in developing critical chain project
plans. No proven effective algorithm exists for resource leveling to ensure
an optimum schedule. The procedure for developing the critical chain
plan ensures that the plan you build will be good enough. That means the
overall length of the schedule will close to the shortest or optimum schedule path. Close means within a small part (25% or less) of the project
buffer. Because reality will change many assumptions, and we cannot
explicitly predict the results of statistical fluctuations, that is “good



Critical Chain Project Management

Examples and practice
Small example

This section presents a small example to work into a critical chain.
Figure 6.1 illustrates the plan in a conventional critical path display, with
the early-start schedule. The first number on each bar is the WBS task
identification. The number in parentheses is the task duration, in days.
Note that task 3 depends on the completion of tasks 1.2 and 2.2.
Following the procedure, in Figure 6.2 we first cut the task times
to the 50-50 estimate and push all the tasks to the latest time possible,
considering the network dependency.
Next, in Figure 6.3, we add the project buffer and the feeding buffer.
Because all tasks use the same resource, we do not need to add resource
buffers to this project.
Now consider the same small project with resource contention.
Figure 6.4 shows the unscaled network of tasks with a PERT chart
representation of the project. The network shows the different resources
as colors. You can think of the colors as different skills, e.g., engineers,
musicians, or equipment operators.

1.1 (30)

1.2 (20)
3 (30)

2.1 (20)


2.2 (10)

80 days

Figure 6.1

A simple project illustrates a normal early-start schedule.


1.2 (10)
3 (15)
2.1 (10)

2.2 (5)
40 days

Figure 6.2 The first step to create the critical chain reduces the task
times and organizes tasks to a late-finish schedule.