Editar perfil de usuario

This variation allows for uncertain time estimates for individual tasks. Draw the net-work as in steps 1 through 6 (pages 101–2) of the basic procedure. For scheduling, replace step 7 with:

7. Make three estimates of the time required for each task.

• Minimum (a)—if everything went right

• Most likely (m)—the normal time required; an average of the times if the task were done repeatedly

• Maximum (b)—if everything went wrong

Show all three times on the diagram, separated by dashes: 3–5–8. Next calculate the expected time (t_E) and the variance (s²) for each task.

t a m b b a

E = + + = −







4

6 6

2

2

σ

arrow diagram 107

Go on to steps 8 through 11 (pages 102–104). Use expected time t_Einstead of task time. Then add this step:

12. Determine the probability (P) that the project will be finished by its deadline, T_D. Calculate three numbers.

T_E= total expected time = the sum of the expected times t_Efor all the critical path tasks

s²_T

E= total variance = the sum of the variances for all the critical path tasks

Look up the value for Z on the table of area under the normal curve (Table A.1). The number read from the center of the table, P, is the probability that the project will be finished by its deadline.

Example

To demonstrate these calculations, we will use a critical path with only four tasks. Table 5.1 shows the minimum, most likely, and maximum time estimates (a, m, and b), the expected time (t_E) and the variance (s²). If the deadline for the project is 25 days, then

Z T_D T_E

Z = 0.75. Looking up 0.75 on Table A.1 shows that P = 0.77. The probability of com-pleting the project in 25 days or less is 77 percent.

It may seem surprising that there is a 23 percent chance of not meeting the dead-line, since the total expected time (T_E) for the project is 23.3 days, less than the dead-line. Remember, however, that each task’s time estimate had a worst case. If everything went wrong and all the worst-case estimates came true, the project would require 36 days.

Considerations

• If any task on the critical path is delayed, all tasks on the critical path will be pushed back. If there is no slack in the overall project, the project will be delayed.

• The timing of tasks with some free slack can be left to the judgment of those handling the task, as long as they do not delay the task more than the amount of free slack. Example: The team making benchmark visits can spread its schedule over 12 days instead of the planned six days without consulting with the rest of the project team.

• When tasks without free slack are delayed, the times and slack for all following jobs must be recalculated.

• Slack time can be negative. Example: If the time allotted for the benchmarking project was less than 57 days, or if the critical path tasks become delayed by more than three days, the slack time would become negative, and ways to make up that time would have to be found.

• To speed up a project schedule, find ways to increase resources or reduce scope only for those tasks on the critical path. Speeding up tasks not on the critical path will have no effect on the overall project time. It may be possible to move resources from noncritical tasks to critical ones. Example: To complete the benchmarking project in 10 weeks instead of 12, ways might be found to identify the team faster (task C), to get public data more quickly (task I), to get faster approvals (tasks B and P), or to speed up any of the other six tasks on the critical path. Collapsing the visit schedule (tasks G or M) will not complete the project sooner.

• However, when critical path tasks are shortened, the entire network must be recalculated. New tasks may now be on the critical path, and they can be examined for opportunities to shorten the schedule. Example: In the benchmark project, if a way were found to collect public data (task I) in five days instead of 10, scheduling visits (task G) would now lie on the critical path.

• Another way to shorten the project time is to rethink the sequence of tasks on the critical path. If some of them can be done simultaneously, total project time can be reduced.

arrow diagram 109

• In the arrow diagram process, involve a team of people who have broad knowledge about the project or process.

• The easiest way to construct the diagram when first laying out the sequence is to find the path with the most tasks. Lay out that path first, then add other parallel paths.

• No loops are allowed in the network of tasks. A loop would be a sequence where task A is followed by task B, followed by task C, followed by task A.

• The length of an arrow is not related to the amount of time the task takes. Arrow lengths depend simply on the way you have chosen to depict the network of tasks.

• A common notation labels tasks with their starting and ending events. A task that starts at event 4 and ends at event 7 would be labeled task 4–7.

• For complex networks of tasks, computer software can make constructing and updating the chart quick. Software can also easily construct a Gantt chart and arrow diagram from the same data, ensuring that the two are always consistent with each other as the project progresses and updates are made.

• This chart fills some of the same functions as the Gantt chart. It analyzes the project’s schedule more thoroughly, revealing the critical path and dependencies between tasks. However, the Gantt chart is easier to construct, can be understood at a glance, and can be used for monitoring progress.

• An alternative way of drawing the network is to represent tasks by circles or rectangles (nodes) and connect them with arrows showing sequence. That format is essentially a flowchart. Task time is written within the node, ES and LS are written to the left, separated by a colon (for example, 7:10 for task C), and EF and LF are similarly written to the right. For PERT analysis, the three time estimates are usually written on the arrow leaving the node. This alternative drawing method is easier to draw, but the one described in this book’s procedure shows milestones more clearly.

• A variety of names have been used for this diagram. In general, they are all considered activity network diagrams. The drawing procedure detailed in this book is called activities on the arc or activities on the arrow and the resulting diagram is named arrow diagram. Arrow diagram and activity network diagram are names used in various descriptions of the seven MP tools. The alternative drawing method described above results in activities on the node and the resulting chart is named node diagram. Both methods of scheduling, PERT and CPM, can be used with either form of diagram. Activity chart is another name sometimes used. However, that name has been used for the Gantt chart as well, potentially leading to confusion. Since several names exist for each of these diagrams, it seems simpler to avoid using the name activity chart.