When explaining software project management, the construction metaphor works well until I hit a wall of project definitions. A construction definition seems so tidy: consider a building's purpose and environment, do some sketches, draw some blueprints, and you are done - much easier than software. Most clients hope their software systems can be easily defined, but we don't know how to do that very well. I got pretty good at explaining why software was different from construction by focusing on two attributes of software:

1. Abstractness - Jerry Weinberg observes in his wonderful Quality Software Management series that because a software system can't be directly observed, all artifacts used to visualize software are abstract representations of the system itself. Each representation is an opportunity to introduce error and ambiguity. While a scale model of a building is an excellent way to help someone visualize what the building will look like, it is more difficult to gain a consistent and coherent perspective on a software system by reviewing a 500-page report extracted from the requirements database.
2. Complexity - Software systems consist of millions of parts that can be very unforgiving of errors. Each zero and one of the software must be EXACTLY correct to produce the desired result, requiring a level of complexity and specificity that is both essential and extremely difficult to manage.

While both of these arguments have merit, I have realized that I was solving the wrong problem - I was trying to explain why the building definition metaphor didn't work for software rather than looking for ways that it really did work. What if construction definitions weren't as tidy as I imagined? I reflected on it, and learned something.

Three years ago my wife and I bought our modest home in a quiet neighborhood. We are the third owners of our house, which was built in 1928. The first owners literally built the home and lived in it for nearly 60 years. The second owner occupied the house from 1986 to 2001. She converted the attic into a small master suite, upgraded the heating and electrical, and tore down a couple of walls. She was a do-it-yourself type who really loved the house. While her renovations were done on a tight budget, they were done with love and care.

We had the good fortune of buying the house three months before we moved in. The time was spent replacing kitchen counters, refinishing the hardwood floors, and painting everything. After settling in, we remodeled a bathroom, reinforced the foundation, and replaced the light fixtures, electrical outlets, water heater, and the stairs to the attic suite.

We really love our home. It's comfortable, charming, simple, and fits our lifestyle. When we recently renewed our insurance policy, my wife noted a replacement clause in the policy. If a fire or flood destroyed our home, the insurance company will replace the house. I thought it would be interesting to try and define our home sufficiently enough so that it could be replaced. I can imagine that my insurance company would get grumpy if I exactly replicated some aspects of our house.

• In our neighborhood, most modern structures are constructed on cement slab foundations and basements are unusual. However our home and others in the neighborhood built in the same era have small basements and a foundation raised about two feet above the lot on piers. This is relevant because I can actually crawl under the house to run speaker and computer network wiring. All of the ductwork for the heating and cooling systems and the plumbing run under the house and are accessible for inspection and repair. A benefit of this construction is that one foot of standing water on my property would flood my basement, but NOT damage my home - an attractive feature when you live near a major river.
• One of the defining features of craftsman style homes is the built-in cabinets and cubbyholes for storage. Visitors who know more about construction than I do have suggested that duplicating these features in a modern house would be expensive.
• The hardwood floors are made of aged oak with walnut inlay. They have survived wonderfully for three quarters of a century because the original owner covered them with linoleum for most of those years.

From the insurance company's perspective, they would probably argue that it isn't practical, reasonable, or cost effective for them to replicate some of the unique aspects of our home. They would likely define the home tersely:

• 1800 square feet
• Three bedrooms
• Two bathrooms
• Hard wood floors
• Consistent with current building practices

I can imagine the insurer offering to have a "comparable" home built atop a slab on our lot. They might even point out that it would be built with new and, in some cases, superior materials and that we were getting a very good deal. I wonder though, even if it has essentially the same floor plan, would my wife and I say they had captured the essence of our adorable little home?

If reasonable people can disagree about the definition of a house when there is a life-size exact model to use as a reference point, is it any wonder that others might disagree about the definition of a software system that exists only in their respective imaginations? Attributes of our home that are relevant to us might not be relevant to our insurance company. Who gets to decide which attributes drive the decision? If I explore further, I might discover some attributes that are important to me that aren't important to my wife, and vice versa.

If something happened to our house, we would be in the classic hard spot of defining what was lost. Our lives would be turned upside down and there would be pressure to recover quickly. The insurance company would also want to settle the issue as quickly and inexpensively as possible (just like most systems integration vendors working on fixed price software projects). The insurance company would care about providing good service, hoping to keep us happy so we might refer our friends to them because many people would hear about it if we were not satisfied.

In this hypothetical situation, agreeing on a reasonable definition seems like a difficult task, yet it is essential to the ultimate success of the project. Making time to attend to details is difficult, and to completely specify all aspects of the project from the outset would likely be impossible. But it is important to agree on a working definition and on a process for negotiating amendments to that definition as the project goes on. Not only are the same things true for software projects, but the extra challenges of abstractness and complexity make flexibility even more important.