Notes on Program Management

General Description

The simplest program management tool was developed by Henry Gantt and bears his name. Gantt Charts plot the steps necessary to complete a project against a timeline. Each task or activityis plotted by a bar or line which begins at a definite time and ends at a defined time. The activity bars are arranged in ascending or descending sequence of time (i.e., in the order in which the tasks begin or the order in which they end). The Gantt Chart provides milestones, or markers, for assuring that a program is on track. 

Take a simple example: Suppose you plan to build an addition on your house. First, you have to decide what you are going to do. For this example, you might have to build a foundation, frame the addition, do the electrical work, sheetrock and trim, roofing, landscaping, exterior painting, and interior painting/finishing. Then you'd have to decide in what order things have to be done. For example, you can't frame the addition until the foundation is done, and you can't put on the roof until the framing is done. On the other hand, once the framing is done the electrician can come in (but the sheetrock can't go up until after that, and the interior painting is last) and the exterior painting and the landscaping can be done at the same time. Then you'd have to estimate how long it will take to do each task. Then you could add up the time it takes to do the various tasks to estimate how long it should take to complete the project.  A typical Gantt Chart might look something like this:

 

Jan

Feb

Mar

Apr

May

Jun

Jul

Aug

Assemble materials

X

 

 

 

 

 

 

 

Foundation

X

 

 

 

 

 

 

 

Framing

 

X

X

X

X

 

 

 

Electrical

 

 

 

 

X

 

 

 

Roofing

 

 

 

 

X

 

 

 

Sheetrock

 

 

 

 

 

X

 

 

Interior Paint

 

 

 

 

 

 

X

X

Exterior Paint

 

 

 

 

 

 

X

 

Landscaping

 

 

 

 

 

 

X

 

While Gantt Charts have the advantage of simplicity, and do perform the work of determining the tasks and some of the order in which they are to be performed, they can hide as much as they display. The linkages between the various tasks are not made explicit nor is the relationship between resources and the time to complete a task. While Gantt Charts can tell a manager whether a program is on track, they often cannot provide information about how to get it back on track.

Enter PERT--Program Evaluation and Review Technique (Krueckeberg & Silvers, 1974). PERT was first used the 1950s on projects like the construction of the Polaris submarine-a project which required coordinating the activities of 250 contractors and 9000 subcontracts. Like Gantt charts, PERT requires task definition and duration; in addition, PERT requires specification of the relationship between tasks and the resources required to complete each task in a given period of time. Once the network of activities is determined, CPM (Critical Path Method) is used to reallocate resources to find the shortest time in which the project can be completed (and what resources would be needed to do that).

Going back to the example of building an addition on the house, the foundation could be dug, poured, and set in, say, two weeks-a week if you really pushed, three weeks if you get bad weather.. You could even shorten the time it took to complete the project if you sped up tasks that were holding back other tasks. This is, in effect, a Program Evaluation and Review Technique. In a "picture," one might draw something like this (by the way, this was done in Word using  the “Drawing” function—Insert to Picture to AutoShapes, using Text boxes and arrows):

Exterior Paint
 

Now, suppose you want to get this addition built as quickly as possible. You could always "crash" the project, using CPM ("Critical Path Method"). The idea is to use estimates of time and cost to find the most efficient use of resources to get the job done. This means getting it done in the least possible time, neither wasting nor sparing costs. To do this, you might develop a table of time and cost information-for each task. What is the "normal" (expected) time the task should take, and what is the least ("crashed") time in which it could be done? And how much does it cost in each case for each task? Using these data, you could develop a "cost per week" for crashing (the crashed cost divided by the time saved). Using your PERT Chart, you could crash the cheapest activity path that is on the longest path for getting the job done (this is called the "critical path"). You could repeat this process, one path at a time, until all the paths have been crashed. Then you should ease up on all the "noncritical paths", just to the point that "all paths are critical"(i.e., so everything comes together at the same time-why spend more for crashing than you have to?).

In the example above, you might develop a table that looks something like this:

 

 

Time

 

Cost

 

Path

Name

normal

crashed

normal

crashed

1-2

Foundation

2

1

$3000

$4000

2-3

Framing

4

1

$4000

$8000

