1. Home
  2. Insights
  3. Root Cause Analysis for Project Delays
Schedule Insight

Root cause analysis for project delays

A late project does not improve by listing symptoms. It improves when the team identifies which causes actually drive slippage and why they keep recurring.

A movement in the completion forecast does not identify its cause. The late activity may not have been critical, while an earlier approval or design decision may have changed the sequence of work. Reliable analysis starts with a credible schedule and a documented chronology, then tests how each event affected the path driving completion.

Symptoms are not root causes

Labels such as “poor productivity” or “contractor delay” often describe an outcome. Why did productivity fall? Was the workface unavailable, the design incomplete, materials late, or resourcing below plan? A delay may have several layers: the direct event, a management condition that allowed it to continue, and a control weakness that failed to detect it.

The objective is not simply to allocate blame. It is to identify a cause that can be acted upon. If the proposed action does not reduce the chance of recurrence, the analysis probably has not reached the root.

Recurring causes behind project delay

  • An unrealistic baseline with weak logic, missing approvals, or unmodelled resource constraints.
  • Late design, approvals, or responses to requests for information on critical work.
  • Architectural, structural, and MEP conflicts discovered during construction.
  • Scope changes implemented without first assessing time and cost.
  • Long-lead procurement disconnected from design, submittal, and approval dates.
  • Insufficient labour or equipment, or productivity below the planned rate.
  • Unavailable workfaces, contractor interfaces, or out-of-sequence execution.
  • Slow decisions because reports show overall progress but not the critical action required.

Information needed for the analysis

Collect the approved baseline, native schedule updates, progress reports, minutes, correspondence, requests for information, approval and procurement logs, daily records, dated photographs, and change instructions. Each event should have an identifier, date, owner, affected work, and source record.

Before drawing conclusions, test schedule quality. Is the logic complete? Are there excessive date constraints? Are durations and calendars realistic? Is actual progress current? An unreliable schedule can produce a misleading critical path regardless of the sophistication of the software.

A practical root cause analysis method

  1. Fix the reference point: identify the approved baseline, scope, data date, and authorised changes.
  2. Measure variance: compare planned, actual, and forecast dates for each key milestone.
  3. Validate the critical path: identify the sequence driving completion in each relevant period, not only the latest update.
  4. Build an event register: connect decisions, changes, and delays to records and affected activities.
  5. Test causation: determine whether the event preceded the effect and examine alternative or concurrent causes.
  6. Use root-cause tools: apply repeated “why” questions or a cause-and-effect structure, testing every hypothesis against records.
  7. Measure impact: distinguish activity delay, milestone delay, and completion delay, and state the limits of the chosen method.
  8. Convert findings into action: assign an owner, date, resource, and leading indicator rather than a vague instruction to accelerate.

Management analysis versus dispute analysis

Management analysis prioritises forecast accuracy, recovery, and control. Analysis for a claim or dispute requires more formal documentation, examination of concurrency and responsibility, and preservation of original schedules and records. The data may come from the same systems, but the purpose and evidential discipline differ.

Building a workable recovery plan

Once the cause is known, test options on the critical path: resequencing, opening additional workfaces, adding a specific resource, accelerating an approval, or splitting a package. Each option should state expected time benefit, cost, risk, and decision owner. Adding labour without design, access, or materials may increase cost without recovering time.

A PMO control process should track critical milestones, constraints, decisions, closure owners, and forecast completion weekly. BIM coordination becomes relevant where delay is driven by design interfaces or workface readiness, while independent technical consulting can challenge acceleration options and their risk before a high-cost decision is approved.

Leading indicators that reduce recurrence

  • Changes in the critical and near-critical paths between updates.
  • Age of critical RFIs and submittals compared with required response dates.
  • Design, material, and access readiness before an activity starts.
  • Actual versus planned productivity and its recent trend.
  • Overdue decisions and the milestone or activity affected by each one.

Example: late delivery is not automatically late completion

Suppose an air-handling unit arrives ten days late. Before attributing ten days to completion, examine its required installation date, manufacturing and shipping, room readiness, power, controls and downstream testing. Float may absorb some impact, or the workfront may already be delayed for another reason. Adding or subtracting delays mechanically does not establish the actual effect.

MEP designers review proposed technical alternatives, while site supervision checks physical readiness and records. The schedule analyst traces downstream effects. Contractual entitlement to an extension remains a separate assessment.

Recovery planning and claim analysis answer different questions

A recovery plan defines how remaining work can be delivered with stated resources, constraints and cost. Claim analysis identifies events, effects, evidence and entitlement. Preserve the baseline and previous updates, and issue recovery plans under revision control. Do not replace the original dates to conceal variance. Check the quality and safety implications of overlapping work or acceleration before authorizing the plan.

Professional references

The GAO Schedule Assessment Guide presents practices for comprehensive, credible schedules, critical-path validation, and schedule risk analysis. The sample and contents of AACE Recommended Practice 29R-03, 2011 edition outline the scope of its forensic schedule analysis guidance; the linked file is not the full recommended practice. Method selection depends on the contract, records, and purpose.

Executive takeaway

Knowing that a project is late is not enough. A decision requires the activity that moved completion, the event that affected it, the evidence connecting the two, and an action capable of changing the forecast. That turns delay analysis from an archive into a recovery and accountability tool.

FROM TECHNICAL READING TO A CLEAR DECISION

Turn the engineering question into a defined scope.

Share the project stage, available documents, and the decision you need. Our team will identify the appropriate technical review and deliverables.

Discuss your requirement Explore our services