## Diagramming Relationships

The convention used in network diagramming of relationships and leads and lags is that the relationship is shown on the logical arrow only if it is not a finish-start relationship. If there are no leads or lags, no designation is given.

### Project Start and Project Finish Events

Each activity in the diagram will always have a predecessor and a successor if the following convention is used. The convention is to create two events, the start of the project and the finish of the project. An event is a project activity that has zero duration and marks a place of significance in the project. Creating a start and finish event for the project allows all other activities to have at least one predecessor and at least one successor. This convention keeps the diagram tidy and avoids having multiple places in the diagram where the project can start and finish. These are called ''danglers.''

Since nodes (the boxes) represent the activities in the diagram, it is not necessary to create dummy activities to show multiple dependencies in the project being represented. Notice that it is easy to show multiple relationships between activities. Activity 4 in the diagram in Figure 2-3 is dependent on activity 1 and activity 2, as well as the start of the project.

### Logical Precedence Diagram

At this point it is possible to lay out the logical relationships of the project activities. The activities themselves came from the work breakdown structure. There should be a one-to-one correspondence between the activities that resulted at the bottom of the work breakdown structure and the activities that are in the schedule. The logical relationship between the activities is also determined in the development of the work breakdown structure. We accomplished this when we developed the inputs and outputs for each activity in the work breakdown structure. Since inputs required for one activity are the outputs for another activity, this gives us much of the information we need for sequencing the order of the activities.

### Activity Durations

The durations of the activities were developed when we estimated the cost of the project. Again, this was done with the help of the work breakdown structure. When we broke the project down to the individual activities that had to be done in the project, we were able to do a bottom-up estimate on cost for the project. While estimating the cost of each of the activities in the project we must also estimate the duration for each activity as well. The duration of an activity will not necessarily be the same as the effort to do the activity. Please refer to Chapter 3, Cost Management, for a complete discussion of the estimating process.

Effort is the number of people-hours needed to do the activity and will help us estimate cost. We speak of effort as being one hundred people-hours. This means that I might have one person working on the activity for one hundred hours, or I might have one hundred people working on the activity for one hour.

Duration is the length of time that it takes to do an activity. This would be the number of days that one person or more actually work on the activity. If project activity is scheduled to be done on Monday and Tuesday by Mary and Joe, Wednesday and

Thursday by Madelyn and Joe, and Friday by Nancy and Fran, the duration of the activity is five days. If a project activity is scheduled to be done on Monday and Tuesday by Mary and Joe, no work is scheduled on Wednesday and Thursday, and work is scheduled on Friday for Nancy and Fran, and on Monday and Tuesday for Madelyn and Joe, the duration of the activity is still five days. Wednesday and Thursday are considered to be nonworking days and contribute nothing to the activity's duration. This is a split activity. It is easy to think of this type of activity as being two activities, or parts A and B of the same activity. The important thing is to realize that the duration of the activity does not include the time when the activity is not being worked.

The span of an activity is different from duration as well. Span is the time that elapses between the start and finish of the activity. Span is simply the number of days that go by between the start and finish of the activity, regardless of whether the activity is being worked on.

Continuing the above example with Mary, Madelyn, Joe, Nancy, and Fran, note that the activity started on Monday of the first week and finished on Tuesday of the second week. The span of the activity is seven days, the duration of the activity is five days, and the effort of the activity is ten people-days.

Fortunately for the sake of our sanity, project schedules are put together without very much use of interrupted activities. This is usually an inefficient way to schedule work. The interrupted activity is, however, often used in adjusting schedules for problems that appear during project execution.

### Building the Network Diagram

Now that we have the durations and logic of the project, we can actually build the schedule. A sequence of steps should be followed in developing the schedule:

1. Create a list of the activities that are to be scheduled.

2. Assign a duration to each of the activities.

3. Determine the predecessor for each activity.

4. Calculate the forward pass, the early schedule for each activity.

5. Calculate the backward pass, the late schedule for each activity.

6. Calculate the float for each activity.

7. Determine the critical path.

8. Determine if the predicted project completion is earlier than the promise date.

9. Adjust schedule or promise date.

10. Apply resources and determine resource constraints.

11. Adjust the schedule to allow for resource constraints.

12. Determine if the predicted project completion is earlier than the promise date.

13. Adjust schedule or promise date.

### 14. Get approval on schedule.

