This article is based on information from Hooks and Farry's book entitled, 'Customer-Centered Products.'

'Better, cheaper, faster!' 'I want it yesterday!'

Everyone out there has heard one or more of these - how and when you've heard them depends on your industry. But they translate into the same headaches for everyone. If you are a product development manager, you must develop and deliver higher quality products in less time and for less money than you have in the past. If you are in charge of procuring products for use in your company, you must procure a quality product faster and cheaper than ever before - especially in this economy. Otherwise, you may not be able to stay in business.

Many of us have been struggling with using the words faster, better, cheaper in the same sentence. Conventional wisdom says that you must sacrifice 'better' to get 'faster' or 'cheaper,' not to mention 'faster' AND 'cheaper.' You probably grew up with ads saying that 'quality takes time' and 'you get what you pay for.' You may have recently been on a project in which someone above arbitrarily cut your budget or reduced your schedule or both, and yet they did not lower their expectations of the final output - and they may have even increased it. If so, you know that you can't get there by simply driving your people faster or even adding more people to the project (which would make the cheaper part impossible anyway).

If you are a development manager, you are already streamlining manufacturing and testing processes, reducing material waste, increasing process yields, and automating the most labor-intensive or operator error-prone steps. These steps reduce time and cost and improve quality, but they usually do not lead to breakthrough savings or revolutionary quality improvements. The savings are limited by the product design. What drives design? Product requirements: the needs the product must meet to be a success. Increasing your investment before product design or purchase - ensuring that you have a complete, correct set of product requirements in the eyes of all stakeholders - is the real key to better, cheaper, and faster product development or procurement.

Consider one of your recent projects, product developments or procurement efforts. What requirements did the effort start with? Were these requirements clear? How many times did they change? Did crises occur during developmental testing? Did you discover that you had missed or misunderstood a requirement in acceptance testing? Did operations deployment go smoothly? You may be shrugging the problems off, thinking, 'No worse than usual.' Or saying, 'That's just the nature of project management or product development.'

If you are a typical manager, your culture may blind you to alternatives. 'Never time enough to do it right, but always time enough to do it over' is not just a joke. It's ingrained into our culture. Reconsider for a moment: Does development rework resulting from misunderstanding the users' needs add to the final product's quality? Do the delays caused by that rework or unanticipated manufacturing or testing requirements add anything to the product's performance in the field? Do product features that your users don't need add to their satisfaction? No. Do they add to the development time and cost? Do they add procurement and installation costs? Yes. One study found that approximately 40% of the total budget for software projects was actually spent on rework. Another study found that the rework cost on the largest software projects can often approach 50%.

Now for the good news

The good news is: 'Better, cheaper, faster' is actually possible. Eliminating rework and the eliminating the inclusion of unnecessary features rooted in poor requirements definition can make projects and product development faster and cheaper without sacrificing better. At the same time, improving the fit between the product or solution and the customer's needs also makes it better. You can frame the structure of success - good requirements - early in a project. Start with good requirements, and win on quality, cost, and schedule.

Now the bad news: You have to change your approach to project and product development or procurement in order to realize 'better, cheaper, and faster.' Repeating the mantra is not enough. Nor is it enough to tell your requirement definition team to simply 'write better requirements.' If that was all it took, we all would have done that long ago. You, as the project manager, must identify the areas needing improvement and empower your people to change. Only a manager can eliminate many of the causes of bad requirements. The seeds of schedule and cost overruns as well as operational failures are planted early in projects, typically with pressure, often from management to procure or begin developing a product before fully defining it's needs and use.

Customers frequently do not understand their own needs before engaging a developer. When customers do understand their needs, they may not communicate these needs clearly. Sometimes customers describe a possible solution to their needs rather than the needs themselves. Developers make assumptions about the customers' needs and do not check their assumptions with the customer before charging into development. It is this type of rogue development practice that can get a project in to trouble quickly. Customer expectations drift while the development or procurement is underway.

Sometimes the original requirements are too ambitious for the budget and schedule. The requirement risk assessment before development start is inadequate. Partway through development, it becomes clear that the original requirements cannot be met. The descoping and redefining process involves scrapping much of the development work done to date, or procuring an entirely different product.

Even worse is the situation when the product enters acceptance testing before the miscommunications become apparent. The customer finds that the product does not meet their needs and reject it, often citing a huge list of 'bugs.' These are bugs only in the context of the customer's needs. They are mismatches with the customer's expectations, not technical flaws in the product. Still the development team must redesign and rebuild the product or solution to meet the customer's now all-to-clear needs. Much of the work that went into the first product, the product that did not meet the customer's needs, is wasted.

Bad requirements result in cost overruns, schedule slips, frustrated and overworked employees, lost profitability, and limited careers. All else being equal, high-quality requirements contribute to high-quality products completed on schedule and within budget. Quality products begin long before manufacturing and testing. They begin before design. Never will you have more leverage - dollar for dollar - on your product or project's quality than you have in the requirement definition phase.

We discussed what we all really already know - that bad requirements usually lead to cost or budget overruns, project timeframe slippages, frustrated and overworked employees, dissatisfied customers, lost profitability, and quite possibly shortened tenure with your company.

The ultimate cost of requirement errors and omissions can be huge beyond just the rework factor. Requirements drive more than just project and product quality. They drive product end-user usability. They drive the personnel skill levels for both product development and operation. They determine how the product will be used. Requirements for ease of operation, for example, lead to products that require less training before use and less time to accomplish tasks. Omitting operability requirements will result in a product that is inexpensive to purchase but costly to use. Worse, end-user operators may make more mistakes in the product's use.

If you increase your investment in requirement definition, what return can you expect? Studies conducted by NASA in 1991 and 1992 revealed average cost and schedule overruns of approximately 65% in 29 programs. Their findings indicated that those projects that invested 10% or more of their total resources before freezing requirements had 0% to 50% overruns. For projects that spent 5% or less on requirements definition experienced 100% to 200% cost overruns.

Public projects are often larger and affect more people than private sector projects; this fact, and the obligation of our government to be open with the public, results in most project failure headlines being about government projects. These headlines can give the impression that government administrators are not managing projects as well as their private sector counterparts when this is not likely the case. Just as many incomplete, over budgeted, and ill-conceived products exist in the private sector as in the public sector - they just don't get the same amount of press.

Conclusion

Public or private, for-profit or not-for-profit, service or manufacturing, it doesn't matter what your industry or product. Good requirements are crucial to a project's success. Project managers from all areas must take responsibility for ensuring quality requirements. If you are managing an effort to define requirements for a procurement, requirements are your first product. If you are directing the procurement, the requirements guide the purchase. If you are managing the development of the product being procured, the requirements guide the development effort.

If your product is a service, defining the requirement to be met is just as important in the consumer's perception of quality as when your product is a physical object. It will be tempting for those whose product is not specifically a set of requirements to say, 'I don't write them ... I just have to meet them.' When all is said and done, however, the customer or end-user will not separate the blame for failure to meet their expectations. The finest design, workmanship, and materials will still be labeled poor quality if it fails to do the job for the customer. Everyone in the chain from product or project concept to realization must concern themselves with the quality of the requirements. Project managers must set the pace for their team and company in this effort.