Critical Parameter (Performance) Management (CPM) - The performance of a system is predicted and managed by various processes including Systems Engineering  (more specifically, through Technical Performance Management (TPM)) and Critical Parameter Management (CPM). Typically, Systems Engineering manages the higher-level requirements and parameters but does not tier down to the lowest level parameters that affect a system. The process of CPM best accomplishes this tiering, or flow down, of a system to its lowest parameters. Of course, the ultimate benefit of CPM is the ability to flow back up the path from low-level parameters to higher-level requirements.

CPM provides a series of techniques to enable engineers to track the interaction between requirements and the parameters that drive those requirements. Most companies are engaged in some form of CPM whether they use the phrase or not.  As  Figure 2 shows, CPM is a process that guides users through the steps of defining a system from high level “wants” and “shalls” to low-level critical specifications. In this way, CPM acts as an enabling backbone to the DFSS process by building the connections between Voice of the Customer, System Requirements, Sub Requirements, Parameters, and driving specifications. CPM becomes the tree to which all of the DFSS branches attach. The transfer functions bring the branches to life so the DFSS team can see immediate impacts of design changes.

The higher-level parts of this “tree” are often defined through Systems Engineering.  CPM kicks in as the parameters are defined at lower and lower levels. Once this tree is complete, it defines a functional performance path through a system and helps identify which specifications and parameters are critical. By adding transfer functions to the tree, as shown in Figure 3 and Figure 4, the engineer creates a dynamic relationship between requirements and parameters that can be used to travel from the bottom of the tree back to the top. The result is a dynamic relationship between requirements and parameters. This is an extremely powerful process that provides feedback on the sensitivity of each critical parameter to the overall system. Table 3 gives some examples of the types of transfer functions used in CPM.

The relationship works two ways. By traveling down the tree, from the highest-level requirements (maybe even Voice Of the Customer) to the lowest level critical parameters, knowledge of the various system interactions can be traced. When the tree is studied from bottom up, the variations and sensitivities of critical parameters will result in specific, quantitative effects on the higher-level requirements. The CPM tree is “alive” with relationships between various parameters and requirements and helps build true knowledge of the performance and functional behavior of a system.

Balancing Cost and Performance

Defining the Process - As an engineer makes decisions regarding the performance of a system, the appropriate elements in the costed structure are flagged to indicate they need attention.  Someone (the engineer themselves, a cost professional, or other designated person) must update the cost on the affected element(s) or define a cost estimating relationship (CER) that will allow automatic updates to cost based on certain performance attributes. This change to cost will flow back to the CPM structure and update the parameter so the engineer can see the cost impact of their performance decision.

The process is bi-directional. When an element or cost in the costed structure changes (maybe a cost reduction initiative is realized and applied to the costed structure) that information flags the appropriate parameters and requirements in the CPM structure. The engineer will see the information and where/how it affects performance targets and estimates.  All of this is done either real time (if there are CER’s to calculate cost-performance trades) or near real time (a user must physically change a parameter or calculate a new estimate.)  Most companies do not yet have CER’s for all performance and cost interactions. This process of balancing cost and performance during design will help drive the need for these CER’s. Even the near real time method significantly shortens the trade study cycle time.

Trade studies will take less time as the cost professional (or whoever is the user of the costed structure tree for the system) will now see immediately which elements are being altered by engineering throughout the design process. This allows them to work new cost estimates on effected elements with important input from the CPM tree. When the element flags itself as out of date, the cost user will see what caused the condition: a specification change to a critical parameter, tolerance information, functional alteration of the system or its behavior, or whatever caused the change. The cost user can now re-estimate elements while having vital input for the reason for the change. They make the new estimate and it flows back to the CPM tree and the engineer user sees the impact of their design decisions on cost.

Interact with the new Design Trade Space - This new process lets users manipulate the design trade space (shown in Figure 5) rapidly and with better fidelity. By providing rapid feedback between the cost and performance structures we make more time for trade studies and improve the overall fidelity of each estimate and prediction. A brief walkthrough of this interaction follows.

First, the relationship between performance parameters and cost (element) parameters is defined through team interactions, historical data, subject matter expert (SME) input, and best practices/tribal knowledge. This is where the connections are made that will later be followed when information changes. It is a one-time event. Figure 6 shows this in progress.

Once these connections are established, there remains  a dynamic, bi-directional relationship between the various elements and parameters (Figure 7.) The two groups, design engineering and professional cost estimating/management, can now continue their once independent work. The difference now is that as each team enters or changes information, the other team will see the impact in their design space.

