Lead time (LT) is the elapsed time from when work becomes available to a process step until its completed output becomes available to the next step. It includes waiting and interruptions, not just time spent working. In an API design-review process, requests can wait for a scheduled review, return for amendments, and wait again for approval. Those delays matter even when the review itself is brief. section 2.4 section 1.1
To make lead time useful in a process investigation:
- Observe the work firsthand and gather verified timing data rather than relying only on a high-level account of the delay. section 2.4
- Record LT for each process step alongside TT and %CA. Count the work items awaiting each step; Jira tickets can provide the queue count in an API-review workflow. section 2.4.3
- Use a time ladder to show each step’s LT and TT and their process totals. Keep the waiting work visible so the map points to possible waste. section 2.4.3
Figure 2.7 Completed Current Conditions and Problem Statement section, showing the process map with metrics
The completed current-conditions process map places performance metrics alongside process steps, making step and total times available for examining delays. section 2.4.3
Set a measurable review target
If total API design-review LT is 16 days, a 20% reduction sets a target of 12.8 days. Put that target in the A3 goal statement, then compare it with the measured LT after improvements. The goal states what success means; it is not itself a proposed solution. section 2.5
A shorter review meeting alone does not establish a shorter lead time: the queue and the rest of the process still count. Use the measured baseline and target to judge whether a change improves the flow of API work. section 2.4 section 2.5
