Managing Product Requirements in the Product Development Process

Every company discusses the need to speed up execution of projects. However, often as an organization, they miss the opportunity to control the details that eventually control the speed of execution of the project. One such critical detail is the "Product Requirements Document" and its management through the span of the project. In one instance while managing a project with a critical timeline, the design had been released when a Product manager came to me asking to change a critical dimension on one of the products by 4 inches. After understanding the reasons for the request, and understanding that it wasnt critical to the customer, I said "No" to the request. A change of 4 inches to a dimension may have seemed small to the Product Manager. The implications would have been for Engineering to change 45 drawings and for Manufacturing and Quality to redo all their Execution plans. All these changes would inevitably have led to a delay of the project and additional cost.

I have developed a few steps that I have used to develop controls around the Product Requirements document. I am sharing these steps with you.

Step 1: The Product Marketing person creates the PRD. Assure alignment between Product Marketing and the Product Development (or Engineering) team.  These are requirements are “critical to the customer” as well “critical to the company”.  

Step 2: Product Development or Engineering team converts these requirements into a spreadsheet which becomes easy to read and track. This spreadsheet would have the SKUs in the columns and the Product attributes in the rows.

Step 3: Build this spreadsheet further into a document that I will call “Engineering Requirements Document” (ERD). The purpose of the ERD is to use the PRD spreadsheet and add the requirements from the Engineering team.  As an example, the PRD document would specify Aluminum as a material for one of the SKUs. The ERD document further describes it as Aluminum with a defined alloy grade.  

Step 4: Incorporate configuration or revision control on the document. My recommendation is that this ERD is owned by the designing Engineer. If any changes are required, the initiating party must discuss the changes with the Engineer and understand the impact of changes to any requirement before the change is made to the requirement in the ERD.

·        Step 5: Avoid making changes to the PRD once it is aligned upon early in the project phase. Any change to a requirement  can result in added time to execution and very often does.  As a general rule, one should expect that the later the change to a PRD, the greater is the impact to the project from Schedule and/or Cost and/or Quality of the product launch.

It is my belief that these steps customized to the needs of the Product Development team, can be a significant factor in eliminating wasted effort thus speeding up the Product Development of the product.

You are also welcome to visit my website to see the rest of my collection of articles that I am writing on Product Development... www.chinmoybanerjee.com