Network Analysis


Networks have been used since the early 1950s, when Lockheed and Booz Allen Hamilton developed the project evaluation review technique (PERT) for the Navy's Polaris missile program. Since then, several other network techniques have been developed to compensate for some shortcomings in the PERT method and to provide additional capabilities. Although the PERT network method is still used occasionally, the most common network analysis technique is the precedence diagram method (PDM). This technique eliminates some of the problems with PERT, but it owes its popularity to Microsoft Project and other project management software because it is easier to program. Since PDM is the generally preferred and used network tool, only its development and analysis is shown in this chapter. However, the PERT technique will be discussed in Chapter 6 as a risk mitigation tool. You can find more detailed discussions of PERT and other networking techniques in most basic project management texts.

The first step in developing the project schedule is to estimate the duration of each individual task. Duration estimation should include any contingencies to plan against potential resource shortages. That is, the best-case scenario should not be assumed for the duration—neither should the worst-case scenario. The duration is usually taken to be the average of similar tasks from the organization's historical database. But those tasks at risk, relative to potentially unavailable resource numbers or skills, should be planned with a contingency factor. One of the major benefits of the PDM method is that it can accommodate and track this kind of planning, whereas the PERT method cannot.

Task leaders typically estimate duration and labor requirements, but some organizations prefer that the functional managers make those estimates, since they are the ones who allocate resources and better understand project priorities. Once all task durations are estimated, the next step is to determine task interdependencies.

Determining task interdependencies is a team effort because each task leader will better understand what she needs as output from other tasks before she can finish her own effort. Task interdependencies drive the schedule because some tasks simply cannot begin until other tasks are completed. For example, the task of system design must be completed before system construction begins. On the other hand, some tasks have no dependencies and can be accomplished in parallel with other tasks. The testing of a completed subsystem, for example, can be accomplished while another subsystem is in development. So careful examination of task interdependencies can shorten the schedule, if two or more tasks are done at the same time rather than sequentially. However, doing this may add substantial risk to the project, which is the trade-off against potential schedule improvement.

For example, you may have planned a technology survey before designing a critical subsystem, but you may then decide to begin the design and survey at the same time in order to use the survey results to validate your understanding of the state of the available technology. If your knowledge of the available technology is current, this approach is viable and could improve the schedule significantly. However, if the survey comes back indicating that your choice of system components is obsolete, then not only have you not improved the schedule, but very likely you have created a schedule slip. Considering each task in turn, and its relationship to every other project task, results in a precedence table, as shown in Exhibit 2-6.

Exhibit 2-6: Sample precedence table.

start example

Task Alphabetical Identifier

WBS Tasks

Precedence

Task Duration (Weeks)

a

Develop system architecture.

4

b

Design software modules.

a

8

c

Write code.

b

12

d

Design hardware subsystems.

a

6

e

Build hardware subsystems.

d

4

f

Write test plans.

a

2

g

Test software.

c, f

2

h

Test hardware.

e, f

1

i

Integrate software and hardware.

g, h

3

j

Test system.

i

2

k

Install system.

j

1

end example

The precedence table lists the tasks of a project or a phase, the tasks that must be accomplished before each other task can begin, and the estimated duration of each. The precedence diagram is developed from the precedence table. Exhibit 2-7 is the PDM representation of the Exhibit 2-6 table information.

Exhibit 2-7: A precedence diagram.

start example

click to expand

end example

The alphabetical task identifiers are used purely for convenience so that the entire task description does not have to be written on the node. The task leader, taking into account the experiences of previous similar task efforts, usually determines the duration of each of the tasks. It is worth repeating that the task duration estimate takes resource availability into account. Otherwise the network analysis to determine the project schedule will be meaningless.

The first step in analyzing any network is to determine the early schedule—that is, the earliest each task can begin and end. The early schedule is determined by beginning at node a and working from left to right through each path. A path follows the arrows from the beginning to the end of the project. For example, tasks a, b, c, g, i, j, and k is a path. The early start (ES) and early finish (EF) of each task is recorded in the upper left and right corners, as shown in Exhibit 2-8. Starting at node a, the earliest the task can begin is at zero. The earliest it can finish is week four, since the estimated duration of the task is four weeks. The earliest that tasks b, f, and d can begin is after task a ends, or after the fourth week. Hence the early start for these three tasks is week four. Note that these times are accumulated times. That is, task b begins after a total of four weeks has been expended in the schedule. The early start for each task is the early finish of the preceding task, except when two or more tasks feed into it, such as at tasks g, h, and i. When two or more tasks feed into a succeeding task, then the early start time is the larger of the preceding early finish time possibilities. Hence, ES for task g is twenty-four weeks because the EF of task c is larger than the EF of task f. Finally, the EF of task k, thirty-two weeks, determines the schedule for the project. That is, thirty-two weeks is the earliest that the project can be accomplished given the available resources.

Exhibit 2-8: Network showing early schedule.

start example

click to expand

end example

Determining the late schedule—that is, the latest a task can begin and end and still meet the estimated schedule of thirty-two weeks in the example—is done by working backward through the network. The late start (LS) and late finish (LF) times are recorded in the lower left and right corners of each node. To calculate LS and LF, begin at node k by recording thirty-two weeks in the LF box. The late finish of the last node is always the EF for that task because we want to determine how late the tasks can be started and ended without changing the estimated project schedule. The task duration is subtracted from the LF to obtain the LS for the task. Therefore, the late start for task k is thirty-one. The LF number for each task is the LS of the succeeding one. Thus, the LF for task j is thirty-one. The LS and LF for each task is calculated in the same manner backward through the network, except where two or more arrows back into a node. In those instances, such as for nodes f and a, then the LF is the smaller of the two LS possibilities. The completed network with the early and late schedules is shown in Exhibit 2-9. The heavy arrows indicate the critical path (i.e., the longest path through the network).

Exhibit 2-9: Completed network showing late schedule and critical path.

start example

click to expand

end example

Slack (sometimes referred to as float) is calculated by subtracting the EF from the LF of a task. For example, the slack in task h is: LF - EF, which equals 26 - 15, which equals 11 weeks. Note that tasks a, b, c, g, i, j, and k do not have any slack. Not having slack on a path is also a defining characteristic of a critical path, and the tasks on it are called critical tasks. Critical in the context of network analysis means that if any one of those tasks slips, then the project schedule is affected. Hence, it is vital that these tasks be accomplished on time or ahead of schedule, but not later than planned.




Managing Information Technology Projects
Managing Information Technology Projects: Applying Project Management Strategies to Software, Hardware, and Integration Initiatives
ISBN: 0814408117
EAN: 2147483647
Year: 2003
Pages: 129
Authors: James Taylor

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net