How to Measure Project Lead Time Without Manual Reports

Measure lead time from a defined request event to a defined completion event using recorded timestamps. Measure cycle time from active start to completion. A work system can calculate these from task history, reducing spreadsheet reconstruction, but the results remain dependent on accurate status changes and a consistent definition of finished work.

Define the start and finish events#

For a task, lead time often means completion timestamp minus creation timestamp. Cycle time usually means completion timestamp minus the first active-start timestamp. State whether you use elapsed calendar time or business time.

For a whole project, choose project-level boundaries such as accepted request and customer acceptance. Do not call the average lead time of its tasks the project’s lead time. Parallel tasks and different creation dates make those measures different.

Worked calculation#

In this hypothetical example, a task is created Monday at 09:00, starts Wednesday at 09:00 and finishes Friday at 09:00. Its elapsed lead time is 96 hours and its elapsed cycle time is 48 hours. The first 48 hours occurred before active work started.

If the task waits for approval after Wednesday, that waiting is still part of elapsed cycle time. Cycle time is not a timesheet of hands-on effort. Use status history to investigate where the elapsed time went.

Collect the history once, then reuse it#

1. Agree status definitions and when owners update them.
2. Record creation, active-start and completion events.
3. Keep blocked reasons and predecessor dependencies.
4. Choose how to handle reopened and cancelled items.
5. Check a sample against the actual work.
6. Review the same scope and time window each period.

Imported tasks may have current status without all earlier transitions. Label the coverage gap and build a reliable observation period before treating historical averages as representative.

Compare similar work and include unfinished items#

Separate short operational requests from complex project deliverables. Review the distribution or individual cases alongside an average, especially with small samples. State how many completed items are included.

Inspect aging unfinished work too. Completed-item metrics exclude the tasks that have not escaped the queue yet. A lower average can coexist with a critical dependency that is still getting older.

Measure task movement in Commandix#

The Flow Analytics view includes task lead time, cycle time and aging work. The underlying records need status history. Use the chart to identify a question, inspect the relevant tasks, then compare the same measure after a change. For an end-to-end project promise, retain the separate project acceptance dates.

Related guide: Read a cumulative flow diagram for growing queues.

Frequently asked questions#