Scarce Resources: Part II

With the last post, I described a common problem in most any technical team: scarce resources. You'll hear, in virtually every technical team anywhere, "we don't have enough resources" and they're almost always talking about people. They're correct, but not always in the way they think.

Are we doing the right things?

Let's start with something simple: requirements documentation. Most people would agree you need requirements in some form, although the specific methods and extent has been debated for nearly as long as software has existed. How do we know enough is enough? How much is too much?

The answer, it turns out, is simple; we simply ask ourselves, during the process: does what I'm doing improve the project or could the time be better spent somewhere else? Does adding this sentance make the specification more clear, or does it serve to confuse? If I only had another hour, would I continue to add more and more detail on how the login function works, or could I better spend that hour detailing a much higher risk requirement, more likely to require clarification?

These sound like simple questions, but even with experienced professionals, they are rarely asked. I once remember reviewing a project requirements specification that spent three pages documenting a login function that had already been built and deployed on another project. We knew how to build it. The client knew how it worked. The time could have been much better spent elsewhere.

How much did it cost?

In the above example, we spent our time and resources detailing a login page that added nearly no value. Let's assume it took 4 hours to add the extra unnessasary documentation. What was the cost? It was not, as first suggested to me, $400 (4 hours x internal loaded resource cost of $100/hr). Let's assume we spent those 4 hours doing the best available alternative: talking to the client to clarify and detail the riskiest point of the project. Had that prevented only one complex defect from being injected during the requirements stage, we might have saved days of work in testing, removing and re-deploying the defect. Our mis-spent 4 hours had, in effect, cost us no less than 24 hours fixing, 3 hours testing, and an hour of deployment time, for a grand total of $2800 (28 hours x $100/hr). When we factor in indirect and intangible costs like client perception (an inhibitor to future work), client meetings to discuss and diagnose the defect, and potential delays to the schedule, we see that our 3 page login spec was quite costly indeed.

28 Hours for a Single Defect: Isn't that a bit much?

Not at all. Barry Boehm first suggested that defects injected in the requirements stage can cost between 10 and 100 times the cost to fix if found in later phases (post launch, for example) in his landmark book, Software Engineering Economics (published in 1981). While that number has been hotly contested, my experience is that the concept, if not the precise numbers, are generally correct. I suspect most software engineers can think of more extreme cases with much larger numbers than I've used as a ballpark here.

In Summary

Focus throughout the project on the best available activities is an important part of keeping a project high quality and on schedule for a given budget. It is no less important for the requirements team (as illustrated here) as it is for later project participants: architects, programmers, quality assurance and, of course, project managers.

More on those in a future entry.