"Measure twice and cut once!" That was my father's mantra on the job site. He was a contractor, building houses, garages, assorted additions, porches, etc. It was his company and he had a small crew. In the summer when school was out, I often got to tag along with him. I'd pound nails, lug wood or roofing shingles, or just go around tidying up the construction site. When I got older I was allowed to operate the table saw, making cuts to the dimensions called down from ladders and scaffolding by my father and others. "Measure twice and cut once" was about making a small investment to avoid waste; the waste of time and material. Take the extra couple of seconds to measure a second time and ensure that the cut you make will produce a board that can be used the first time. A fraction of an inch too long and you have to walk the board back down, mark it up again, and shave off the excess while a person stood idle waiting for you to get it right. Make a cut just a fraction of an inch too short and you have to toss the board aside and cut a new one.

Thirty years later I too am in the construction business...of a sort. Developing software may seem very different and far removed from building a house, but I believe there is more in common than not. Consider requirements for example. If you don't invest the time and effort to capture and communicate a project's requirements effectively, the result will be wasted in the form of very costly rework. The Standish Group's "Chaos Report", an annual analysis of our industry and how we perform, consistently reports rework (on average) in the 40-60% range of total project spend. If my father built a house where 50% of the cost to the owner was in fixing things that he didn't get right the first time, he never would have built a second one, plain and simple. But yet, it appears to be "normal" or at least acceptable for our line of construction.

As a matter of full disclosure, I work for a software company with a requirements definition and management solution. However, this isn't a subtle (or not so subtle) attempt to pitch my product. Rather, it's an attempt to focus on the exact nature of the problem we all have a vested interest in solving. During sales cycles with prospective clients, I am often asked by a decision maker if implementing our solution will save time in the requirements process. My answer is no, implementing our solution is not going to make your existing people and process 10-15% faster or anything along those lines. If anything, it will probably add time to your existing process as there is a learning curve with anything new. However, I also add that this isn't what we as a vendor or they as a customer should be focused on at present. That isn't the problem. In fact, from a development organization's perspective, it should be acceptable, even desirable to DOUBLE the time it takes to execute on requirements, IF they can get them right the first time around.

Consider that on average only 3% of a project's cost is actually spent on the requirements process and that spending more (all things equal) will yeild better results (1). On a project that ultimately costs $1 Million, that figure would be $30k. We also We also know from the Standish Group that on average, $500k of that $1 Million total is wasted in the form of rework. Let's say we double the spend on requirements to $60k with the result that it drives out half of the rework or $250k. That is over a 400% return on investment and I don't know of any business man or woman that would forgo that rate of return.

What constitutes an increase in the requirements spend? It could be as simple as allowing the same people with existing process and tools more time to do their job. You could invest in process improvement initiatives or technology or both. You can train your existing practitioners in the use of new techniques such as use cases, storyboarding, diagramming, visualization, etc. You might consider an approach that breaks out requirements as a discipline into a center of excellence in much the same way that PMOs arose around project execution in years past.

But again, this article isn't so much about the solution as it is about shining the light on the problem. What we want/need to solve is the problem of waste or rework in our projects. Solve the requirements problem (the cause) and you solve the rework problem (the effect). As organizations we should be eager to invest in solutions (people, process & technology) relative to the requirements process. It really is as simple as "measure twice and cut once".

1. Hooks, Ivy F., and Kristin A. Farry. Customer-Centered Products: Creating Successful Products through Smart Requirements Management . New York: The American Management Association, 2001.