Section 9.3. Creating A Network Diagram

9.3. Creating A Network Diagram

A network diagram is a tool that helps you and the IT project team graphically represent the nature of the relationships and dependencies of the project's tasks. Clearly, you can't create the network diagram until you've identified all the project work packages. You can't begin to create a realistic schedule until you know about all the work that must be done, but just having your WBS doesn't give you the whole picture. Once the work has been clearly identified, you can work as a team to figure out the logical sequencing of activities. The logical sequencing forms the foundation of the project schedule. We know, for example, that the house painter can't paint the trim until the walls have been put up and the walls can't be erected until the foundation has been poured and set. These are examples of constraints or dependencies.

Cheat Sheet…
Network Diagramming Methods

There are several different ways you can create your network diagram. We won't cover them in detail, but if you're interested, you can do some independent research to learn more about methods that interest you.

Arrow Diagramming Method (ADM) Uses nodes to represent events and arrows to represent activity duration.
Precedence Diagramming Method (PDM) Uses nodes to represent activity duration and connectors to show precedence and dependencies (this is a commonly used method).
Program Evaluation and Review Techniques (PERT) Uses weighted average for duration to calculate project completion time/date. Average includes optimistic duration, most-likely duration, and pessimistic duration estimates.
Critical Path Method (CPM) Uses sequential network logic with a single estimated duration for each task (rather than weighted averages). This is a method and should not be confused with the critical path itself.
Graphical Evaluation and Review Technique (GERT) Uses probability sequencing and duration estimates. GERT is an advanced method of creating a network diagram.

Sequencing is a function of logical, desirable, and feasible timing for all project tasks. For instance, some sequence of activities might be logical but not desirable. Other sequencing may appear to be desirable, but it's just not feasible. The first step in creating a detailed project schedule is creating the sequencing for tasks and this is best done through a network diagram. There is no requirement that you create a network diagram; there are other ways you may have used in the past to create the optimal sequence for your project tasks, but a network diagram is a commonly used tool. There are four common methods of creating a network diagram, but we're going to focus on the most commonly used (and easiest to use) method: Precedence Diagramming Method (PDM). Many project management software programs, including Microsoft Project, use some sort of PDM (various hybrids exist). You can create your network diagram by entering your tasks, sequences, dependencies, and constraints into your PM software tool and allow the program to create the network diagram for you, or you can create the diagram by hand. One popular method is to write the tasks on sticky notes and physically create your network diagram by placing the sticky notes on a white board and drawing lines for dependencies. This way, it's easy for everyone to see and visualize and it's easy to move things around. While it might sound a bit archaic, it's a very effective and efficient method for working with your team on task sequencing. We've thrown around three terms: sequence, constraints, and dependencies. Let's discuss them with regard to your WBS and your project schedule.

Sequence The sequence in which tasks should be started, worked on, or completed is your starting point. Most of the tasks in the project have some sort of logical sequence and that might be your best starting point. Once you've put tasks in their logical sequence, you have to begin thinking about other elements that will affect the sequence. Once tasks are in logical order, have the team look at the sequence and see if anything jumps out at them. For instance, someone might note that Task 4 logically follows Task 2, but it would be more desirable if it followed Task 5 instead. Someone might identify a logical sequence that is simply not feasible. Yes, it would be great if we could do Task 11 and 14 at the same time, but they require the same resource, so it's just not feasible.

Constraints Once you and your team have identified the most logical, desirable, feasible sequence, you have to begin looking at any constraints in place. You should refer back to your project document where you may have identified some project constraints early on. For instance, now that you're getting closer to knowing when the project will start and how long it will take, there may be constraints such as availability of key resources or outside vendors that will impact your schedule. One of the most common constraints is that a required resource is not available when needed or that two or more tasks require the same resource at the same time.

Dependencies Dependencies between tasks often mean that one task cannot start until another is complete. Using our home-building analogy, you can't put the walls up until the foundation is set. That's a finish-to-start dependency because Task A (foundation) must be finished before Task B (walls) can start. There are other types of dependencies, but this is the most common one and the default type of dependency used in most project management software programs. The four dependencies are depicted in Table 9.1 below.

