GPEP process overview:

GPEP is basically a staged (or phased) and controlled process, but it by no means is bereft of creativity! It demands that deliverables exist between stages. These deliverables are well defined going into a stage (phase) and are consequently objectively met and verified during the stage. Then new deliverables are defined, reviewed and approved before passing to the next stage.

At the beginning of each stage (Phase) formulate the pertinent questions that need to be answered by the end of the phase so that a Go/No-Go decision (gate) can be made for moving on, or not, to the next phase.

Notice the dollar amounts at the output of each phase in Figure 1. These figures-of-merit indicate a relative sunk-cost for all the preceding phases. They symbolize how much investment can be 'thrown down the drain' should the product development process be cancelled after any phase. This is why it's important to make a Go/No-Go assessment at the end of each early phase.

This supports the 'Fail Early - Fail Often' (FEFO) philosophy by prototyping early and often: the earlier you can pull the plug on a bad idea, the better.

There is a minimum level of necessary formalism for processes and documentation, which however does not need to be bureaucratic: see Product Development Through the Eyes of Documentation. This formalism is necessary in order to repress the chaos that normally accompanies ad hoc engineering practices. The formalism comes in the form of:

• Appropriate documentation, plans, designs and processes.
• Critical, periodic reviews of all documentation.
• Attention to regulatory compliance and industry standards and policies
• Controls established for:
  • Product documentation.
  • Risks & Hazards analysis
  • Reviews
  • Changes of process & product.
  • Project - via project Anchors, see Product Development; Where do you Start?, R. Haney.
• Verification of components, subsystems and their integration: i.e. are they designed correctly and contain only non-hazardous substances?
• Validation of the complete product: i.e. is the correct product designed as described in the MRD?

Why do the process and product need to be well documented? First, products cannot be manufactured, tested or serviced without documentation. Second, the following motivations require the documentation of key information:

• Transportability - to train new employees and manufacturers.
• Increased product value - in case of selling or licensing the product.
• Knowledge - the capability for efficient testing, debugging & maintenance.
• Traceability - in case liability & safety or liability issues arise.
• Security confidence - loopholes and deficiencies can be efficiently discovered & filled.
• Intellectual Property value - for patents, trademarks, trade secrets & copyrights.