Creating a Future State Value Stream Map

 

Lean.org VSM example

Last week I was talking to a colleague of mine preparing her for another first in her lean facilitation journey:  creating a future state Value Stream Map to start a second wave of improvements.  The team had done a VSM event in March and already made improvements, and now wanted to create a new future state VSM to drive new kaizens.

The process was a systems engineering process and covered roughly 70,000 engineering hours if I remember correctly, so it wasn’t a clean and simple map like the example above.  It has approximately 75 steps and many parallel paths and rework loops, even after the initial improvements.

Since we were on different continents at the time, I couldn’t there to support her in her event, so I created a basic outline that she found very helpful.  I do this for most tasks I undertake that require some thought and a specific outcome.  Even if you’re not familiar with VSM techniques, I encourage you to start outlining the work you do – you might find it makes it easier to break into smaller chunks, easier to get started, and then easier to see progress.  All of which should help you get more done with less effort as well as having less things partially completed.

Here’s the outline I shared, with some modifications to make it a little more generic.  She found it very helpful, and their future state map was a big step forward in eliminating parallel activities and moving closer to creating true flow in their engineering organization.

Future State VSM key points

• Lay out the team expectations at the beginning.
• Start with a quick review of current state.
• Work with the team to create a clear problem statement.  Make sure everyone agrees on the objective and what problem you’re trying to solve.  This might be very easy, but sometimes it’s not.
• Because you have such a large process, Select an area of the process to focus on to start with the Future State.  Ideally the area where the most rework is generated and/or the most effort is spent on a project.
  • Ask the following types of questions:
    • In places where we have parallel processes, what could we do to eliminate the parallel paths
      • IF not possible, how can we increase the frequency of verification between paths?
    • For process steps that are long duration, how could we break it into smaller steps to have people doing smaller chunks of work (smaller batches of hours) and incorporate verification earlier in the process?
      • How could we document a standard approach for each chunk of work?
    • How could we test and verify work in smaller increments?  Instead of waiting until everything is done (batch processing), could we test after every 80 hours of development?  Every month? (flow)
  • These types of leading questions should lead you to many more discussions, but the goal is to deliver designs faster and more accurately. And often the first response is “we can’t do that because….”
  • Whenever you hear “We can’t do that because…”, dig deeper.  Ask how it could be done; deepen the understanding of the collective team.  Focus on “We could do that if….”; these are the sources of significant improvements. 

• As you start getting a future state, or “to-be” process drafted, start asking “What improvements or changes do we need to make to get from where we are today to this future state?”  Those become kaizen bursts on your future state map, and form the basis of your action plan.
  • Be careful here.  Make sure you use  something that resembles the “5 why” approach.
    • For example –   SRS/Requirements Management should be an improvement that comes up during the discussion.
      • But saying “we have the new process so we do not need to worry about it anymore; we will apply the new process” is not the answer for this event.
        • You must define the specific steps that need to happen
        • Often asking “What would prevent this from succeeding or being applied properly?” helps you identify the actions.
        • So for RM – when they say – “we are applying the new RM process”, you ask, “What could prevent us from implementing RM?” or “What problems do we anticipate as we apply the new process?”
          • Then you develop actions to solve those problems or mitigate the risk
          • If they say there is no risk, no problems, expect it to be done in 30 days or less.
            • Then if there are problems, they will explain why it can’t be done in 30 days.
          • Don’t hesitate to use a fishbone/Ishikawa diagram if you identify challenging problems, but don’t spend hours on one topic; there’s enough other easy ideas or “low-hanging fruit” to deal with right now.
          • Once you have the improvement ideas, identify the amount of improvement it will give you.
            • Work in percentages of cycle time and rework hours.
            • It is easier to get it during the event, and someone is going to want to know the answer anyway.
  • Have Fun.  These second, third, and later visits to the same process are when the organization starts to transform.