As you know, PDSS' expertise is product development. We classify product development processes in four broad categories. They are:
- Portfolio Development Processes
- Research Processes
- Technology Development Processes
- Product, Service/Support and Production/Supply Chain Development Processes
These processes enable an enterprise to develop everything necessary to deliver products and services. Over the 31 years I have been a "development engineer" I have noticed common patterns of incomplete development processes across enterprises as well as incomplete, anemic behaviors inside of the development processes listed above. This article illustrates some of the issues I've observed in Technology Development processes.
Time-Bombs as Outputs of the Technology Development Process
Technology Development is the arena of innovation as research is the arena of invention. New science is transferred to Technology Development to be converted into useful platforms or modular designs that, in turn, will be transferred to Product Development for final commercialization. Technology functions are often lacking rigorous evaluation across their controlling parameters under both nominal and stressful application conditions and environments. The outcome is immature, over-sensitive technologies incorporated into a product development project. These under-developed technologies are ticking time bombs that go off the moment they are integrated. I know intimately how this happens because early in my career, I used to make these time bombs and I was not very popular when they went off in these designs. Peer pressure motivated me to stop doing this to the product development teams. We technology developers began asking ourselves, "Why can't we deliver solid technologies that work?"
Avoid Creating Time-Bombs
The reasons technologies fail are: a) they lack adjustability to desired target functions; b) they possess internal sensitivities that are designed into their parametric inner workings; and c) they lack robustness to integration variation as well as external sources of variation that can assail the system in which they reside. Other than that, these innovations are what make new products possible. That is their allure - they look wonderful until you actually integrate them - then all hell breaks loose and nobody knows why!
To avoid these problems, technology development processes should include the following:
- A focus on the adjustability of the inner-working parameters as they govern repeatable and consistent output functions,
- internal parametric sensitivity characterization (aka interactivity), and
- robustness to external and deteriorative sources of variation as well as integratability into the system they are intended to harmoniously reside. Integration dynamics of a new technology is just another form of adjustability that happens to relate to what the technology contributes to outside of its own inner workings.
Technology Development must have a clearly defined process to assure that the technologies are measurably capable of meeting product development requirements. This is why I created "The Big 7" metrics of Critical Parameter Development and Management. There are just 7 things to measure to know if your technology is a time bomb or not. For all new, unique or difficult functions and their controlling parameters, these are the questions we must ask--and answer. Is the technology...
- Measurable?
- Stable?
- Adjustable?
- Independent, interactive, and statistically significant?
- Hypersensitive?
- Robust?
- Capable?
If you can answer these questions for the high-risk functions, their controlling parameters under nominal and stressful sources of unwanted variation for your technologies - then you know what you are transferring to the down-stream development teams. Otherwise, you are making time bombs.
|