Good Requirements vs. Rework

The post is made possible by the great people at Seavus, creators of online Project Management tools such as ProjectOffice.net, Project Viewer, and Project Planner.  Please visit their site for more information.

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.

Related posts:

1. Good Requirements vs. Rework – Part 2
2. Good Requirements vs. Rework – Part 3
3. Should Requirement Quality be Measured?
4. Four Cases for Early Requirements Verification
5. Should Requirements be Prioritized?