Dependency Chart

You should examine the call chains, and lay out a first draft of the dependencies between components in the architecture. You start with all the arrows connecting components, regardless of transport or connectivity, and consider each as a dependency. You should account for any dependency exactly once. However, typically the call chain diagrams do not show the full picture because they often omit repeated implicit dependencies. In this case, all components of the architecture (except the Resources) depend on Logging, and the Clients and Managers depend on the Security component. Armed with that additional information, you can draw the dependency chart shown in Figure 11-4.

As you can see, even with a simple system having only two use cases, the dependency chart is cluttered and hard to analyze. A simple technique you can leverage to reduce the complexity is to eliminate dependencies that duplicate inherited dependencies. Inherited dependencies are due to transitive dependencies¹—those dependencies that an activity implicitly inherits by depending on other activities. In Figure 11-4, Client A depends on Manager A and Security; Manager A also depends on Security. This means you can omit the dependency between Client A and Security. Using inherited dependencies, you can reduce Figure 11-4 to Figure 11-5.

1. https://en.wikipedia.org/wiki/Transitive_dependency

About Milestones

As defined in Chapter 8, a milestone is an event in the project denoting the completion of a significant part of the project, including major integration achievements. Even at this early stage in the project design, you should designate the event completing Project Design (activity 3) as the SDP review milestone, M0. In this case, M0 is the completion of the front end (short for fuzzy front end) of the project, comprising requirements, architecture, and project design. This makes the SDP review an explicit part of the plan. You can have milestones on or off the critical path, and they can be public or private. Public milestones demonstrate progress for management and customers, while private milestones are internal hurdles for the team. If a milestone is outside the critical path, it is a good idea to keep it private since it could move as a result of a delay somewhere upstream from it. On the critical path, milestones can be both private and public, and they correlate directly with meeting the commitments of the project in terms of both time and cost. Another use for milestones is to force a dependency even if the call chains do not specify such a dependency. The SDP review is such a milestone—none of the construction activities should start before the SDP review. Such forced-dependency milestones also simplify the network, and you will see another example shortly.

Initial Duration

You can construct the network of activities listed in Table 11-1 in a project planning tool, which gives you a first look at project duration. Doing so gives a duration of 9.0 months for this project. However, without resource assignment, it is not yet possible to determine the cost of the project.

Project Phases

Each activity in a project always belongs to a phase, or a type of activities. Typical phases include the front end, design, infrastructure, services, UI, testing, and deployment, among others. A phase may contain any number of activities, and the activities in a phase can overlap on the timeline. What is less obvious is that the phases are not sequential and can themselves overlap or even start and stop. The easiest way of laying out phases is to structure the planning assumptions list into a role/phase table; Table 11-2 provides an example.

In much the same way, you could add other roles that are required for the duration of an entire phase, such as UX (user experience) or security experts. However, you should not include roles that are required only for specific activities, such as the test engineer.

Table 11-2 is a crude form of a staffing distribution view. The relationship between roles and phases is essential when building the staffing distribution chart because you must account for the use of all the resources, regardless of whether they are assigned to specific project activities. For example, in Table 11-2, an architect is required throughout the project. In turn, in the staffing distribution chart, you would show the architect across the duration of the project. In this way, you can account for all resources necessary to produce the correct staffing distribution chart and cost calculation.

Infrastructure First with Limited Resources (Iteration 3)

Choosing the latter, somewhat middle-of-the-road scenario of one and then two developers, recalculate the infrastructure-first project to see how the project behaves with limited resources. Instead of three parallel activities (one critical) at the beginning, as shown in Figure 11-9, you now have one activity that is critical, then two activities in parallel (one critical). Serializing activities in this way increases the duration of the project. This variation extends the schedule by 8% to 9.9 months and increases the total cost by 4% to 61.5 man-months. Figure 11-10 shows the resulting staffing distribution chart. Note the gradual phasing in of the developers, from one, to two, to four.

Extending the critical path by limiting the resources also increases the float of the noncritical activities that span that section of the network. Compared with unlimited resources, the float of the Test Plan (activity 4 in Figure 11-6) and Test Harness (activity 5 in Figure 11-6) is increased by 30%, the float of Resource A (activity 9 in Figure 11-6) is increased by 50%, and the float of Resource B (activity 10 in Figure 11-6) is increased by 100%. This is noteworthy because a seemingly minute change in resource availability has increased the float dramatically. Be aware that this knife can cut both ways: Sometimes a seemingly innocuous change can cause the floats to collapse and derail the project.

No Database Architects (Iteration 4)

