Fixing the misunderstandings about estimating iterative projects requires a look at a language issue. At least part of the problem can be traced to the words and models we use to explain our work. First, we typically present the software-development-lifecycle model without putting it in the context of the software product lifecycle. Second, when we talk about the development lifecycle, we use words that lead the listener to compare what we're describing to other product lifecycle models, not other development lifecycle models. Worse yet, we use language that causes users to compare our development lifecycle model to the wrong industry.

To clarify the misunderstanding, we need to place the development lifecycle into the context of the product lifecycle. Why? Because any misunderstanding at this level virtually guarantees false expectations. Product lifecycles are inherently sequential. To use a manufacturing analogy, when PCs come off the assembly line they're supposed to go to customers, not back to engineering. Development lifecycles, on the other hand, are inherently iterative. The engineering groups in a PC manufacturer typically produce several iterations of a product before the design is called final and released to the manufacturing
group.

Iterations in a development lifecycle represent learning. Iterations in a product lifecycle represent waste. We need to make sure that our customers understand the difference between product lifecycle models and development lifecycle models and, when it comes to expectations about predictability, that they are using the appropriate concept. Why would business people think we're talking about a product lifecycle rather than a development lifecycle? In presenting the SDLC we use words that almost automatically lead the listener into that trap. Have you seen SWEBOK? The IEEE recently released the trial version of the Software Engineering Body of Knowledge. You can download it at www.swebok.org.

What does it call the coding phase? Construction. The presentation of the SDLC as "Requirements Design-> Construction-> Test->" corresponds all too closely to the product lifecycle for the building industry. Google "building lifecycle" and you'll find a paper on "Sustainable Design" by the University of Minnesota College of Architecture and Landscape Architecture, which characterizes the building lifecycle phases as Pre-design; Design; Construction; Occupancy.

Both the model and the words we use to present the SDLC make it easy for business people to make the mistake of comparing it to a product lifecycle model. What happens when they do? They expect coding to be like laying bricks. They think, "All we need to do is estimate the number of bricks (or lines of code) we'll need and, voila, out will pop a reliable estimate!" Flawed analogies lead to flawed expectations.

As if it's not damaging enough to make inappropriate comparisons between the wrong models, the use of the word construction in the SDLC leads the listener to compare the wrong industries. The examples from the building industry that come to mind for a typical businessperson are much too simple. The manufacturing industry, especially PC manufacturers, provides much more appropriate analogies. Both computer hardware and software are logic-based. They're obviously related since software runs on hardware. And when you compare the design phases of the product lifecycles, you get very good analogies.Hardware engineering groups typically produce a multitude of designs, several of which are actually manufactured and tested, before a design is called final and released to manufacturing. The design or engineering phase in the hardware business is very iterative. This is the analogy to which we should be steering the business consumers of software. The words we use to describe what we do are probably too firmly ingrained to change. But we can, at least, start presenting the SDLC in the context of the product lifecycle to bring home the point that all of software development is a design activity. We need to start presenting something like the picture below.

Requirements-> Design-> Manufacturing-> Ship

This is by no means a perfect representation of reality. No model is. But it gets us closer and gets us talking about the right things. Requirements show up in both places. That's because once we enter design we begin getting much more detailed requirements. Requirements gathering and management is an ongoing, learning process.

What about manufacturing? We don't have to do that for IT software. Exactly. But that doesn't mean it's valid to treat part of the design phase as though it were a manufacturing activity. We need to correct the invalid and unattainable expectations of predictability that too many people have of IT software development. Such expectations follow from the misnomer: "construction." Presenting a more accurate model, and emphasizing that some of the words may be misleading, is a step in the right direction.