From Rigid Project Management to Iterative Learning in Product Development

Last week, my associate Richard Sheridan, co-founder of Menlo Innovations, an innovative software development company, was guest lecturing in my class and made a profound point.  In his many years as a leader in IT companies, he has witnessed a clear trend – the swing wildly between extremes of chaos and rigid bureaucracy.  The rigid bureaucracy might take the form of a detailed process of defined stages with gate reviews every few months.  For this, one must check the boxes to satisfy a myriad of gate review requirements to proceed to the next step of the project.  When this becomes a check-the-box exercise with no real improvement, the company stops seriously enforcing the rigid process and swings back toward chaos. 

Between these extremes, he described a process used at Menlo which offers a simple, repeatable, and measureable structure.  The overall design project is broken into small pieces including features written on note cards.  From this, times for each card are estimated, and a day’s work is laid out for each pair of programmers.  Customers review the work each week so there is a clear daily and weekly cadence to the process with rapid feedback.  His book, Joy, Inc., argues that people strive for structure that works and allows creativity within the structure.

This is a key point of what I talked about in my last blog post about Toyota Kata, How Small Steps Turn into Lean Manufacturing Game Changers.  The improvement kata, which is a meta-habit of how to systematically and creatively work toward a clear goal, is a structured, repeatable, and measurable structure based on iterative learning in bite-sized chunks. I would like to illustrate the positive things that can happen when an organization shifts their thinking from big, inflexible programs to learning iteratively.

Solar Turbines, nestled on one end of the San Diego Bay, is the market leader for medium-sized gas to electric turbine power generators (see fig 1).  Their main competitive advantage is through technology and quality: customers get high quality products and service with more power for the same size and cost generator.  Yet they rarely completed a development project on time or within budget.  Lean had been successful in their manufacturing operations and had strong management support.  In April 2008, they requested help to implement lean product development.  They had developed their own phase-gate process, had read a lot about lean, but they were not getting any traction.  I remember trying to read on the plane to Solar their 50 page phase-gate document and falling asleep.

Figure 1: Taurus 70 Turbine Power Generator

When I presented to senior management I suggested that they put away the stage-gate model and try a different approach based on real product development programs, ideally one that was relatively short, but important, so we could see results from start to finish.  They selected the Taurus uprate for two reasons:

1. Their key competitors were uprating their equivalent products, and Solar was potentially in the rare situation of getting behind.
2. Sales had promised the uprated version within 16 months, which was faster than any similar program had ever been completed.

Our starting point was value stream mapping.  They assembled a cross-functional team of about 25 people, and in 2 ½ days, we developed a current state picture using their traditional method.  We also developed a future state vision that would meet their time requirements and crafted an action plan. 

Figure 2: Solar Current State Map for Taurus Uprate Program

The current state, as seen in figure 2 above, revealed some serious obstacles to their reduced lead time target:

1. Late involvement:  Downstream functions like prototyping, tooling, and manufacturing were involved very late in the process, and then there was chaotic activity as product launch approached.
2. Batching of work:  Engineers would do a lot of work and then release it in one large batch.  For example, the entire database for the machined steel turbine had to be complete before it was released to purchasing so they could order prototype castings.
3. Scope creep:  A great deal of rework was done within the development process itself because management or sales routinely changed the requirements.

The future state map addressed these concerns by front loading the design with simultaneous engineering of the product and process, providing deadlines for freezing the design requirements, and releasing portions of the design as it was complete to purchasing so they could order in small batches.

Figure 3: Solar Future State Map for Taurus Uprate Program

Voila! If achieved, the future state would reduce lead time from 24-27 months in the current process down to 15-16 months.  The solutions were obvious.  The execution was not.

This is where the human side of change entered in.  Senior executives approved the plan and agreed to everything, including freezing requirements.  For execution, we used a Toyota tool called obeya, Japanese for big room.  The idea is simple – get representatives from all key functions, particularly those who did the mapping and began the team building process, to meet every week in a visual planning room.

Figure 4: Obeya is the Pacemaker of Cross-Functional Communication

Each function has a section of the wall and posts their current status relative to target on financial issues, technical issues, and timing.  Current and potential future gaps between plan and actual are discussed for rapid resolution.

What happened is that the future state map quickly faded away, phase-gate models were barely considered, and the focus was on execution, identifying current and potential future obstacles, and creatively resolving issues to achieve the future state.  The future state map actually represented what, in Toyota kata, are called target conditions.  For example, front loading was not a solution but rather a desired target condition to be achieved through rigorous planning, trying, checking, and adjusting.   The weekly meeting provided a cadence to the PDCA cycles.  What happened between meetings was a lot of hard work to try things, resolve communication issues, keep sales at bay and senior management from agreeing to scope creep, keep all functions coordinated, and solve unanticipated challenges such as a three-month delay in a critical component.

The result was on time, on budget, and ultimately, meeting all the technical requirements.  As Solar Turbines program manager Howard Kinkade put it:  “I have never been more encouraged by an idea or initiative in my 25 years in Engineering.”

He was on fire!  Fortunately, the success of this and a similarly successful parallel pilot program to develop a new combustion injector created enough in-house knowledge, skill, and leadership to build on the momentum.  Value stream mapping to build a core team that met weekly in an obeya became standard practice.  The company then worked hard to learn problem solving, and eventually learned about Toyota kata.  Meeting program objectives became the norm rather then an unnatural event.  And the concepts spread to every aspect of development including prototyping, on-site installation, and even trouble shooting problems in the field.  One of the key lessons they learned was that the future is never certain and they need to learn through many small experiments, one challenge at a time.  Now, in their seventh year, they are still learning every day.

Dr. Jeffrey Liker is professor of industrial and operations engineering at the University of Michigan and author of The Toyota Way.  He leads Liker Lean Advisors, LLC and his latest book (with Gary Convis) is The Toyota Way to Lean Leadership.