Home > The Lean Post> The Faster We Go, the Behind-er We Get
The Lean Post
Sharing how the world is making things better through lean.

The Faster We Go, the Behind-er We Get

by Jim Morgan
August 28, 2013

The Faster We Go, the Behind-er We Get

by Jim Morgan
August 28, 2013 | Comments (6)

Speed to market is not just about doing things faster. It's about taking the time to do things more intentionally. I've observed numerous companies attempt to shorten their product development lead times over the years, and would like to share a few questions that might help you tackle this important task:

Jim Morgan

Deeply understand your product through cross-functional learning at the gemba

Do you deeply understand what your product needs to be? Many organizations trivialize the immersion/study phase of development. Or they skip it all together and jump right to execution. This is incredibly wasteful because it usually leads to developing a lousy product—which is an indefensible waste of your people's time and talent. It is crucial that you take the time to deeply understand what the product needs to be, what product and process attributes are fixed and which are flexible, and what each individual needs to deliver. To do otherwise risks crappy products, organizational chaos, late changes, and invaluable engineering resources stuck on launch when they should be upstream working on the next product, leading to a continuous cycle of delay.

Are you capable of delivering your product with quality on time? I'm always surprised that some of the companies that are most intent on greater speed to market have not taken the time to understand their organizational development capability fully. Consequently they cannot effectively manage their capacity or improve their product/process development performance. Their capacity planning consists largely of estimating engineering hours, counting heads, and refereeing resource allocation "death matches" while continuing to jam projects into the system. No surprise then that excessive "special case" expediting and "project deep dives" further bog down an over-taxed system. Keep in mind that your development capability is dynamic. Project numbers, complexity, technologies (both product and process), regulatory environment, manufacturing footprint, suppliers... all affect your capability. That's why I encourage you to understand your complete product/process development system capability. Consider a rigorous system capability study from concept development through design, testing, tool up, and launch.

Do you have an enabling standards strategy? I can't tell you how few companies have taken the time to create an enabling standards strategy, by which I mean clear definitions of fixed and flexible attributes with effective mechanisms for continuous improvement enable speed, quality, and creativity. Far from inhibiting creativity, a dynamic system of standards is the foundation of product/process engineering excellence and a key enabler for delivering great products because it serves as a critical knowledge repository, provides a common working framework, and underpins continuous improvement.

Can everybody "see the whole"? That is, does the entire development team—spanning different functions—understand how their work ties into that of other concurrent activities? The most common opportunity to shorten lead-time I have seen is taking the time to understand and synchronize cross-functional activities in the development process. This is key to improving simultaneous development and creating flow. To start, often their base development process is rife with cross-functional disconnects which actually build re-work and waste into their process. Equally as bad, their lack of knowledge of how development work is actually done across functions, severely limits their lead-time reduction efforts. Too often well-intended efforts to increase speed to market are reduced to arbitrary directives to shorten large chunks of "block timing" without any enabling countermeasures. Consequently these types of efforts tend focus on rushing individual task completion without a thorough understanding of the larger system implications. Once again this results in lots of late changes, rework, and delay.

One principle that can help you improve cross-functional synchronization is compatibility before completion (CbC). That is to say, building mechanisms into your development process to make sure that individual product or process components are compatible with other, interdependent parts of the system before completing their individual design. Optimally, these mechanisms should take place as early as practicable in your process. This requires you to understand and specifically define a minimum level of design maturity by part/process, when dependent parts and processes are able to base their work. This maturity level is known as the minimum feasible maturity (MFM) level. Establishing this "Goldie Locks" level of maturity can be tricky, but this concept is a key underpinning to the successful execution of simultaneous engineering, reducing lead-time, and creating great products. It requires a significant level of organizational collaboration and technical capability. The best organizations continually work to minimize the MFM and increase overlap and consequently speed to market.

This post is certainly not intended to be a comprehensive recipe for a lean development process. Just a few observations, questions, and notes of encouragement to take a thoughtful and deliberate approach to your product/process development process improvement efforts. Remember that with lead-time reduction, like so many things in life, faster is not necessarily better.

The views expressed in this post do not necessarily represent the views or policies of The Lean Enterprise Institute.
Keywords:  product development
Search Posts:
Leader Standard Work
Joe Murli & Mark Hamel
Gemba Walks
By Jim Womack
Seeing the Whole Value Stream
By Dan Jones and Jim Womack with D. Brunt, M. Lovejoy
Was this post... Click all that apply
HELPFUL
22 people say YES
INTERESTING
27 people say YES
INSPIRING
18 people say YES
ACCURATE
21 people say YES
Related Posts
6 Comments | Post a Comment
Katrina Appell August 29, 2013
2 People AGREE with this comment
A great post that is very applicable to the development of service products including how we engage people with lean

Reply »

Durward Sobek August 30, 2013
3 People AGREE with this comment

Great post!  I find it a bit surprising how many companies seem to ignore the power of enabling standards in products and manufacturing processes.  Standards allow you to build on prior development work.  Without them, you keep learning the same things over and over again!  


I hope people interested in these topics will join Jim and me in Savannah for the Lean Product and Process Development Exchange (www.lppde.org).

Reply »

Michael Ballé August 30, 2013
Agree with Durward, and sorry not to be able to make the event. It's a great post, on a key topic to our further understanding of lean thinking. As far as I can tell from the gemba, a the greater part of value is set at the engineering stage, without diminishing the importance of excellence in manufacturing and delivery. A unique aspect of lean thinking is indeed the feed-back from manufacturing back into engineering in the form of standards. This is both an exciting and crucial discussion that I hope many lean thinkers will join - Thank you Ji

Reply »

Joe Sammut August 31, 2013
2 People AGREE with this comment
Very insightful and real world

Reply »

George Bernwanger August 31, 2013
2 People AGREE with this comment
Relative to standards, one of my prevoius bosses used to say "the only way to sanity is to spend sufficient time on non-program specific work". This goes along with your enabling standards strategy. Standards are one of the key ways to capture and get value from lessons learned. One of the ways we do this within product development is developing and continuously refining basic architecture strategies and design parameters. Thanks for sharing all of the great ideas!

Reply »

Art Hyde September 09, 2013
Thanks Jim.  As you point out, the need to have an ability to have "compatibility before completeness" is both very critical and is also a very difficult to implement.  Developing the standards that are credible enough to enable this without endless levels of detail needs to be a major focus of any lean organization.

One other consideration I would suggest may be that a key step in reducing time while not crossing over to the in-effective territory of risking the product is to have a good mechanism to identify waste in the development process -- good time reduction can be found if you can take non-value added "work" out of the system.  Like your "Goldilocks" example, this too is essential and also probelematic in any large organization. 


Reply »

Search Posts:
Leader Standard Work
Joe Murli & Mark Hamel
Gemba Walks
By Jim Womack
Seeing the Whole Value Stream
By Dan Jones and Jim Womack with D. Brunt, M. Lovejoy
Leave Your Ego at the Door
Product Focus = Customer Focus