Meridian Logistics: Eighteen Steps to a Usable Environment
A platform engineering group at Meridian Logistics has mapped the value stream from 'developer requests a standard environment' to 'environment usable'. The map has 18 steps, 6 handoffs and 3 approval gates. Lead time averages 19 working days; hands-on work totals 4.5 hours. The security gate approves 96% of requests and the architecture gate 94%; the change manager estimates 40% of requests bounce back because the requester omitted subnet or data-classification details and must re-enter the stream. The team's first instinct is to buy a workflow tool and digitise the three approval forms to save an estimated two days. The service owner's sponsor wants a 50% lead-time cut within one quarter and has offered two engineers. Two adjacent streams, database provisioning and access requests, share the same architecture gate.
1. Where should the team focus first? Show the arithmetic and justify whether automating the approval forms is the right first move.
Read the worked answer
Arithmetic first. Flow efficiency is roughly 0.6 days of touch time against 19 days of lead time, about 3%. Waiting, batching and rework account for the other 97%.
Digitising three approval forms saves an estimated two days: 2/19, about a 10% cut. Even if accurate, it accelerates a step that is not the constraint and leaves the queues intact.
Rework is the larger lever. Forty percent of requests re-enter the stream. If a rework loop costs even eight days of re-queueing through intake and gates, the expected penalty across all requests is 0.4 x 8 = 3.2 days, larger than the automation prize, and it repeats. Combine that with approvals that approve 94-96% of what they see: a gate with a 96% pass rate is not discriminating risk, it is batching and adding delay, and the 6% it rejects are interacting with a backlog that also serves two other value streams.
Recommendation. Sequence: (1) eliminate the rework cause in intake, (2) shrink or delegate the architecture gate, (3) only then automate. State the order explicitly to the sponsor: automating approvals first is textbook local optimisation, because the tool would make a non-constraint faster and hard-code the current step sequence into software that is expensive to change later. The 50% target is achievable, but only by the first two moves; automation alone gives 10%.
2. Design the intake change that removes the rework without simply adding mandatory fields and more validation. What would you do with the shared architecture gate?
Read the worked answer
Intake redesign, driven by evidence. Sample 20 bounced requests and count the missing fields. Most rework concentrates in a few attributes, typically subnet and data classification. If that holds:
- Derive those values by default from the requesting team's registered service profile rather than asking a human to retype them.
- Make the catalogue render only valid combinations, so an invalid request cannot be submitted; the rework disappears rather than being filtered.
- Remove free-text fields that exist only to justify a decision nobody reads (94-96% approval rates suggest this).
- Keep a fast exception path with a named owner.
This converts rework into prevention. Adding mandatory fields moves effort to the requester and inflates cycle time at intake, which is why it is the wrong answer.
The shared architecture gate must not be optimised at the expense of the other streams. It is a shared service with one queue and three customers, so:
- Make its queue visible as a single board with age and class of service, and measure gate cycle time as its own service metric.
- Delegate low-risk approval decisions to the requesting team under policy-as-code, with sampling audit, keeping the gate for genuinely novel or high-blast-radius designs.
- Set a service expectation for gate turnaround and review it jointly with the database and access stream owners.
If Meridian shortens only its own stream by pushing work into a shared queue, the portfolio lead time will not move and the credibility of the whole mapping exercise will be lost.
3. What measurement and governance would you put in place to demonstrate a 50% cut, and what would you refuse to accept as proof?
Read the worked answer
Baseline before changing anything. Record p50 and p85 lead time, flow efficiency, rework rate, gate queue time per stream, and throughput. Target a 50% cut on p50, roughly 19 to 9.5 days, and require p85 to fall at least as much; if p85 does not improve, the team has sped up easy cases only.
Cadence and display. A weekly lead-time run chart with annotations for each change made, so cause and effect are visible and the sponsor sees a trend rather than a single before/after claim. Monthly value stream review with the platform, security and architecture owners present, walking the current-state map against the updated data.
Guardrails. Change failure rate, security exceptions granted, and incident volume attributable to provisioning must not rise; a lead-time win that raises failures is a transfer of cost to production. Also watch the adjacent streams' queue times, since the shared gate can be starved by our improvement.
Refuse as proof: tool adoption metrics, the number of steps removed (removing a non-bottleneck step changes nothing), stories completed, and any comparison based on self-reported elapsed time. I would also refuse to declare victory from a single month of data, because a batch that happens to clear can produce a flattering dip that reverses; the run chart over 8-12 weeks is the honest evidence.