Articles...

Copyright 2009 Corvus International Inc.  All Rights Reserved

Home      About Corvus       Contact Us       Articles/Resources       Clients          Affiliations  

Life is trying things to see if they work
 

                            Ray Bradbury
                     Science Fiction Author


ACM DL Author-ize serviceProject portfolios: organizational management of risk
Phillip G. Armour
Communications of the ACM - The disappearing computer, 2005

 

The bipolar risk company                                       

Some companies and individuals have a curious bipolar attitude to the risk associated with software projects.  As long as the risk is conceptual and in the future they vigorously assert they are not "risk averse".  In fact, not being willing to "accept" risk is considered wussy in some quarters, as if risk tolerance were some kind of testosterone measure.

However, when the risk becomes manifest, when it actually occurs, the hairy-chested, big-muscled risk takers suddenly turn into risk wimps, wringing their weeny hands and wailing about the result, casting about for someone to blame for the failure.  It is as if the relationship between risk and failure have been disconnected--we are willing to take risks, just as long as we don't fail.

All projects are risky                                           

All software projects are "risky" in that, when we start them there are things we do not know, and some of those things might be very important.  This is inherent in software projects--every project is (should be) building something we haven't built before and to some extent, we don't know how to build it or, in some extreme cases, even if we can build it.

Estimates MUST have probabilities                       

One of the consequences of this is that an estimate is not really an estimate UNLESS it has an associated risk.  That is, we should never see a result such as:

        "This project will cost $5m"

To truly express the reality of the project, the statement should be something like:

        "This project has a 50% probability of being completed for under $5m" [SEE NOTE AT BOTTOM]

Give me your best estimate                                   

I expect that you have heard this request from your boss.  It is a bogus request.  To a project manager the "best" solution is one that maximizes the probability of a "successful" project, one that comes in under budget and schedule.  The simple way to achieve this is to have a very large budget and long duration.  This is the simplest way to ensure resources are available to deal with risk if it manifests itself; but this is exactly opposite to the person making the request. 

An executive demanding: "...give me your best estimate..." really means: give me a small budget and short duration, often a budget and schedule at or below what I have already committed to.

We can see here, how appending a probability to an estimate makes sense.  We might quote a low probability for a given solution that is shorter and smaller budget and higher probability of delivering within budget and schedule if both are larger.

We do not inform risk                                           

The problem with quoting risk along with "estimates" is that few companies are able to quantify risk on their projects.  There are ways to do this, some of them similar to those used in equity investments in the stock market.  What companies need to build is an information structure and system that informs risk and project estimates the way we have done for accounting in companies.

Too many too risky                                           

Many companies seem to push all their projects up against the schedule wall.  They attempt to do too much in too short a time with too few resources.  In many cases this is driven by what they see as "market forces".  In other cases it is driven simply by senior executives' wishes and wants.  In all cases it is allowed to continue because companies have not set up the processes necessary to moderate it.

Almost all research in the topic shows that calendar duration is the most limiting resource.  Attempting to deliver functionality too quickly results in much lower productivity on a project and very significant levels of sheer waste.  See Real Work, Necessary Friction, Optional Chaos for the reasons.

What these companies are doing is investing only in all high risk (though not necessarily high return) projects.  It is the equivalent of stocking your 401(k) savings with all high tech junk bonds.

 

NOTE: What projects REALLY cost:
If I have a 50% probability of cost containment at $5m, but the project could run over to, say $6m or run under to, say, $4.5m then, given a typical probability distribution across this range, the Cost at Risk is just over $5.5m, so the project will most likely cost $531,000 more than expected. 

So says my Return at Risk Calculator. 

Please contact me to know more about this calculator.

Project Portfolios: Organizational Management of Risk