Written in collaboration with John Drogosz, PhD and originally published in August 2019 at The Lean Post

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. This also prevents the long re-work loops from design iterations when down-stream knowledge is incorporated into the designs earlier in the process.

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.