User:Sarda sarda/Critical Parameter Management

Definition: Critical Parameter Management (CPM)
Critical Parameter Management(CPM) is an important part of a rigorous, systems engineering-driven product development process. CPM is an engineering methodology for managing, analyzing, and reporting system performance throughout each stage gate or phase of the process. It includes processes for mathematically linking system parameters to track sensitivity, variational analysis, and optimization of critical performance drivers throughout an entire product, process, or system. CPM is a strategic approach for improving product development through the unification of software, hardware, and total systems engineering activities. CPM guides the development team to identify which requirements are the most critical and therefore need the most engineering attention and analysis resources. CPM also helps identify which requirements are less critical and therefore do not need as much engineering attention. By using CPM during product development, the development team will be able to answer the following questions before the product is released:


 * Will the product (or process) performance meet customer expectations?
 * What features control the product performance?
 * Where can team members go to find out about product performance?
 * What are the most influential drivers affecting the product performance?
 * How does the development team transfer this product performance to other platforms?
 * What are the customer expectations (also called Market Requirements of Voices Of the Customer(VOC))? What are the internal business expectation?
 * Which of the customer Expectations are most important? Why?
 * Will the product performance meet the customer expectations?
 * What features/characteristics control the product performance?
 * Where can team members and management go to find out about product performance?
 * How does MY feature affect the product performance?
 * Who else do I affect? Negatively or Positively? What are my system interactions?
 * What are the risks involved? What are the test protocols?
 * What is the total system trace through Voices, Requirements, Specifications (parameters), and Tests?



Critical Parameter Management (CPM) starts with and maintains a continuous focus on the Customer Needs and Expectations to ensure a successful development program.

CPM captures the product performance & functional knowledge during the product development process

CPM provides traceability of the component, material and process specifications to the system level requirements

CPM identifies and manages the interactions by maintaining a system level view point during design

CPM sets the framework for predictive engineering via the use of concurrent engineering practices and the DFSS proces

Critical Parameter Management in the product development process
CPM as an active process begins when the program begins and ends when the product or process is produced. Once the product or process is released the CPM knowledge is used for reference and knowledge re use in later programs. The sooner you begin to use CPM the sooner you will realize its savings in reducing late-design firefighting due to poor collaboration. CPM will expose risks in design and manufacturing capability, identify cost savings opportunities due to over-design, and eliminate inefficiencies in program reporting.

The following image is a schematic representation of how CPM views the world of product development Note the center circle which represent product/process requirements for a program. These requirements do not exist in a vacuum; they are interconnected to many process steps, program deliverables, and other items that are tracked and managed throughout product development. CPM helps to feed the requirements and thereby all the other items and deliverables for the pgogram through the early identification of critical parameters (drivers) of the system and subsequent statistical analysis of exactly HOW those critical parameters effect requirements and program metrics.

This next image shows how CPM complements the traditional PDM (BOM) structure of a program. CPM looks at a program through a functional and performance lens which gives a different view into system behavior from the PDM view. Both views are needed for successful product development. The product functional paths determine the critical parameter architecture. The critical parameter view crosses ALL boundaries of the physical architecture (BOM) The overlapping area of the two ovals represents the intersection of systems requirements management and critical parameter management

Analytical Feedback
Statistical modeling & optimization of the performance – cost trade space Real-time System-level sensitivity analysis Creates and analysis thread between system, subsystem and component levels

CPM provides a guided approach to statistically analyzing critical parameters and their effects and sensitivity on higher level requirements. Transfer functions relate the driving specifications to their parent requirement or requirements. The result is a predicted behavior of a requirement given its driving parameters (children) to help product development teams identify key drivers early in the development process. This helps them focus limited design resources on the most critical parameters of a system and reduce over design of parameters that have a lower sensitivity on the design performance.

Continuous Reporting and Status
CPM design margins are statistically tracked over product lifecycle Automated, real-time CPM data gathering / report generation Reconciliation of requirement allocation and engineering design capability

Total Systems Team Collaboration
Shares technical analysis and knowledge Links ownership to parameters Mathematically connects Program teams and parameters to understand requirement flow-down Captures and leverages invested intellectual capital for future business reuse

Engineering whitepapers, memos, models, and analyses attach directly to parameters Connect team members to each analysis, requirement, performance measure, and design trade The CPM "tree of knowledge" becomes a real-time “Global Positioning System” for program performance and responsibility

Re-use of technical knowledge, analysis tools, and intellectual capital

CPM utilizes a mathematically interconnected hierarchy of critical parameters in the evaluation of the system performance - cost trade space

Benefits to Design Teams
Methodical, Consistent Way to Define Product Performance

Tracks Performance Predictions and Test Data via Scorecards

Backs Up & Proves Design Performance at Review Meetings

Identifies Key Critical Parameters & Interactions

Evaluate Impacts of Low Cp/Cpk Test Results

Transfer to Manufacturing to Reduce Post Launch Involvement

Effectively Collecting & Prioritizing Customer Needs Collaboratively Defining the Corresponding Product Requirements Identifying the Top Level Risks and Opportunities Decomposing the “Critical Few” Parameters (CPM & DFMEA) Mitigating the Risks of the “Critical Few” Parameters Maintain Traceability of the Critical Parameter Relationships & Info Implement & Deploy Tools to Support this Endeavour

Benefits to Program Management
Identification of the Top Product Specifications via CPM Allows for Proper Allocation of Resources & Scheduling

CPM Determines where to Focus Resources to Develop Transfer Functions, the Biggest Technical Challenge in DFSS

CPM Assists in the Development of an “Analysis Roadmap”

“Implied” Knowledge Tree Adds Value even without Transfer Functions

Trace & Evaluate Impacts & Sources of Low Cp/Cpk Test Results

CPM Reduces late-design firefighting due to poor collaboration. It exposes risks in design and manufacturing capability and helps management identify cost savings opportunities due to system over-design. CPM also eliminates inefficiencies in program reporting by providing up to the minute detailed reports on all the interactions between critical parameters and system requirements.

Identifying Critical Parameters
Up Front design team “Discovery Sessions” lead to identifying risks and discovering opportunities early in the development cycle. Facilitation meetings maintain a system level perspective during development with constant focus on customer and business needs

Cross Functional Team Members (Engineering, Test, Quality, Mfg, SMEs)

Enables Cross Function Perspectives that Discover Interactions & Constraints

Provides a Forum for “Out of the Box” Thinking That Leads to New Idea Generation

Two Different Ways To Identify System Requirements
Requirements management flow down: This is commonly applied to “optimistic” requirements

How do we achieve the required weight? How can we assure System Availability?

Design Failure Modes & Effects Analysis (DFMEA): This is commonly applied to “pessimistic” requirements

How do we make this unit water proof? How can Login Security be breached? Both ways are important and both lead to different types of requirements. The power of the CPM approach is to blend requirements from both identification methods together into a single "shall" document. The end result is a traceable "tree" showing all the possible many-to-many relationships between critical parameters and the requirements they effect.

The CPM Process Flow
The image below is the traditional "V diagram" view of the Critical Parameter Management Process. Start in the upper left and follow down to the bottom. Then move to the right and follow back to the top upper right to complete the process.