Lead Time Calculator
Process AnalysisAnalyze end-to-end delivery times, optimize workflow efficiency, and track performance with comprehensive lead time metrics
Filters
Task Timeline Data
| Task | Category | Priority | Requested | Started | Completed | Deployed | Actions |
|---|---|---|---|---|---|---|---|
Category Performance
Understanding Lead Time Metrics
Time Components
- •Lead Time: Total time from request to delivery
- •Wait Time: Time before work starts
- •Cycle Time: Active work time
- •Deployment Time: Time from complete to production
Optimization Strategies
- •Reduce wait times through better prioritization
- •Streamline deployment with automation
- •Implement continuous integration/continuous delivery
- •Monitor and address bottlenecks proactively
What is Lead Time in Project Management?
Lead time is the total elapsed time from when a customer or stakeholder makes a request to when that request is fulfilled and delivered. It is the single most customer-centric metric in flow-based project management because it represents the actual waiting experience from the requester's perspective. While cycle time measures your team's execution speed, lead time measures your organization's responsiveness, and the gap between the two reveals how much time is lost to queuing, prioritization delays, and handoff overhead.
In the Kanban Method, lead time is one of the three primary flow metrics alongside throughput and work in progress (WIP). The PMBOK Guide addresses lead time within the Control Schedule process, where it serves as a leading indicator of delivery performance. Unlike earned value metrics that compare planned versus actual progress at a snapshot in time, lead time captures the end-to-end customer experience and is particularly valuable in adaptive life cycles where requirements emerge incrementally and stakeholder feedback loops are tight.
The decomposition of lead time into its constituent parts is where the real analytical power lies. Lead time equals wait time plus cycle time plus deployment time. In most knowledge-work organizations, wait time dominates, often consuming 70-85% of total lead time. This means that the most effective way to reduce lead time is usually not to work faster (which reduces cycle time) but to start work sooner (which reduces wait time). This insight, drawn from queueing theory, fundamentally changes how project managers should think about optimizing delivery speed.
Lead Time Formula Explained
Wait Time is the interval between when a request is submitted and when the team actively begins working on it. This includes time spent in the backlog, in prioritization discussions, and waiting for approvals or prerequisite tasks to complete.
Cycle Time is the active work period from when development begins to when the task meets its definition of done. This is where hands-on value creation happens: coding, testing, reviewing, and revising.
Deployment Time is the interval from when work is technically complete to when it is actually in the hands of users. This includes release preparation, staging environment validation, production deployment, and post-deployment verification.
Process Efficiency is calculated as Cycle Time divided by Lead Time, expressed as a percentage. An efficiency of 15% means only 15% of the total lead time is spent on actual value-adding work. Top-performing teams target 40% or higher.
Step-by-Step Guide to Reducing Lead Time
Capture timestamps at every stage transition: request date, start date, completion date, and deployment date. Without these four data points, you cannot decompose lead time or identify where delays are occurring.
Calculate the average wait time, cycle time, and deployment time across a representative sample of tasks. The component with the largest percentage of lead time is your highest-leverage improvement target.
Apply Little's Law to validate your system stability. If Average WIP divided by Average Throughput does not approximate your measured cycle time, your system may not be in steady state and forecasting will be unreliable.
Reduce wait time by implementing a pull-based prioritization system with explicit WIP limits. When teams stop starting new work and focus on finishing what is in progress, queue lengths shrink and items enter active work faster.
Set SLA targets based on percentile analysis rather than averages. Use the 85th percentile lead time as your standard service-level target: it accounts for variability while providing a realistic commitment that your team can meet consistently.
Real-World Example
Scenario: A product team tracking 4 feature requests
• User Authentication: Requested Jan 1, Started Jan 3, Completed Jan 10, Deployed Jan 12 (Lead Time: 11 days)
• UI Dashboard Redesign: Requested Jan 2, Started Jan 5, Completed Jan 15, Deployed Jan 16 (Lead Time: 14 days)
• API Performance Fix: Requested Jan 8, Started Jan 8, Completed Jan 11, Deployed Jan 12 (Lead Time: 4 days)
• Mobile App Testing: Requested Jan 5, Started Jan 10, Completed Jan 18, Deployed Jan 20 (Lead Time: 15 days)
• Average Lead Time: 11 days
• Average Wait Time: 2.75 days (25% of lead time)
• Average Cycle Time: 6.75 days (61% of lead time)
• Average Deployment Time: 1.5 days (14% of lead time)
• Process Efficiency: 61%
Result: Cycle time is the dominant component at 61% of lead time, suggesting the team should focus on improving development efficiency. The 85th percentile lead time is approximately 14 days, making this a reasonable SLA target. The API Performance Fix (same-day start) shows that urgent items can bypass the wait queue entirely.
Common Mistakes to Avoid
- Measuring only cycle time and calling it lead time — If you start your measurement when work begins rather than when the request is made, you are measuring cycle time, not lead time. Customers experience lead time, and that is what you should be tracking and communicating.
- Ignoring deployment time — Many teams stop the clock when code is merged but before it reaches production. Deployment time is real customer-facing delay and must be included in lead time calculations.
- Using mean instead of median — Lead time distributions are almost always right-skewed. The median (50th percentile) gives a more representative "typical" experience than the mean, which is pulled upward by outliers.
- Not tracking by work type — Bug fixes, features, and technical debt items have fundamentally different lead time profiles. Mixing them together produces meaningless averages that cannot guide improvement.
PMP Exam Tips
On the PMP exam, lead time appears in both predictive and adaptive scheduling contexts. In predictive scheduling, lead time has a specific definition: the amount of time a successor activity can advance with respect to a predecessor activity. For example, if you can begin writing test cases 5 days before development is complete, the lead time is 5 days. This is distinct from the Kanban definition (request-to-delivery), and the exam will provide context to clarify which meaning applies.
In Agile and Kanban scenarios, understand how Little's Law connects lead time, WIP, and throughput. The formula L = lambda * W (where L is average WIP, lambda is average throughput, and W is average lead time) may appear in quantitative questions. If the exam gives you two of these variables, you should be able to calculate the third. Also know that Little's Law requires a stable system: items should not be entering significantly faster or slower than they are exiting.
Be prepared for questions about how to improve lead time. The correct PMP answer typically involves reducing WIP (which reduces queue time and thus lead time) rather than adding resources (which introduces coordination overhead and Brook's Law effects). Understand that lead time reduction strategies differ depending on which component dominates: if wait time dominates, focus on prioritization and WIP limits; if cycle time dominates, focus on process improvement and automation; if deployment time dominates, focus on CI/CD pipeline optimization.