Table 9-2. Task Dependencies
Dependency Type	Graphical Representation	Description
Finish-to-Start Most common type of dependency		One task cannot start until a preceding task finishes. The walls of a house (Task 2) cannot be built until the foundation is poured and set (Task 1).
Finish-to-Finish		Ideally, the two tasks finish at the same or nearly same time. For instance, if you're installing network cabling in a new location, the technician putting the wall plate on in each office (where the computer cable will connect in the wall to the network cable) can't complete the task until the network cable is pulled to that location. Ideally, as the cable is being pulled, the technician begins putting on wall plates so that when the cable-pulling is complete, so too is the face plate installation. In many cases, improperly terminated cables can result in network problems, so you'd want the pulling of the cables and the installation of the connecting wall plates to finish at about the same time.
Start-to-start		When Task 1 must start before Task 2, but both can happen at the same time. This type of dependency is often used to indicate tasks that can occur in tandem once Task 1 begins. An example of this type of dependency is that ghosting drives and new desktop installation can run in tandem as long as the first drive is ghosted before the first desktop is installed. Once Task 1 (ghosting drives) begins, Task 2 (installing new desktop computers) can begin as well.
Start-to-finish		The start-to-finish Rarely used dependency is rarely used and it is somewhat unusual to find this type of dependency outside the construction or manufacturing arenas. In this type of dependency, Task 1 must start so that Task 2 can finish.

The IT Factor…
Network Diagramming Guidelines

There are a number of guidelines that you should keep in mind as you create your network diagram. These guidelines are designed to help you prevent overlooking key elements such as critical dependencies.

Use milestones to create a high-level diagram if you're not sure where to start.
Make sure all of the tasks are included in the diagram.
Make sure the relationship between a task and its dependencies is correct.
Make sure that all tasks that can be done simultaneously are shown in the diagram as such.
Look for hidden dependencies including entry and exit criteria and operational boundaries. Use subject matter experts to assist in this to ensure you're not overlooking critical data.

9.3.1. Milestones

If you're not sure where to start in creating your network diagram, begin with milestones. When do certain phases have to begin or end? If you know where your milestones are, you can then begin to put your tasks in the right order to meet these milestones. Two things to note: don't diagram the relationship between a task and a summary task (a summary task is comprised of all related sub-tasks) and don't diagram the relationship between summary tasks and milestones. Summary tasks are not actually tasks themselves, but a roll-up (summary) of groups of linked tasks. Link to the specific task that forms the dependency or to the milestone at the end of the group of tasks instead.

9.3.2. Creating the Diagram

Let's look at a portion of a network diagram, shown in Figure 9.4, created in Microsoft Project. Notice that you can't develop server specs until you've developed hardware specs (this may not be true in all projects, but it is true for this project).

The software specs in this case are dependent upon the hardware specs. The ordering of the enterprise application depends on the completion of the software specs (a finish-to-start dependency). Notice that once the hardware specs are completed, two paths are created. The top path that begins with "Develop software specs" is not on the critical path (in Microsoft Project's network diagram, all tasks on the critical path are shown in red, though you can't see red in this black and white diagram). The path that begins with "Develop server specs" is the critical path and is shown in red in the software program. A delay to any task on the first path will not necessarily delay the project (though it could) but a delay on the second path will delay the entire project.

Figure 9-4. Network Diagram

Your network diagram may be more bunched up or more spread out, depending on how many tasks of the project can run simultaneously. Look for places in the project where you can run tasks in parallel to decrease the overall length of the project where possible. Since the project management software programs are rather linear in nature, it often causes people to look at things in a very linear manner. This sometimes causes people to overlook the fact that many tasks can be started at just about any time in the project or that they have a lot of flexibility as to when particular tasks start or must finish. Keep this in mind as you sequence your tasks.

9.3.3. Critical Path

We've defined the critical path as the longest, least flexible path through the project. This does not mean the path containing the most "critical" tasks (however you define "critical") in the project but those that, if delayed, put your project schedule at risk. Remember when we defined our flexibility matrix? That comes into play here because if schedule is your least flexible element, you may have to come up with alternatives, such as hiring additional help, to meet your schedule. If your critical path puts your schedule at risk and your schedule is the least flexible element, you'll have to figure out ways to deal with this. On the other hand, if schedule is most flexible and budget is least flexible, you may need to re-arrange your schedule in a way that reduces expenses such as allowing more time for the completion of tasks so you don't incur overtime.