Figure 8 shows the heart of the process underway. Performance information is created/updated and then, through the dynamic link created at the beginning of the process, flowed to the cost elements for notification of the cost professional. If there are CER’s to define the relationship then automatic cost estimate updates will trigger. More likely, there is no complete set of CER’s today so the cost element flags the change and “asks” to be updated. The update (automatic with CER or manual by cost professional) is completed and flowed (again through the original dynamic link) back to the originating performance parameter. The engineer will see the cost impact of their design choice. Figure 9 shows information flowing back from the cost elements to the performance parameters.

At any point during the process, either side (performance or cost) can query for the change history of important performance and cost decision points. This allows users to explore the “why” behind a change. Figure 10 shows a cost professional’s view of an element. The user asked for the most recent change to an element and is alerted to a cost driver change from the performance tree: in this case, a change to the cutting rate specification requirements for a lawn mower system.

Conclusion - Followers of this cost-performance balancing process will notice a reduction in the time to complete cost-performance-configuration changes. The automated interconnection between critical performance parameters and cost/structure elements means that users will see the information they need right away, and not need to wait for formal reviews or gates. Cost estimating results will improve in fidelity as key cost drivers are flowed through the system faster and more accurately. The cost professional will see the explicit performance characteristics that are being defined by engineering as they happen. Costing and cost management will gain respect as they will have more timely and accurate feedback to engineering. Development teams will not be able to avoid the costing process as they will have that near real time feedback right alongside their performance characteristics for each critical parameter of the system

PRODUCT DEVELOPMENT SYSTEMS & SOLUTIONS INC. (PDSS) is a professional services firm dedicated to assisting companies that design and manufacture complex products. We help our clients accelerate their organic growth and achieve sustainable competitive advantage through functional excellence in product development and product line management.

We are experts in Critical Parameter Management and Design for Six Sigma. See founder Clyde “Skip” Creveling’s book, “Design for Six Sigma in Technology and Product Development” (C.M. Creveling et al, Prentice-Hall PTR), Part III, entitled Introduction to the Use of Critical Parameter Management in DFSS. We also develop risk management scorecards based on critical parametrics for design reviews and risk management reviews."

Use them.

"Customers estimate that 80-95% of their problems are 2D. Because Enventive is 2D, and 2D tolerance models are at least an order of magnitude easier to build and understand, users can build Enventive models much faster and easier. A principal engineer at a major appliance manufacturer, comparing Enventive with competitors stated, “With Enventive, engineers can achieve 80% of the tasks with 20% of the effort and time.”

Enventive's models are comprehensive, working representations of a part, not just sketches of geometric objects. With its cohesive geometric modeling, assemblies, equation solving, backsolving, and optimization, users describe Enventive as "the best-ever conceptual design tool." A familiar Windows interface, seamlessly integrated Excel, and availability of ANSI standard GD&T callouts make Enventive exceptionally easy to learn and use.

The key to effective optimization is the ability to rapidly explore alternatives—a task at which Enventive excels.

Changing dimension schemes is fast and easy and doesn’t require model rework. Parameter values can be changed directly from the tolerance analysis report, and re-analysis is automatic. Both parameter and tolerance optimization can be driven directly from the tolerance analysis report. Enventive’s ability to rapidly explore alternatives is hundreds of times faster than that of competitive tools.

Enventive is the only mechanical engineering tool that provides optimization of both parameters and tolerances directly from a tolerance analysis report. Using the Excel solver add-in, users may simultaneously optimize up to 200 parameters with up to 500 constraints on the values of those parameters.

For example, you could optimize the parameters of a spring (wire diameter, spring diameter, number of turns, and free length) to produce a specific force-deflection relationship, with minimal variation, simultaneously with a constraint that specifies the shear stress must be less than the endurance limit."

Every Requirement in a system needs to be part of the definition of the entire system. If you use one tool for costing and another for FMEA, how easy will it be to see the effects of various mitigation strategies on system cost? It will be extraordinarily difficult to get any sort of visibility into the various pieces that make up the definition of a requirement and how it fits within the entire system. Trying to integrate various tools from each vendor can be a lesson in futility, not to mention cost prohibitive.

Ross Perot ran for President in 1992. His running mate, Vice Admiral James Stockdale, made history when during a debate he began with the line, and I paraphrase,  "Who am I and why am I here?"  That line got him a lot of laughter and ridicule but it is just the sort of line that every component in your system, every requirement, needs to ask.  When you interrogate a requirement it should be able to tell you its name, rank, and serial number. It also needs to tell much, much more. How well is it meeting its target? Is it over budget? Behind schedule? What potentially dangerous risks are associated with it? Are there any initiatives currently underway by the development team to address hot spots? How exactly did this requirement come into existence? Can it trace back directly to a Voice Of the Customer? How about its critical parameters? Is there something driving this requirement that is particularly sensitive?

A requirement is so much more than a textual description of a goal with a textual description of a test attached to it. Only by recognizing this and creating a total, holistic approach to product development and requirements management will we take the radical leap into the next generation of product development.