Calendars must be entered if project management software is used. They must be considered when scheduling even when software is not being used. A calendar is the data that tells precisely when a resource is available for work. It defines the holidays, days off each week, and the time of day that the resource is available. A separate calendar is necessary for each resource that has a different work schedule, but resources having the same work schedule can use the same calendar. For example, Arnie and Zara are working on the same project. Arnie works from 8:00 a.m. to 5:00 p.m. with an hour off for lunch from 12:00 noon to 1:00 p.m. He works Monday through Saturday and takes off all of the company standard holidays. Zara works from 8:00 a.m. to 5:00 p.m. with an hour off for lunch from 12:00 noon to 1:00 p.m. She works Monday through Friday and takes off all of the company standard holidays. Zara and Arnie would require separate calendars.

The first thing we do is to create a list of activities (1) that will be in our schedule. This list is identical to the bottom level of the work breakdown structure. The duration of each activity (2) was determined during the estimating process. The predecessor of each activity (3) was determined during the final stages of the construction of the work breakdown structure.

Calculating the early schedule for each activity (4) requires the adoption of a few scheduling conventions. These conventions are accepted by the scheduling community. The first activity is always scheduled to start on the project start date. This date is input as part of the project plan. The first start date is the project start. The early finish date is the early start date plus the duration of the activity. Here another convention comes into play. Each activity is considered to have started at the beginning of the period that it starts on and to finish at the end of the period it finishes on. This means that if an activity has a duration of one day and it starts on January first, it ends on January first, too. Due to this convention the early finish of any activity equals the early start plus the duration minus one. So, activity 1 starts on day 1 and finishes on day 15 (Table 2-1).

The next activity must start at the beginning of the time period it starts in. This means that the next activity starts in the next available time period. Since activity 1 finishes on day 15, activity 2 must start on day 16, and it finishes on day 20.

Activities 3 and 4 present a new problem. Both of these activities depend on activity 2 to be completed before they can start. Both have an early start date of day 21. The schedule development continues.

In order to complete the backward pass (5) we must start at the last activity that was completed in the early schedule. The rationale for this is that if the early schedule was the soonest that the project could be completed, then what we seek in the backward pass is the latest that each of the activities can be done so that the final completion of the project can be made.

We begin by taking the latest of the early finish times from the last activity to be completed. This is the late finish time. The duration is then subtracted from the late

 Activity Description Duration Predecessor ES EF LS LF Float 1 Develop project deliverables 15 — 1 15 1 15 0 2 Approval from stakeholders 5 1 16 20 16 20 0 3 Select site 4 2 21 24 86 89 65 4 Evaluate and select vendor 4 2 21 24 53 56 32 5 Purchase hardware 3 4 25 27 57 59 32 6 Design software 15 2 21 35 21 35 0 7 Write code 30 6 36 65 36 65 0 8 Test software 4 7 66 69 66 69 0 9 Test hardware 10 5 28 37 60 69 32 10 Integrate hardware and software 20 9, 8 70 89 70 89 0 11 Install and final acceptance 5 3, 10 90 94 90 94 0

finish time to get the early finish time. The late schedule times, late start and late finish, for activity 11 are thus days 90 and 94. Since activity 11 has a late start date of day 90, activities 10 and 3 must be finished no later than day 89. This will be the late finish date for both of them. It is the latest that they can be finished in order to support the project completion on day 94 and the latest start of activity 11.

Remember the convention that says that the activity work always starts at the beginning of the work period and ends at the end of the work period. A late finish of day 94 and a duration of 5 days means that the activity must have started on day 90. Days 90, 91, 92, 93, and 94 are the five days worked. The durations are subtracted to get the late start dates for each activity. When we come to activity 2 we must be careful to choose a late finish date that supports the late start dates of activities 3, 4, and 6. Since the late start dates for activities 3, 4, and 6 are days 86, 53, and 21, respectively, the latest that activity 2 can be finished is day 20.

Now, referring to Table 2-1, we see that we have completed the calculation of the early start, early finish, late start, and late finish dates for our schedule.

When we calculated the early and late schedule dates for our project we found that sometimes the early and late schedule dates were the same, and in other activities the dates were different. In these activities there was a difference between the earliest day that we could start an activity and the latest day we could start the activity. The difference between these two dates is called ''float,'' or sometimes ''slack.'' These terms mean exactly the same thing and can be used interchangeably. The float of an activity is the amount of time that the activity can be delayed without causing a delay in the project.

