SCHEDULE, COST, AND SITUATION ANALYSIS
4.2 SCHEDULE ANALYSIS AND MONITORING
Matters relating to the project schedule were presented briefly in the last chapter in discussing the project plan. Every project plan must have a schedule, although such a schedule is generally an overview of the project, with a detailed schedule included perhaps as an appendix. In this chapter, we examine some of the “nuts and bolts” of project scheduling, exploring particularly the characteristics of the PERT (program evaluation and review technique) approach.
PERT is the preferred scheduling procedure for a large-scale system in which there are large numbers of events and activities that must be identified and tracked. This technique, in distinction to Gantt charting, deals explicitly with dependencies between the various tasks and activities. A PERT network is normally devised by starting with known “end” events and milestones and asking the question: What activities need to be accomplished before this event or milestone can be achieved? By working backward in this fashion, eventually an entire network is developed.
The PERT procedure leads to a network of serial and parallel paths of events and activities. A simple example of such a network was shown in Figure 3.3 of the previous chapter. We use this example here to examine the network itself as well as some of the data that are required to formulate the network.
We first work backward from the end event (number 8) and redraw the network so as to identify the critical path, which is the longest path through the network. This path, by definition, has no slack in it, and slippage along this path leads to slippage in the project end date unless corrections are made.
The redrawn network, based on Figure 3.3, is shown here as Figure 4.1. We note that the critical path now consists of the following sequence of events:
Critical Path=0–1–4–5–7–8
In this example, this path is 8 weeks long. We note that slack exists in various subpaths:
Subpath 0–3–4 has slack of 1 week Subpath 0–2–1 has slack of 1 week Subpath 4–7 has slack of 1 week Subpath 5–6–7 has slack of 1 week
Using the convention that, where slack exists, all activities start as late as possible, we have the network in Figure 4.1. If we used the convention that, where slack exists, all activities will start as early as possible, the network would change by events 2, 3, and 6, all moved to 1 week earlier. If we compare Figures 3.3 and 4.1, we see that in the latter, event 6 has been moved 1 week
January10,200813:32CharCount=
(0) TE = 3
TE = 2
TE = 2 TE = 2
TE = 2
TE = 1
TE = 1
TE = 1
TE = 1 TE = 1
TE = 1
0 1 2 3 4 5 6 7 8
Time, weeks 2
Project environment
examined Project requirements
analyzed
3 COTS alternatives
defined 0
Start
4 Alternative
selected
5 Software purchased
6 Software installed
7 System operation documented
8 Personnel
trained
Figure 4.1. Illustrative project PERT chart.
101
to the right to reflect the convention adopted here of starting an activity as late as possible.
The basis for determining the critical path is the set of time estimates for the various activities in that path. These time estimates are designated as “expected times” (TE) for these activities. In the original PERT procedure [4.4], expected times were derived from three time estimates for each activity:
r An optimistic time (TO) r A most likely time (TL) r A pessimistic time (TP)
Under an assumption of a “beta” distribution for the activity times, the ex- pected time for each activity is calculated as
TE = TO +4TL +TP
6
Some projects still use this three-time estimate procedure in order to develop expected value estimates, but many do not. In the latter case, the expected times are estimated directly and associated with the various project activities, as in Figure 4.1. It is also possible, given the three time estimates, to calculate the activity time variance utilizing the following relationship:
σ2=
TP−TO
6 2
The basic purpose of this calculation is to sum the variances along the critical path and thereby calculate the variance associated with the project end date.
This estimate (or its square root, the standard deviation) yields some measure of the “uncertainty” of this end date. For those who wish to explore uncertainty in this fashion, the preceding relationships are available. For the remainder of this discussion, we limit our scope to the use of expected values of activity times.
Analysis of a schedule, given the basic network and the time estimates, starts with the determination of the critical path. If we are able to shorten the critical path, then it may be possible to reduce the overall project schedule.
Thus, each activity along the critical path should be reexamined to see if reductions in time are feasible. This is especially important if, in a project that has missed earlier milestones on the critical path, the Project Manager is looking for ways to get back on schedule. If the reduction of activity times along the critical path leads to another path becoming critical, then the same procedure would apply to the new critical path.
The next aspect of analyzing a network schedule is the examination of slack along noncritical subpaths so as to establish where the slack is to be placed. The Project Manager has that prerogative, and the decisions in this
regard are deceptively complex. The PM can use the conventions discussed before or can attempt to base a decision on personnel availability. If personnel are available, the PM may elect to start as soon as possible; if they are not available, the PM will likely start an activity when they become available as long as the critical path is not increased. Thus, there is an interaction between the schedule network and the availability of personnel. In general, the PM tries to “level” the resources across a project as long as such leveling does not force an increase in the overall critical path.
Another aspect of the interaction between personnel assignments and schedule is the obvious fact that, within limits, it may be possible to re- duce activity times by adding resources. Thus, we have the PERT “anomaly”
that allows one to estimate activity times without explicit consideration of the resources that will be applied to these activities. Working back and forth between activity times and personnel assignments can be a complex analysis task. It may be facilitated by using project management software, as discussed in Chapter 12. In general, considerable effort may be necessary to “optimize”
a complex project schedule, that is, to derive a schedule that meets internal and customer requirements and also makes the best possible use of personnel and other project resources (e.g., facilities). Best use includes minimizing personnel down time (maximizing personnel utilization).
A final project schedule should be based upon the foregoing considerations and the Project Controller is often the person who attempts to optimize this schedule with respect to both time and utilization of resources. Unfortunately, this process is normally repeated numerous times as the inevitable changes and slippages occur. Most projects require juggling and rescheduling as the differences between reality and plan begin to surface. For this reason, a good PC who is able to reschedule quickly and efficiently can have a major influence on the success, or lack of it, of a complicated project.
We pause here to comment upon a subject that does not generally receive enough attention in the world of schedule and cost analysis and tracking.
That subject is the manner in which input time and dollar estimates are provided. The GIGO (garbage-in, garbage-out) principle clearly suggests that we can be in serious difficulty if we are not careful about how we obtain input data.
Input estimates, of course, are provided as the first order of business as we prepare schedules and budgets. Once a project is up and running, an information system provides automated reports on current status, but we still require new inputs, at least every month, on time and cost to complete.
Treating these inputs in a cursory manner can be a disaster waiting to happen.
Following one simple rule can help us solve a host of problems with respect to poor input estimates. That rule is that we require multiple independent estimates in all areas in which we are likely to run into problems. A more conservative approach is simply to apply that rule for all schedule and cost estimates. Following the rule means that we obtain inputs from more than one person and, further, that the folks who provide the inputs are required to not
discuss the matter with the other estimators before they make their estimates.
A simple “rule of 2 or 3” is that two people are asked for inputs for most situations, and three folks provide independent inputs for very important or critical situations.
For example, if we are approaching the last 3 months of a one-year project being carried out on a firm fixed price (FFP) contract, we might consider invoking the “rule of 3” for time and cost to complete estimating. If we get similar results from the 3 estimators, we can have considerable confidence in these inputs. If we get disparate inputs, it’s time to call a meeting to resolve the disparity. The objective, of course, is to zero in on the best input data we can produce as we move into the final stretch of an important project. Another example is that of estimating the cost and schedule of a software development project. Chapter 10 will define the COCOMO (Constructive Cost Model) method for providing these cost and schedule estimates, both of which are seriously dependent upon estimates of delivered source instructions (DSI).
Therefore, if the DSI estimates are incorrect at the beginning, much trouble is in store for the project. Applying the “rule of 3” for the initial (as well as updated) estimates is likely to pay great dividends during the life of the project.