The product concept should now have been developed in fairly good detail. Change and risk management procedures (with contingency plans) for the product should now be implemented to control radical changes in the project 'anchors' that could throw the project off track (see section II in Product Development - Where Do You Start?).

The product is first designed in detail at the highest level (the system architecture) first and then later partitioned into manageable subsystems and components to better determine the detailed design requirements. The design documents detail all design criteria, test issues, risks and hazards, etc. They will be used to generate the subsystem and component design requirements and will be used for system verification (to guarantee that the system is designed correctly) in the next phase. At this point it must be absolutely determined if the product can be designed and produced within the proposed time frame and funding. This is a reality check again.

Remember that the design process must maintain close adjacency to the market, users and the business plan. Note that high level creativity and decisions are not eliminated, but are maintained at the architectural level, where appropriate, in order to eliminate ad hoc design decisions at the lower levels, especially at the implementation level.

The process must maintain close proximity to the market, customer and business plan during this phase. Note that design creativity and decisions are not eliminated, but are kept at the design stages in order to eliminate ad hoc design decisions at the implementation stages.

The subsystems and components will be subsequently verified to the relevant subsystem PRS in the next phase to demonstrate that the 'product was designed correctly'. This is a major reality check.

At the end of this phase all design creativity (the PRS) is frozen. Only through the change control process can design changes be made after this time. However, low-level implementation creativity is free to occur as long as none of the design requirements defined in this phase are violated. Also test development and implementation creativity takes place at this stage.

Concepts must be constantly compared to reality during this process, and the business case subsequently refined to match. The project is then detailed and a complete Product Requirements Specification (PRS) is generated.

Any processes required during the project (for example: risk management or regulatory agency compliance) are also detailed and 'costed'. Once again the business case is reviewed. Most project assumptions must be replaced with factual information at this stage and a process to manage the remaining unknowns established. The PRS shall contain no wishes or wants; i.e. every requirement in the PRS must be a funded commitment.