Stand Back and Deliver: Introduction to Key Principles
- What Could Go Wrong?
- What Went Right
- Why Do We Do This to Ourselves?
- A Framework of Effective Tools
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
In this chapter, we explain what we mean by "stand back and deliver" by first presenting some situations that may seem alarmingly familiar to you. We then cover some of our core concepts and beliefs that underlie the tools we recommend you implement to get your organization going in the right direction.
What Could Go Wrong?
Have you ever done things by the book, but the book was out of print? Such was the case for a large, successful product company. This company had developed what it considered to be a revolutionary new product. With its heavy engineering background, the company did product development by the book—the way it had worked many times before.
Through its research and development activities, the company had discovered that it could use a waste material as the basic raw material for a new product. Imagine the possibilities: Currently the company pays to dispose of this material, but now it could use this "waste material" to make an industrial product. The company did what it had always done. It selected one of its best engineers to sort through the product design and manufacturing options. It set up the engineer with all of the development and testing equipment he would need. It gave the engineer the time and flexibility he needed to design what he thought the market needed.
Within a year, the engineer had perfected a formulation that worked. The resulting product had impressive characteristics. It had high workability and could be formed into various shapes and sizes. The engineer produced small batches of the product that the company used to generate early customer interest. Using these small batches, the company formed several industry joint ventures and alliances. The future looked bright.
The engineer next worked on the manufacturing processes needed to produce the product. In parallel with this effort, the company issued press releases and featured the new product in its annual report: "Coming soon, a revolutionary, green product." One year later, the engineer announced that his work was done. He documented the product formulation. He described in great detail how to scale the manufacturing process from the small batches he had created to full-scale production. The company built the first of what it planned would be multiple manufacturing plants and hired a plant manager to follow the engineer's scale-up process. In the meantime, the market waited for the formal product release. The company hired a dedicated sales force to start generating interest in the product. The development engineer was promoted and assigned to a different project.
Five months later, the first manufacturing plant came on line. As the first full-size batches of the product came out of processing and into packaging, problems arose. When subjected to full-sized manufacturing, the product had tiny cracks. In the small batches prepared by the development engineer, there had never been any cracks. In expanding the product batch size by a factor of 10, however, there they were—tiny cracks. At first, no one gave the cracks much thought, because they did not affect the product characteristics or performance. But then the company shipped its first order. As the delivery truck rolled down the road, the cracks propagated throughout the product. By the time the truck arrived at the customer's facility, some of the product had broken into pieces. After two years of engineering and five months of manufacturing scale-up, the company had a great product, so long as it did not have to ship the product to anyone!
In retrospect, it is easy to identify some of the mistakes this company made. We have spent hours with groups dissecting this true story to learn from—and to not repeat—the mistakes of the past. The development engineer developed the product in isolation and did not think through scale-up issues. The company did not produce any full-sized product samples until after it had built the manufacturing plant and then discovered the propagation of the cracks. It is easy to mock management for the wasted investment.
Before being too critical, however, we should consider this point: If the final product had not developed the tiny cracks that spread during shipping, the product and the process would have been a success. In fact, many times previously, the company had used a similar process and gotten good results. Using what had worked before, those involved in this project were clueless about the risks that lurked in the shadows of their process. What is now obvious to us became obvious to them only after this product failure.
The most important lesson we can draw from this story is that we, too, are brilliant but sometimes clueless. We live in an environment of increasing global competition, an increasing pace of market changes, and a need to develop solutions that are increasingly complex. In this environment, we do not have the luxury of missteps and hidden risks. There is increasing pressure to deliver complex solutions in less time and to get it "right the first time." If we don't, we can completely miss our business value goals. The good news is that we can make sure that our brilliance results in things that work. To see how, we continue our story.