Constructing the Project Network Diagram

,

At this point in the PMLC, you have identified the known set of tasks in the project as output from building the RBS and WBS as well as the task duration for the project. Next, the planning team needs to determine the order in which these tasks are to be performed.

The tasks and the task duration are the basic building blocks needed to construct a graphic picture of the project. This graphic picture provides you with the following two additional pieces of schedule information about the project:

• The earliest time at which work can begin on every task that makes up the project
• The earliest expected completion date of the project

This is critical information for the project manager. Ideally, the required resources will be available at the times established in the project plan. This is not very likely, and Chapter 6 discusses how to deal with that problem. But first, you need to know how to create an initial project network diagram and the associated project schedule, which is the focus of this section.

Envisioning a Complex Project Network Diagram

A project network diagram is a pictorial representation of the sequence in which the project work can be done. You need to follow a few simple rules to build the project network diagram.

Recall from Chapter 1 that a project is defined as a sequence of interconnected tasks. You could simply perform the tasks one at a time until they are all complete, but in most projects, this approach would not result in an acceptable completion date. In fact, it results in the longest time to complete the project. Any ordering that allows even one pair of tasks to be worked on concurrently results in a shorter project completion date.

Another approach is to establish a network of relationships between the tasks. You can do this by looking forward through the project. What tasks must be complete before another task can begin? Conversely, you can take a set of tasks and look backward through the project: Now that a set of tasks is complete, what task or tasks could come next? Both methods are valid. The one you use is a matter of personal preference. Are you more comfortable looking backward in time or forward? My advice is to look at the tasks from both angles. One can be a check of the completeness of the other.

The relationships between the tasks in the project are represented in a flow diagram called a network diagram or logic diagram.

Benefits to Network-Based Scheduling

A project schedule can be built using either of the following:

• Gantt chart
• Network diagram

The Gantt chart is the oldest of the two and is used effectively in simple, short-duration types of projects. To build a Gantt chart, you begin by associating a rectangular bar with every task. The length of the bar corresponds to the duration of the task. You then place the bars horizontally along a time line in the order in which the tasks should be completed. In some instances you will be able to schedule and work on tasks concurrently. The sequencing is often driven more by resource availability than any other consideration.

There are two drawbacks to using the Gantt chart. They are as follows:

• Because of its simplicity, the Gantt chart does not contain detailed information. It reflects only the order imposed by the manager and, in fact, hides much of that information. In other words, the Gantt chart does not contain all of the sequencing information that exists. Unless you are intimately familiar with the project tasks, you cannot tell from the Gantt chart what must come before and after what.
• The Gantt chart does not tell the project manager whether the schedule that results from the chart completes the project in the shortest possible time or even uses the resources most effectively. The Gantt chart reflects only when the manager would like to have the work done.

Although a Gantt chart is easier to build and does not require the use of an automated tool, I recommend using the network diagram. The network diagram provides a visual layout of the sequence in which project work flows. It includes detailed information and serves as an analytical tool for project scheduling and resource management problems as they arise during the life of the project. In addition, the network diagram enables you to compute the earliest time at which the project can be completed. That information does not follow from a Gantt chart.

Network diagrams can be used for detailed project planning, during implementation as a tool for analyzing scheduling alternatives, and as a control tool as described here:

Building the Network Diagram Using the Precedence Diagramming Method

One early method for representing project tasks as a network dates back to the early 1950s and the Polaris Missile Program. It is called the task-on-the-arrow (TOA) method. As Figure 5-14 shows, an arrow represents each task. The node at the left edge of the arrow is the event that begins the task, and the node at the right edge of the arrow is the event that ends the task. Every task is represented by this configuration. Nodes are numbered sequentially, and in the early versions of this method, the sequential ordering had to be preserved. Because of the limitations of the TOA method, ghost tasks had to be added to preserve network integrity. Only the simplest of dependency relationships could be used. This method proved to be quite cumbersome as networking techniques progressed. This approach is seldom used these days.

Figure 5-14: The TOA method

With the advent of the computer, the TOA method lost its appeal, and a new method replaced it. This method is called the task-on-the-node (TON) method, or more commonly, the precedence diagramming method (PDM).

