One Stanford academic is saying there is a major flaw in how project time is calculated, particularly in software development. All it takes, says Professor Sam Savage of Stanford University, is for one inflexible average number to be added in a spreadsheet to throw off the whole project.
Tony Kontzer at CIO Insight writes in a recent blog post:
““The flaw of averages happens when people plug a single number into a cell to represent a probability,” Savage said during a recent interview. “Think of taking a spreadsheet and adding a third dimension to it. Any cell in your spreadsheet should be able to provide you with an average.”It’s a big concept to get one’s brain around, so to illustrate the problem consider this crude example of how Savage believes averages doom many IT projects: Take a software development project in which 10 separate teams are each working on a particular sub-routine, with no interdependence between them at all. The project manager isn’t sure how long each sub-routine will take, but he knows the average will be 3 months, so he relays that to the boss when pressed.Unfortunately, according to Savage, there is only one chance in a thousand that the project will be done in 3 months–the same odds as flipping a quarter and have it come up heads 10 straight times. In the end, the boss is unhappy, the project manager is held responsible, and stress levels for the next development project rise. Ultimately, companies find themselves resigned to [accepting] that most software projects will take longer than expected, when in fact the problem is that the practice of using historical averages to compute probable completion dates is fundamentally flawed.“
This is pretty heady stuff, but the point is well taken–especially if developing a new technology or with a changing roster of players these days (think layoffs and ship jumpers). Now, Savage suggests, is not the time to get burned by too much risk and incorrect averages. He details all of this in his book “The Flaw of Averages.”
Savage has gone so far as to develop software he believes is more in tune with probability than current tools out there. You can request to check out a version of XLSim 3.0 here.