The series explores the relationship between Lean Startup Principles, Knowledge Based Product Development, and Project Risk Management, and how they can be combined to dramatically accelerate projects and profits.

Lean Startup Methodology and Early Learning

In part 4, we’ll review some quantifiable benefits of reducing the Design Build Test batch size, as presented in a research paper by Sang-Don Lee of General Motors and Ik-Sung Lim of Namseoul University.

In summary, Lean Startup presents the value of integrating and testing earlier in cases of extreme uncertainty. This research paper quantifies these benefits for an example case where uncertainty is not extreme and yet the improvement in cycle time is quite large. The paper also shows several other interesting characteristics of Lean and Traditional New Product Development.

A 23% reduction in development time results from reducing the DBT batch size in this typical case. It can be much more.

For those of you looking forward to the posts using the Wright brothers example, stay tuned. I’ll get to that in the next post. I wanted to share this first.

Please find the paper here. You will be prompted to register, but you can just close or click outside of the prompt window. Then, in the lower right-hand corner, select the View button.

I will let the paper speak for itself, as I think it does a fine job. It even touches on Cost of Delay, the ’90 percent syndrome’ and the firefighting that results, and other topics we have been discussing in recent posts and will discuss more in the future. I will just pique your interest further and summarize here by reviewing a few key points.

Lean Case Study - The Value of Testing Early

The system dynamics model presented in this study is generic enough to be common to all product development projects. (See Figure 3 in the paper.)

1. The number of “designs to do” seems high in this simulation, because it represents an entire automobile. However, it is still representative of simpler products. Where, in this simulation, each “design to do” might represent an entire sub-system containing many parts, in simpler products each individual component, or each interface, or any other subset of design specifications can be considered a “design to do”.
   
   
2. The length of time (10 weeks) to design, build and test each “design to do”, at least at a sub-system level, is also somewhat long in this simulation because of the complexities of many automobile components. Certainly, in many other product development projects, this time can be much shorter. The result of doing this is that it changes the absolute values for cycle time. However, the relative value between smaller DBT batches and bigger ones remains similar. e.g., it took 4 years to develop an automobile in big batches and 3 years to develop it in small batches. For simpler products we might be reducing development time from 12 months to 9 months by using smaller DBT batches.
   
   
3. This simulation assumes that requirements are fixed early and that the rework needed on 30% of ‘designs accomplished’ is due to design errors (part specifications that need to change) that become apparent during the system test. However, in today’s fast-paced world of NPD, even high-level requirements are often uncertain and changing. If we recognize this, our ‘system test’ becomes actual customer testing which often finds ‘requirements errors’. Unfortunately, a single requirement error can have a large impact on the design and result in many part specification changes. We may need to change everything we thought we had completed already, rather than just 30% of it.

When there are requirements errors to find, and an integrated product is necessary to find them, getting to that integrated product earlier has an even larger benefit than this simulation shows.

Why are small batch sizes important in early learning? 

1. 90 percent syndrome

   With larger batches, we exacerbate the ’90 Percent Syndrome’, where we seem to be 90% done even though we are not. In fact, this phenomenon is natural when we develop in batches which are too large.

2. Earlier project completion

   The actual number of iterations needed exceeds the number expected in all cases. However, with the smaller batch approach we still complete the project much earlier.

3. Out with large batch project planning

   Traditional ‘get it right the first time’ project plans are large-batch iterations. We think we can develop the separate pieces, put them together once, make a few changes, put them together again, and everything will be fine. We expect two iterations. Unfortunately, it doesn’t work out that way – ever.

4. More iterations in less time

   Most traditional companies plan for three iterations to complete an average product development project, and it actually takes four or five iterations. However, there is little benefit to going from three actual batches (two expected) to four (three expected). Because this is as far as many companies go, they see a low benefit over ‘get it right the first time’, so many fall back to trying to find ways to ‘get it more right the first time’.

5. Integrate early

   There is big benefit in going from four batches to six. Integrating a little earlier than ‘get it right the first time’ doesn’t have a big payback. We need to integrate a lot earlier. Expecting four or five smaller batch iterations and doing it in five or six is optimal according to this simulation. This aligns with our experience at Playbook.

6. Point of diminishing returns

   There is again little benefit to developing in even more, smaller batches. There is a point of diminishing return, as it intuitively seems – at least when there is hardware involved. This is an area where hardware and software largely differ. In software, I don’t think we reach a point of diminishing return, or at least that point is with many, many more, much smaller iterations. We will discuss this further in future posts.

7. Testing earlier accelerates projects

   The simulation shows about a 23% improvement in development time simply by integrating and testing fewer completed designs earlier. 23% is a big improvement. Additional benefits of earlier testing are manifold. We have an improved understanding of the requirements, we can make better architectural decisions. Plus we have faster communication and feedback loops enabled by up-to-date plans and daily stand-up meetings, improved resource availability enabled by controlled WIP, minimized multitasking and time blocking.

…and a 50% reduction in cycle time is very achievable. We just have to do it.

Conclusion

In summary, Lean Startup presents the value of integrating and testing earlier. This research paper quantifies these benefits for an example case. When there are requirements errors to find, as described throughout Lean Startup, the benefits of testing earlier are much larger. We do this by designing, building, and testing our product in smaller batches.

We’ll continue in the next post by reviewing the example from the Wright brothers and how to learn earlier, in smaller batches. We’ll see more of how to capture and communicate requirements and risks, and the differences between hardware and software. Stay tuned…

What is the number one cause of project delays? It's not what you think. Watch this 9-minute video to find out.

 

Related articles

Lean Startup Methodology and Product Development 
Lean Startup Methodology and Risk Management
Lean Startup Methodology and Reducing Batch Sizes
Lean Startup Methodology and Early Learning
Lean startup principles
Small batch sizes