Compression and Risk
As discussed previously, risk decreases slightly with high compression, reflecting the intuitive observation that shorter projects are safer. Quantified risk modeling offers an explanation for this phenomenon. The only practical way of highly compressing a software project is to introduce parallel wor0k. Chapter 9 listed several ideas for engaging in parallel work, such as splitting activities and performing the less-dependent phases in parallel to other activities or introducing additional activities that enable the parallel work. Figure 10-6 shows this effect in a qualitative manner.
FIGURE 10-6 High compression makes the network more parallel
Figure 10-6 depicts two networks, with the bottom diagram being the compressed version of the top diagram. The compressed solution has fewer critical activities, a shorter critical path, and more noncritical activities in parallel. When measuring the risk of such compressed projects, the presence of more of activities with float and fewer critical activities will decrease the risk value produced by both the criticality and activity risk models.
While the design risk of a highly parallel project may be lower than the design risk of a less compressed solution, such a project is more challenging to execute because of the additional dependencies and the increased number of activities that need to be scheduled and tracked. Such a project will have demanding scheduling constraints and require a larger team. In essence, a highly compressed project has converted design risk into execution risk. You should measure the execution risk as well as the design risk. A good proxy for the expected execution risk is the complexity of the network. Chapter 12 discusses how to quantify execution complexity.