A project-controls reporting model covering 800 activities across 24 monthly reporting snapshots, with WBS/packages, planned vs actual progress, forecast finish, float, milestones and resource-hour variance.
Every month a project team may report one overall progress percentage. That number is useful, but it can hide a problem. One work package can already be falling behind while stronger packages make the overall project still look acceptable. At the same time, activities can lose float, milestone dates can move and extra labour hours can be used without producing the expected improvement.
I wanted to see whether I could identify the part of a programme that was beginning to deteriorate before the final completion date visibly moved. Instead of only asking “How complete is the project?”, I wanted to answer: Which package is behind? How far behind? Is float being lost? Which milestones are moving? Are extra resource hours actually helping?
I built a project-controls reporting model with 800 programme activities observed across 24 monthly reporting cut-offs. Each activity carries its WBS/package, planned and actual progress, baseline and forecast dates, float, milestone information and resource hours. This lets me reproduce the type of monthly exception reporting a project manager or project-controls team would need.
Prepare and structure the activity and reporting-period data.
Group activities into packages, calculate latest-state results and compare reporting periods.
Create management KPIs and reporting measures.
Turn the calculations into package, milestone, float and resource exceptions that can be explored.
With the problem and data purpose clear, the next section shows the result first. The detailed steps below then show exactly how I got there.
The project-wide gap hides where recovery attention should start. The largest project-level gap across the 24 snapshots is 2.9 pp at 2025-08-31.
Yatify project-controls reporting model · 800 activities · 24 snapshotsDefined the WBS/package reporting structure and monthly schedule-snapshot model.
Built progress, float, milestone and resource exception calculations.
Created trend and latest-state reporting without destroying reporting history.
Validated row counts, keys, progress ranges, dates and reporting periods.
Project teams need to detect slippage before the final completion date visibly moves. The analytical problem is connecting schedule snapshots, progress, float, milestones and resource effort so management can see which packages are deteriorating and why.
The reporting model contains 19,200 activity-snapshot rows: 800 programme activities observed at 24 monthly reporting dates. One row is not “one project”. It is the state of one activity at one reporting cut-off.
activity_idpackageWBSsnapshot_datebaseline_finishforecast_finishplanned_progress_pctactual_progress_pcttotal_float_daysplanned_hours_to_dateactual_hours_to_dateRoads South at the 31 Dec 2025 reporting cut-off contributes to the package result using its activities’ planned progress, actual progress, float, milestones and resource hours. The package is not judged from one activity or one percentage.
Actual progress − Planned progressRoads South: 64.9% − 68.7% = −3.8 percentage points.
Meaning: this package is further behind its plan than any other package in the 31 Dec 2025 snapshot.Actual hours − Planned hours513,031.5 h − 494,713.3 h = +18,318.2 h (+3.7%).
Meaning: resource consumption is above plan while progress is below plan, so I would investigate productivity and where the extra hours are being consumed.Forecast finish − Baseline finish: → = + days.
Meaning: the activity requires a logic/constraint/recovery review; it cannot be hidden inside the project-wide percentage.At risk = Total float ≤ 5 daysactivities are at 5 days float or less, including with negative float.
Meaning: I would rank the negative-float activities by package and milestone impact rather than reviewing all 800 activities equally.The headline chart gives the decision signal. These additional views show whether the same conclusion survives when the data is sliced another way.
The project is below plan, but the project-wide gap alone is not enough to explain the problem.
This is the first package I would open in the drill-down because it has the largest progress variance at the reference snapshot.
The issue is distributed across activity logic and milestones, so I would not describe it as a single late activity.
I would not claim the whole project completion date is late. The evidence supports internal package/milestone risk that needs recovery before it reaches the final completion date.
All schedule and resource records are synthetic. No cost, tender rate or confidential project value is included.
Every interactive chart above already has a CSV button for its exact plotted numbers. These files are the deeper audit trail: source extract, model, SQL/DAX and validation.