Having your network diagram available (either in the software program or on a white board) can help you identify problems in your sequence and high-level schedule. It can be an excellent way to visualize the project and determine the way to sequence tasks to meet project parameters. You don't have to have PM software to create your network diagram and to determine your critical path. Figure 9.5 shows a network diagram using a block diagram style. In this case, it's likely that Task 6 has an external constraint of some type that prevents it from starting any sooner than it does, though its start time is not dependent upon the other tasks in the project. In this case, both the second (Tasks 2,5,7) and third (Tasks 6, 8) paths through the project appear to be the critical path. However, by definition, the longest, least flexible path is the critical path, which in this case is comprised of Tasks 1, 2, 5, and 7. If Task 6 is delayed, it might also delay the project, and at that point the critical path might shift from Task 1-2-5-7 to Task 1-6-8. The point to remember is that your critical path may change through the life of the project if tasks are delayed to the point where they will push your entire project schedule out. Identifying these possible problem areas is much easier with a network diagram than if you were simply looking at all these tasks in a list of start and finish dates.

Figure 9-5. Block Diagram of Network

9.3.4. Slack and Float

You may have heard the term slack or float associated with project tasks or schedules. They are used interchangeably and refer to the amount of time an activity can be delayed without delaying the rest of the project. To use the information from Figure 9.4, we know that "Develop software specs" is not on the critical path. Still, if that activity is delayed long enough, the other tasks on that path will be delayed and they could eventually (if delayed long enough) end up on the critical path. Clearly, if any task in the project is delayed long enough, it could put the project at risk (if not, you might ask if the task should be done at all). Here's another example: suppose users need to be trained on the new features of an enterprise application that is going to be upgraded. Users are already familiar with the product and simply need a short four-hour training session to get them up to speed on new features. This training, hypothetically, could occur any time before the actual product rollout and not delay the completion of the project. Certainly, there are some optimal timeframes for training in this case, but the training can be said to have a certain amount of float or slack. For instance, it might be scheduled for one month prior to application rollout, but it might have two weeks of float meaning that it could be pushed out two weeks and still not delay the project. That gives you a bit of flexibility in case the training is delayed or in case the trainer is out sick for a week. Identifying slack in your tasks is an important part of scheduling because it will let you know where you have tasks that can be moved to accommodate problems that might pop up in scheduling. It also lets you know where you might have resources available to apply to problem areas if the going gets tough. Some people indicate slack on the task in their diagrams (if you use PM software, you can enter slack or float and it will be shown in the network diagram) so they can visually see where they have a bit of leeway.

Remember, tasks on the critical path almost always have zero float, which is how they end up on the critical path in the first place. If a task has no float, it is "least flexible" and cannot budge. Tasks with float are typically not on the critical path because the reason that they can be moved around a bit to accommodate other changes.

Applying Your Knowledge

Identify the slack or float that exists for tasks in your project. This will help you make decisions more easily when something changes (and it will). Understanding which tasks have float and which ones don't will help you make better decisions about how to allocate resources and will make your scheduling more efficient. Since the critical path may shift if too many tasks have zero float, make sure you know which tasks can shift around and which ones absolutely cannot.

Once you've identified duration and float (or slack, whichever term you prefer), you can add that data to your network diagram, as shown in Figure 9.6 Once you've added that data, you can easily calculate your critical path by adding up the longest, least flexible path. Using Figure 9.6, you can see that Tasks 1, 3, and 4 add up to 7 days' duration and have 6 total days of float. The second path, which includes Tasks 1, 2, 5, and 7, has a total duration of 11 days and 0 days of float. The third path, Tasks 1, 6, and 8 have a total duration of 5 days and 7 days of float. Clearly, then, the critical path is the second path. When you have these types of duration and float estimates, you can more easily visualize your critical path. Once you know which tasks are on the critical path, you can take steps to ensure that these tasks remain on schedule.

Figure 9-6. Network Diagram with Duration and Float

The result of this part of your planning should be your project's network diagram, which should be added to your project plan for final project sponsor approval. This document can be created by hand, in a program such as Proquis allClear, Microsoft Visio, or Microsoft Excel, or in a project management software program. It is represented by the document icon shown in Figure 9.7