The basic unit of analysis in a network diagram is the task. Each task in the network diagram is represented by a rectangle called a task node. Arrows represent the predecessor/successor relationships between tasks. Figure 5-15 shows an example of a project network diagram in PDM format. You take a more detailed look at how the PDM works later in this chapter.

Figure 5-15: PDM format of a project network diagram

Every task in the project will have its own task node (see Figure 5-16). The entries in the task node describe the time-related properties of the task. Some of the entries describe characteristics of the task, such as its expected duration (E), whereas others describe calculated values (ES, EF, LS, and LF) associated with that task. (These terms will be defined shortly, and you'll see examples of their use.)

Figure 5-16: Task node

In order to create the network diagram using the PDM, you need to determine the predecessors and successors for each task. To do this, you ask: “What tasks must be complete before I can begin this task?” Here, you are looking for the technical dependencies between tasks. After a task is complete, it will have produced an output, which is a deliverable that becomes input to its successor tasks. Work on the successor tasks requires only the output from its predecessor tasks.

What is the next step? Although the list of predecessors and successors to each task contains all the information you need to proceed with the project, it does not represent the information in a format that tells the story of your project. Your goal is to provide a graphical picture of the project. To do that, you need to understand a few rules. When you know the rules, you can create the graphical image of the project. This section teaches you the simple rules for constructing a project network diagram.

The network diagram is logically sequenced to be read from left to right. With the exception of the start and end tasks, every task in the network must have at least one task that comes before it (its immediate predecessor) and one task that comes after it (its immediate successor). A task begins when its predecessors have been completed. The start task has no predecessor, and the end task has no successor. These networks are called connected. They are the type of network used in this book. Figure 5-17 gives examples of how the variety of relationships that might exist between two or more tasks can be diagrammed.

Figure 5-17: Diagramming conventions

Dependencies

A dependency is simply a relationship that exists between pairs of tasks. To say that task B depends on task A means that task A produces a deliverable that is needed in order to do the work associated with task B. There are four types of task dependencies, as illustrated in Figure 5-18.

Figure 5-18: Dependency relationships

The four task dependencies shown in the figure are as follows:

Constraints

The type of dependency that describes the relationship between tasks is determined as the result of constraints that exist between those tasks. Each type of constraint can generate any one of the four dependency relationships. The following four types of constraints will affect the sequencing of project tasks and, hence, the dependency relations between tasks:

• Technical constraints
• Management constraints
• Interproject constraints
• Date constraints

The following sections describe each of these constraint types in more detail.

Technical Constraints

Technical dependencies between tasks arise because one task (the successor) requires output from another (the predecessor) before work can begin on it. In the simplest case, the predecessor must be completed before the successor can begin. I advise using FS relationships in the initial construction of the network diagram because they are the least complex and risk-prone dependencies. If the project can be completed by the requested date using only FS dependencies, there is no need to complicate the plan by introducing other, more complex and risk-prone dependency relationships. SS and FF dependencies will be used later when you analyze the network diagram for schedule improvements.

Within the category of technical constraints, the following four related situations should be accounted for:

Management Constraints

A second type of dependency arises as the result of a management-imposed constraint. For example, suppose the product manager on a software development project is aware that a competitor will soon introduce a new product with similar features. Rather than follow the concurrent design-build strategy, the product manager wants to ensure that the design of the new software will yield a product that can compete with the competitor's new product. He or she expects design changes in response to the competitor's new product and, rather than risk wasting the programmers' time, imposes the FS dependency between the design and build tasks.

You'll see management constraints at work when you analyze the network diagram and as part of the scheduling decisions you make as project manager. Dependencies based on management constraints differ from technical dependencies in that they can be reversed, whereas technical dependencies cannot. For example, suppose the product manager finds out that the competitor has discovered a fatal flaw as a result of beta testing and has decided to indefinitely delay the new product introduction pending resolution of the flaw. The decision to follow the FS dependency between design and build can now be reversed, and the concurrent design-build strategy can be reinstituted. That is, management will have the project manager change the design-build dependency from FS to SS.

Interproject Constraints

Interproject constraints result when deliverables from one project are needed by another project. Such constraints result in dependencies between the tasks that produce the deliverable in one project and the tasks in the other project that require the use of those deliverables. For example, suppose a new piece of test equipment is being manufactured by the same company that is developing the software that will use the test equipment. In this case, the start of the testing tasks in the software development project depends on the delivery of the manufactured test equipment from the other project. The dependencies that result are technical but exist between tasks in two or more projects, rather than within a single project.

Interproject constraints arise when a very large project is decomposed into smaller, more manageable projects. For example, the construction of the Boeing 777 took place in a variety of geographically dispersed manufacturing facilities. Each manufacturing facility defined a project to produce its part. To assemble the final aircraft, the delivery of the parts from separate projects had to be coordinated with the final assembly project plan. Thus, there were tasks in the final assembly project that depended on deliverables from other sub-assembly projects.

Date Constraints

At the outset, I want to make it clear that I do not approve of using date constraints. I avoid them in any way I can. In other words, “just say no” to typing dates into your project management software. If you have been in the habit of using date constraints, read on.

Date constraints impose start or finish dates on a task, forcing it to occur according to a particular schedule. In this date-driven world, it is tempting to use the requested date as the required delivery date. These constraints generally conflict with the schedule that is calculated and driven by the dependency relationships between tasks. In other words, date constraints create unnecessary complication in interpreting the project schedule.

The three types of date constraints are as follows:

All of these date constraints can be used on the start or finish side of a task. The most troublesome application is the on-this-date constraint. It firmly sets a date and affects all tasks that follow it. The result is the creation of a needless complication in the project schedule and in reporting the status of the project as it progresses. The next most troublesome date constraint is the no-later-than constraint. It will not allow a task to occur beyond the specified date. Again, you are introducing complexity for no good reason. Both on-this-date and no-later-than constraints can result in negative slack. If at all possible, do not use them. There are alternatives, which are discussed in the next chapter.

The least troublesome date constraint is the no-earlier-than constraint. At worst, it simply delays a task's schedule and by itself cannot cause negative float.

Using the Lag Variable

Pauses or delays between tasks are indicated in the network diagram through the use of lag variables. Lag variables are best described with an example. Suppose that data is being collected by mailing out a survey and is entered as the surveys are returned. Imposing an SS dependency between mailing out the surveys and entering the data would not be feasible unless you introduced some delay between mailing surveys and getting back the responses that could be entered. For the sake of the example, suppose that you wait 10 days from the date you mail the surveys until you schedule entering the data from the surveys. Ten days is the time you think it will take for the surveys to arrive at the recipient locations, for the recipients to answer the survey questions, and for the surveys to be returned to you by mail. In this case, you have defined an SS dependency with a lag of 10 days. To put it another way, task B (data entry) can start 10 days after task A (mailing the survey) has started.

Creating an Initial Project Network Schedule

As mentioned, all tasks in the network diagram have at least one predecessor task and one successor task, with the exception of the start and end tasks. If this convention is followed, the sequence is relatively straightforward to identify. However, if the convention is not followed, if date constraints are imposed on some tasks, or if the resources follow different calendars, understanding the sequence of tasks that result from this initial scheduling exercise can be rather complex.

To establish the project schedule, you need to compute two schedules: the early schedule, which you calculate using the forward pass, and the late schedule, which you calculate using the backward pass.

The early schedule consists of the earliest times at which a task can start and finish. These are calculated numbers derived from the dependencies between all the tasks in the project. The late schedule consists of the latest times at which a task can start and finish without delaying the completion date of the project. These are also calculated numbers that are derived from the dependencies between all of the tasks in the project.

The combination of these two schedules gives you the following two additional pieces of information about the project schedule:

• The window of time within which each task must be started and finished in order for the project to be completed on schedule
• The sequence of tasks that determine the project completion date

The sequence of tasks that determine the project completion date is called the critical path. The critical path can be defined in the following ways:

• The longest duration path in the network diagram
• The sequence of tasks whose early schedule and late schedule are the same
• The sequence of tasks with zero slack or float (as defined later in this chapter)

All of these definitions say the same thing: The critical path is the sequence of tasks that must be completed on schedule in order for the project to be completed on schedule.

The tasks that define the critical path are called critical path tasks. Any delay in a critical path task will delay the completion of the project by the amount of delay in that task. Critical path tasks represent sequences of tasks that warrant the project manager's special attention.

The earliest start (ES) time for a task is the earliest time at which all of its predecessor tasks have been completed and the subject task can begin. The ES time of a task with no predecessor tasks is arbitrarily set to 1, the first day on which the project is open for work. The ES time of tasks with one predecessor task is determined from the earliest finish (EF) time of the predecessor task. The ES time of tasks with two or more predecessor tasks is determined from the latest of the EF times of the predecessor tasks. The earliest finish (EF) time of a task is calculated as ((ES + Duration) – One Time Unit). The reason for subtracting the one time unit is to account for the fact that a task starts at the beginning of a time unit (hour, day, and so forth) and finishes at the end of a time unit. In other words, a one-day task, starting at the beginning of a day, begins and ends on the same day. For example, in Figure 5-19 note that task E has only one predecessor: task C. The EF for task C is the end of day 3. Because it is the only predecessor of task E, the ES of task E is the next day, the beginning of day 4. Conversely, task D has two predecessors: task B and task C. When there are two or more predecessors, the ES of the successor (task D in Figure 5-19) is calculated based on the maximum of the EF dates of the predecessor tasks. The EF dates of the predecessors are the end of day 4 and the end of day 3. The maximum of these is 4; therefore, the ES of task D is the morning of day 5. The complete calculations of the early schedule are shown in Figure 5-19.

Figure 5-19: Forward-pass calculations

The latest start (LS) and latest finish (LF) times of a task are the latest times at which the task can start or finish without causing a delay in the completion of the project. Knowing these times is valuable for the project manager, who must make decisions regarding resource scheduling that can affect completion dates. The window of time between the ES and LF of a task is the window within which the resource for the work must be scheduled or the project completion date will be delayed. To calculate these times, you work backward in the network diagram. First set the LF time of the last task on the network to its calculated EF time. Its LS is calculated as ((LF – Duration) + One Time Unit). Again, you add the one time unit to adjust for the start and finish of a task within the same day. The LF time of all immediate predecessor tasks is determined by the minimum of the LS, minus one time unit, times all tasks for which it is the predecessor.

For example, calculate the late schedule for task E in Figure 5-20. Its only successor, task F, has an LS date of day 10. The LF date for its only predecessor, task E, will therefore be the end of day 9. In other words, task E must finish no later than the end of day 9 or it will delay the start of task F and hence delay the completion date of the project. Using the formula, the LS date for task E will be 9 – 2 + 1, or the beginning of day 8. Conversely, consider task C. It has two successor tasks: task D and task E. The LS dates for these tasks are day 5 and day 7, respectively. The minimum of those dates, day 5, is used to calculate the LF of task C — namely, the end of day 4. The complete calculations for the late schedule are shown in Figure 5-20.

Figure 5-20: Backward-pass calculations

Critical Path

As mentioned, the critical path is the longest path or sequence of tasks (in terms of task duration) through the network diagram. The critical path drives the completion date of the project. Any delay in the completion of any one of the tasks in the sequence will delay the completion of the project. You should pay particular attention to critical path tasks. The critical path for the example problem you used to calculate the early schedule and the late schedule is shown in Figure 5-21.

Figure 5-21: Critical path

Calculating Critical Path

One way to identify the critical path in the network diagram is to identify all possible paths through the diagram and add up the durations of the tasks that lie along those paths. The path with the longest duration time is the critical path. For projects of any size, this method is not feasible, and you have to resort to the second method of finding the critical path: computing the slack time of a task.

Computing Slack

This method of finding the critical path requires you to compute a quantity known as the task slack time. Slack time (also called float) is the amount of delay, expressed in units of time, that could be tolerated in the starting time or completion time of a task without causing a delay in the completion of the project. Slack time is a calculated number. It is the difference between the late finish and the early finish (LF – EF). If the result is greater than zero, the task has a range of time in which it can start and finish without delaying the project completion date, as shown in Figure 5-22.

Figure 5-22: ES-to-LF window of a task

Because weekends, holidays, and other nonwork periods are not conventionally considered part of the slack, these must be subtracted from the period of slack.

There are two types of slack, as follows:

Based on the method you used to compute the early and late schedules, the sequence of tasks having zero slack is defined as the critical path. If a task has been date-constrained using the on-this-date type of constraint, it will also have zero slack. However, this constraint usually gives a false indicator that a task is on the critical path. Finally, in the general case, the critical path is the path that has minimum slack.

Near-Critical Path

Even though project managers are tempted to rivet their attention on critical path tasks, other tasks also require their attention. These make up what is called a near-critical path. The full treatment of near-critical tasks is beyond the scope of this book. I introduce the concept here so that you are aware that paths other than critical paths are worthy of attention. As a general example, suppose the critical path tasks are tasks with which the project team has considerable experience. In this case, duration estimates are based on historical data and are quite accurate in that the estimated duration will be very close to the actual duration.

Conversely, suppose there is a sequence of tasks not on the critical path with which the team has little experience, so the duration estimates have large estimation variances. Also suppose that such tasks lie on a path that has little total slack. It is very likely that this near-critical path may actually drive the project completion date even though the total path length is less than that of the critical path. This situation will happen if larger-than-estimated durations occur. Because of the large duration variances, such a case is very likely. Obviously, this path cannot be ignored.

Analyzing the Initial Project Network Diagram

After you have created the initial project network diagram, one of the following two situations will be present:

• The initial project completion date meets the requested completion date. Usually this is not the case, but it does sometimes happen.
• The more likely situation is that the initial project completion date is later than the requested completion date. In other words, you have to find a way to squfeeze some time out of the project schedule.

You eventually need to address two considerations: the project completion date and resource availability under the revised project schedule. The following section is based on the assumption that resources will be available to meet this compressed schedule. Later in this chapter, the resource-scheduling problem is addressed. The two are quite dependent on one another, but they must be treated separately.

Compressing the Schedule

Almost without exception, the initial project calculations will result in a project completion date beyond the required completion date. That means the project team must find ways to reduce the total duration of the project to meet the required date.

To address this problem, you analyze the network diagram to identify areas where you can compress project duration. Look for pairs of tasks that allow you to convert tasks that are currently worked on in series into patterns of work that are more parallel. Work on the successor task might begin once the predecessor task has reached a certain stage of completion. In many cases, some of the deliverables from the predecessor can be made available to the successor so that work might begin on it.

You first need to identify strategies for locating potential dependency changes. Focus your attention on critical path tasks because these are the tasks that determine the completion date of the project, the very thing you want to have an impact on. You might be tempted to look at critical path tasks that come early in the life of the project, thinking that you can get a jump on the scheduling problem, but this usually is not a good strategy for the following reason: At the early stages of a project, the project team is little more than a group of people who have not worked together before (I refer to them as a herd of cats). Because you are going to make dependency changes (FS to SS), you are going to introduce risk into the project. Your herd of cats is not ready to assume risk early in the project. You should give them some time to become a real team before intentionally increasing the risk they will have to contend with. That means you should look downstream on the critical path for those compression opportunities.

A second factor to consider is focusing on tasks that are partitionable. A partitionable task is one whose work can be assigned to two or more individuals working in parallel. For example, painting a room is partitionable. One person can be assigned to each wall. When one wall is finished, a successor task, such as picture hanging, can be done on the completed wall. That way, you don't have to wait until the room is entirely painted before you can begin decorating the walls with pictures.

Writing a computer program may or may not be partitionable. If it is partitionable, you could begin a successor task like testing the completed parts before the entire program is complete. Whether a program is partitionable depends on many factors, such as how the program is designed, whether the program is single-function or multifunction, and other considerations. If a task is partitionable, it is a candidate for consideration. You might be able to partition it so that when some of it is finished, you can begin working on successor tasks that depend on the part that is complete. After you have identified a candidate set of partitionable tasks, you need to assess the extent to which the schedule might be compressed by starting the task's successor task earlier. There is not much to gain by considering tasks with short duration times. I hope I have given you enough hints at a strategy to help you find opportunities to compress the schedule that you will be able to find those opportunities quite easily. If you can't, don't worry. The next chapter gives you other suggestions for compressing the schedule.

Assume you have found one or more candidate tasks to work with. See what happens to the network diagram and the critical path as dependencies are adjusted. As you begin to replace series (SF dependencies) with parallel sequences of tasks (SS dependencies), the critical path may change to a new sequence of tasks. This change will happen if, because of your compression decisions, the length of the initial critical path is reduced to a duration that is less than that of some other path. The result is a new critical path. Figure 5-23 shows two iterations of the analysis. The top diagram is the original critical path that results from constructing the initial network diagram using only FS dependencies. The critical path tasks are identified with a filled dot.

The middle diagram in Figure 5-23 is the result of changing the dependency between tasks A and B from FS to SS. Now the critical path has changed to a new sequence of tasks. The tasks with filled triangles illustrate the new critical path. If you change the FS dependency between tasks C and D, the critical path again moves to the sequence of tasks identified by the filled squfares.

Figure 5-23: Schedule compression iterations

Occasionally, some tasks always remain on the critical path. For example, notice the set of tasks that have a filled circle, triangle, and squfare in Figure 5-23. They have remained on the critical path through both changes. This set of tasks identifies a bottleneck in the project schedule. Although further compression may result in this set of tasks changing, this set of bottleneck tasks does identify a set of tasks deserving of particular attention as the project commences. Because all critical paths generated to this point pass through this bottleneck, you might want to take steps to ensure that these tasks do not fall behind schedule.

Management Reserve

Management reserve is a topic associated with task duration estimates, but it more appropriately belongs in this section because it should be a property of the project network more so than of the individual tasks.

At the individual task level, you might be tempted to pad your estimates to have a better chance of finishing a task on schedule. For example, you know that a particular task will require three days of your time to complete, but you submit an estimate of four days just to make sure you can get the three days of work done in the four-day schedule you hope to get for the task. The one day that you add is padding. First, let's agree that you will not do this. Parkinson's Law (which states that work will expand to the time allotted to complete it) will surely strike you down, and the task will, in fact, require the four days you estimated it would take. Stick with the three-day estimate and work to make it happen. That is a better strategy. Now that you know padding is bad at the task level, you are going to apparently contradict yourself by saying that it is all right at the project level. There are some very good reasons for this.

Management reserve is nothing more than a contingency budget of time. The size of that contingency budget can be in the range of 5 to 10 percent of the total of all the task durations in your project. The size might be closer to 5 percent for projects having few unknowns, or it could be closer to 10 percent for projects using breakthrough technologies or that are otherwise very complex. After you have determined the size of your management reserve, you create a task whose duration is the size of management reserve and put that task at the end of the project. It will be the last task, and its completion will signal the end of the project. This management reserve task becomes the last one in your project plan, succeeded only by the project completion milestone.

What is this management reserve used for? First, the project team should manage the project so that the reserve task is not needed — though in reality, this is rarely possible. The date promised to the client is the one calculated by the completion of the reserve task. The reserve task's duration can be shortened as necessary. For example, if the critical path slips by two days, the reserve task's duration will be reduced by two days. This holds the project completion date constant.

This technique keeps the management reserve task visible and enables you to manage the rate at which it's being used. If 35 percent of the overall project time line has elapsed and 50 percent of the reserve task has been used, you know you're heading for trouble.

Second, management reserve can be used as incentive for the project team. For example, many contracts include penalties for completing milestones later than planned, as well as rewards for completing milestones ahead of schedule. Think of management reserve as a contingency fund that you do not want to spend. Every day that is left in the contingency fund at the completion of the project is a day ahead of schedule for which the client should reward you. Conversely, if you spend that contingency fund and still require more time to complete the project, this means that the project was completed later than planned. For every day that the project is late, you should expect to pay a penalty.