strategy+business is published by PwC Strategy& Inc.
 
or, sign in with:
strategy and business
Published: May 29, 2007

 
 

Innovation Agility

Translating that spirit of cooperation to a Western context isn’t easy, because it demands aligning the goals of all product development programs as tightly as possible. It won’t work without two types of people in place: a true chief engineer for every program (a shusa equivalent) and every functional team (a bucho equivalent). Both individuals must have the experience to succeed and the respect of all players on their teams. A successful R&D career at such a company may include time spent as both a shusa and a bucho — and, most importantly, time spent internalizing the needs and priorities of both sides.

Reclaiming Knowledge
Most Western companies take a process-driven approach to product development, involving elaborate handbooks, compiled over decades, that prescribe hundreds or thousands of deliverables, checklists, and coordination meetings — all no doubt good ideas when they were developed for some long-forgotten project. But because engineering teams rarely have the time, resources, training, or inclination to meet all these requirements, management often appoints “process police” who are charged with driving compliance with the handbook, while mandating sparsely attended, high-level “gate reviews,” all in the name of keeping the program on track. Well-intentioned as the system may be, the result is a project development team that spends far too much time — and money — on compliance and reporting, and not enough time on experimentation and technical problem solving.

Instead, establish an event-driven approach in which various key decision points (events) are laid out in sequence, along with the engineering results that will be needed to make each decision. Hold your engineering teams accountable for meeting various technical objectives by a specified time. In the course of their work, they may use checklists and procedures to keep track of their progress. But leave that to their discretion. Invest your oversight in helping them make better technical decisions based on rigorous data and experimentation.

Simultaneously, refine your knowledge processes: your means of capturing information about processes and products and making systematic use of that knowledge. Expect design engineers to maintain their own benchmarks, industry standards, technology trends, and supplier data for the components they work on. That might include the creation of checklists, trade-off curves (plotting diagrams of component performance), A3 reports (detailed breakdowns of technical problems, which take their name from the A3-sized tabloid paper on which they are plotted), teardown analyses (detailed evaluations of competitors’ product costs), and other quality-oriented forms of observation and analysis. Engineers should also be trained to synthesize this information and articulate what it means in the wider scheme of the product development process.

A well-designed knowledge-building process will help you build both technical problem solving in the short run and more extensive capabilities in the long run. This type of learning doesn’t just happen. To develop such a system of your own, you will undoubtedly apply information technology in innovative ways, but the most important aspects are human: engineers continually thinking about the significance of what they observe, and management continually rethinking the way knowledge is put to use. Can you design a system in which engineers “pull” the knowledge they need, as they need it, rather than having someone “pushing” knowledge at them? Can you manage such critical processes as teardowns so that every engineer is responsible for his or her part in the process? And can you institute a more effective program “postmortem,” capturing and institutionalizing the lessons from each launch, to the benefit of future projects?

Instilling a Flexible Risk Ethic
Every product development project brings with it inherent risks: technical risk (will it work as planned?), schedule risk (will it be ready in time?), market risk (will people buy it?), and financial risk (will pricing, costs, volume, and program life come together in such a way that you can make money?). Many companies aspire to eliminate risk by embedding a system of constraints in their product development processes. When programs go over a cost threshold, miss deadlines, or leave too many problems unsolved too long, “red flags” are raised that bring unwanted attention and sometimes penalties. Then all work on the project halts while the issue is dealt with, often in the hastiest manner possible to bring the project back into line.

 
 
 
Follow Us 
Facebook Twitter LinkedIn Google Plus YouTube RSS strategy+business Digital and Mobile products App Store

 

Resources

  1. Matthew A. Clark, editor, Mastering the Innovation Challenge: Unleashing Growth and Creating Competitive Advantage (s+b Books, 2006): An omnibus of approaches for improving and expanding a product development or R&D core function.
  2. Jon Gertner, “From 0 to 60 to World Domination,” New York Times Magazine, February 18, 2007: Incisive introduction to Toyota’s unique culture and its view of the future, particularly with hybrids.
  3. Barry Jaruzelski, Kevin Dehoff, and Rakesh Bordia, “Smart Spenders: The Global Innovation 1000,” s+b, Winter 2006: What Toyota has in common with Christian Dior (plus Apple, Adidas, Petrobras, Samsung, Google, and 87 other high-leverage innovators). Click here.
  4. H. Thomas Johnson and Anders Broms, Profit Beyond Measure: Extraordinary Results Through Attention to Work and People (Free Press, 2000): Based on methods developed at Toyota and Scania, this book describes how to substitute ingrained awareness for rote metrics.
  5. Matthew May, The Elegant Solution: Toyota’s Formula for Mastering Innovation (Free Press, 2006): Inside look at the creative process that implements 1 million ideas each year.
  6. James M. Morgan and Jeffrey K. Liker, The Toyota Product Development System: Integrating People, Process and Technology (Productivity Press, 2006): For engineers; dense and detailed.
  7. Taiichi Ohno, Toyota Production System: Beyond Large-Scale Production (Productivity Press, 1988): Shusa-style wisdom from one of the originators of the Toyota production system.
  8. For more articles on innovation, sign up for s+b’s RSS feed. Click here.
 
Close
Sign up to receive s+b newsletters and get a FREE Strategy eBook

You will initially receive up to two newsletters/week. You can unsubscribe from any newsletter by using the link found in each newsletter.

Close