Home > The Lean Post> The Dark Side of Concurrent Engineering
The Lean Post
Sharing how the world is making things better through lean.

The Dark Side of Concurrent Engineering

by Katrina Appell & John Drogosz
August 9, 2019

The Dark Side of Concurrent Engineering

by Katrina Appell & John Drogosz
August 9, 2019 | Comments (2)

One of the fastest ways to reduce lead time from concept to market is to work concurrently. And this makes perfect sense; if everyone just did their work in parallel instead of sequentially everything would get done quicker because we would eliminate the waste of waiting to get started. Unfortunately, too many people see the benefits of concurrent engineering and jump in without doing the necessary understanding and planning of the work to be successful, leading them to experience the “Dark Side of Concurrent Engineering.”

This “dark side” is often far worse than working sequentially leading people to conclude that either concurrent engineering doesn’t work and it is better to go back to working sequentially with long development lead times or working long hours doing re-work and paying to expedite the work to meet time-lines. So, what can be done to prevent the problems and get the benefits of working concurrently without experiencing the “dark side.”

The problems we experience result from doing unsynchronized concurrent work, which is one of the 12 wastes in lean product and process development. Similar, to overproduction in manufacturing, the waste of unsynchronized concurrent work leads to many other wastes being created such as re-working tasks, stop-and-go tasks, high process and arrival variation, system overutilization, misuse of talent, etc.

Rather than having unsynchronized concurrent work we need the work to be synchronized, which requires a deep understanding of the work to be done including the interdependencies across the work. A key piece of this is that data transferred to downstream partners must be stable. This isn’t implying that you shouldn’t share information that might change, but part of sharing that information should be clarity on what is stable and won’t change and what is being shared to facilitate collaboration - to bring in knowledge from different disciplines early in the process to make the best decisions for the product overall.

This isn’t a case of getting a “base-line” with constant deviations from the “base-line,” where no data is stable until the final freeze. In a “base-line” situation no data is stable and every change cascades rework across the organization, which is what drives the desire to get all the data stable and complete leading to working sequentially with downstream partners.

Avoiding the “dark side” begins with understanding the work and interdependencies to enable downstream partners to provide inputs at the right times to incorporate their knowledge earlier in the process. This isn’t just inviting people to participate in meetings earlier, but rather understanding the work together and what information is relevant at the right time and then structuring how the work is done to get that information.

This starts with planning the work together – ideally with simple visual tools that engage the team. It then continues through executing and adjusting the plan as needed, which obeya and design reviews can enable. Synchronizing the work in the planning stage and frequent collaboration to learn together, make adjustments, and stay synchronized can lead to reductions in time to market as illustrated in Figure 1. This also prevents the long re-work loops from design iterations when down-stream knowledge is incorporated into the designs earlier in the process.

prod dev vs map

Figure 1: Lean Product and Process Development: creating flow and eliminating waste for speed to market.

So as you work on your product development projects, be watchful of the “dark side” of concurrency. Are you getting the right information at the right time to do value-added work? Do you and your team see and understand the flow of work to be done? If not, a common way to see and understand the work together is through a product development value-stream map.

To Do:

 

The views expressed in this post do not necessarily represent the views or policies of The Lean Enterprise Institute.
Was this post... Click all that apply
HELPFUL
11 people say YES
INTERESTING
12 people say YES
INSPIRING
8 people say YES
ACCURATE
8 people say YES
Related Posts
2 Comments | Post a Comment
Carl Watt August 12, 2019
1 Person AGREES with this comment

Sure, you need to coordinate, all the frameworks say that, but what is your visual for coordination? Gantt Chart?  Program Board?  Roadmap?  depends on the product.  Software has fewer dependencies, hardware many more.  What tool do you use?

Reply »

Katrina Appell August 27, 2019

The tool really depends on your situation. No one tool is going to be the best choice for everyone in all situations. 

What really matters is that you are seeing together with all of the right people involved and that people have ownership of their parts of the plan to coordinate. 

Some tools support this better than others, but all tools can be used in a way that doesn't support it. Your behavior in whatever tool you choose to use is what really matters. 

Reply »

Developing Your Obeya, Stage-by-Stage