Onboarding in 27 days: the SaaS value stream

The map says this is a queueing and handoff problem, not a work problem.

• Flow efficiency is roughly 0.6%. Four hours of work inside a 27-day (approximately 216 working-hour) elapsed time. Even allowing for generous estimation, the process is >99% waiting. Optimising the work itself - making provisioning faster - would move the number almost not at all.
• The dominant wait reason is 'waiting for information' (62%). That is not capacity; that is unclear entry criteria and incomplete inputs. The contract is signed but the provisioning team does not have what it needs, and it discovers this after the handoff rather than before it.
• 9 handoffs × 3 gates means every customer waits behind nine queues in series. Total lead time is roughly the sum of queue times, so each handoff adds delay irrespective of how fast each team is.
• The constraint is the serial handoff structure plus the single-point-of-failure competence. Priya is a throughput constraint that also creates variance - two of five onboardings slipped, which is 40% of the sample.

Conclusion: the promise of 10 days is achievable in principle - the work takes 4 hours - but only by removing handoffs and gates, not by working faster.

This makes the problem worse on both axes: slower and not meaningfully safer.

• It adds two more queues. With 3 gates already contributing to a lead time of 27 days, two more approvers add at least two more wait states. Lead time rises; the 10-day promise moves further away.
• Approval is a weak risk control. An approver who sees a request days after it was raised, with no context, adds signature risk rather than reducing it. The risk in provisioning is misconfiguration, and approvers read forms, not infrastructure.
• The risk is real but misdiagnosed. The actual risk driver is that one person holds the knowledge and executes ad hoc. The control that addresses it is codified, reviewed, automated provisioning with peer review of the code.

Counter-proposal:

1. Replace the 3 gates with 1, placed where the risk actually is - a peer review of the Terraform change itself, not of the customer request.
2. Move validation to the front: a defined, machine-checkable 'ready for provisioning' checklist returned to sales at contract signature, eliminating most of the 62% waiting-for-information.
3. Automate provisioning so the work is repeatable and reviewable.
4. Re-measure: target 10 days, with flow efficiency as the diagnostic.

If the board insists on a control: make it a sampled post-hoc audit of completed onboardings, which adds a control without adding a queue.

Two distinct problems: resilience now, capability later.

1. Immediate resilience (0-3 months)

• Skills matrix across the provisioning team: for each capability, record who can do it, who can do it with support, and who cannot. Priya will be the only 'can do independently' entry for most rows - that is the finding.
• Pair on every onboarding until at least two other engineers can provision independently. Pairing is the only intervention that transfers tacit knowledge fast enough.
• Document the scripts to the standard of an outsider, then have the outsider execute them and fix what breaks. Documentation nobody has executed is fiction.
• Interim control: an escalation route to Priya's deputy with agreed hours, so leave is not a single point of failure.

2. Sustainable capability (3-12 months)

• Make the capability structural, not personal: provisioning as code in version control, with peer review. Then competence lives in the repository as well as in heads.
• Decide build vs buy explicitly - if provisioning is not differentiating, buy or adopt a mature tool rather than deepening bespoke knowledge.
• Team design: this work needs a small team with end-to-end ownership of onboarding, not a handoff node.

Measure: number of engineers who can provision independently (target ≥3), onboarding lead time, and slip rate due to knowledge availability.