Tue e/5/07

Tue e/5/07

A product can be pulled or pushed through to production. In development, the product should be pulled by the need to conduct a project review at the end of the phase to make the go or no-go decision. The product should not be pushed through. Pushing the product in this case suggests that work is conducted with no end point in mind except to finish tasks. Ideally, the product is pulled through development toward information needed in project review, configuration management, and production requirements. Everyone in the process understands that development produces information for the key go or no-go decision. Everyone knows the product may not make it because of technological or business reasons.

The danger here is that configuration management will lock into a product prematurely, before its final development is completed, simply through the forces that press the product to market. The challenge to project management here is to keep the process open but controlled, and focused on data and information. Configuration management tends to press development to create product details, to move quickly to a production model, and to preserve the supply and contractor chain associated with each component.

The management function during development is more hands-on than in concept definition. This requires project management and team members to be attentive to the passage of uncontrolled time and excessive consumption of resources beyond the project development budget—playing with the product instead of developing it.

Development pulls new products through two essential phases: preliminary development and final development. Sometimes these phases are called alpha and beta testing, or prototype development and prototype testing in a user acceptance mode.

Prototype development

The role of prototype development is to move from functional requirements for the new product to a forward development stage in which documents (CAD drawings, schematics, pictures, models, and so on) are generated, and outputs are planned that support preliminary component and equipment design as well as other development work. The information generated in this activity will be used to demonstrate that the design is capable of meeting the quality, performance, reliability, and cost specifications of the project. This is where the product begins to take shape and look like its production and marketing design. This activity produces a hard copy or electronic design that can be manipulated and altered as project and design reviews suggest. Test data will be gathered on the physical or engineering prototype, and the design is signed off by a concept designer to assure that there is continuity between early performance requirements, early concept design, and the more mature development prototype.

The final output of prototype development is a workable design with tested performance. Also included are preliminary feasibility and risk assessments, and functional requirement verification test plans. Other miscellaneous design documents to support the review process are also generated in this activity. All plans will be tested in the later tasks of full development.

Development means transitioning the concept into a model of the final product, hard or soft. It is important to note here that new products will go through this development phase whether they are "hard" products, such as engineering, construction, or production products, or "soft" products, such as software or information systems, online reports or Web products, or marketing and sales promotion outputs. For a physical consumer or systems product, the outputs of development prototype include CAD models, schematics, part lists, wiring diagrams, and sketches. Output should be adequate so that the entire design can be reviewed and scrutinized by peers. Every part—subassembly and assembly—should be documented well enough to convey preliminary thoughts on design and assembly. Calculations and other supporting data should all be generated from these models and sketches.

The concept of peer review is often used here, opening the product to review by an inside, or sometimes outsourced group of peers. This process works against locked in views of the product that are created when a company cannot see any data that do not confirm product feasibility and performance. This is the paradigm issue again. During this phase, figures, drawings, and text will be dated and clearly labeled so that the peer review can easily find and understand drawings. All of this data is to be presented in a peer design review.

The Failure Mode and Effects Assessment (FMEA) identifies the hypothetical failure modes of the product design, and projects the internal and external effects of such a failure (severity and probability of occurrence). It is a risk assessment at the product and operational levels, and is useful even in "soft" products such as software. The FMEA is important because it allows the designer to rank the failure modes, and facilitates discussion around the worst failure modes of the product. This gives the developer a process to identify which failure modes need to be prevented or reduced in severity (or probability). This is not a full risk assessment, which looks at a wide range of failures, both technical and managerial, but a supplement to it for the product itself.

Risk assessment involves the dimensioning of risk under alternative operating conditions and performance requirements, with a risk matrix including risk definition, probability, severity, impact on cost, schedule, quality, and contingency (mitigation) plan. The designer will need to assess all possible risks in the design, and that includes risk associated with: part supply, design, product performance, operating conditions, schedule, and cost. Risk may also come from an obscure area, e.g., logistics or distribution of the product, or packaging, so care must be given by the designer to consider all possible areas of risk.


Product reliability is a big issue in development. Reliability is tested at the highest level to confirm technical specifications and produce performance information on customer, user, and functional requirements. This question here is:

"Can the product components and the product as a whole meet reliability targets of the design in a user setting?" For instance, for a digital avionics instrument, the test might be whether the low voltage system can run properly at the voltage stated in requirements. The test plan may indicate that the design targets will be verified using analysis, testing, or by similarity. Similarity means that the component, say a resistor or a building component, is the equivalent of another component that has already passed muster, in an earlier product development process, and that the test results have been documented. Risk assessment will uncover critical subassemblies or untested components that require special attention. Failures of critical parts are highlighted in project reports and documented to allow retesting and possible redesign. It is the role of the functional engineer or technical specialist to identify untested product components and to flag them for testing, but the configuration management system is the final confirmation that all components have been tested.

Build and production transition plan

It is not too early to plan for production of the product, so this preliminary activity identifies how the product will move from development into the production or manufacturing process. Often called the production transition plan, the build plan addresses build issues and generates a build strategy. Included in this process are designers and developers, assemblers, manufacturing engineers, production schedulers, and the project manager.

Safety and regulatory review

It is also not too early to look at the safety aspects of the product in terms of outside public regulations and industry safety standards. This is an early look at regulations that will control the product in various markets and requirements for approvals, paperwork, and so on, that will allow the product to be marketed.