To calculate the float (6) for each activity, subtract the early start day from the late start day of the activity. Incidentally, the subtraction could be performed using the late finish and the early finish days as well, since the difference between start and finish dates is simply the duration, and that is the same for the early and late schedules.

The critical path (7) is really not a path at all. In the days when activity on arrow diagramming was used, the activities formed a path through the project schedule. Today, with the use of computerized project management scheduling software, the critical path can be more versatile. The critical path is defined as the group of activities that cannot be delayed without delaying the completion date for the entire project. In other words, it is the series of activities that have ''zero float.''

Using computerized project management scheduling software, we can modify the list of activities on the critical path to include activities that are nearly on the critical path. This is important, since the critical path method is a management method for managing project schedules. The activities that have zero float are the activities that cannot be delayed without delaying the completion of the project. These are the activities that must be monitored closely if we want our project to finish on time. Conversely, the activities that are not on the critical path, those activities that have something other than zero float, need not be managed quite as closely. In addition, it is important to know which activities in the project may be delayed without delaying the project completion. Resources from activities having float could be made available to do a ''workaround'' if the need should arise.

Now that we have determined our schedule for the earliest completion of the project it is time for a reality check (8). The schedule should be showing a completion date that is earlier than the promise date that may have already been given to the stakeholders. If this is not the case, then warning flags should be up and waving.

The schedule that we have produced so far does not yet include delays that will occur if resources are not available when they are needed. Schedule reserves have not yet been added to allow for the effect of known and unknown risks. We also have not taken into consideration the normal variations that will occur between the predicted and actual project activity durations.

Next, we must adjust the schedule or the promise date (9). We have two situations, a schedule that has a promise date that is earlier than the predicted date, and a schedule that has a promise date that is later than the predicted date. If the predicted date of the schedule is later than the promise date we must compress the schedule. Crashing or fast tracking must be used. Crashing a schedule is doing anything at all to reduce the scheduled completion of the project. Examples of crashing would include reducing the scope of the project, adding additional resources for selected activities, eliminating activities, and changing the process to eliminate steps.

Fast tracking is a special case of crashing. In fast tracking activities that would have been scheduled in sequence are scheduled to be done with some overlap instead. The use of leads in the logical relationships between activities can be used to facilitate this, or the relationships can be changed completely.

For example, suppose the project is to paint a house (Figure 2-5). The original schedule called for one crew of people to scrape off the loose paint, apply the primer, and then apply the finish coat. The schedule calls for the three activities to be done in sequence.

To improve on the scheduled completion of the project, some of the activities could

Figure 2-5. Painting a house.

### Figure 2-5. Painting a house.

be fast tracked. Instead of one crew, two crews could be utilized. The first crew starts chipping and scraping. Eight hours later the second crew starts applying the primer to the scraped areas. When the first crew finishes scraping and chipping the house they can begin painting the finish coat over the primer that the second crew has been applying and which is now half done.

The overall effect on the project is to reduce the time for doing the project from 30 hours to 22 hours. The work content, the effort, remains the same at 30 person-hours. If the crew size were 2 people, then the project effort would be 60 person-hours. The disadvantage of fast tracking the schedule as we have done here, and the disadvantage of crashing any schedule, is that cost or risk, or both, will increase.

In this example, the overall cost of the project did not go up according to what we have measured. However, the real cost of the project, if all things were considered, would have gone up. Transportation of the additional crew to the job site would have increased. The cost of the additional equipment needed for two crews would have gone up.

The risk of the project goes up as well. If a mistake is made by one crew or the other, there will be little time to recover before the project schedule is affected. For example, if the wrong primer was used by the second crew, the finish coat may have already been applied before the mistake is found (Figure 2-6).

### Buffering the Schedule

The other problem that we addressed was what to do if the schedule is earlier than the promise date (12) of the project to the stakeholders. This is a much more pleasant problem than trying to shorten the schedule. It is a very important problem to solve, however. This must be done after allowing for reserve schedule time, normal fluctuations in the activity durations, and resource limitations on the schedule (Figure 2-7). If after all of this the schedule time is less than the promise date, buffering may be applied.

Figure 2-6. Painting a house.

Figure 2-6. Painting a house.

SS + 4

Figure 2-7. Schedule without contingency.

Figure 2-7. Schedule without contingency.

Finish Required

May 30 July 30

Finish Required

### May 30 July 30

