Tải bản đầy đủ
Critical Chain Project Management
◗ Critical path status: Projection of time to complete the project;
◗ Actual cost versus budget status: Comparison of actual cost to
budget cost and estimate to complete the project.
Some project managers use somewhat more sophisticated measures,
especially on larger projects. For example, they plot milestone completion
on control charts or report and do something with slack time on noncritical paths.
When you are managing to the critical path, it is normal to evaluate
the activity status, milestone status, progress on the critical path, and
overall cost to overall budget. Usually data are available to monitor cost to
budget at lower levels of a WBS than the total project. Activity status is
normally gathered in real time by the project manager at status meetings
with work package managers. Actual cost data usually have some delay,
since most accounting systems run the costs only monthly. The cost data
usually come directly from the accounting system, with which managers
in the company are familiar.
Recall that when you resource-level a critical path, it is no longer the
critical path. The critical path is actually the resource-dependent chains
you have created. It is the de facto critical chain. Unfortunately, it usually
is not tracked that way after resource leveling. Thus, the critical path
project manager loses focus.
Many people apply the critical project management software to
update the plan to date. That allows delay in any path to create a new
critical path. Worse, it adds the delay to the calculation of float for all the
other project paths. Thus, if the project recovers the apparent lost time on
the new critical path, it is likely that delay has been introduced in the
other paths working to the delayed schedule. Some will argue that comparing the statused schedule to the baseline schedule prevents that undesirable effect. My experience is that most people in such environments
focus on the due date listed in the statused project schedule.
CSCSs (cost schedule control systems), introduced in the early 1960s
as a method to determine appropriate progress payments on projects,
were extended to attempt to resolve a fundamental problem in project
management: Cost and time are not in the same units of measure.
Although the primary purpose of CSCSs was to provide a basis for contract payments on government contracts, many organizations adopted
Measurement and control
them as a project management tool. CSCSs define measures for schedule
performance (time) in terms of dollars.
CSCSs also compute variances as differences between the numbers
and indices as ratios of the variances to the plan measures. I described the
cost variance as a useful measure of cost buffer penetration. CSCSs also
develop another measure, inappropriately titled the schedule variance,
that measures the cost difference due to actual versus planned schedule
performance. It is a cost measure, not a schedule measure. While it
provides a definition of the other part of the difference between actual
cost to date and scheduled budget to date, it has little value as a schedule
indicator because it weights schedule performance by the cost of the
tasks. It can give entirely misleading information on actual schedule
performance. You should not use it.
CSCSs calculate all three of the measures (BCWS, ACWP, BCWP)
down to the finest level of detail determined for project measurement and
roll them up to the total project. Many of the projects that have suffered
the grandest schedule slips and cost overruns have had the most sophisticated CSCSs.
Milestone status (including critical path milestone status) is a direct
measure of the project schedule status, available to the project manager
immediately as the project is sensed. Most project managers ascertain
milestone status at least weekly, either in a meeting or through a simple
reporting process. Now that most projects are hooked up on e-mail, the
status reports can be compiled in real time.
Putting schedule status in terms of dollars is not meaningful. Schedule variance is further confounded by the ability to account for BCWP a
variety of ways and any rollup likely will be a combination of many ways.
BCWP makes no distinction between activities on the critical path/chain
and those not on the critical path/chain. The actual meaning in terms of
the schedule is substantial. As noted earlier, the actual cost impact of activities on the critical chain (the project bottleneck) could be the whole cost of
the project for the time lost, not just the cost of the individual activity.
Finally, CSCS usually creates some indices, essentially the percentage
of variance. That presumably was to allow constant comparison through
a project life and between projects. But there are different ways to calculate that value. One method even goes so far as to recalculate a time from
the schedule variance (schedule variance divided by project expenditure
rate) to represent some type of average project schedule performance in
Critical Chain Project Management
days. The numbers require more calculation and are meaningless in terms
of project decision making.
The primary problem with CSCSs is that they violate the first focusing
step. Rather than finding and focusing on the constraint, CSCSs require
attention to each activity based on its cost. They are the ultimate costworld defocusing device.
If you must report to a CSCS measurement system, keep in mind that
the measures will show project completion where you show the end of
the project budget. Your critical chain project completion is at the end
of the project buffer. One way you can reconcile that difference is to put
the cost buffer into an activity that represents the project buffer.
With the critical chain measurement system, you monitor progress
along the critical chain by the completed critical chain activities and with
the project buffer and critical chain feeding buffers. Every day, you gather
the data, which have clear meaning, measured in time. You also monitor
actual cost as in the critical path method, so data are available as soon as
the financial system cranks it out.
Change control actions
Section 4.4 described the need for formal project change control. The
project managers should approve any changes to the plan. You should
have a form to aid tracking changes and a numbering system so you can
be sure you are always working to the latest version of the plan. In an
ideal world, the plan would never change. In the world most people are
coming from, it changes all the time. You likely will be somewhere in
between in your initial efforts. You have to decide on criteria that
constitute a change to the plan. Following are some thoughts for your
◗ A change in the plan logic (e.g., add a task, delete a task, change to the
predecessor or successor on a task) should be considered a change.
◗ A significant change in scope of a task (you have to define signifi-
cant) should be considered a change.
◗ A significant change in the task resource estimate or in the identifi-
cation of the resource should be considered a change. It may be
necessary to recheck the critical chain.
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
◗ Conventional project change control methods are necessary to
handle scope changes and impacts of special cause variation.