On top of limiting the initial availability of the developers, suppose the project did not get the database architects called for in the previous solutions. This is certainly a real-life scenario—such qualified resources are often hard to come by. In this case, developers design the databases to the best of their abilities. To see how the project responds to this new limit, instead of just adding developers, constrain the project to no more than four developers (allowing for more developers would be identical to having the database architects). Surprisingly, this does not change the duration and results with a total cost of 62.7 man-months, a mere 2% increase. The reason is that the same four developers start working earlier and do not even have to consume float.

Further Limited Resources (Iteration 5)

Since the project could easily cope with four developers, the next limited-resources plan caps the available developers at three. This also does not change the duration of the project because it is possible to trade the fourth developer for some float. As for cost, there is a 3% reduction in cost to 61.1 man-months due to the more efficient use of developers. Figure 11-11 shows the resulting staffing distribution chart.

Note the use of the test engineer along with the three developers. Figure 11-11 is the best staffing distribution so far, looking very much like the expected pattern from Chapter 7 (see Figure 7-8).

Figure 11-12 shows the shallow S curve of the planned earned value. The figure shows a fairly smooth shallow S curve. If anything, the shallow S is almost too shallow. You will see the meaning of that later on.

Figure 11-13 shows the corresponding network diagram, using the absolute criticality float color-coding scheme described in Chapter 8. This example project uses 9 days as the upper limit for red activities and 26 days as the upper limit for the yellow activities. The activity IDs appear above the arrows in black, and the float values are shown below the line in the arrow’s color. The test engineer’s activities—that is, the Test Plan (activity 4) and the Test Harness (activity 5)—have a very high float of 65 days. Note the M0 milestone terminating the front end and the M1 milestone at the end of the infrastructure. The diagram also shows the phasing in of the resources between M0 and M1 to build the infrastructure (activities 6, 7, and 8).

No Test Engineer (Iteration 6)

The next experiment in resource reduction is to remove the test engineer but keep the three developers. Once again, this design solution results in no change to the duration and cost of the project. The third developer simply takes over the test engineer’s activities after completing other lower-float activities already assigned. The problem is that deferring the Test Plan and Test Harness activities to much later consumes 77% of their float (from 65 days to 15 days). This is very risky because if the float drops by 100%, the project is delayed.

Subcritical Cost and Duration

Compared with the limited-resources solution of three developers and one test engineer, the project duration is extended by 35% to 13.4 months due to the serialization of the activities. While using a smaller development team, the project total cost is increased by 25% to 77.6 man-months due to the longer duration and the mounting indirect cost. This result clearly demonstrates the point: There really is no cost saving with subcritical staffing.

Planned Earned Value

Figure 11-15 shows the subcritical planned earned value. You can see that the supposed shallow S curve is almost a straight line.

In the extreme case of only a single developer doing all the work, the planned earned value is a straight line. In general, a lack of curvature in the planned earned value chart is a telltale sign for a subcritical project. Even the somewhat anemic shallow S curve in Figure 11-12 indicates the project is close to becoming subcritical.

Compression Using a Top Developer (Iteration 8)

Suppose you have access to a top developer who can perform coding activities 30% faster than the developers you already have. Such a top developer is likely to cost much more than 30% of the cost of a regular developer. In this project you can assume the top developer costs 80% more than a regular developer.

Ideally you would assign such a resource only on the critical path, but that is not always possible (recall the discussion of task continuity from Chapter 7). The normal baseline solution assigns two developers to the critical path, and your goal is to replace one of them with the top resource. To identify which one, you should consider both the number of activities and the number of days spent on the critical path per person.

Table 11-4 lists the two developers in the normal solution who touch the critical path, the number of critical activities versus noncritical activities each has, and the total duration on the critical path and off the critical path. Clearly, it is best to replace Developer 2 with the top developer.

Next, you need to revisit Table 11-1 (the duration estimations for each activity), identify the activities for which Developer 2 is responsible, and adjust their duration downward by 30% (the expected productivity gain with the better resource) using 5-day resolution. With the new activity durations, repeat the project duration and cost analysis while accounting for the additional 80% markup for Developer 2.

Figure 11-16 shows the critical path on the network diagram before and after compressing with the top developer.

The new project duration is 9.5 months, only 4% shorter than the duration of the original normal solution. The difference is so small because a new critical path has emerged, and that new path holds the project back. Such miniscule reduction in duration is a fairly common result. Even if that single resource is vastly more productive than the other team members, and even if all activities assigned to that top resource are done much faster, the durations of the activities assigned to regular team members are unaffected by the top resource, and those activities simply stifle the compression.

