J. SYSTEMS SOFTWARE 1 1993; 23:1-2

Editor’s Corner Software Estimation is Not a Rational Process

Robert L. Glass

How do project cost and made in your organization?

Do you ask key players

schedule estimates get

who’ve been there and done it before for their expert opinion? (Academics call this the “analogic approach” since the estimate is made by analogy with past experiences). Or do you use some sort of algorithm, perhaps a computer- ized one, into which you put a lot of data estimates about the size and shape of the eventual finished product? (Academics call that the “analytic ap- proach” since it involves analysis of past and present data). Most computing people would say they do one or the other. Many companies, in fact, use both methods-sort of a belt and suspendors approach to estimation, since neither approach has proven terri- bly credible by itself.

Analogic, analytic. Is that as far as estimation approaches? Based on what I see in print, the an- swer would seem to be “yes.” But there’s another, more troubling, very different answer to the ques- tion “how do we do software estimation?”

Shh! Quietly, now, follow me into the corner over here, where no one can hear us, and I’ll tell you how software estimation really happens! You see, ana- logic and analytic approaches are essentially “ra- tional.” That is, we gather data to understand our problem and then use those data in a logical way to formulate an answer. But there is another less ratio- nal way in which software estimates happen. It is called “political estimation.” And it is probably the preferred form of estimation in most of the compa- nies I’ve worked for.

What is political estimation? It’s the process of coming up with an estimate based not on the time and money it will take to build a project but on the time and money available from the funders of the project. And it doesn’t involve any analogy or much analysis at all. It involves bargaining and mutual

This editorial was reprinted with permission fi-om the column “Software Reflections” by Robert L. Glass in System Development, P.O. Box 9280, Phoenix AZ 85068.

0 Elsevier Science Publishing Co., Inc.

655 Avenue of the Americas, New York, NY 10010

adjustment based on political power and supply and demand.

The process of political estimation is nicely de- scribed in a paper by Albert Lederer and coworkers [l]. The authors say, based on a research study, that most companies use this estimation approach in spite of the fact that they have a formalized, standard- ized, documented, rational estimation approach. What actually happens is that, when the rational estima- tion process is completed, the political process takes over-and takes precedence. Does marketing need the product last week? The schedule accelerates. Does the customer have tight pockets this quarter? The cost estimate drops. And the final negotiated cost and schedule estimate to which the project is built, is determined independent of the input of those who will build it.

So the cost and schedule estimates that define many software projects are, in fact, often not based on rational thought. Small wonder that people often see software development having cost and schedule conformance problems!

There is another strange side to the software estimation process. It has to do not with how but with when we do software estimation. We have come to accept that software estimates are made at the beginning of the life cycle. We commit to targets before we do the requirements analysis, create the design, write the code, or do any testing. At first reading, since we are used to doing business in that way, it all seems perfectly reasonable.

But is it? Let’s start with the middle sentence of the above paragraph: “We commit . . . before we do the requirements analysis. . . . ” We what? We pro- vide our rational estimates before we have even studied the problem enough to state what it is? And we call this a “rational” approach?

Do people in other fields provide estimates before they have defined the problem? A friend of mine who rubs shoulders with other kinds of (nonsoft- ware) engineers says that, for the most part, they don’t. They give an estimate for constructing a prod- uct after they have studied the requirements. How

(llh4-1212/93/$6.00

2 J. SYSTEMS SOFTWARE 1993: 23:1-2

Editor’s Corner

did we in software get in this strange predicament of being asked for a degree of foresight, in our new field that has little history from which to draw ana- logic or analytic insight, that our colleagues in older and more practiced fields aren’t asked to provide?

And then it gets worse. In most fields, as the project moves forward, estimates are adjusted based on actual conditions. That is, if during the first month of the project, it becomes obvious that the project is taking twice as long as the original esti- mates, the final target estimates are adjusted to accomodate this (unfortunate) piece of reality. Does that happen in software development? Rarely. In- stead, pressure is put on the developers to make up the schedule slack. One lives-or, more often, dies -by the original schedule estimate.

Now if this discussion were only about estimation, then it might be dismissed with a “ho-hum, wouldn’t it be nice to fix that.” But there’s an even deeper problem here. As we approach an ever-less-realistic cost and schedule deadline, and as management increases the pressure to meet the increasingly im- possible targets, something has to give. Because

software quality is elusive and hard for customers to measure, it is usually quality that suffers. Testers cut back on testing. An unreliable software product re- sults.

There’s an irony to all this. Bad estimates, caused by an irrational political process and irrational tim- ing, result in software that is behind schedule, over budget, and unreliable. But wait! Aren’t those the characteristics of the so-called “software crisis?” Could it be that, whatever this software crisis really is, it is caused not by poor technology and weak technologists, but rather by irrational estimation? If that is so, the price we are paying for this problem is high, indeed. Both the image and the reality of software are being tainted by the estimation process.

It’s something to think about. And a problem worth solving.

REFERENCES

1. A. Lederer et al., Information System Cost Estimat- ing: A Management Perspective, MIS Quart (June, 1990).