A project schedule should not be adjusted by lengthening the duration of the activities (see Figure 2-8). If this is done, each of the people responsible for a scheduled activity will essentially be given the extra allowance and will probably work to this schedule. The schedule should also not be left as it is, since this is an optimistic schedule with no allowances for the items we discussed earlier.

A better way to schedule the project is with a buffer (Figure 2-9). Buffering a schedule is simply adding float to selected activities. In some project management scheduling software this feature is available. If it is not a part of your software, it can still be done. There are two methods: using lags in the relationships and creating buffer activities.

Using relationship lags is easily done but is tedious to accomplish. Each pair of activities must be considered and a lag added wherever it is desired to add buffer. To increase the project's scheduled completion time, a lag may be added between any two activities on the critical path. Changing the relationship from a normal finish-start to an FS + 10 would add 10 days of float to the activity and also shift the project completion day to ten days later.

Figure 2-8. Schedule with contingency.

Figure 2-8. Schedule with contingency.

Finish Required May 30 July 30

Figure 2-9. Schedule with buffer.

Figure 2-9. Schedule with buffer.

Finish Required

May 30 July 30

Finish Required

### May 30 July 30

Another technique is to create a duplicate activity for each activity that is to be buffered (Figure 2-10). The activity created is inserted between the independent activity to be buffered and the dependent activity in the relationship. If there was originally an FS relationship between activities A and B, the new relationship would add activity A'. This gives us an FS relationship between A and A' and another between A' and B. When this technique is used, the buffering dummy activities can be selected out of the schedule so that they will not appear. The remaining activities in the schedule will show with their correct dates.

Which activities should be buffered? This can be answered in a number of ways. The amount of buffer time that is applied to activities can be proportioned according to the risk of the activity, the dependencies that follow it, or any other reason that seems appropriate to the project manager.

In all project management scheduling software available today there is the ability to constrain the project with the use of resources (10). The unavailability of the resources may cause schedule delays. This problem occurs when an activity is scheduled that uses a

Figure 2-10. Buffering.

Figure 2-10. Buffering.

Without buffer: 9 days. With buffer: 12 days.

particular person or equipment and that piece of equipment is being used in some other part of the project or on some other project altogether.

To enter the resource information into any project management scheduling software package, a number of different pieces of information must be entered:

• Work Calendar. This describes the work schedule of the resources. Many of these may be necessary to take care of all the different work patterns of the various resources. The days of the week worked, the time of day that is worked, and holidays that are not worked must be entered.

• Resource Availability. The availability of the resource in terms of when the resource is available as well as the quantity of the resource that is available.

• Resource Requirement. The amount of the resource required and when it is required.

Next, we adjust the schedule to allow for resource constraints (11). The resource-leveling function in all scheduling software packages is useful for a first look at this problem but is not intelligent enough to solve any but the simplest resource problem. To solve this problem the software contains a feature called the ''resource histogram'' (Figure 2-11).

The resource histogram is done in a split screen format. Generally, the upper portion of the screen shows the Gantt chart with the activities that are using the resource in question. In the bottom portion of the screen, vertical bars indicate the amount of reFigure 2-11. Overallocation of resource (resource histogram).

20 hours/week

20 hours/week

40 hours/week

20 hours/week

source that is necessary for the time period in question. The time scales that are used are the same for both views.

By looking at the two parts of the screen in Figure 2-11, it can be seen that during weeks 1 and 2 the resource is underutilized, and that in weeks 5 and 6 the resource is overutilized. While the underutilized resource may be employed somewhere else in the project, it will be very difficult to make the overutilized resource work 20 hours of overtime for those two weeks.

To resolve the problem, activity 2 was scheduled to be interrupted for two weeks (Figure 2-12). By doing this the workload of this resource was leveled out, and no overtime was required.

Now, with the resource constraints and the schedule adjusted to meet promise dates, another check is made to be sure that the schedule can be met (12). If the promise date and the planned date are still not consistent, then it is time to readjust the schedule one more time (13). Before the plan can be finalized it is important that the plan be approved (14) and that there is a formal sign-off for this schedule baseline.

### Reverse Resource Allocation Scheduling

Some projects are required to be completed on a specific date regardless of the resources needed. This makes it necessary to schedule the resource in reverse. The end date of the project minus the time needed for the resource determines the start date for using that resource.

Figure 2-12. Overallocation of resource resolved (resource histogram).

20 hours/week

IQ hours/wk.IQ hours/wk.

40 hours/week

IQ hours/wk.