In the product development world, KPM evolved for parameters that present high risk because they are either 1) New to everyone, 2) Unique to the enterprise and/or are very 3) Difficult to stabilize, adjust or otherwise control when unwanted sources of variation assail the product and/or production process. Key Parameters can be developed pro-actively during the technology and product development processes, or they can be developed reactively in the post-launch production environment. Both applications of Key Parameter development are intended to prevent problems. The easier and most cost-effective approach is to develop Key Parameters from the beginning of technology and product development and then transfer a fully documented Key Parameter database for use in post-launch processes.

Parameters Worth Watching

The US Army's Armament Research, Development and Engineering Center (ARDEC) have been working diligently to structure a new Technology & Product Development Process known as Vector. The major tasks and enabling best practices of Key Parameter development have been carefully integrated into Vector's 4 Phases and Gates for Technology Development and 5 Phases and Gates for Product Development. In this way a fully developed Key Parameter database is ready at the technology transfer phase and then again at product launch, thereby avoiding down-stream performance problems, cost over-runs and slips in development cycle-time. Production and supply chain teams are nearly euphoric upon receiving the Key Parameter database. When it comes to knowing what parameters are worth watching with SPC charts, capability studies and the trust-inducing execution of Gage R&R studies, the Key Parameter database is as "eyesight to the blind". All of these evaluations are costly and should be limited to only those parameters that really need them - the trouble-makers known as "Key".

What if there was no front-end Key Parameter development?

On the other hand, in many enterprises, Key Parameters were not pro-actively developed and documented during technology and product development. Some product designs have been around so long that the people who knew why the specifications were set are either retired on a golf course somewhere in Florida or gone to their eternal rest.

Often, the answer to what parameter relationships control a given function or roll-up of functions from production to parts to subassemblies to subsystems to the system level - is "We don't know". Without data, it's impossible to know which parameters are "Key". The default becomes "all parameter" management, resulting in unnecessary, time-consuming and costly work.

Starting with an Old Gum Wrapper and Lint

The first step trying to answer these questions often begins with hope-laden searches through engineering change documents to trace the history of the design's current specifications - if such a history of revision even exists. This happened to me years ago when I was a production support engineer at Eastman Kodak. To comply with new European flammability requirements, I had to change the material a part was made from. I searched for the file to read the part revision history and hopefully, the original engineering design summary report. Such reports would explain why the materials, dimensions, surface finishes and bulk material properties were specified and what would likely happen if they were changed. When I opened the file I found two things: an old gum wrapper and lint. A true story! Needless to say, many, many hours were spent re-constructing the necessary information.

Discovering Key Parameter Relationships in the Production Environment

So, what if you are starting with the equivalent of my gum wrapper and lint? Today, there is a 12-step Key Parameter development process designed for cross-functional production support teams to re-engineer or develop a Key Parameter data base. This is a "better late than never" reactive approach to understanding and applying Key Parameter relationships in the post-launch environment. It does not mean that normal production support tasks are suspended and the support team starts working as a product development team - well, maybe a little.

Select a Key Parameter project and work on it as time allows and/or as motivated by cost and quality issues. Partition the products and processes to conduct manageable Key Parameter development projects until you have the information needed.

If the standard is set for what a useful Key Parameter database looks like - they will improve the ability to prevent problems and will eventually eliminate the need for them to be developed in production. The goal is for production to get out of the Key Parameter development business and become proficient at using them during production and out to product discontinuance.