Cycle time

Cycle time is the total time it takes to complete one unit of work from start to finish. In manufacturing, it is the time from when raw materials enter a production process to when a finished product exits. In software development, it is the time from when work begins on a task to when it is deployed to production. In service delivery, it is the time from when a customer request is picked up to when it is fulfilled.

Cycle time is distinct from lead time, which measures the total elapsed time from when a request is made to when it is delivered, including any waiting time in queues. A customer who submits an order that sits in a queue for 2 days before being processed in 1 day experiences a lead time of 3 days but the cycle time is 1 day. The difference between the two reveals how much time is spent waiting versus working.

Cycle time is also distinct from takt time, which is the rate at which products must be completed to meet customer demand. Takt time is calculated as available production time divided by customer demand. If a factory has 480 minutes of available time per day and must produce 240 units, the takt time is 2 minutes per unit. If the actual cycle time exceeds the takt time, the process cannot keep up with demand.

The power of cycle time as a metric lies in its universality and its direct connection to throughput, quality, and cost. Shorter cycle times mean faster delivery to customers, higher throughput from the same resources, and lower work-in-progress inventory. Longer cycle times mean slower delivery, lower throughput, and more capital tied up in unfinished work.

The relationship between these three metrics tells a powerful story. When lead time significantly exceeds cycle time, the gap is queue time: work items sitting idle waiting to be processed. This suggests a capacity constraint or a prioritisation problem. When cycle time exceeds takt time, the process cannot keep up with demand and backlogs will grow. When cycle time is well below takt time, there is excess capacity that could be redeployed or used to take on additional work.

In a metric tree, all three metrics can be tracked together. Lead time decomposes into queue time plus cycle time. Cycle time decomposes into the individual process steps. Takt time provides the target that cycle time must meet. This three-way comparison makes it clear whether the bottleneck is in the process itself (long cycle time), in the queue (long wait time), or in the demand-capacity balance (cycle time vs takt time).

Cycle time is the sum of time spent in each step of the process. A metric tree breaks the total into step-by-step durations and identifies the sources of delay within each step.

This decomposition reveals a critical insight: in most processes, the majority of cycle time is spent on non-value-adding activities. Studies across manufacturing and knowledge work consistently find that value-adding time accounts for only 5% to 30% of total cycle time. The rest is waiting, rework, setup, and transitions.

This finding has profound implications for improvement. Rather than trying to make value-adding steps faster (which is often difficult and expensive), the biggest gains come from eliminating or reducing non-value-adding time. Removing a handoff delay that adds half a day costs nothing but reduces cycle time by the same amount as a major process re-engineering effort.

The tree also makes the cost of rework visible. If 15% of cycle time is spent correcting defects found during testing, investing in upstream quality (better specifications, earlier testing, automated checks) will reduce cycle time while simultaneously improving quality. This is one of the few interventions that improves multiple metrics simultaneously.

1. 1

   Map the process and identify non-value-adding time

   Before optimising, understand where time is actually spent. Map each step of the process and classify time as value-adding, necessary but non-value-adding (regulatory, safety), or pure waste (waiting, rework). Focus reduction efforts on the waste categories first, as they offer the easiest and largest gains.

2. 2

   Eliminate handoff delays and approval queues

   Every handoff between teams or individuals introduces a delay while the next person finds time to pick up the work. Reduce the number of handoffs by broadening individual or team scope, co-locating dependent teams, or automating approvals that do not require human judgement.

3. 3

   Reduce batch sizes

   Larger batches increase cycle time because each item must wait for the entire batch to complete before moving to the next step. Smaller batches flow through the process faster, reduce work-in-progress, and surface quality issues sooner. This principle applies equally to manufacturing lots and software deployment batches.

4. 4

   Invest in quality at the source

   Defects detected late in the process cause rework loops that dramatically increase cycle time. Build quality into earlier stages through clearer specifications, automated testing, peer review, and mistake-proofing. Prevention is always faster than correction.

5. 5

   Limit work in progress (WIP)

   Counter-intuitively, starting fewer items simultaneously reduces cycle time for each item. When people and systems juggle too many tasks, context switching adds overhead and nothing finishes quickly. WIP limits force the team to complete current work before starting new work, which accelerates flow and reduces cycle time.

Cycle time reduction has a cascade of positive effects on business outcomes. Faster cycle times mean faster delivery to customers, which improves satisfaction and competitiveness. They mean higher throughput from the same resources, which improves capital efficiency. They mean less work-in-progress inventory, which frees working capital. And they mean faster feedback loops, which accelerates learning and improvement.

In software development, cycle time is directly linked to competitive advantage. Teams that can go from idea to production in days rather than weeks can respond to customer feedback faster, fix bugs sooner, and iterate on features more rapidly. This speed compounds over time: faster teams learn faster, and learning is the ultimate competitive advantage.

In manufacturing and operations, cycle time reduction improves responsiveness to demand changes. A factory with a 2-day cycle time can respond to a demand spike far more quickly than one with a 2-week cycle time. This responsiveness reduces the need for forecast accuracy and safety stock, further improving capital efficiency.

KPI Tree lets you model cycle time as a step-by-step metric tree that connects process duration to its value-adding and non-value-adding components. Each process step becomes a node with its own timing data, revealing exactly where work items spend the most time.

The tree can be segmented by product type, work item category, team, and priority level to identify whether cycle time patterns are uniform or concentrated in specific workflows. Connecting cycle time to throughput, quality, and customer satisfaction provides a complete picture of process performance and ensures that speed improvements do not come at the expense of quality or reliability.

Each step can be owned by the team responsible for that stage of the process. When cycle time increases, the tree shows which step slowed down and which team should investigate, enabling targeted improvement rather than across-the-board pressure to "go faster."