Project On-Time Delivery Rate

Goal of the analysis:

Measure how reliably projects and/or key milestones are delivered by the committed dates, and identify the drivers of schedule slippage. On-Time Delivery Rate is a core indicator of IT delivery health that influences stakeholder confidence, value realization, and portfolio cost. Executives use it to balance ambition with feasibility, allocate resources effectively, and manage risk. A high on-time rate—without sacrificing scope and quality—signals disciplined planning, dependency management, and execution. Conversely, chronic misses indicate systemic issues (overcommitment, bottlenecks, vendor performance) that jeopardize strategic outcomes.

Data required:

• Project and milestone plan data:
  • Project ID/name, program/portfolio, business owner, project manager, methodology (Agile/Waterfall/Hybrid), criticality/priority, complexity score.
  • Baseline and committed dates: project start/finish, stage gates, PI objectives, key milestones with baseline versions and approval dates.
  • Change requests and rebaselines: date, reason, impact on schedule, approvals.
• Actuals and acceptance data:
  • Actual completion dates for milestones and final delivery; acceptance/sign-off dates and criteria (definition of done, go-live verification).
  • Scope delivered vs planned for the milestone (features/stories, deliverable checklist).
• Execution and flow metrics (leading indicators):
  • Sprint/iteration commitments vs completed, throughput, velocity, burn-down/burn-up.
  • Task cycle time, flow efficiency, WIP, blocker time.
  • Earned Value Management (if used): PV, EV, AC, SPI, CPI.
• Resource, dependency, and vendor data:
  • Team capacity (FTEs, skills), allocation, holidays/time-off calendars.
  • Dependency register (internal/external), environment readiness, change freeze windows.
  • Vendor SOWs, deliverable due dates, SLA/OLA performance.
• Risk and issue logs:
  • Open risks with probability/impact, mitigation plans, risk burndown.
  • Issues/impediments, root cause tags (requirements churn, approvals delay, environment instability, security/compliance, vendor slippage).
• Systems/tools:
  • PPM tools (ServiceNow PPM, Clarity, Planview, MS Project/Project Online, Smartsheet).
  • Work management (Jira/Azure DevOps), CI/CD calendars (for release-dependent milestones).

Detailed step-by-step instruction on how to conduct the analysis:

1. Define scope and unit of analysis:
   • Choose milestone-level (recommended for comparability) and/or project-level delivery. Define “committed date” (latest approved baseline) and a standard grace window (e.g., 0–3 business days).
   • Define inclusion/exclusion rules: exclude canceled projects, defer those without fixed dates, treat rebaselines approved within X days of due date as misses unless justified.
2. Extract data from source systems:
   • From PPM: baselines, milestones, rebaseline history, approvals.
   • From work tools: completion/acceptance dates, scope delivered, sprint/PI plans.
   • From vendor/contract repositories: committed vendor deliverable dates and actuals.
3. Normalize and clean:
   • Standardize time zones and business calendars; map milestones to projects/programs and owners.
   • Deduplicate milestones and ensure a single authoritative committed date per milestone (use latest approved baseline version).
