Root Cause Analysis for Project Delays: A Practical Method

Investigate project delays with a timeline, dependency checks and competing explanations. Learn how a bottleneck analysis tool supports the review.

Commandix task board with Planned, Active, Blocked and Done columns
Blocked and active tasksSample workspace: keep ownership and blocked reasons current so the review reflects real work.
On this page

To investigate the root cause of a project delay, reconstruct the work timeline, find the handoff where progress stopped and compare plausible explanations against the records. Then test a response and review what changed. A bottleneck analysis tool can organize the evidence, but a score or a late-task list does not prove causation.

Reconstruct what happened before asking why#

Define the missed milestone and the completion condition. List the unfinished dependencies and record when inputs arrived, work started, blockers appeared and decisions occurred. Check important dates with the people involved.

Separate facts from interpretations. “Approval was requested Tuesday and remained open Friday” is an observation. “The approval team is understaffed” is one possible explanation.

Compare four explanations#

Possible causeEvidence to seekResponse to test
Incomplete inputsReturned requests and clarification loopsReadiness checklist
Conflicting prioritiesReady work repeatedly interruptedShared queue order
Unclear authorityDecision passed between ownersNamed decision owner
Capacity shortageClean, prioritized demand exceeds accepted outputQualified capacity change

Several causes can coexist. State which one the proposed action addresses and which remain outside the test.

Worked example: a late technical approval#

In a hypothetical project, the team initially attributes a late approval to a busy specialist. The timeline shows that the request arrived on time but lacked acceptance criteria. After clarification, it was ready for only one day before the due date.

The evidence supports improving readiness and commitment planning before drawing a staffing conclusion. A follow-up test measures the wait after complete inputs arrive. That gives the next capacity discussion a stronger basis.

Commandix Constraints page showing queue depth, waiting time and affected work
Project bottleneck evidenceSample workspace: inspect the waiting work and supporting records before choosing a response.

Use a reversible test where possible#

  1. State the explanation and supporting records.
  2. Name the evidence that would contradict it.
  3. Choose one change within the sponsor’s authority.
  4. Save the baseline and observation period.
  5. Check the milestone and the local waiting measure.

Record other changes that could affect the result, such as different demand or staff availability. Before-and-after improvement can support a hypothesis without establishing that one action caused the whole difference.

Use software to expose evidence and gaps#

Commandix’s Constraints view presents a possible bottleneck, confidence and affected work. Its task and project records help inspect the underlying explanation. Use missing or stale records as a reason to narrow the conclusion, not to accept a more confident narrative.

Related guide: Data needed for a useful delay investigation.

Frequently asked questions#

Is the five-whys method enough?#

It can structure questions, but each answer still needs evidence. Otherwise the chain can turn an initial assumption into a convincing story.

What if the data cannot establish the cause?#

Document the strongest supported hypothesis and what information is missing. Choose a data-collection action or a limited test instead of claiming a proven root cause.

Review your project delay

Bring one late project to a 45-Minute Delay Review.

Map the work behind it, check the available evidence and define one action worth testing. If the records are insufficient, start with a data-readiness finding.
Review one delayed result
Back to all Commandix articles