8. Network and Float
The project network acts as a logical representation of the project for planning purposes. The technique for analyzing the network is called the critical path method, although it has as much to do with the noncritical activities as it does with the critical ones. Critical path analysis is admirably suited for complex projects, ranging from physical construction to software systems, and it has a decades-long proven track record of success. By performing this analysis, you find the project duration and determine where and when to assign your resources.
Because the project network is so instrumental to project design, this chapter expands on a few of the concepts that were introduced in Chapter 7, in the project design overview. You will see recurring techniques, terms, and universal concepts that are independent of any specific project or even any industry. The ideas of this short chapter enable objective and repeatable analysis of the project. Any two architects analyzing the same project network should produce very comparable results.
The Network Diagram
An activity in a software project is any task that requires both time and a resource. Activities may include architecture, project design, service construction, system testing, and even training classes. The project is a collection of related activities, and the network diagram captures these activities and their dependencies. In network diagrams, there is no notion of order of execution or concurrency between the activities.
Network diagrams are often deliberately not shown to scale so that you can focus purely on dependencies and general topology of the network. Avoiding scale in most cases also simplifies the design of the project. Attempts to keep the network diagram to scale will impose a serious burden when estimations change, when you add or remove activities, or when you reschedule activities.
There are two possible representations of a project network diagram: a node diagram and an arrow diagram (Figure 8-1).
Figure 8-1 A node diagram (left) and the equivalent arrow diagram (right)
The Node Diagram
With a node diagram, each node in the chart represents an activity. For example, on the left side of Figure 8-1, every circle is an activity. The arrows in a node diagram represent dependencies between the activities, and the length of the arrow is irrelevant. There is no time spent along the arrows; instead, all time is spent inside the nodes. There is no simple way of drawing node diagrams to scale other than by increasing the radius of the nodes. Doing so tends to clutter the diagram and makes it difficult to interpret correctly.
The Arrow Diagram
With an arrow diagram, arrows represent activities, and the nodes represent dependencies on the entering activities, as well as events that occur when all the entering activities complete, as shown on the right side of Figure 8-1. Note that both diagrams in Figure 8-1 depict the same network, illustrating that the two diagram types are equivalent (i.e., any network can be rendered using either notation). Since the nodes in an arrow diagram represent events, no time is ever spent inside a node; that is, the events are instantaneous. As with node diagrams, time passes in the direction of the arrows. To draw an arrow diagram to scale, you would scale time to the length of the arrow. That stated, typically the arrow’s length is irrelevant (in this book, unless explicitly stated, all network diagrams are not to scale).
With an arrow diagram, all activities must have a start event and a completion event. It is also good practice to add an overall start and completion event for the project as a whole.
Dummy Activities
Suppose in the network of Figure 8-1, activity 4 also depends on activity 1. If activity 2 already depends on activity 1, the arrow diagram has a problem, because you cannot split the arrow of activity 1. The solution is to introduce a dummy activity between the completion event of activity 1 and the start event of 4 (shown as a dashed arrow in Figure 8-2). The dummy activity is an activity of zero duration whose sole purpose is to express the dependency on its tail node.
Figure 8-2 Use of a dummy activity
Arrow Versus Node Diagrams
While the two notations are equivalent, there are distinct pros and cons for each. One point favoring arrow diagrams is that the completion events are a natural place to designate milestones. A milestone is an event denoting the completion of a significant part of the project. With node diagrams you typically have to add activities of zero duration as milestones.
Nearly everyone requires a bit of practice to correctly draw and read an arrow diagram, whereas people intuitively draw node diagrams and understand them, giving node diagrams what appears to be a clear advantage. Node diagrams at first seem to have no need for a dummy activity because you can just add another dependency arrow (such as another arrow between activities 1 and 4 on the left side of Figure 8-1). For these simplistic reasons, the vast majority of tools for drawing network diagrams use node diagrams.
In contrast, at least four of IDesign’s customers have developed arrow diagramming tools (and two of these tools are available along with the support files for this book). They invested in the tools for arrow diagrams due to a crucial flaw in all node diagrams. Consider the networks in Figure 8-3.
Figure 8-3 Repeated dependencies in node versus arrow diagrams [Adopted and modified from James M. Antill and Ronald W. Woodhead, Critical Path in Construction Practice, 4th ed. (Wiley, 1990).]
Figure 8-3 depicts two identical networks, both comprising six activities; 1, 2, 3, 4, 5, 6. Activities 4, 5, and 6 all depend on activities 1, 2, and 3. With an arrow diagram the network is straightforward and easy to understand, while the corresponding node diagram is an entangled cat’s cradle. You can clean up the node diagram by introducing a dummy node of zero duration, but that may get confused with a milestone.
As it turns out, the situation in Figure 8-3 is very common in well-designed software systems in which you have repeated dependencies across the layers of the architecture. For example, activities 1, 2, and 3 could be ResourceAccess services, and activities 4, 5 and 6 could be some Managers and Engines, each using all three ResourceAccess services. With node diagrams, it is difficult to figure out what is going on even in a simple project network like that shown in Figure 8-3. By the time you add Resources, Clients, and Utilities, the diagram becomes utterly incomprehensible.
It is pointless to draw unintelligible network diagrams. The primary purpose of the network diagram is communication: You strive to communicate your project design to others or even to yourself. Having a model that no one can understand and to which no one can relate defeats the purpose of having the network diagram in the first place.
Consequently, you should avoid node diagrams and use arrow diagrams. The initial arrow diagram learning curve is more than offset by the benefits of having a concise, clear, clutter-free model of your project. The lack of widely available tool support for arrow diagrams, which forces you to draw your arrow diagram manually, is not necessarily a bad thing. Drawing the network by hand is valuable because in the process you review and verify activity dependencies, and it may even unveil additional insights about the project.
Floats
Activities on the critical path must complete as soon as planned to avoid delaying the project. Noncritical events may be delayed without slipping the schedule; in other words, they can float until they must begin. A project without any float, where all network paths are critical, could in theory meet its commitments, but in practice any misstep anywhere will cause a delay. From a design perspective, floats are the project’s safety margins. When designing a project, you always want to reserve enough float in the network. The development team can then consume this float to compensate for unforeseen delays in noncritical activities. Low-float projects are at high risk of delays. Anything more than a minor delay on a low-float activity will cause that activity to become critical and derail the project.
The discussion of floats so far was somewhat simplistic because there are actually several types of floats. This chapter discusses two types: total float and free float.
Total Float
An activity’s total float is by how much time you can delay the completion of that activity without delaying the project as a whole. When the completion of an activity is delayed by an amount less than its total float, its downstream activities may be delayed as well, but the completion of the project is not delayed. This means that total float is an aspect of a chain of activities, not just particular activities. Consider the network in the top part of Figure 8-4, which shows the critical path in bold lines and a noncritical path or chain of activities above it.
Figure 8-4 Float as an aspect of a chain of activities
For the purpose of this discussion, Figure 8-4 is drawn to scale so that the length of each line corresponds to each activity’s duration. The noncritical activities all have the same amount of total float, indicated by the red line at the end of the activity’s arrow. Imagine that the start of the first noncritical activity in the top half of the figure is delayed or that the activity takes longer than its estimation. While that activity executes, the delay in completing the upstream activity consumes the total float of the downstream activities (shown in the bottom half of the figure).
All noncritical activities have some total float, and all activities on the same noncritical chain share some of the total float. If the activities are also scheduled to start as soon as possible, then all activities on the same chain will have the same amount of total float. Consuming the total float somewhere further up a chain will drain it from the downstream activities, making them more critical and riskier.
Free Float
An activity’s free float is by how much time you can delay the completion of that activity without disturbing any other activity in the project. When the completion of an activity is delayed by an amount less or equal to its free float, the downstream activities are not affected at all, and of course the project as a whole is not delayed. Consider Figure 8-5.
Figure 8-5 Consuming free float
Again, for the purpose of this discussion, Figure 8-5 is drawn to scale. Suppose the first activity in the noncritical chain in the top part of the figure has some free float, indicated by the dotted red line at the end of the activity’s arrow. Imagine that the activity is delayed by an amount of time less than (or equal to) its free float. You can see that the downstream activities are unaware of that delay (bottom part of diagram).
Interestingly, while any noncritical activity always has some total float, an activity may or may not have free float. If you schedule your noncritical activities to start as soon as possible, back to back, then even though these activities are noncritical, their free float is zero because any delay will disrupt the other noncritical activities on the chain. However, the last activity on a noncritical chain that connects back to the critical path always has some free float (or it would be a critical activity, too).
Free float has little use during project design, but it can prove very useful during project execution. When an activity is delayed or exceeds its effort estimation, the free float of the delayed activity enables the project manager to know how much time is available before other activities in the project will be affected, if at all. If the delay is less than the delayed activity’s free float, nothing really needs to be done. If the delay is greater than the free float (but less than the total float), the project manager can subtract the free float from the delay and accurately gauge the degree by which the delay will interfere with downstream activities and take appropriate actions.
Calculating Floats
The floats in the project network are a function of the activity durations, their dependencies, and any delays you may introduce. None of these have to do with actual calendar dates when you schedule these activities. You can calculate the floats even if the actual start date of the project is as yet undecided.
In most decent-size networks, such float calculations, if done manually, are error prone, get quickly out of hand, and are invalidated by any change to the network. The good news is that these are purely mechanical calculations, and you should use tools for calculating the floats.1 With the total float values at hand, you can record them on the project network as shown in Figure 8-6. This figure shows a sample project network in which the numbers in black are each activity’s ID, and the numbers in blue below the arrows are the total float for the noncritical activities.
Figure 8-6 Recording total floats on the network
1. You can use Microsoft Project to calculate the floats for each activity by inserting the Total Slack and the Free Slack columns, which correspond to the total and free float. To learn how to manually calculate floats, see James M. Antill and Ronald W. Woodhead, Critical Path in Construction Practice, 4th ed. (Wiley, 1990).
While only total float is required for project design, you can also record free float in the network diagram. The project manager will find this information invaluable during project execution.
Visualizing Floats
Capturing the information about the floats on the network diagram, as shown in Figure 8-6, is not ideal. Human beings process alphanumeric data slowly and have a hard time relating to such data. It is difficult to examine complex networks (or even simple ones, like that in Figure 8-6) and at a glance to assess the criticality of the network. The criticality of the network indicates where the risky areas are and how close the project is to an all-critical network. Total floats are better visualized by color-coding the arrows and nodes—for example, using red for low float values, yellow for medium float values, and green for high float values. You can partition the three float value ranges in several ways:
Relative criticality. Relative criticality divides the maximum value of the float of all activities in the network into three equal parts. For example, if the maximum float is 45 days, then red would be 1 to 15 days, yellow would be 16 to 30 days, and green would be 31 to 45 days of float. This technique works well if the maximum float is a large number (such as greater than 30 days) and the floats are uniformly distributed up to that number.
Exponential criticality. Relative criticality assumes that the risk for delay is somewhat equally spread across the range of float. In reality, an activity with 5 days of float is much more likely to derail the project than an activity with 10 days of float, even though both may be classified as red by relative criticality. To address this issue, the exponential criticality divides the range of the maximum float into three unequal, exponentially smaller ranges. I recommend making the divisions at 1/9 and 1/3 of the range: These divisions are reasonably sized but more aggressive than those produced by 1/4 and 1/2, and the divisors are proportional to the number of colors. For example, if the maximum float is 45 days, then red would be 1 to 5 days, yellow would be 6 to 15 days, and green would be 16 to 45 days of float. As with relative criticality, the exponential criticality works well if the maximum total float is a large number (such as greater than 30 days) and the floats are uniformly distributed up to that number.
Absolute criticality. The absolute criticality classification is independent of both the value of the maximum float and how uniformly the floats are distributed along the range. The absolute criticality sets an absolute float range for each color classification. For example, red activities would be those with 1 to 9 days of float, yellow would be 10 to 26 days of float, and green activities would be 27 days of float (or more). Absolute criticality classification is straightforward and works well in most projects. The downside is that it may require customizing the ranges to the project at hand to reflect the risk. For example, 10 days may be green in a 2-month project but red in a year-long project.
Figure 8-7 shows the same network as in Figure 8-6 with color coding for absolute criticality classification using the absolute float ranges just suggested. The critical activities in black have no float.
Figure 8-7 Floats color coding
Compare the ease with which you can interpret the visual information in Figure 8-7 versus the same textual information in Figure 8-6. You can immediately see that the second part of the project is risky.
Floats-Based Scheduling
As stated in Chapter 7, the safest and most efficient way to assign resources to activities is based on float—or, given the definition of this chapter, total float. This is the safest method because you address the riskier activities first, and it is the most efficient because you maximize the percentage of time for which the resources are utilized.
Consider the snapshot of a scheduling chart shown in Figure 8-8. Here the length of each colored bar represents the time-scaled duration of that activity, and the right or left position is aligned with the schedule.
Figure 8-8 Maximizing resource demand when not consuming float
The figure has four activities: 1, 2, 3, 4. All activities are ready to start on the same date. Due to downstream activities (not shown), activity 1 is critical, while activities 2, 3, and 4 have various levels of total float indicated by their color coding: 2 is red (low float), 3 is yellow (medium float), and 4 is green (high float). Suppose these are all development activities that all developers can perform equally well, and that there are no task continuity issues. When staffing this project, you first must assign a developer to the critical activity 1. If you have a second developer, you should assign that developer to activity 2, which has the lowest float of all other activities. This way, you can utilize as many as four developers, working on each of the activities as soon as possible.
Alternatively, you can staff the project with only two developers (see Figure 8-9). As before, the first developer works on activity 1. The second developer starts with activity 2 as soon as possible because there is no point in postponing a near-critical activity and making it critical.
Figure 8-9 Trading float for resources
Once activity 2 is complete, the second developer moves to the remaining activity with the lowest float, activity 3. This requires rescheduling 3 further down the timeline, until the second developer is available after completing activity 2. This is only possible by consuming (reducing) the float of activity 3; due to some downstream dependencies in this example, this causes activity 3 to become red. Once activity 3 is complete, the second developer proceeds to work on activity 4. This, too, is possible only by consuming the available float of activity 4; while acceptable in this example, this turns the float of activity 4 from green to yellow.
This form of staffing trades float for resources and, in effect, for cost. When assigning resources, you use floats in two ways: You assign resources to available activities based on floats, low to high, and if needed, you consume activities’ float to staff the projects with a smaller level of resources without delaying the project.
Float and Risk
As just stated, assigning resources based on float allows you to trade float for cost. You may be tempted to trade all the project’s float for lower cost, but that is rarely a good idea because a project with little float has less tolerance for delays. When you trade resources for float, you reduce the cost but increase the risk. In effect, you are not merely trading float for lower cost, but lower cost for higher risk. The float trade therefore is a three-way trade. In the example of Figure 8-9, using two developers rather than four has reduced cost but, as a side effect, made the project risker. During project design you should constantly manage the remaining float, and by doing so manage the risk of the project. This allows you to craft several options that offer different blends of schedule, cost, and risk.