An attempt to trade quality for cost or schedule actually results in increased cost and a longer schedule.

Steve McConnell,
Professional Software Development

What has long been known in other businesses is true for software development as well: if you cut corners for shorter schedules or lower costs, you will get longer schedules, higher costs, and higher defect rates; but if you take the right measures to lower defect rates, you can get lower defect rates and shorter schedules and lower costs. As Crosby wrote, “Quality is free.” But it’s free only in terms of ROI, meaning the investment must be made first; and it’s only free if you first define what you mean by “quality”.

Fortunately, Crosby provided the appropriate definition as well: quality is conformance to requirements. That can be a concrete, quantifiable definition; but in some way it just moves the problem down the road, leaving us to define requirements: not just the term, but the specific requirements of our projects. It leaves us with this inescapable truth:

If we don’t know our requirements, we can’t have quality.

…we must define quality as “conformance to requirements” if we are to manage it.

Philip B. Crosby,
Quality is Free: The Art of Making Quality Certain

Poorly defined requirements are endemic to the software development industry. Boehm’s research on factors that affect development schedules and costs show that:

Excellent requirements analysts can reduce a project’s schedule by almost 30%, while inadequate analysis can increase the schedule by over 40%.

Again and again, schedule pressures lead teams to start developing before they have sufficient requirements definition.

Even though requirements analysis is a key skill, the topic isn’t as “hot” as new technologies and tools that are promoted by vendors and conferences and magazines. And many development teams feel swamped just trying to keep up with technologies and tools.

Martin L. Shoemaker

Data from Boehm et al., Software Cost Estimation with COCOMO II

Among all personnel factors, Analyst capability has the widest range of impact (multiplier range of 2, worst case divided by best case). Teams may tout their application experience as a strength; but application experience has an Influence Range of only 1.51. Application and platform experience combined have an Influence Range of 2.11. Teams would never throw out their domain knowledge and develop for an entirely new platform; but poor requirements practices have almost the same Impact Range.

These teams aren’t foolish, yet they foolishly let a critical aspect of their process get out of control on project after project. A look at their team rosters may give a clue as to why: while there are many roles on the rosters, there may be none with requirements as a primary responsibility. Marketing and sales have requirements responsibilities, but many conflicting responsibilities as well. Lead engineers are supposed to verify requirements; but they are also too busy, and are commonly focused on solutions, not requirements. Designers and developers also focus more on how than on what. Traditionally in software development, analysts have primary responsibility for and are evaluated on the correctness of requirements.

The role of requirements analysts is
to define the problem in a verifiable form,
so that teams may recognize a valid solution.

And next you must ask: who owns that responsibility in your organization? If the answer is “no one” or “I don’t know”, there’s a ripe opportunity to cut your schedules by 30% to maybe even 50%, all while improving your quality.

Code is not enough. It’s all about requirements; and that’s all about communication.

A business classic tells us that Quality Is Free. The title is intentionally provocative: no, quality isn’t free, it just pays for itself. But first, you have to pay for it.

And that, unfortunately, is where we fail in the quality game so often. Corporations seem addicted to the practice of compartmentalized budgeting, or what I think of as “bucket budgeting”: you’ve got a bunch of different buckets you pour money into at the start of the fiscal period; and each bucket can only be spent on a particular purpose. When that bucket is empty, you can’t accomplish that purpose any more. Oh, the company may have some reserve you can tap; but you’re going to get frowned at for exhausting your budget.

I understand bucket budgeting as a planning tool. I think it makes perfect sense, for the same reason you should make estimates out of small elements. In fact, it should the exact same reason, because these budgets should be estimates, not shackles. You’ll correct over time.

And that’s where the failure comes in. Somehow, some way, in too many organizations, those buckets are shackles. Your bucket is what you can spend, what you will spend — regardless of the bottom-line impact of your spending. Even if every $1 spent out of your bucket brings $1.20 into the company, you only get to spend what’s in your bucket. This isn’t a new complaint, of course; and smart managers certainly keep an eye out for ways that spending money can save or generate more than they spend. But less bold managers don’t like to rock boats. They live within their buckets, because overspending their bucket gets them a bad review. It takes courage to stand up and make a case for more money in your bucket, unless you have a very clear, simple chain between the money you spend and the money that comes back in.

And the quality equation is particularly susceptible to bucket budget shackles. Quality does pay for itself, but it seldom shows up anywhere near the buckets where the costs came from. The cost of quality is measured in extra labor and time up front on preventing defects, along with extra labor and on the back end detecting and correcting defects. It’s also training time, which takes time away from “productive” work. It’s also management time and communications effort in getting everyone — execs, workers, and customers — to understand that seemingly slower time is actually faster in the long run.

The benefits of quality, meanwhile, are in reduced support costs, reduced rework costs, and increased customer satisfaction and loyalty. These do affect the bottom line; but they don’t put money in the buckets of the managers who have to pay for the quality in the first place.

A common sarcastic reaction I here among the workforce is “Quality is free, so management thinks they can have it without paying for it.” And sadly, this reaction is often justified. But I don’t think most managers are really that clueless. I do think many managers are shackled by bucket budgeting, and unwilling to buck the system for something that won’t have an effect on their budgets. The effect may be the same as cluelessness; but if we don’t understand the proper cause, we can’t devise the proper correction.

And no, I don’t know what that correction is. I mean, to me, the answer is simple: start treating budgets as estimates, not shackles; but I don’t think little old me is going to change corporate culture that drastically just by saying so.

Final note: this isn’t inspired by anything at my current client. Really, it’s not: I’ve been complaining about bucket budgeting for over a decade. But it’s true that my client is currently entering a phase where they’re trying to invest in quality in pursuit of benefits in the long run, and I want to do my part for that. There are forces that will push against that effort, and forces that will push for it. I’m doing a little writing to help me clarify how I can help push in the right direction.