Why Software Estimates Stink

When a builder prices a custom home, he looks at all the pieces. He considers the concrete, lumber, plumbing, HVAC equipment, wiring, etc. — all the way down to the bathroom fixtures.

Why don’t software builders have the same level of accuracy in their build estimates?

Well, we could talk about how houses are assembled from well-known components available from multiple vendors. Or we could examine the amount of time and discipline that the housing industry enjoys, which dwarfs the software industry.

A major issue for software buyers is that they cannot easily describe the size, features and quality of the “house” they want. They offer desires like “fast” and “easy to use” and talk in vague terms about “order entry” and “shipping” functions. Likewise, the builder can rarely walk them through a software “model home” to demonstrate the ammenities available and their cost.

The benefit that a home builder has in approaching estimation with confidence a proven instrument of clarity and decision-making: a blueprint.

The heart of a software blueprint is the Features List — the list of what is to be built. If this list is broken down into estimatable units, the builder has a fair chance to give a price that is meaningful.

What is an estimatable unit? Think in verb-noun pairs like this:

  • Add Customer
  • Delete Order
  • Find Vendor
  • Update Order Status

When a complex subsystem like “Order Entry” is broken into smaller parts like this, both the buyer and the builder can see what is being estimated. Clarity like this produces confidence that the estimate has value — and the buyer can budget for success.

How to spot a Requirements Analyst


The next time you want to find the requirements analysts in your church (you don’t do this quarterly?), try this little trick.

Take the condiments from the church buffet line and put them in front of the hamburger buns.

An organized person will notice the discrepancy and discuss it with the people around them.

A process analyst will actually pick up the condiments and move them back, causing an immediate, though temporary, improvement in the efficiency of the line.

A requirements analyst — the kind of automation experts that we employ — will winsomely convince the buffet manager that everyone will benefit from reworking the buffet planning checklist so that this flaw in their queue management is never repeated.

Why use a Requirements Analyst?

Why hire an expert Requirements Analyst? Why not gather your own requirements internally?

Here are five reasons not to do it yourself:

  1. You’re in the box. You can’t even smell the cardboard anymore, much less describe it with a critical eye. An outsider will help you see yourselves objectively.
  2. The analyst has been here before. They’ve got the T-shirt,  understand the process and they already know what good requirements look like.
  3. Analysts are linear thinkers. These are people who get ill if the condiments are before the buns at the church picnic. Process thinking comes naturally to an analyst. You may or may not have honed that skill in your work.
  4. A good Requirements Analyst is also an experienced facilitator. There are different kinds of interviews to conduct: Executives, managers, staff, customers, etc. Our people can gather the essentials from each audience efficiently.
  5. You have better things to do. You had a full time job before this new project came along. Don’t you really want to leverage your strengths?

Using an experienced Requirements Analyst to systematically gather and document the features of your new system is a very efficient use of resources — yours and theirs.