An Exciting New Model of Project Management
A Rare Compliment
Every so often something happens to make everything seem worth while, and so it is with this web site. In April we were paid a rare compliment because one, Joe Marasco, spotted our Musings on Sexy Triangles of a few months back and promptly took off. Now Joe is a very interesting person. He is a retired senior vice president of Rational Software, a company now owned by IBM. He has a PhD in physics from the University of Geneva, Switzerland, and an MBA from University of California, Irvine. During is career he has successfully managed very large software development projects and, perhaps more importantly, he is a thinker with an elite circle of intellectual friends to assist with problem solving.
So, what did Joe do? With some help he tore apart my illustration of Davis's tetrahedron (March 2004) and rebuilt it as a pyramid. Not only that, but by mid April he had a full paper published about it in the RationalEdge Ezine, IBM's premier software news magazine. Such is the speed of the Internet! You can see the full paper at: http://www-106.ibm.com/developerworks/rational/library/4291.html
A Rational Progression
I find the steps in his thinking most instructive because they build on previous work and follow roughly along these lines. First he took my star and changed "Cost" to "Resources" as you'll see in Figure 1. That is interesting because, of course, the consumption or application of resources is the main source of project cost in the first place.
Figure 1: Max's Star model (Modified)
Then he took a look at the tetrahedron model as shown in Figure 2.
Figure 2: The tetrahedron model (modified)
Of this, Joe observed:
"Although I agree with Max's insistence on quality as a critical fourth factor, I believe that his model still leaves something to be desired. When thinking about a project prior to beginning work on it, management is typically interested in the "shape" of the project - an interest that maps nicely to the four parameters illustrated in Figures 1 and 2. That is, we can state how much we intend to do (scope); we can describe how well we are going to do it (quality); we can predict how long we will take to complete the project (time); and we can estimate how much it will cost (resources). But then are we done with our project description?"
"I don't think so. Management is always interested in a fifth variable: namely risk. That is, given the previous four parameters we've identified and the plan that goes with them, management wants to know whether the project represents a high, medium, or low risk to the business."
A New Pyramid Model, Using the Sides, Not the Corners
So Joe proposed a pyramid with the base representing the original four variables but the height representing risk. That is also interesting because "risk" has always been a bit of an outsider, neither a project constraint, nor one of the facilitative functions in the traditional line up of eight project functional divisions.
But then he said let's assign extensive properties to the sides instead
of the vertices. However, he also wanted all sides to have compatible metrics
for their characteristics. That is to say, more scope is good, more quality
is good, more speed - the inverse of time spent - is good, and more frugality (of
resources, i.e. less cost) is good. Next, he tackled the pyramid's altitude.
More risk is not good, but more success is, so we have the probability of
success as the vertical dimension, all as shown in Figure
3.
Figure 3: Joe Marasco's project pyramid model
Joe then posited that for a given project and its implementation team, the volume should be a constant – a sort of project criterion value. That is, the volume is proportional to:
"challenge x probability of success"
As one goes up, the other must go down. For example, if we want to increase the chances of success, then we must decrease one or more sides of the base to reduce its area. Another way of looking at it is that maximizing the area of the base also maximizes the profitability of the project by simultaneously maximizing the value of the product and minimizing the cost to produce it. Hence, what we are trading off is profit versus probability of success. Interestingly, this is a fundamental premise with which every project manager is intuitively familiar.
Just exactly what the intrinsic volume of the pyramid is made up of is a bit of an open question at this point. Certainly there are all the project's "unknowns", and the question of the capability of the project team, but obviously this part needs more work.
A Problem, with a Solution
But then Joe observe a problem with the success scale. Higher is obviously better, but probability never exceeds (or even reaches) 100%, so you cannot double the probability of success by going from 60% to 120%. A different scale is needed that is not in fact far away. We could assume that project outcomes, in his case software development projects, conform to the positive side of the well-known "bell-curve" as shown in Figure 4. Hopefully, we don't launch any projects with planned negative outcomes!
Figure 4: Project outcomes related to the standard probability bell curve
Now, the distribution of successful outcomes can be expressed as a lognormal distribution using sigma, (i.e.
standard deviation) as the scale of outcomes as shown in Figure 5.
Figure 5: Lognormal distribution of positive outcomes only
The mid point of the bell curve, Figure 4, is "µ", and in Figure 5 it is coincident with 1 Sigma. That is, half the area to the left of 1 sigma and half to the right, assuming that our distribution of projects is correct. If that is true, then clearly we want our latest project to fall to the right. However, the meaning of sigma is different in this distribution in that you accrue area a little differently, i.e. below 1 you halve but above 1 you double. So, as shown in the Figure 5, 68% of the area lies between 0.5 and 2.0 sigma, and 95.5% lies between 0.25 and 4.0.
Application to Real Projects
What does all this have to do with real projects? I'll leave it to Joe to explain:
"What are the implications of this distribution for real projects? Because the peak of the curve lies at around 0.6 sigma, we see that the most likely outcome (as measured by the curve's height) is an unsuccessful project! In fact, if the peak were exactly at 0.5 sigma, your probability of success would be only around 16 percent:
50% - 1/2(68%) = 50% - 34% = 16%.
Since the peak is not at 0.5 sigma but closer to 0.6 sigma or 0.7 sigma, the probability of success is a little higher - around 20 percent."
"Now this is starting to become very interesting, because the Standish CHAOS report, of which I have always been skeptical, documents that around four out of every five software development projects fail. This is a 20 percent success rate. ... [So] it is interesting to note that the lognormal distribution predicts the Standish metric as the most likely outcome, which may mean that most development projects have a built-in difficulty factor that causes the lognormal distribution to
obtain."
In short, we should not be surprised at the outcomes we are getting.
Bottom line …
Of course the model makes a number of coarse assumptions and therefore has its limitations with consequent caveats. If you are interested, you should read the full paper which, as I said, can be
found at: http://www-106.ibm.com/developerworks/rational/library/4291.html
Nevertheless, the model does make one thing clear, if you want to significantly improve the chances of success of these kinds of projects, fiddling around with a mere 10% or even 20% contingency is not the answer! As Joe says:
"The simple pyramid model also shows how much you must trade off to improve your probability of success. Although it is speculative, the model helps us to soberly decide whether we are willing to invest the resources required to raise our probability of success above the minimum threshold acceptable for our business, given the scope, quality, and time constraints that we specify."
The fact is, most initial project plans are overly optimistic, either by design or by default. By design because we don't want this project to get killed before it is even started, or because we simply don't know any better, or both! So, project plans are typically overly optimistic by a lot. And, by the time the project manager and other management realize by just how much, it is too late. At that point they will typically try to band-aid the situation with a 10% to 20% patch on only one variable, when in fact they need to do much, much more to get to even a fighting chance of success.
So, we should use the Inception Phase of every project to at least correctly calibrate the remaining big unknowns and the quality of the team. If there is little chance that we can increase the volume of the pyramid at this point, then we must re-evaluate the area of the base and focus on the altitude. If we don't do that, then we are simply driving straight through the "orange light" that is flashing before our very eyes at the start of the elaboration phase. Iterative development especially, cannot work if we do not start adjusting the length of the legs when it becomes apparent that our altitude is far too short.
But, come to think of it, that also applies to any other type of project.
|
