PM.
Transport — Case study blueprint

UK Transport Performance

Line reliability, disruptions and time-of-day risk made easier to compare and act on.

APIPythonSQLPower BIDAX
Business problem

Live disruption feeds answer what is happening now, but service planners also need a consistent view of recurring problem routes and risk periods.

Objective

Blend current TfL status data with historical performance data to surface repeat issues, reliability gaps and customer-impact patterns.

Decision

Prioritise interventions where frequency and customer impact are both high.

01

Data source

Official line status, disruptions, routes and related transport data for London.

Visit Transport for London Unified API ↗
02

Data preparation

  • Collect line status and disruption records on a scheduled basis.
  • Deduplicate incident updates and classify planned versus unplanned events.
  • Join line, mode and time dimensions to historical performance files.
03

Data model

  • FactDisruption at incident-update grain
  • FactLinePerformance by reporting period
  • DimLine, DimMode, DimDate and DimSeverity
04

Analysis

  • Pareto analysis of disrupted routes
  • Time-of-day risk profiles
  • Trend comparison before and after major interventions
05

Dashboard

Embed-ready dashboard area

Designed for Power BI, Tableau, Looker Studio or Plotly.

The live report will sit here after publication. Until then, the portfolio keeps a clear, truthful build status.

Discuss the project ↗
06

Key questions & KPIs

  • Rank lines by both incident frequency and estimated customer impact.
  • Find the days and hours with repeat disruption patterns.
  • Distinguish planned engineering works from unplanned incidents.
Disruption countLost customer hoursService operatedReliability index
07

Business recommendations

  • Prioritise interventions where frequency and customer impact are both high.
  • Target passenger communications ahead of repeat high-risk windows.
  • Track whether reliability changes after operational interventions.
08

Limitations

  • Live status records can be updated repeatedly during the same incident.
  • Customer impact requires additional historical performance measures.
09

Next steps

  • Create the scheduled API snapshot process.
  • Add London Datastore performance measures.
  • Prototype a disruption-risk score.

From blueprint to published analysis.

Build the pipeline, validate the model, document the findings, then add the live dashboard and code.

Explore another project →