Requirements in Product Development

Product development is like racing, and once you get out of the starting blocks, you can set your product development project up for success or failure. As Simon Ramo (that's the R in TRW Inc.) said, "the really big mistakes in a project are made on day one".

You start every product development race with a plan. To develop a plan, you need to understand what problem you want to solve. The beginning of any development race is defining who the customer is, what they need and what they are willing to pay for, and then deciding what the product needs to do to fulfill their needs. In other words, the longer you fiddle around in the starting blocks or come out of the starting blocks with the wrong requirements, the more difficult it will be to win the race against the competition, as the famous management guru Peter Drucker put it: "Nothing is as useless as doing efficiently what should not be done at all".

The greatest value of requirements does not lie in requirements management, but in their integration into product development.

If you don't get out of the starting blocks properly and quickly enough, your project will lose the race.

Here are some worrying statistics on product development...

• According to the Standish Group 15% of projects fail completely, 51% are called into question"
• only 67% of the originally defined features appear in the finished product, of which 45% are NEVER used" Standish
• At a Harvard Business School cyberposium, it was claimed that "half of the resources spent on product development are spent on products that fail"
• IEEE Magazine pointed out that we're getting pretty good at component engineering, but miserable at systems "90% of electronics components work as designed, 50% of them fail when integrated into their systems".

...according to analysts and organizations like Texas Instruments, a common denominator in many of these runaway projects and integration failures is the failure to understand and keep pace with customer needs/requirements...

Why requirements are so important.

• This is what the customer will buy. If you don't define the requirements properly, it means you're not actively planning to meet customer needs, which means you'll be "lucky" if you produce a product that drives customer demand.
• That way you know when you've done enough work/development - otherwise you tend to do too much or too little depending on how much time you've allocated to the project. You need something you can use to verify yourself.
• This is how you communicate between the many disciplines involved in your product development (different disciplines use the same words to describe different things). Requirements are the only common language that ensures a shared understanding that ultimately matters to everyone - without them, you'll argue and have the same meetings over and over again.
• So you know when you have a quality product - after all, the definition of quality according to quality gurus Crosby and Juran is "conformity to requirements"
• And so you know what can be reused from last time - which existing components fulfill this set of requirements.

Advantages of Requirments Management