Deliverables from the Product design review:

The key deliverable of the product design review is the verification and agreement by all stakeholders that the product design specification (PDS) is as complete as feasible and conforms to the needs of all stakeholders.

At this point it's important to briefly mention four aspects of product development reality that are not exemplified by the discussion to this point. These can complicate the methodology just outlined but they can be managed by extending the methodology. Resolving the following issues is not the subject of this article, but they are included to briefly outline common complications and to impress why the product design review is so important.

1. What do you do about designs and reviews of complex systems, which contain subsystems or co-systems and include multi-departmental and inter-company responsibilities?
   
   It's absolutely critical that appropriately experienced stakeholders representing each Sub-system, co-system, multi-departmental or inter-company group with a stake in the product participate to some extent in the top-level design generation but, certainly, in the product design review. The PDS can be 'layered' or expanded to include the complexity. As Greer and Black's research confirms⁹, the available product knowledge for complex systems needs to be embedded in the project structure at a level of mutual understanding.



2. What happens if an implementation meets the design, but is found to have problems or be inadequate when tested?
   
   This will happen more often than not if the level of expertise of the stakeholders is below par and the communications channels, via the boundary objects, are inadequate (sparse, incomplete, jargon-prone to a specific group, etc.) Even if they are adequate, sometimes pertinent information is just not available or doesn't even yet exist. Therefore the process of Fail Early and Fail Often¹⁰ (FEFO), which is an early, post PDS emphasis on physical product evaluation (i.e., design, technical, functionality, performance, market acceptance, costs, etc.) will minimize the 're-spins' within a product development project. Also, haste in recognizing, analyzing, reporting and managing changes is paramount during necessary re-spins.
   
   
3. What do you do when marketing (or another group) comes back at a later stage in the development process and wants design changes because of valid changes in the market, laws, regulatory rules or company direction?
   
   This sometimes happens (see item 2 above). However, should such demands necessitate a change to a product already in development, haste in recognizing, analyzing, reporting and managing the changes through a controlled process (e.g., ECR, ECO, etc.) is the most expedient way to handle things.
   
   
4. Post-production improvements will occur through feed-back from sales staff, resellers, and the users of a product... or bugs are uncovered.
   
   Product improvements are quite common, but they are usually relegated to a new model or product introduction.
   Bugs are occasionally uncovered within the market place; most should have been caught with the FEFO process or good product and pre-market-testing. Bugs require that the product needs correcting or updating - but, depending on the level of changes, this activity is best handled through a 'planned' product upgrade activity under warranty authorization.

---

⁹ Greer and Black, op. cit., p. 1
¹⁰ http://www.techmankanata.com/ar-42-pg-1/The-Business-and-Hidden-Values-of.htm