Preliminary equipment and component review

Remember that development is aimed at informing project review at the end of this stage. The purpose is to help management make the decision to proceed to the next stage. This preliminary equipment design review assesses the design for technical competence and functional requirement adherence. This is where the product is tested against requirements using tracking software that links performance results to requirements, one by one. The output of this preliminary equipment design review (and potential design rework that is required) is a solid product design and set of specifications that serve as the basis for future feasibility, reliability, and the FMEA (Failure Mode Effects Analysis) assessment.

The review is actually a meeting that all relevant participants attend. Project management needs to make sure key technical and management people attend and contribute to this review. This is sometimes a challenge because technicians and new product developers in general tend to avoid such meetings, which they often believe do not directly involve their work. The design review package is sent out to all participants one week ahead of time so that everyone can adequately prepare for the design review meeting. All preliminary equipment design outputs will be approved by project leaders who conduct these downstream tests and assessments.

Top-level drawings, models, and schematics are produced here to identify the product prototype and its assemblies, subassemblies, and components. The documentation here needs to be relevant documentation that includes an official description and design. Supporting documents needed for testing include:

1. Product configuration and numbered parts list from configuration management system

2. Mechanical, electrical, and software design specifications

3. Final Bill of Material at subsystem level

4. Preliminary product design FMEA (Failure Mode Effects Analysis)

5. Updated product technical and performance specification.

6. Electronic access to all the design content, test results, and so on, for safe and secure storage

Configuration management

The configuration management function is extremely important in new product development because it is this function that documents design and component configurations as they are changed and finalized. It is important that there be continuity and compatibility between the software used to preserve design and the software used to document designs in configuration management. However, from a management standpoint, configuration management cannot be allowed to inhibit good design and development. Configuration management should be managed by a functional department associated with development and managed as part of the project.

Validate functional requirements

The validation of functional requirements ensures that the product design will perform to the product specifications. The product is taken through a build and test cycle to validate its performance. Design and development plans are updated as the design evolves during the alpha process. Functional requirements are finalized from concept definition and product specifications in this process. In the process of developing specifications, incomplete, ambiguous, and/or conflicting requirements are resolved with both the concept definition and potential customers. As requirements are defined, individual subsystems may be released into detailed design after design reviews. To achieve validation of functional requirements, requirements must be clearly defined with no ambiguity and eventually documented in a configuration management system.

Design validation (how the product will be designed to function properly) ensures that the product will meet all of the requirements imposed by the product specifications. This includes the product system as a whole, hardware, software, electrical and other components, and failure modes. Validation is typically performed to an internally generated requirements document to ensure that the product meets the standards required for thoroughly testing the production product. Design validation data is documented for use in project review and go or no-go decision making.

To make sure there is a continuing linkage back to customer need, functional design validation includes "touching" customers as well. Through focus groups, simulations, and meetings, customers validate that the product functional requirements and specifications will meet their needs. This avoids the risk of suboptimizing around a limited product viewpoint, and experiencing failure in the test cycle.

Confirmation of Final Product Design

Development of the final product design requires a final update and documentation for market execution. This task is critical to product success because it confirms the final design to be produced and marketed. The task documents all results for testing as well as any changes in product configuration, design, and parts lists from earlier development. Traceability is critical at this point; a final design check is compared to product specifications and customer needs to ensure that the product design can be traced from specifications directly back to customer needs.

Final product requirements, specifications and drawings used to produce the prototype, and production products are evaluated through a critical, final design review. Review includes detailed design outputs, written or electronically formatted drawings, acceptance test requirements, design documents, product models, and other analysis documents. Updating these outputs enables the product to be manufactured, and its performance validated against requirements once after beta testing is completed. Three steps are involved

1. Final Product Models Prepared—Final versions of product models are prepared to facilitate market execution.

2. Final Analysis Documents Prepared—These updates may include interface requirements, applicable design standards, trade studies, layout drawings, product test procedures, and configuration management documents.

3. Final Bill of Materials—The final bill of materials identifies all of the components of the product and gives them preliminary part numbers for eventual documentation into a configuration management file.

Confirm Functional Requirements

This task involves confirming product specifications and functional requirements so that they can be validated with customer needs. This task produces a validated design requirement that conforms to the functional requirement template. Table 5-2 shows what a functional requirement might look like at a high level.

Confirmation of Product Specifications

The confirmation of product specifications involves a review and assessment of how current specifications may have changed as a result of design and prototype testing as well as other outcomes of the product development process. Particular attention must be given not only to documented changes—changes that were fully documented in the product configuration and reflected in the bill of material—but also de facto changes that may not have been documented. In other words, this is the point at which any changes are documented for field testing.

A special project management challenge here is to assure that no undocumented changes in product design occurred in contractor activity. Intellectual property issues can surface here because product design has potential value to contractors.

The risk involved is that outdated field test units will be built and go to test. This can happen if some specification issues remain open and are not resolved in this confirmation process. This task locks in the product configuration for field testing.

TABLE 5-2 Functional Requirement Template

New product Functional performance function requirement Comments

Produces Digital GPS Receives GPS data Data on Mobile Phone

Shows digital data on various phone screens

GPS data change during movement

TABLE 5-3 Customer Need/Functional Requirement Template

Customer need

Corresponding functional requirement, e.g., fitness for use


Ease of use

Digital screen easy to clean and maintain

Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook

Post a comment