A couple of stories…
When I was a very young lad, I worked in product development at a very large (and struggling) organization that had hired W. Edwards Deming as a consultant. He was a legend. I did not work with him directly, but several of the middle management folks I reported to or worked with were coached by him or in classes with him and brought back…
Control charts. The message was we needed to create control charts. In retrospect, I think the real message was that we needed to think of our work as a process, measure it, identify waste and improve, but nuance was lost and when the order came down to my level we simply were ordered to make control charts. Of course, nonsense control charts became the order of the day, we did not improve, and eventually, the enterprise failed – not necessarily due to this, but it certainly did not help.
Years later, I was part of the leadership team at an enterprise that was struggling with product development – programs delayed, over budget, not meeting customer needs, not meeting cost targets – the classic “target rich environment”. Lots of frustration from top management, especially with the level of change that was occurring as teams tried to react to the latest (often bad) news. The call goes out for action. Program Management responds with decisive action – a new “Lean” policy. The policy states that any program team can only have 2 change requests active at any moment in time – when these are closed out additional change requests can be processed, but 2 is the limit at any moment in time.
I point out an analogy – a factory is struggling with quality and has several dozen repair bays at the end of the line. These are always full, but the plant manager becomes frustrated and issues an order to close all repair bays except 2. Where do you think the poor quality work went?
The stories above are true and are examples of what happens when people do not understand the underlying “first principals” of Lean, and how they apply to Product Development. Since “The Machine that Changed the World” was published in 1990 good descriptions of Lean Product Development have become part of the record, and excellent books like Morgan and Liker’s “Lean Product Development” give considerable detail of Lean PD best practices. In this article, however, I want to hypothesize the “first principals” of Lean PD – the “why?” or philosophical underpinnings. With these, I believe you can teach an organization to correctly invent new and ever more effective Lean PD tools and practices – without first principals things can quickly degenerate into nonsense.
My hypothesis: any Lean PD activity should be based on:
- Obsession with customer value
- Continuous improvement – P-D-C-A
- Reduction of waste
Some detail of each. Obsession with customer value means maximization of customer delight – which means frequently creating something the customer could not have imagined (think most things Apple) – while simultaneously making tough tradeoff decisions and reducing what the customer has to pay for the product or service. To both imagine the product as well as making correct tradeoff decisions implies an obsession with understanding the customer by the entire product development organization, especially the Chief Engineer, not just the marketing function.
Hopefully, you can agree that continuous improvement – P-D-C-A – is an essential part of any Lean activity. Simply, feedback (did the plan give the expected results?) and sustainability (don’t repeat past mistakes) are critical. Continuous improvement can be intimidating – I have had experience where an organization interpreted continuous improvement as the desire to be perfect (and of course everyone then becomes terrified and frozen). Nothing could be further from the truth, and I repeatedly emphasize that the joy of P-D-C-A is that it does not matter where you start, an organization doing true continuous improvement will quickly surpass organizations that effectively ignore continuous improvement. The mantra is not “Make no mistakes” – it is “Make NEW mistakes”.
Reduction of waste is the third principle – which implies structuring Product Development as a process, identifying all the ways waste can occur (waste of knowledge, waste of time, waste of cost driven by design, waste of creating a product the customer does not want, and so on). Developing the ability to “see” waste and address it effectively is some cases not obvious (the Program Manager that created the “two change requests only” policy above was clearly trying to reduce waste). Another example: counterintuitively, Don Reinertson has shown based on queueing theory that optimization of a subactivity in a Product Development system can disrupt throughput and increase waste of the overall system. Nonetheless, the ability to “see” waste correctly and address it with continuous improvement is one never-ending challenge of Lean PD and yields great results.
How about your opinion? Do the “first principals” above ring true? I have tried to reduce all the Lean PD activity I have experienced in my career to the absolute essence and converged to the above, but in the spirit of continuous improvement would welcome your view and comments.