Most managers are familiar with the use of a Gantt chart to delineate project schedules.
But for most projects that involve numerous tasks and an assortment of resources with associated costs, it is
preferable to take a more formal approach to project planning and management.
In this section we will discuss and critique techniques such as the Critical Path Method of Project
Management (CPM) and the Program Evaluation and Review Technique (PERT); and we'll
also take you beyond these basic approaches to consider alternatives such as
project uncertainty simulation and Critical Chain Project Management
To demonstrate the sorts of things we can accomplish using formal project management techniques, we will use a
relatively simple hypothetical example of an advertising agency that is planning for a new-business pitch to a
prospective client. The statement of the problem is shown in the table below:
There are a total of 13 tasks in the project, starting with some basic secondary research to get background
information about the client's industry and brand as well as the brand's target market and competitive frame. This
task would also include an examination of existing advertising and promotion for the brand and its competitors,
Once the agency has a better understanding of the brand and its situation, an appropriately staffed pitch team
will be assembled to accomplish the subsequent tasks in the project. The remaining tasks in the pitch project
sequence are shown above, ending with the actual pitch itself. The lefthand column lists the task numbers
sequentially; the second column gives a brief summary description of each task.
The "Predecessor" column lists, for each task, the numbers of the task(s) immediately preceding it in the
project schedule. These preceding tasks must be completed before the current task can be started. For example, we
see that task two cannot begin until the basic background research is completed. Similarly, task three depends on
the completion of task two; tasks four and five both depend on task 3; and so on. We also see that two tasks depend
on the completion of two predecessor tasks: task eight depends on the completion of both tasks four and seven; and
task 13 depends on the completion of both tasks 11 and 12.
The "Time" column shows the estimated time required to complete each task. The "EST" through "LFT" columns tell
us, respectively, the earliest start time, earliest finish time, latest start time and latest finish time for each
task. The "Slack" column shows us what, if any, extra time is available to finish a task because it's completion in
the expected task time is not critical to keeping the project on schedule.
For example, the completion of tasks five, six and seven each can be delayed by up to two days because, although
the starting of task eight depends on their being completed, task four, on which the start of task eight is also
dependent, takes so long that the agency does not have to stick to the originally allotted time for tasks five
In contrast, critical-path tasks must be completed on time, or else the project will be delayed. In the above
table, the task numbers and number of slack days for noncritical tasks are shown in blue, while the corresponding
data for critical-path tasks are shown in red. (Critical path tasks have zero slack.) The data in the
table are shown below in a Gantt chart, where the noncritical tasks are shown as blue bars and the critical
tasks are shown as red bars, with arrows showing dependencies of start times of later tasks on the finish
times of predecessor tasks:
The blue hash marks extending beyond the blue bars indicate the amount of slack time associated with a given
noncritical task, showing the two-day slack for tasks five, six and seven, and the one-day slack for task 11.
[Note: For this example we assume that no work is done on the weekend; so although some task bars and slack bars
appear excessively long, the portion of the bar that occurs during the work week accurately reflects the actual
work-week task/slack time.]
The total expected completion time for the project is 32 working days, or 44 calendar days. Note that the 32
working days equal the sum of the critical-path tasks' working days. The critical path is the
longest path in the schedule, and it also represents the
shortest possible time necessary to complete the project. Project management
techniques that take account of the critical path are typically referred to as the Critical Path
Method, or CPM.
In addition to the Calendar and Gantt chart, we can also conveniently show the project paths in a
network diagram, which allows us to include key task-length and calendar data in the diagram
itself, instead of having a separate calendar and Gantt chart. Below is a snippet from a network diagram, again
showing noncritical tasks in blue and critical tasks in red, with arrows indicating task dependencies:
Back to Top
Sometimes unforeseen events may require us to compress the project schedule, finishing the project is less time
than we originally planned. This is often referred to as "project crashing." Let's suppose that just before the
agency starts working on the pitch project, the prospective client requests a completion date that gives the agency
only 26 working days instead of the originally planned 32 working days to finish the project.
The table below shows us the situation, after we have figured out where we could save some time by using
additional resources. The "Crash Days Allowed" column shows us how many days we could save on various tasks by
crashing the project. For example, we could save one day on task one, two days on task four, and so on. Note that
for some tasks, we have determined that we cannot realistically shorten the time required for the task; these tasks
have zero crash days allowed.
The "Crash Cost Per Day" column shows how much the extra resources would cost for each day by which we shorten a
task. (In-house resources are "opportunity costs" that accrue because resources are pulled off of billable
activities to help speed up the nonbillable project's schedule. In addition, some external vendors such as research
suppliers will charge us a premium for accelerating their work schedule.) We multiply this daily crash
cost by the number of crash days available and add it to the original estimated cost for completing the task
to arrive at the total crash cost for each task. In addition to the Normal Time column, we now also have a Crash
Time column that shows the estimated number of days required to complete the task under a crash schedule.
But we still have some head scratching to do. Different tasks not only have different numbers of potential crash
days available, ranging from zero to two; but the daily cost of crashing a given task also differs among
crashable tasks, ranging from $1,400 to $1,800 per day. So we decide to apply an optimization technique
called linear programming to help us arrive at the best
The table below shows us the setup of the linear programming problem. The green zeroes will be changed by
the linear programming process to optimize a solution. The resulting final number of working days will be shown in
blue near the bottom of the table ("Project Finish Time"); and the incremental cost of crashing the project ("Total
Cost of Crashing") will be shown below that, at the very bottom of the table.
Here is the solution that allows us to complete the project in exactly 26 days, at an additional cost of
Now let's suppose that instead of having to shorten the project from 32 working days to 26, we only need to
shorten the schedule to 29 days. In this case, we don't want to crash the project for more days than
necessary, because that would be unnecessarily expensive. So now, instead of minimizing the time required to
complete the project, we want to get the project done in 29 working days while minimizing the crash
So we again use linear programming to find an optimal solution. The table below shows that we can achieve our
goal at an incremental cost of only $4,200 instead of the $12,400 required if we had to complete the project
in only 26 days:
For some types of project, we may need to trade off shortening the project and controlling costs. In
those situations, we can apply a type of optimization technique known as
Multiple Objective Linear Programming (MOLP) to
figure out a reasonable tradeoff.
Back to Top
Uncertainty and Risk
Sometimes the amount of time required to complete various tasks in a project is not as clear-cut as in the above
example. There are often uncertainties that make it difficult to estimate task completion times precisely. In these
situations, we can employ risk analysis to help us devise realistic estimates for our project schedule.
One method that has been used for many years is referred to as the Program Evaluation and Review
Technique, or PERT. Unlike CPM, PERT sees task times not as fixed values, but as random
variables that have an expected value (a mean) and a variance around that expected value. PERT uses three
parameters to model uncertainty related to completing
mi = estimated most
likely task duration
ai = estimated
duration under the most favorable conditions
bi = estimated
duration under the least favorable conditions
PERT then uses these values in formulas to estimate uncertainty and task duration. The expected duration of a
task is given by the following formula for task i:
ai + 4mi + bi
And the estimated variance of the duration for each task is given by:
vi = (bi - ai)2
These formulas assume that task completion times are random variables that follow the beta probability
distribution. Here is a typically right-skewed beta distribution for project completion times:
To find the expected completion time and variance for an entire path in a project, PERT sums, respectively, the
means and variances of each task in the path. The path with the longest completion time is considered to be
the critical path, just as in the CPM method.
There are at least two troublesome drawbacks to PERT. First, although PERT assumes that task completion
times are independent of one another, in reality this is not always true. For example, if a predecessor task
runs a bit longer than expected, some managers will try to shorten the duration of one or more subsequent tasks to
make up the time. And while this adjustment usually will not significantly change the expected
completion time for the project, it does artificially reduce the estimated variance, thus somewhat defeating the
purpose of using PERT in the first place.
Secondly, and even more troubling, there is a tendency for many inexperienced project managers to
focus too much on the critical-path tasks, based on the faulty assumption that these tasks are the ones most likely
to delay timely completion of the project. Actually, it is sometimes the case that tasks that are
not on the critical path are the ones most likely to delay the project. So, by introducing variability
into the project task network, PERT may be subtly changing the definition of "critical path." While the
critical path in CPM is considered to be the longest path, perhaps those who use PERT should consider
the critical path to be the one with the lowest probability of being completed on time.
A more useful method for accounting for project schedule uncertainty is risk/uncertainty simulation. We
will not go into detail here; but the reader can visit our Monte Carlo
Simulation page to see an example of simulating uncertainty in budgeting. If we substitute project tasks
for budget items, then we can just as easily model project uncertainty/risk.
Similarly, the reader can visit our Monte Carlo Optimization
page, where we use a combination of Monte Carlo simulation and optimization modeling. If
we substitute project tasks for the consulting projects used in that example, we can both model
project duration uncertainty and find an optimal solution to project scheduling.
Critical Chain Project Management (CCPM)
CCPM is another project management technique that moves beyond simple CPM. It combines concepts from
various fields such as Planning and Control Processes, the Theory of Constraints (TOC), Lean Manufacturing and Six
Sigma (variability reduction) in an attempt to control phenomena such as:
- Parkinson's Law (work expands to fill the time allotted to it)
- Murphy's Law (whatever can go wrong will go wrong)
- Poor multi-tasking that can hold up the start of successor tasks
- Student Syndrome (procrastinating until the last minute; then rushing to complete a task)
We won't go into details here, but CCPM is useful when resources are constrained and there is a need or
desire to control task slack and time buffers, and to remove bottlenecks so that constraints can be seen more
clearly and dealt with more effectively. The technique basically attempts to opimize buffers at the end of
tasks, task sequences and the entire project; and significantly reduces the estimated time for completion of each
task, sometimes by as much as 50%.
When implemented properly, CCPM can help you achieve at least three important goals:
- Significantly reduce project duration
- Use resources more effectively
- Achieve a more balanced focus on critical and noncritical tasks
SmartDrill can assist you in applying project management techniques, including CPM, uncertainty
simulation modeling and CCPM, to help your organization work more effectively and increase your bottom line.
Back to Top
Back to the Operations Research and Analytics page