At this point, I can attempt to figure out the right "scale" for the altitude. I can measure the edges along the base in familiar units:
But what about that pesky probability of successour altitude? We know that "longer is better," that a higher altitude corresponds to a higher probability of success. But there is a slight problem with using probabilitya percentagebased measurementas the scale. For example, if I have a pyramid with an altitude corresponding to a 60 percent probability of success, I cannot, under the constant volume assumption, improve that percentage by cutting the area of the base in half in order to double the altitude. That would give us an absurd answer of "120 percent probability of success," and I know that probabilities must be between zero and 100 percent. To resolve this conundrum, I must investigate how the outcomes of software development projects are distributed. Can I assume that these project outcomes are distributed according to the standard normal distributionthe wellknown "bell curve"? The diagram in Figure 9.4 is worth a thousand words. Figure 9.4. How software development project outcomes relate to the standard probability bell curve.If you happen to be rusty on what a probability distribution function is, recall that the xaxis represents the outcome, and the yaxis represents the number of events with that outcome which, properly normalized, is the probability of that outcome. If you start from the left edge and sweep out the area under the curve, you measure the cumulative probability of attaining that outcome. In Figure 9.4, the percentages beneath the xaxis show us how much area is contained between the xaxis coordinates that are spanned. Note that the distribution is "normalized" here, with the midpoint called µ, and the "width" of the distribution characterized by the standard deviation sigma (s). The distribution extends to both plus and minus infinity, but note that the "tails" of the distribution past the plus and minus 3 sigma limits are quite small; the two tails share less than 0.3 percent of the entire area under the curve. The graph tells us that 68 percent of the projects will be either somewhat successful or somewhat unsuccessful, that only about 27.5 percent (95.5 percent minus 68 percent) will be either very successful or very unsuccessful, and that only 4.2 percent (99.7 percent minus 95.5 percent) will be either extremely successful or extremely unsuccessful. To get the relevant percentages for each of these, you can just divide by two, as there is symmetry around the middle. For example, you can predict that around 34 percentapproximately a thirdof all projects will be somewhat successful. In many applications you assume that µ is zero, so the outcomes range from minus infinity to plus infinity. But the standard normal distribution is also used to model things that are only positive, such as the heights of people. In that case, µ is shifted to represent the mean value of the distribution. What is the situation for project outcomes? You can think of the xaxis as the net payoff or reward. Although I am sure many software development projects have had zero or negative payoff, it is hard to conceive of a project having a very large negative payoff.^{[3]} This is because all projects will be cancelled by management long before they even start to approach minus infinity! So the symmetrical standard normal distribution centered on zero with tails to infinity in both directions seems to be the wrong model. What about the "shifted standard normal?" Here again, there are lots of reasons to suspect that the distribution is skewed, with a very long (if not infinite) positive tail and a shorter, finite tail in the negative direction. For example, the total net payoff on a project such as MSDOS is very, very large. On the other hand, it is hard to imagine a project not being cancelled long before its net payoff was the symmetrical negative number! What we'd prefer is a distribution that has a finite limit on negative outcomes.
