What to Do After Value Stream Mapping

After value stream mapping, write a named owner beside the future-state map's main service measure before scheduling the changes.

A mapping workshop can end with clear changes while leaving routine follow-up undecided. The team knows which delays to remove. It still needs to decide who will check actual performance when normal work resumes.

Value stream mapping records how work and information move through a process, then describes a future flow intended to improve delivery.

The future-state map makes process changes specific

Value stream mapping helps a team understand how work reaches its customer. It connects processing steps with the information that tells people what to do. A current-state map records the existing flow. A future-state map shows how the team intends that flow to change. Before mapping more detail, a SIPOC boundary check tests whether the named output lets the receiving customer complete their next task.

The Lean Enterprise Institute's account of value stream mapping explains why that whole-process view matters. Teams can see how the steps connect instead of improving each department separately. A quicker local task has little value if the next department receives work it cannot handle.

Timing makes the discussion specific. Keep processing time separate from the time a request spends waiting. Reducing the work inside a process box may leave the customer's wait unchanged. Conversely, changing how work is released may shorten delivery without making an individual task faster.

The useful result is a proposed change to the whole flow, with a clear reason for expecting better service. Keep that reason beside the change. It should explain which delay disappears or which handoff becomes reliable. That makes the map useful within strategic problem solving, where improving an activity must serve the intended outcome.

The usual next step is an implementation plan. ASQ's value stream mapping guidance includes a project leader and the resources needed to reach the future state. That is sound advice. A future-state drawing cannot change a work queue by itself.

Use the map to choose the first change rather than launching every improvement at once. The checkpoint after a kaizen event is relevant here: completing the workshop leaves implementation decisions to make. Confirm that the proposed change addresses the delay observed in actual work.

Before assigning delivery dates, define how the team will recognise an improvement in the customer's experience. That gives the implementation plan a result to test.

The future-state map needs a service measure and an owner who will respond when the result changes. Start the Walk →

Will the faster process hold under normal demand?

A future-state map contains expectations about work that has not yet happened. The team may expect complete requests to arrive at a steady rate. It may expect an approver to be available when needed. Those expectations affect whether the shorter wait shown on the map is achievable.

Check the expectations against the conditions the service actually faces. A pilot with extra staff may establish that the redesigned sequence works. It does not establish that the regular team can handle the normal workload. Record the staffing condition rather than treating the pilot's result as an unconditional promise.

The distinction is recognised within lean practice. In his discussion of product development mapping, John Drogosz describes the future state as a hypothesis tested through implementation. The map gives direction. The team learns whether the proposed process works as it makes changes.

A lower target cycle time needs repeated evidence from actual work before it becomes a reliable operating expectation. That evidence must use a consistent definition. If the customer cares about submission-to-completion time, measure those endpoints. Do not replace that measure with the time staff spend actively processing the request. If the proposed improvement requires more capacity, the follow-up to a bottleneck analysis checks the next constraint before spending is approved.

Record open work as well as completed work. Completion times can look better when difficult requests remain in the queue. Check whether old requests are accumulating before concluding that the redesign has improved service. Record demand alongside the result so the owner can tell when the workload has changed.

This is an application of testing assumptions in a decision. Select the condition that would make the process fail to deliver its promised benefit. Then choose an observable sign that would reveal that condition early enough to respond.

The owner needs a reason to reopen the decision, not merely a date to present the latest chart. A missed service commitment may require action immediately. Less urgent deterioration may require a review of the trend. Agree which response applies before the first disappointing result arrives.

Denver Health measured its document workflow after the redesign

Denver Health provides a useful example of follow-through after value stream analysis. Its 2016 Patient Safety and Quality annual report, section 10.1, describes a 2015 analysis of policy, procedure and guideline creation and revision. The aim was to make that document process clearer and more efficient.

The report records changes made in 2016. The organisation introduced a standard committee approval process and added a formatting review at the start. A subcommittee reviewed documents. Follow-up with areas holding very overdue documents resulted in 11 documents being retired and nine becoming active.

The Policy Committee approved 210 workflows out of 495 during the year. The team also surveyed end users and approvers after the analysis. Its follow-up included easier access to documents and single sign-on for editing and approval.

Figure 10.1-1 reports weekly PolicyStat measures for overdue documents and documents in approval, with a goal line. These are measures of the operating document service. They extend the evidence beyond a completed analysis or a list of planned changes.

The documented lesson is that the analysis was followed by process changes, user feedback and recurring measures. The section does not report a measured cycle-time reduction. It should not be used to claim that a shorter turnaround target was achieved or that every improvement persisted.

That limit matters when reporting results from a redesign. Completed approvals tell the team that work moved. An overdue-work measure asks whether unresolved work remains. Both help the team question a simple success claim. Neither establishes the cause of an improvement without further evidence.

A team applying this approach should match its measures to its own promise. If the purpose is faster approval, it needs actual elapsed approval time. If the purpose is keeping documents current, overdue status matters directly. The gap-analysis checkpoint similarly asks whether closing the chosen gap produces the intended result.

Assign the measure and the response before rollout

Take the map's main improvement claim and give it an owner who can influence the whole process. The project leader may coordinate installation or training. Responsibility for checking routine service must continue after those tasks finish. The handover after a Six Sigma project likewise needs a process owner who can act when performance changes.

Write the measurement rule beside the owner's name. State when the clock starts and stops. Identify where the evidence comes from and when the owner will review it. Keep the definition consistent with the baseline so that a change in reporting cannot create an apparent improvement.

Then agree what would require a response. Use the service commitment or the assumption behind the redesign to choose the trigger. Avoid selecting a convenient percentage without explaining what it means for customers. The article on monitoring decisions explains why a measure should support a decision about continued action.

A trigger is complete only when someone knows what to do when it is reached. The response might be to examine delayed requests before extending the redesign. It might be to adjust capacity or revisit the release of work. Choose the response that addresses the threatened benefit.

Record those arrangements with the implementation decision. A concise Decision Record can connect the proposed improvement to the evidence needed for continuation. It should also show who can change the process if the evidence weakens.

This fits the Universal Decision-Making Method: decide what to monitor before committing to implementation. There is no need to redraw the entire map each week. Check the actual service and revisit the design when the conditions supporting it change.

The next useful addition to a finished value stream map is an owned test of its main improvement claim. Put that test into the rollout plan before the changes begin.

Grant Purdy is the co-author, with Roger Estall, of Deciding (2020), and the architect of the Universal Decision-Making Method.