Ads

Categories:

- A Case in Point
- Assigning Resources
- Choosing an Organizational Form
- Considering Dependencies
- Creating the Work Breakdown Structure
- Defining the Goal and Scope of the Software
- Determining Project Risks
- Developing the Software Requirements Specification
- Eliciting Requirements
- Estimating Duration and Cost
- identifying the tasks and activities
- Introduction
- Introduction to Software Engineering
- Managing Domain Processes
- Process Overview
- Reliability
- Scheduling the Work
- Selecting a Project Team
- Selecting Software Development Life Cycles
- Software Size and Reuse Estimating

Popular Posts:

Archive:

- April 2013
- May 2013
- June 2013
- July 2013
- August 2013
- September 2013
- October 2013
- November 2013
- December 2013
- January 2014
- February 2014
- March 2014
- April 2014
- May 2014
- June 2014
- August 2014
- September 2014
- October 2014
- November 2014
- December 2014
- January 2015
- February 2015
- March 2015
- April 2015
- May 2015
- June 2015
- July 2015
- August 2015
- January 2016
- February 2016
- January 2017
- May 2017

Popular Tags:

Views (1152)

On October 13, 2014, In Scheduling the Work by Admin

These two methods of schedule analysis have been around since the 1950s, and form the foundation of what the profession knows about scheduling today. CPM (critical path method) was developed by DuPont in 195859, and uses fixed-time estimates for each activity. PERT (program evaluation and review technique) was developed for the U.S. Navy Special Projects Office Polaris missile submarine project by the consultants Booz, Allen, and Hamilton during the same years.

Both PERT and CPM use network-diagramming techniques to illustrate activity precedence. But most scheduling today is done using CPM. First we'll look at the major difference between the two methods (point estimate or weighted average), and then see how to use network diagramming for CPM analysis.

The beta distribution was chosen for PERT instead of the normal distribution because it more closely resembles people's behavior when estimating. We are naturally optimistic, which skews the results to the left. Some call the beta distribution the "Murphy's Law distribution". Note that the tails of the distribution intersect the X-axis and do not trail off toward the sides (they are not asymptotic). This means that there is no chance at all of an actual duration being zero or infinity. If the actual duration is shorter than the most likely, it will not be much shorter (to the left), but if it is longer, then it could be a lot longer (to the right). The message is "when things go badly, they go very badly". Actually, since we only use three estimates in PERT, you would get a triangular distribution if plotted. The PERT and triangular distributions are shown together in Figure 2.

The formula for the weighted average of PERT is actually the mean of the triangular distribution used as an approximation of the beta, by experimentation. This is because in the 1950s, computing power to crunch the actual mean of the beta distribution was not available. The formula for computing the weighted average is:

Since scheduling a lot of activities with three estimates is computationally messy, and many people argue that three "estimates" are not that much more accurate than one "estimate", most project management scheduling software uses the CPM method for scheduling. This results in the fixed-length activity bars we are used to seeing in most Gantt charts. You can compute the three values for each activity in your project plan, and plug them into your Gantt, but if any duration or estimate changes, you must recompute. This is not practical for most project schedules. However, you can use an aftermarket plug-in tool such as @Risk from Palisade Corporation, to plug in the three values and get the resulting PERT mean for your activity durations.

CPM analysis starts with a WBS that has single point estimates for each activity and uses PDM to relate precedence in a network. With the network drawn, you can then perform a two-pass analysis through the network of activities and calculate the node quantities for each activity. Once this is done, you will see the critical path. The critical path for the top network (using circle nodes) in "Scheduling Fundamentals" Figure 5 is path BCDF, and in "Scheduling Fundamentals" Figure 6, it is path BDHI. The critical path for the bottom network in "Scheduling Fundamentals" Figure 5 cannot be determined yet because there is no duration information for the nodes.

To perform the two-path analysis, you first make a forward pass through the network, beginning at the start node, which begins with zeros for both earliest start and earliest finish. In "Scheduling Fundamentals" Figure 5, they are noted at the top of the node as a numbered pair. At node A, the earliest start time will be zero, and the earliest finish time will be zero plus however long it takes to do A. In this case it will be 0 + 10 = 10. Continue following the arrow to C where the earliest start cannot yet be computed because we first need to know the data from node B. Go back to the start node and do the same calculation for B as was done for A. In this case, B will have an earliest start of zero, and an earliest finish of 20 (0 + 20 = 20). With this information, you can now compute C's earliest start time as the longest of A or B (A was 10 and B was 20, so in this case that's 20). Add the duration for C of 30 to get C's earliest finish time of (20 + 30 = ) 50. Continue this process through D and F calculating the earliest start and finish times for each node. Be sure that you traverse each path in the network that feeds into a node to be calculated, or else you will not have all the information necessary to calculate the next earliest start time. The end node's earliest finish time is the total length of the longest path through the network, and is the length of the project (80 in the example of "Scheduling Fundamentals" Figure 5).

With the forward pass complete, you are ready to do the backward pass. Starting at the end node, calculate the latest start and latest finish for each node in the network all the way back to the start node. This time, put the calculated numbers in the pair at the bottom of each node. This will be (80,80) for the end node in "Scheduling Fundamentals" Figure 5. For node F, the latest start time will be the (known) finish time of 80 minus the duration for F (20), so it will be 80 20 = 60, and the latest start/finish pair will be shown as (60,80). For node D, a similar calculation occurs where the latest finish time is the same as the latest start time for node F (just calculated as 60), so 60 minus D's duration of 10 will be 50, and the pair will be (50,60). For node E, the calculation begins with the latest start of F (60) and subtracts E's duration from it (30) giving a latest start time of 30, so the number pair is (30,60). This process continues until you reach the start node and all number pairs have been calculated. The start node should calculate to (0,0).

Notice that for the forward pass, we:

● start at the start node.

● compute the top pair of numbers.

● always add the duration to the connecting node's earliest finish time.

And note that for the backward pass, we:

● start at the end node.

● compute the bottom pair of numbers.

● always subtract the duration from the connecting node's earliest start time.

When completed, each node shows its float as the difference between (either) the earliest start and latest start, or the earliest finish and the latest finish. It doesn't matter which number you use from each pair (start or finish) at a node, as long as both are the first or both are the last. Since the duration used to calculate them is the same number, you will get the same results. This float time means that the activity could start anytime between the earliest start and the latest start, yet still not lengthen the total length of the network (which is the total time for the project).

The critical path will show up as the path indicated by nodes with zero float. The critical paths are indicated in the networks in "Scheduling Fundamentals" Figure 5 and Figure 6 as heavy lines. For "Scheduling Fundamentals" Figure 5, the critical path is BCDF, and for "Scheduling Fundamentals" Figure 6, it is BDHI. Being on the critical path means that if duration grows for any of these nodes, the finish time for the whole project will grow. Conversely, if any of their durations shrink, then the finish time will also shrink. But (and this is a big "but"), any change in the duration of any node may change the critical path, so you would need to recalculate after each node change. Now you see why this is best left to computers! But at least you will now understand what the computer is doing to your schedule.

Notice that in all the calculations we've done to calculate float and find the critical path, we've not considered the availability of any of the resources necessary to actually do the activities. In most organizations, this is a major oversight as the resource availability is what usually constrains the schedule. This is the big weakness of CPM. It is an activity-oriented method that provides activity-constrained schedules. To put more realism into the schedule, we need to map the resources' actual availability to create a resource-constrained schedule.