When my career began in 1980 with my entrance into Penn State University to study mechanical engineering and design, my goal was to practice in the arena of new product development. Since then, I have paid attention to anything that helped further my goal of being competent to conduct product development. If you only used what they taught you in the university (in my case, Penn State and Rochester Institute of Technology) you could make a go of it, but there is only so much you can do solely with a bachelor's or even master's degree in engineering science. After I started working at Kodak, I needed to look beyond my academic education. The mistakes I made in my early years at Kodak motivated me to search for books, articles, courses and, most importantly, people, to show me unique methods and tools to help prevent me from screwing up so much! It's hard to not make mistakes during product development!

The Prevalence of "Build-Test-Fix" Mentality

Seasoned colleagues in my early career at Kodak helped in many ways. They showed me how to bridge the gap between academic approaches to problem solving to the "real world" events that have to be done to ideate, model, design, build and test a design that is headed for production and its supply chain. I quickly noticed big differences in how each one did their version of design and engineering. They each had their own ways, means and logic, but they all seemed to have a common pattern of "Build-Test-Fix" as the product slowly congealed out of everyone's distinct efforts. This was accepted by everyone, including upper management, as the way things get done. It was a messy, largely unpredictable, ad hoc process. Every project was different, as was every product we developed and launched. It all depended on the unique mix of people who ran the project and were responsible for the detailed engineering, design, drafting, prototyping, testing and follow through on all the things that did not go right along the way. It was difficult and frustrating to work this way, but in spite of all the variability and under-defined processes that were cooked up, in the end it worked, and products were launched. Very few of these products ever met their goals in terms of the business case or the Cost, Schedule and Performance goals established at the beginning of the product development process. It was rare for anyone to be held accountable for their contribution to a short-fall; there were few or no consequences at that time. We worked this way for many years. Harumpf.

My Introduction to Critical Parameter Management

One day in the 1990 timeframe, my colleagues and I were discussing how frustrated we were about how product development was being conducted. We were concerned about our leaders' behavior, as well as our own lack-luster performance as individual contributors on development projects. We inherently knew we could significantly improve what we were doing. We were anything but arrogant; we wanted to change but really had no idea what to do. One of us stumbled across a white paper written by the late Dr. Don Clausing titled, "The 10 Cash Drains". It was a polemic on why companies fail to meet their goals in new product development. It hit us, management and engineers alike, right between the eyes! Clausing had articulated the very things that were driving us crazy. Soon after, we invited Dr. Clausing to Kodak to have a word with us all about radically improving how we did product development. He spoke of many things, but he strongly advised us to get really good at Critical Parameter Management. Since none of us had any idea what Critical Parameter Management was, we were about to get one hell of an education!

Three Wise Men(tors)

I spent years listening to Dr. Clausing and his consulting buddies, Dr. Stewart Pugh and Dr.Genichi Taguchi, guide us to learn and apply the unique process, methods and tools of Critical Parameter Management. Clausing focused on building clear, ranked and prioritized requirements using Voice of the Customer methods and the disciplined application of the stratified layers of Houses of Quality defined by the method known as QFD - Quality Function Deployment. Stewart Pugh taught us the now famous Pugh Concept Evaluation and Selection Process. This just blew the lid off our ability to conduct rapid, reasonable and efficient innovation. Taguchi quietly walked into our development labs like the eastern genius he truly was and proceeded to rebuild our ad hoc mental processes. He taught us to think through the physics of our functions and detailed design elements with the objective of making the lowest to highest levels of our assemblies insensitive to unwanted sources of variation that arose from our production processes, packaging, shipping, storage and ultimately the customer use environments. All of this learning was wrapped up in a tidy, disciplined process called Critical Parameter Management, and it was very effective!

The CPD&M Quick Guides

After 23 years of applying and maturing everything these giants of product development taught me, I hope to honor them by sharing what I've learned in my CPD&M "Quick Guides" in this newsletter. These Quick Guides are a distillation of the process to develop and manage critical parameters from the many parameters that make up and control a product and its production processes. The Quick Guides will also introduce a set of metrics to identify critical parameters during development. I call these metrics The BIG 7! At the end of the series, you will have all 24 Quick Guides for the incredibly effective methods of CPD&M!

Oh, and one more thing.... CPD&M is where Design for Six Sigma (DFSS) is heading as the Six Sigma brand slowly fades!