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 (CCPM).

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, etc.

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 through seven.

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 

Project Crashing

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 solution.

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 $12,400: 

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 costs.

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
task i:

m_i = estimated most likely task duration

a_i = estimated duration under the most favorable conditions

b_i = 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:

t_i = a_i + 4m_i + b_i 
       6

And the estimated variance of the duration for each task is given by:

v_i = (b_i - a_i)²
      36 

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.

Uncertainty Simulation

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