4. Calculate core metrics:
   • Mark milestone as on-time if ActualCompletionDate ≤ CommittedDate + GraceWindow and acceptance criteria met.
   • On-Time Delivery Rate (milestone-level) = (# milestones delivered on time in period) / (total milestones delivered in period) × 100%.
   • Project-level variant: count a project on-time if all critical path milestones and final delivery met their committed dates.
   • Schedule variance (days) = CommittedDate − ActualCompletionDate (positive = early/on-time, negative = late). Report mean/median and distribution.
   • Weighted on-time rate (optional) using weights such as budget, business value, or criticality.
5. Segment and compare:
   • By portfolio/program, business unit, product/service, project type (run/grow/transform), methodology, complexity/size, vendor-involved vs in-house, geography.
   • By milestone type (requirements complete, design, build complete, UAT, go-live) or PI objectives for Agile programs.
6. Trend and control:
   • Plot monthly on-time rate and 3-month rolling average; show count of delivered milestones for volume context.
   • Use control charts on schedule variance (days) to detect special-cause variation.
7. Root-cause analysis:
   • Tag each late milestone with primary cause from issue logs; build a Pareto of causes (e.g., dependencies, resource constraints, scope change, environment, approvals).
   • Correlate lateness with leading indicators: low SPI (<1), high WIP, low velocity predictability, high blocker time, high change request count close to due date.
8. Forecast risk to future milestones:
   • Use historical predictability (commit vs complete), velocity trends, and Monte Carlo schedule simulations to estimate probability of hitting upcoming dates (P50/P80).
   • Flag milestones with ≤P80 below threshold (e.g., <70% likelihood) for corrective action.
9. Validate with delivery leaders:
   • Review contested rebaselines, exceptions, and attribution with PMO, product, and engineering leads to ensure fairness and consistency.
10. Institutionalize:
    • Publish a standing dashboard; automate data refresh; define target thresholds and trigger playbooks (e.g., escalation when program on-time <80% for two consecutive months).

Format of the output of analysis:

• Executive summary slide: current on-time rate, variance trend, top 3 delay drivers, at-risk milestones.
• Time series charts: monthly on-time rate with delivered milestone volume; rolling average.
• Distribution of schedule variance (histogram/box plot) and control chart for variance.
• Heat map by portfolio/program/owner showing on-time rate and volume; bubble chart weighted by budget/value.
• Pareto of delay causes; waterfall showing cumulative days late by cause.
• Milestone tracker table: committed vs actual date, variance (days), cause tag, scope delivered, owner, vendor involvement.
• Forecast view: probability to hit next 90 days of key dates (P50/P80), with confidence bands.

How to interpret results:

• High on-time rate (with stable scope and acceptable quality) indicates realistic planning, controlled WIP, and effective dependency/vendor management.
• Low on-time rate suggests systemic overcommitment, estimation inaccuracies, hidden dependencies, or resource/contention issues.
• Large negative variance tails (many milestones significantly late) point to governance or risk management gaps; small negative variance but frequent indicates planning hygiene issues.
• Segment differences are diagnostic: vendor-heavy work often lags; complex cross-platform releases have lower predictability than team-contained enhancements.
• Trade-offs matter: very high on-time with declining scope or quality indicates date gaming; review scope change rate and defect leakage alongside schedule metrics.
• Trends: improving on-time rate and narrowing variance distribution is positive; volatility suggests date churn or unmanaged dependencies.

Steps a company can take to improve on this measure:

• Planning and estimation:
  • Adopt P50/P80 scheduling with explicit buffers; set executive commitments at P80 for critical deliverables.
  • Use historical throughput/velocity for forecasting; break work into smaller, independently testable increments.
  • Apply Monte Carlo simulations and critical path analysis; keep plans current with rolling-wave planning.
• Execution discipline:
  • Limit WIP; enforce clear Definition of Ready/Done; protect team capacity from unplanned work.
  • Introduce cadence-based release trains and dependency boards; timebox decision/approval SLAs.
  • Strengthen environment readiness and release orchestration; avoid change freezes colliding with critical dates.
• Governance and change control:
  • Standardize rebaseline criteria; prevent last-minute rebaselines from masking misses.
  • Establish milestone health reviews 6–8 weeks before due dates; trigger corrective actions (scope trade, resource infusion, de-risking).
  • Tie incentives to predictability (meeting P80) rather than aggressive P10 dates.
• Resource and vendor management:
  • Capacity plan by skill; reduce multitasking by dedicating teams to value streams.
  • Set vendor SLAs with milestone adherence KPIs and earned incentives/penalties; integrate vendor deliverables into dependency boards.
• Data, tooling, and transparency:
  • Integrate PPM with work-management tools to keep committed/actual dates in sync; automate milestone status.
  • Instrument leading indicators (SPI, velocity predictability, blocker time) and alert on early drift.
  • Run blameless retrospectives on late milestones and codify learnings into estimation checklists.
• Targeted actions by signal:
  • If dependency-related delays dominate: add a dedicated dependency owner, implement program boards, and rehearse end-to-end cutovers.
  • If estimation error is high: use reference-class forecasting and parametric models; require historical analogs with each estimate.
  • If vendor slippage is frequent: add stage-gate quality checks, earlier acceptance testing, and dual-sourcing for critical items.

Benchmark comparisons:

General benchmarks:

• Typical enterprise portfolios show 60–85% milestone on-time rates; high-performing organizations sustain 85–95% with stable scope and quality.
• Schedule variance medians of ±3–7 business days are common; top performers keep 80% of milestones within ±5 business days.

Segment- or industry-specific benchmarks:

• Small enhancements/platform teams with few dependencies: 85–95% on-time is achievable; median variance within ±3 days.
• Large, multi-team transformation programs: 70–85% on-time; variance tails longer due to integration and change management.
• Highly regulated or vendor-heavy projects: 70–80% on-time unless mitigated with strong contract and dependency management.

If external benchmarks are insufficient, construct internal benchmarks by comparing on-time rates across portfolios and teams over 4–8 quarters, set targets at internal top quartile (by project type/complexity), and track both on-time percentage and variance dispersion to drive continuous improvement.