VSM Foundation study materials
VSM Foundation study resources

The 38-Day Map Built from Memory

VSM Foundation · Put your knowledge to work in context.

All case studies

The 38-Day Map Built from Memory

CarePath, a healthcare SaaS vendor, maps its 'patient intake' value stream in a two-hour workshop with nine people. The map shows 14 steps, 38 days elapsed from signed contract to patient data live, and 4 days of touch time. The largest waits are security review (12 days), environment provisioning (9 days), and waiting for product owner clarification (7 days). The security manager says reviews take two days, the environment team says provisioning is automated, and the product owner says clarifications are rare. The map was drawn from memory, with no timestamps and no sampling. The VP wants to publish the 38-day figure and launch a 'cut waste' campaign aimed at security and environment teams. A customer has threatened to leave over slow onboarding. Three of the 14 steps are rework loops discovered after the workshop.

1. How should the team validate the map before acting on the 38 days?

Read the worked answer

Do not publish the 38 days yet. Reconstruct the current state from system timestamps. Define the start event, for example contract signature recorded in the CRM, and the end event, for example first patient data loaded and verified. Take a stratified sample of 10 to 15 recent onboarding cases across product lines and customer sizes. Extract events from CRM, security review tickets, environment provisioning logs, deployment records, and support tickets. For each stage, separate queue entry, first active work, and exit. Capture rework loops, including the three discovered after the workshop. Interview the security manager, environment team, and product owner to explain the events, not to replace them. Label each stage with confidence: measured, reconstructed, or estimated. Publish a range and distribution, not a single average. If the security review tool shows a 12-day entry-to-exit but only 2 days of reviewer activity, the gap is queue time, not review effort. That distinction changes the countermeasure.

2. What can and cannot be concluded from 4 days of touch time against 38 days elapsed?

Read the worked answer

Four days of touch time inside 38 days elapsed implies flow efficiency of roughly 10.5%. That is a strong signal that waiting and handoffs dominate, so the first place to inspect is the queues. It does not prove that security or environment teams are inefficient. The 12-day security wait may be batch arrivals, incomplete submission packets, reviewer capacity, or a queue that includes customer response time. The 9-day environment wait may be a request queue in front of an automated provisioner. Some waiting is necessary, such as regulatory checks or customer availability. A two-hour workshop with no timestamps also cannot support a precise figure or generalization. Use the map to choose where to measure, then use data to size the queues. Segment by work type and customer size. The conclusion should be that the system has long queues and rework, and the next step is validated queue data, not a waste campaign aimed at two teams.

3. How should the VP handle the blame dynamic and choose the first experiment?

Read the worked answer

The VP should reframe the issue as a system problem. Start with a blameless review of the validated data, with security, environment, and product in the room. Ask what makes the work hard: do reviews arrive in large batches, are packets incomplete, are criteria unclear, is staffing matched to demand? For the product owner, ask how clarification requests are triggered and whether acceptance criteria are testable at handoff. Choose one experiment with a baseline and a target. For example, introduce a pre-submission checklist and small-batch security intake, then measure p85 security queue time and rework rate for six weeks. Or create self-service environment provisioning for one standard stack and measure request-to-ready time. Do not launch an org-wide 'cut waste' campaign before validation. Publish the experiment result, including if it fails. The customer escalation makes speed important, but acting on an unvalidated map risks blaming the wrong constraint.