In terms of cost, the compressed project cost is unchanged, despite having a top resource that costs 80% more. This, too, is expected because of the indirect cost. Most software projects have a high indirect cost. Reducing the duration even by a little tends to pay for the cost of compression, at least with the initial compression attempts, because the minimum of the total cost curve is to the left of the normal solution (see Figure 9-10).

Compression Using a Second Top Developer (Iteration 9)

You could try compressing with multiple top resources. In this example, it makes sense to ask for just a second top developer to replace Developer 1 because a third top developer could be assigned only outside the critical path. With a second top resource, the compression has a more noticeable effect: The schedule is reduced by an additional 11% to 8.5 months, and the total cost is reduced by 3% to 59.3 man-months.

Low-Hanging Fruit

The best candidates for parallel work in most well-designed systems are the infrastructure and the Client designs because both are independent of the business logic. Earlier, you saw this independence play out in Iteration 2, which pushed the infrastructure to start immediately after the SDP review. To enable parallel work with the Clients, you split the Clients into separate design and development activities. Such Client-related design activities typically include the UX design, the UI design, and the API or SDK design (for external system interactions). Splitting the Clients also supports better separation of Client designs from the back-end system because the Clients should provide the best experience for the consumers of the services, not merely reflect the underlying system. You can now move the infrastructure development and the Client design activities to be parallel to the front end.

This move has two downsides, however. The lesser downside is the higher initial burn rate, which increases simply because you need developers as well as the core team at the beginning. The larger downside is that starting the work before the organization is committed to the project tends to make the organization decide to proceed, even if the smart thing to do is to cancel the project. It is human nature to disregard the sunk cost or to have an anchoring bias² attached to shining UI mockups.

2. https://en.wikipedia.org/wiki/Anchoring

I recommend moving the infrastructure and the Client designs to the front end only if the project is guaranteed to proceed and the purpose of the SDP review is solely to select which option to pursue (and to sign off on the project). You could mitigate the risk of biasing the SDP decision by moving only the infrastructure development to be in parallel to the front end, proceeding with the Client designs after the SDP review. Finally, make sure that the Client design activities are not misconstrued as significant progress by those who equate UI artifacts with progress. You should combine the work in the front end with project tracking (see Appendix A) to ensure decision makers correctly interpret the status of the project.

Adding and Splitting Activities

Identifying additional opportunities for parallel work is more challenging elsewhere in the project. You have to be creative and find ways of eliminating dependencies between coding activities. This almost always requires investing in additional activities that enable parallel work such as emulators, simulators, and integration activities. You also have to split activities and extract out of them new activities for the detailed design of contracts, interfaces, messages or the design of dependent services. These explicit design activities will take place in parallel to other activities.

There is no set formula for this kind of parallel work. You could do it for a few key activities or for most activities. You could perform the additional activities up-front or on-the-go. Very quickly you will realize that eliminating all dependencies between coding activities is practically impossible because there are diminishing returns on compression when all paths are near-critical. You will be climbing the direct cost curve of the project, which, near the minimum duration point (see Figure 9-3), is characterized by a steep slope, requiring even more cost for less and less reduction in schedule.

Infrastructure and Client Designs First (Iteration 10)

Returning to the example, the next iteration of project design compression moves the infrastructure in parallel to the front end. It also splits the Client activities into some up-front design work (e.g., requirements, test plan, UI design) and actual Client development, and moves the Client designs to the front end. In this example project you can assume that the Client design activities are independent of the infrastructure and are unique per Client.

Table 11-5 lists the revised set of activities, their duration, and their dependencies for this compression iteration.

Note that Logging (activity 6), and therefore the rest of the infrastructure activities, along with the new Client design activities (activities 24 and 25), can start at the beginning of the project. Note also that the actual Client development activities (activities 19 and 20) are shorter now and depend on the completion of the respective Client design activities.

Several potential issues arise when compressing this project by moving the infrastructure and the Client design activities to the front end. The first challenge is cost. The duration of the front end now exceeds the duration of the infrastructure and the Client design activities, even when done serially by the same resources. Therefore, starting that work simultaneously with the front end is wasteful because the developers will be idle toward the end. It is more economical to defer the start of the infrastructure and the Client designs until they become critical. This will increase the risk of the project, but reduce the cost while still compressing the project.

In this iteration, you can reduce the cost further by using the same two developers to develop the infrastructure first; after completing the infrastructure, they follow with the Client design activities. Since resource dependencies are dependencies, you make the Client design activities depend on the completion of the infrastructure (M1). To maximize the compression, the two developers used in the front end proceed to other project activities (the Resources) immediately after the SDP review (M0). In this specific case, to calculate the floats correctly, you also make the SDP review dependent on the completion of the Client design activities. This removes the dependency on the Client design activities from the Clients themselves and allows the Clients to inherit the dependency from the SDP review instead. Again, you can afford to override the dependencies of the network in this case only because the front end is longer than the infrastructure and the Client design activities combined. Table 11-6 shows the revised dependencies of the network (changes noted in red).