3-4

Dummy

 

 

 

 

3-5

Electrical

.4

.2

$1000

$1500

4-5

Roofing

1

.4

$1000

$1750

5-6

Sheetrock

1

.4

$1000

$1500

6-7

Interior Finish

2

1

$1500

$3000

2-7

Landscaping

.4

.2

$500

$650

3-7

Exterior Paint

.8

.4

$600

$1000

Using this information, you would expect to complete the addition in 8 weeks at a cost of $12,600 . If you crashed the project, you could get it done in a little over 5 weeks, but it would cost an additional $5,750.

A simple project like this can be done fairly easily with paper in pencil. A larger project (like the Polaris submarine, for example), requires a computer program, such as Microsoft Project for Windows.

Definitions

Program management tools make a few assumptions, and use only a few technical terms.

PERT and CPM assume that all activities have distinct beginning and ending points. In the earlier example of constructing an addition to a house, the landscaping activity might not need to be a distinct activity-as time is available, workers could push the fill back around the foundation, police the site, and grade the soil. But PERT could not readily take those random opportunities into account.

PERT and CPM also assume that the estimates of the time needed can be well-defined mathematically. It takes a fair bit of experience to accurately gauge the time a task will take. Barring such experience, time estimates will be highly variable and the quantitative measures of "normal" time and the probability estimates of completion time will be highly unreliable.

Third, resources must be able to be shifted from one activity to another. In the housing addition example, a carpenter's slack time cannot be shifted to an electrician's job or vice versa (the Trades and the Building Inspector would not approve). On the other hand, the dollars spent for hiring labor can be shifted from carpenters to electricians fairly easily. It depends on whether you are scheduling your work crews or hiring workers whether or not (in this example) you can shift resources.

Fourth, quantitative analysis in PERT and CPM assume that cost is a direct function of time and that those costs are evenly spread over the time (i.e., there is no "lumpiness" of activities). For example, the cost of sheetrocking is mostly in the early stages of screwing the sheetrock to the studs and the original taping. The subsequent sanding and additional layers of mud take a relatively short time, but require at least a day for drying between each application of mud. There is no cost to this drying time, but it cannot be shortened. In cases like these, fractional increases or decreases in time may not make sense.

Finally, PERT and CPM assume that the time value of money is not an issue. In other words, there is no need to consider discounting of future costs (or benefits), nor are there indirect monetary benefits to time (other than those incorporated in the costs to "crash" the time). For most projects, these assumptions are acceptable. For really large-scale projects (like the Polaris submarine project, or even the construction of, say, a civic center), the model can be adjusted to include discounting or (for example) the time-value of money as reflected in the construction-mortgage rate.

There are also a few technical terms used in PERT and CPM:

Interpretation

Interpreting PERT and CPM is fairly straightforward. They do not tell you what to do, but they provide the consequences in terms of time and resources (usually, money) of alternative choices you might make given the assumptions you built into the analysis.

It is generally a good idea to review the five assumptions whenever you interpret the results of a program management analysis, particularly CPM:

  1. All tasks have distinct beginning & ending points
  2. Time estimates are quantitatively well-defined
  3. Resources can be shifted from one task to another
  4. Cost of each activity is evenly spread over time
  5. No discounting or indirect costs

The probability of meeting the expected time, which is part of PERT, also requires some explanation. By adding the standard deviation of the time estimate for each activity into a pooled estimate, you create the opportunity to estimate the probability of completing the project within a certain time. This is a crude estimate (not a guarantee!). If the pooled deviations are treated as confidence limits (if these words don't make sense, get hold of a statistics text and review the concept), then 95% of the time the project can be expected to be completed somewhere between -2 and +2 times the probability of the expected time, assuming the distribution of completion times are normally distributed. In other words, if the PERT analysis arrives at an expected completion time of 10 weeks and the probability of that estimate (i.e., the pooled standard deviations of the various tasks) is 1.0, then you can expect that 95% of the time (or, you can predict with 95% confidence) the project will be completed in 8-12 weeks. If you are more of a risk-taker, the confidence interval for + or - 1 standard deviation is about 68%.

MSU

 

© 2005 A.J.Filipovitch
Revised 8 June 2005