Value Stream Mapping a GCC Shared Services Handoff

Start with the Handoff, Not the Whole System

Shared services handoffs are where GCCs lose the most time and quality. A value stream map (VSM) of a handoff focuses on the exact flow of work from one GCC to another, not the entire enterprise. This keeps the map small, actionable, and focused on bottlenecks that actually affect delivery.

Identify the Handoff Triggers

Define what starts the handoff. Common triggers include:

• A completed development sprint ready for QA
• A production incident escalated to a support GCC
• A completed training module needing certification review

Each trigger defines the start point of your map. Write it down clearly. If you can't describe the trigger in one sentence, the handoff isn't well-defined.

Map the Flow of Work

Draw the handoff flow using standard VSM symbols:

• Process boxes for activities
• Queues for waiting
• Arrows for flow direction
• Time stamps for duration

Track each step from trigger to completion. Include both visible and hidden steps like email threads, Slack messages, and approval waits. If it takes time, it's in the map.

Capture Cycle Time and Wait Time

For each step, record:

• Cycle time: How long the work actually takes
• Wait time: How long it sits idle

Example:

• Development handoff to QA: 2 hours cycle, 18 hours wait
• QA review to production deployment: 4 hours cycle, 6 hours wait

The goal is to see where work piles up. High wait time relative to cycle time signals a bottleneck.

Identify Waste in the Handoff

Look for these common waste types:

• Overprocessing: Extra steps that don't add value
• Waiting: Work sitting in queues
• Defects: Rework due to unclear requirements
• Excess inventory: Work in progress that delays everything

Annotate your map with these labels. Example: "Queue at QA approval: 18 hours wait due to unclear acceptance criteria."

Apply Lean Six Sigma to Fix the Bottleneck

Once you identify the bottleneck, apply Lean Six Sigma methods:

• DMAIC to structure the improvement project
• Root cause analysis (5 Whys or Fishbone) to find why work waits
• Standard work to reduce variation
• Kanban to limit work in progress

Example: If QA approval waits 18 hours, root cause might be unclear acceptance criteria. Fix by creating a shared checklist. Redefine the process. Redo the VSM to measure improvement.

Validate with Metrics

After implementing changes, measure:

• Handoff cycle time
• Wait time reduction
• Defect rate
• Customer satisfaction

If metrics don't improve, revisit the map. The VSM is a living document. Update it as you improve.

Scale the Improvement

Once one handoff is optimized, replicate the VSM process for other handoffs. Create a library of standard handoff maps. Train GCC teams to maintain their own maps. This builds a culture of continuous improvement.

Remember: A VSM of a handoff isn't about drawing pretty charts. It's about exposing waste, fixing bottlenecks, and making shared services delivery faster and more reliable. Start small. Measure often. Scale what works.