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.
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.
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.
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
Figure 9-7. Network Diagram for Project Plan