The other challenge with splitting activities is the increased complexity of the Clients as a whole. You could compensate for that complexity by assigning the Client design activities and development to the same two top developers from the previous compression iteration. This compounds the effect of compression with top resources. However, since the Clients and the project are now more complex and demanding, you should further compensate for that by assuming there is no 30% reduction in the time it takes to build the Clients (but the developers still cost 80% more). These compensations are already reflected in the duration estimation of activities 19 and 20 in Table 11-5 and Table 11-6.

The result of this compression iteration is a cost increase of 6% from the previous solution to 62.6 man-months and a schedule reduction of 8% to 7.8 months. Figure 11-17 shows the resulting network diagram.

Compression with Simulators (Iteration 11)

Examining Figure 11-17 reveals that a near-critical path (activities 10, 12, 15, 18, and 19) has developed alongside the critical path. This means any further compression requires compressing both of these paths to a similar degree. Compressing just one of them will have little effect because the other path then dictates the duration of the project. In this kind of situation, it is best to look for a crown—that is, a large activity that sits on top of both paths. Compressing the crown compresses both paths. In this example project, the best candidates are the development of the Client apps (activities 19 and 20) and the Manager services (activities 17 and 18). The Clients and Managers are relatively large activities, and they crown both paths. You could try to compress the Clients, the Managers, or both.

Compressing the Clients becomes possible when you develop simulators (see Chapter 9) for the Manager services on which they depend and move the development of the Clients somewhere upstream in the network, in parallel to other activities. Since no simulator is ever a perfect replacement for the real service, you also need to add explicit integration activities between the Clients and the Managers, once the Managers are complete. This in effect splits each Client development into two activities: The first is a development activity against the simulators, and the second is an integration activity against the Managers. As such, the Clients development may not be compressed, but the overall project duration is shortened.

You could mimic this approach by developing simulators for the Engines and ResourceAccess services on which the Managers depend, which enables development of the Managers earlier in the project. However, in a well-designed system and project, this would usually be far more difficult. Although simulating the underlying services would require many more simulators and make the project network very complex, the real issue is timing. The development of these simulators would have to take place more or less concurrently with the development of the very services they are supposed to simulate, so the actual compression you can realize from this approach is limited. You should consider simulators for the inner services only as a last resort.

In this example project, the best approach is to simulate the Managers only. You can compound the previous compression iteration (infrastructure and Client designs at the front end) by compressing it with simulators. A few new planning assumptions apply when compressing this iteration:

• Dependencies. The simulators could start after the front end, and they also require the infrastructure. This is inherited with a dependency on M0 (activity 22).

• Additional developers. When using the previous compression iteration as the starting point, two additional developers are required for the development of simulators and the Client implementations.

• Starting point. It is possible to reduce the cost of the two additional developers by deferring the work on the simulators and the Clients until they become critical. However, networks containing simulators tend to be fairly complex. You should compensate for that complexity by starting with the simulators as soon as possible and have the project benefit from higher float as opposed to lower cost.

Table 11-7 lists the activities and the changes to dependencies, while using the previous iteration as the baseline solution and incorporating its planning assumptions (changes noted in red).

Figure 11-18 shows the resulting staffing distribution chart. You can clearly see the sharp jump in the developers after the front end and the near-constant utilization of the resources. The average staffing in this solution is 8.9 people, with peak staffing of 11 people. Compared with the previous compression iteration, the simulators solution results in a 9% reduction in duration to 7.1 months, but increases the total cost by only 1% to 63.5 man-months. This small cost increase is due to the reduction in the indirect cost and the increased efficiency and expected throughput of the team when working in parallel.

Figure 11-19 shows the simulators solution network diagram. You can see the high float for the simulators (activities 26 and 27) and Client development (activities 28 and 29). Also observe that virtually all other network paths are critical or near critical and there is high integration pressure toward the end of the project. This solution is fragile to the unforeseen, and the network complexity drastically increases the execution risk.

Adjusting Outliers

Figure 11-28 features a conspicuous gap between the two risk models. This difference is due to a limitation of the activity risk model—namely, the activity risk model does not compute the risk values correctly when the floats in the project are not spread uniformly (see Chapter 10 for more details). In the case of the decompressed solutions, the high float values of the test plan and the test harness skew the activity risk values higher. These high float values are more than one standard deviation removed from the average of all the floats, making them outliers.

