Most every development project begins with optimism, if not confidence, of success. Markets are studied to understand the needs of the customer. Different concepts and technical solutions for meeting those needs are discussed. Sales projections are made. Financial analyses are performed. Detailed project plans are crafted. While product development processes requiring frequent management oversight guide the work.
Usually all progresses well until late in the project when problems are discovered. The specification goals are not being met. There are technical problems. Manufacturability is substandard. Schedules slip and budgets are busted. Sales forecasts are missed. If fact, many product development organizations report spending 50% to 75% of their engineering resources on this type of late project firefighting. And, depending on which study you look at, only about one third of product development projects are ultimately successful. With all the work that has gone into crafting product development processes and the attention given to managing that portion of the business, we really have to ask: Why?
Hello, my name is Kent Harmon of Targeted Convergence Corporation. I would like to thank Product Innovation Academy for providing this forum to share with you some thoughts about challenges of developing increasingly complex products for an increasingly competitive marketplace. I have been deeply interested in this subject for 25 years. My commitment to improving productivity in product development began in 1991 when I was promoted from engineering manager to product line manager for a multi-million dollar family of semiconductor products. This was a very heady and exciting moment – until they told me about the revenue goals and the hiring freeze. From some very simple arithmetic it was clear we needed to become much better at identifying market opportunities and executing their development. And we needed to do it fast.
At the time, industry was still focused on Total Quality Management and Lean Manufacturing, so there was not an established body of best practices on which to rely. So we studied Lean, Theory of Constraints, standardized white-collar business processes and project management. From these we selected the practices that looked best for us and incorporated them into a phase-gate development project. That itself was fairly novel at the time.
We were successful, and I went on to lead the implementation of these practices across the company. Overall, time-to-market decreased by 20% and schedule attainment increased from 40% to overall 85%. Not a bad productivity improvement for a 6 billion dollar business that invested 12% of revenues in R&D. Or so I thought.
In 2004 I met a gentleman named Michael Kennedy. Mr. Kennedy had just published a book describing what he learned from participating in a product development benchmarking study in the late 1990’s. The startling outcome of the study was the discovery of a company that could develop a new product in half the time with half the number of engineers as their competitors. Frankly, I didn’t believe it. And even more astonishing was that this company didn’t employ the conventional best practice; in fact they sometimes acted in apparent contradiction to them. They didn’t start the project with specific targets for customer requirements. They delayed decisions as long as possible. They did very little design validation in the traditional sense. And most unbelievable to me as a former engineering manager, they continued to evaluate all feasible design solutions until they were proven infeasible. How could they afford that?
Yet they were consistently profitable, constantly gaining market share and independently ranked as having the best quality and reliability in their industry. I was intrigued, so I set out to understand what this company was really doing, if it really worked and, if so, why. Within a few short months I was both amazed and chagrinned.
What this company was doing was amazingly simple in its concept, skills and practices; it just approached product development with a different paradigm. It is so simple and logical that when presented to engineers they declare it to be “common sense”. I was chagrinned that I had thought of it myself. So I joined Mr. Kennedy’s company Targeted Convergence Corporation in the endeavor of bringing these principles, practices, techniques and the commensurate benefits to other organizations. And provide some computer-aided tools to make it easy.
So what is this seemingly magical approach to product development? Well, a number of terms have evolved over the past decade to describe it or parts of it: Learning First Product Development, Knowledge Driven Product Development, Set-Based Concurrent Engineering, Success Assured™, and Lean Product Development. A full explanation of these is beyond the scope of a blog, but I can distill the key points:
Most phase-gate product development processes focus on the execution of tasks. In contrast, the benchmark company recognized many decades ago that the success of product development depended on the quality of the engineering and marketing decisions. So they subjugated everything to those decisions and optimized their ability to make those decisions. (When you think about it, everything on a drawing, the bill of material, a process sheet, the system architecture and even the customer requirement targets are a decision that someone has made.)
The order of work in most product development processes is to hypothesize a solution to the perceived customer needs, design it with simulation where possible, build it and then test it. Only then, late in the process, do we learn if the hypothesis was correct. The benchmark company moved that learning to the front of the process, so that they didn’t commit to a solution before it was proven to work. In fact, they sought out multiple proven solutions and then spend their time finding the optimal solution. Importantly, they changed the decision strategy from choosing the likely best alternative, to eliminating those proven to be infeasible of meeting the customer needs within the time and money available. And that changes everything.
To be able to do this, an organization must be able to learn rapidly and robustly. And be able to collaborate effectively around visible knowledge of the trade-offs that are naturally present in complex systems.
The first reaction upon hearing this approach is that it is not possible – there is not the time or the money. I remember that was my initial reaction. Yet we have worked with a number of companies over the past decade that have fully committed to this approach and achieved the same 4X productivity improvement as the benchmark company. Others, embracing only a subset of the practices, have achieved a 2X productivity gain.
Achieving this level of productivity does require organizations to build some new skills, adopt some new behaviors and perhaps make a modest investment in the tools needed to promote rapid learning and effective collaboration. These are well within the capability of most product development organizations. After working with dozens of companies over the past eleven years, I believe the biggest obstacle is simply embracing and committing to working in a new way.
I recognize that the brevity of this blog only allows us to scratch the surface of this subject, and perhaps raised more questions than it answered. Hopefully, for those of you challenged with getting more from your product development process, or just holding steady in the face of increasing complexity, I have provided ideas for further investigation.
If you are interested in learning more, I would suggest the following books as a starting point:
Also, I will be presenting a paper at APCOSEC 2016 in Bangalore this November. Following that conference, Product Innovation Academy and Targeted Convergence Corporation will be co-hosting a series of seminars on this and related subjects. If you’re interested, perhaps we can spend a day in deeper discussion.
process, do we learn if the hypothesis was correct. The benchmark company moved that learning to the front of the process, so that they didn’t commit to a solution before it was proven to work. In fact, they sought out multiple proven solutions and then spend their time finding the optimal solution. Importantly, they changed the decision strategy from choosing the likely best alternative, to eliminating those proven to be infeasible of meeting the customer needs within the time and money available. And that changes everything.
