The Eye of the Beholder

[article]
Why Project Definition is Important, Difficult, and Dynamic
Summary:

Home construction metaphors are often helpful for communicating software project management concepts. Listeners don't need an engineering degree to grasp that task sequence is important. Explain how you must schedule an appointment for the "open wall" electrical inspection two weeks in advance. Then, explain how a one-day slip on a wiring task can result in a much longer delay in the start of the sheet rock task, which in turn may delay painting, thus, occupancy by weeks, possibly months -- same as with delays in software projects. In this week's column Payson Hall draws from personal home-ownership experience and defines the resemblance between software project management and managing his home.

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

About the author

Payson Hall's picture Payson Hall

Payson Hall is a consulting project manager for Catalysis Group, Inc. in Sacramento, California. Payson consults on project management issues and teaches project management. Email Payson at payson@catalysisgroup.com. Follow him on twitter at @paysonhall.

StickyMinds is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!