When computing activity risk at the decompression points, you can adjust the input by replacing the float of the outlier activities with the average of all floats plus one standard deviation of all floats. Using a spreadsheet, you can easily automate the adjustment of the outliers. Such an adjustment typically makes the risk models correlate more closely.

Figure 11-29 shows the adjusted activity risk curve along with the criticality risk curve. As you can see, the two risk models now concur.

Risk Tipping Point

The most important aspect of Figure 11-29 is the risk tipping point around D4. Decompressing the project even by a little to D4 decreases the risk substantially. Since D4 is right at the edge of the tipping point, you should be a bit more conservative and decompress to D3 to pass the knee in the curves.

Direct Cost and Decompression

To compare the decompressed solutions to the other solutions, you need to know their respective cost. The problem is that the decompression points provide only the duration and the risk. No project design solutions produce these points—they are just the risk value of the normal solution network with additional float. You have to extrapolate both the indirect and direct cost of the decompressed solutions from the known solutions.

In this example project, the indirect cost model is a straight line, and you can safely extrapolate the indirect cost from that of the other project design solution (excluding the subcritical solution). For example, the extrapolation for D1 yields an indirect cost of 51.1 man-months.

The direct cost extrapolation requires dealing with the effect of delays. The additional direct cost (beyond the normal solution that was used to create the decompressed solutions) comes from both the longer critical path and the longer idle time between noncritical activities. Because staffing is not fully dynamic or elastic, when a delay occurs, it often means people on other chains are idle, waiting for the critical activities to catch up.

In the example project’s normal solution, after the front end, the direct cost mostly consists of developers. The other contributors to direct cost are the test engineer activities and the final system testing. Since the test engineer has very large float, you can assume that the test engineer will not be affected by the schedule slip. The staffing distribution for the normal solution (shown in Figure 11-11) indicates that staffing peaks at 3 developers (and even that peak is not maintained for long) and goes as low as 1 developer. From Table 11-3, you can see that the normal solution uses 2.3 developers, on average. You can therefore assume that the decompression affects two developers. One of them consumes the extra decompression float, and the other one ends up idle.

The planning assumptions in this project stipulate that developers between activities are accounted for as a direct cost. Thus, when the project slips, the slip adds the direct cost of two developers times the difference in duration between the normal solution and the decompression point. In the case of the furthest decompression point D1 (at 13.4 months), the difference in duration from the normal solution (at 9.9 months) is 3.5 months, so the additional direct cost is 7 man-months. Since the normal solution has 21.8 man-months for its direct cost, the direct cost at D1 is 28.8 man-months. You can add the other decompression points by performing similar calculations. Figure 11-30 shows the modified direct-cost curve along with the risk curves.

Minimum Direct Cost

Following similar steps with the direct cost formula, you can easily calculate the point in time of minimum direct cost as 10.8 months. Ideally, the normal solution is also the point of minimum direct cost. In the example project, however, the normal solution is at 9.9 months. The discrepancy is partially due to the differences between a discrete model of the project and the continuous model (see Figure 11-30, where the normal solution is also minimum direct cost, versus Figure 11-31). A more meaningful reason is that the point has shifted due to rebuilding the time–cost curve to accommodate the risk decompression points. In practice, the normal solution is often offset a little from the point of minimum direct cost due to accommodating constraints. The rest of this chapter uses the duration of 10.8 months as the exact point of minimum direct cost.

Minimum Direct Cost and Risk

As mentioned earlier, the minimum of the direct cost model is at 10.8 months. Substituting that time value into the risk formula yields a risk value of 0.52; that is, the risk at the point of minimum direct cost is 0.52. Figure 11-33 visualizes this with the dashed blue lines.

Recall from Chapter 10 that ideally the minimum direct cost should be at 0.5 risk and that this point is the recommended decompression target. The example project is off that mark by 4%. While this project does not have project design solution with a duration of exactly 10.8 months, the known D3 decompression point comes close, with a duration of 10.9 months (see the dashed red lines in Figure 11-33). In a practical sense, these points are identical.

Optimal Project Design Option

The risk model value at D3 is at 0.50, meaning that D3 is the ideal target of risk decompression as well as practically the point of minimum direct cost. This makes D3 the optimal point in terms of direct cost, duration, and risk. The total cost at D3 is only 63.8 man-months, virtually the same as the minimum total cost. This also makes D3 the optimal point in terms of total cost, duration, and risk.

Being the optimal point means that the project design option has the highest probability of delivering on the commitments of the plan (the very definition of success). You should always strive to design around the point of minimum direct cost. Figure 11-34 visualizes the float of the project network at D3. As you can see, the network is a picture of health.