Seeing and Understanding the Work in Product and Process Development

The role of most lean tools is to enable problems to be identified or to enable problems to be solved. An important part of being able to identify problems is being able to see them. The harder it is to see the work being done, the harder it is to see the problems in the work being done. But what do you do when the work being done is typically only visible on a computer? This is the case in many office environments and common throughout product and process development.

You can start with identifying the work to be done and making it visible. That is easy to say, but where do you start?

For one, you can start by making the project schedule or plan visible. A common initial reaction to this suggestion is that it isn’t necessary because everyone can already see the schedule on their computers. This is certainly an efficient way for everyone to see the schedule from anywhere, but it often leads to individuals looking at the plan in isolation at their desk or somewhere else. And as such, it misses the biggest benefit of making the work visible – the conversations and interactions it facilitates. The ensuing dialogue about the plan facilitates mutual understanding amongst the different functions involved about how their work fits together to deliver customer value. This isn’t about just understanding the plan, but understanding each other and the impact of decisions and the timing of deliverables on each other, the project, and the customer.

This dialogue also allows for plans to be adjusted as necessary as the cross-functional team decides when they need to be be collaborating, sharing information, and creating new knowledge. This approach can even be taken one step further by enabling the teams to plan their own work in support of project milestones. This pull planning creates ownership of the plan with the team. By making these plans visual and discussing them, the team can identify when they need to synchronize their work and collaborate on both decisions and deliverables to each other and the project.

Now all of this planning is critically important – as Dwight D. Eisenhower said, “Planning is indispensable.” But let’s not forget the first part of Eisenhower’s quote: “Plans are useless.”

What can we do to ensure that these plans aren’t useless? The first step is to track what is actually happening. We need to know when there is a deviation from the plan. It might mean that our plan wasn’t accurate, which we can learn from and improve our planning in the future. Or it could be signaling that there is a problem that needs to be solved, which we want to know about sooner rather than later. Or it could mean that we are learning new information that requires the plan to be adjusted. This enables people to make adjustments to best support the project. If the cross-functional team continues to check and adjust on a regular cadence with dialogue, the benefits of understanding how their work fits together, supports the project, and delivers customer value continue and grow deeper.

For a more in-depth view of how cross-functional collaboration with visibility can enable better product development, check out this case study of an organization that completed a project in 17 months that would have typically taken more than 24 months: Value Stream Mapping and Obeya: Key Enablers for Better Product Development.

Value Stream Mapping in a Product Development Context: A Q&A with John Drogosz


I have applied value stream mapping in the manufacturing environment and on a few administrative processes, but I am struggling with applying it in the product development. Every time I get started with the current state map, everyone says “it depends” as they say each project is different and there are so many data flows occurring at the same time that it is difficult to keep track. Do you have any tips?


I do. Value stream mapping is a proven approach for understanding any process, seeing the wastes within it and helping you to formulate a vision of where you want to take your process in the future. It is potentially even more valuable in Product Development than than in manufacturing since “seeing” waste in the virtual and somewhat complex world of product development and pinpointing its source is challenging. But you’re right, some people do get caught up in the complexity of the process and lose sight of the goal of VSM – which is to find and eliminate waste. So here are some adaptations to the VSM to help you get started and keep your product development teams more focused:

  • Pick a specific product to map: Many people fall into the trap of mapping the “generic” PD process for their product. This leads to a lot of “it depends” and anecdotal comments about pain points. It is better to pick a specific product/project that you have recently completed. This calibrates everyone to be talking about the same value stream and will be able to provide you more consistent data. Yes, all projects are different, but the wastes are systemic so frankly it does not matter which product/project you choose to map. The wastes are waiting to be found!
  • Decide on the level of process you want to map: Unlike manufacturing which has one level of processes, PD has multiple layers of processes:
    • PD value stream –e.g. the end-to-end high-level “stage gate” process
    • Multi-functional – e.g. component design; engineering release; DV, PV, etc.
    • Single-function – e.g. durability test, finite element analysis, etc.
    • Process level – e.g. writing a test report

Each level will clearly surface opportunities for improvement. My advice is start with the higher level to understand the overall flow first and then dive deeper where needed to pinpoint the waste. This should help you to avoid getting lost in the details.

  • Engage the right people to do the mapping: Like product development, VSM is a team sport. Given the virtual nature of PD today you will not see all the waste by simply walking around the office. The people who are part of the process need be involved so they can surface the wastes/challenges they are facing. Otherwise, those wastes will remain hidden.
  • Walk the flow: Even though most work in PD goes on virtually over a long period of time, it is still important to go to the gemba to see the work environment and speak with people at their desks to get their unvarnished view of the current state.
  • Capturing times: In the factory we use stopwatches to measure time – in product development we use calendars. Given the long duration of times of tasks, it is impractical to capture real-time data like we do in the factory. It is best to use times based on the given product/project you have decided to map (see above) so at least you have a relatively consistent set of times. We don’t need data rounded to four decimal places; rather, we need data that is directionally correct to understand the current state. Don’t forget to distinguish between the time elapsed on the project (i.e. the time it is in the system) and the actual task time (time spent working on a particular task).
  • Positioning activities: As you follow the flow in PD you will quickly discover that not all activities are sequential as they are in manufacturing. In fact, many groups may be working, collaborating and integrating in parallel (or should be!). Be sure to not only capture what is happening and how long it took but also when it occurs. This may help you identify areas where you have unsynchronized concurrent waste and arrival variation and help identify opportunities to better front-load.
  • Spend time on the linkages: Many of the wastes you find in product development actually happen at the interfaces. Take the time at each step to understand what your downstream customer really needs and when they need it. Understand what inputs are necessary to each step in order to do the task. This will help you to better understand quality/maturity of the information flowing through the overall process.
  • Don’t forget the rework loops: Rework can at times be difficult to see when mapping product development processes. Some iterations may be discovery of knowledge while others are pure waste. Challenge the team to distinguish between the two. Finally, look carefully into each process box to see if rework is hidden within. Sometimes we label tasks with “refine,” “review,” or “reevaluate” – which on the surface may appear to be adding value, but in fact are code-words for “rework.” If the word starts with “re-” it is more often than not rework in disguise.

I hope this advice puts you in a better position to identify waste in your PD value streams. Keep it simple, ask questions when you have a doubt, and engage the people who do the work to do the mapping and the opportunities will come flowing out.