Every large project generates two stories. There is the story people tell in meetings — "we're broadly on track, a few pressures on the façade package" — and there is the story the data tells, if anyone assembles it. Project controls is the discipline of making sure the second story exists, is accurate, and reaches decision-makers while there is still time to act on it.
It is one of the least glamorous and most consequential functions on a project. Projects with strong controls still hit problems — but they see them early, size them honestly, and respond deliberately. Projects without controls discover their problems at milestones, when the cheap options have already expired.
Definition and scope
Project controls is the set of processes for planning, measuring, forecasting, and correcting project performance — primarily across time and cost. In practice it spans six areas:
- Planning and scheduling. Building the work breakdown structure, dependency network, and baseline schedule; computing the critical path; keeping the schedule a living model rather than a wall poster. (How this is changing is the subject of our CPM vs AI scheduling piece.)
- Progress measurement. Systematically capturing what has actually been done — quantities installed, percent complete, milestones achieved — at a frequency and granularity that supports honest forecasting. On site, this is the daily progress report.
- Cost control. Budgeting, commitment tracking, actuals, and forecast-at-completion — keeping the money story synchronized with the schedule story, because a project can be "on time" while burning contingency at a fatal rate.
- Risk management. Identifying what could push the project off plan, quantifying it where possible, and tracking mitigation actions with the same rigour as construction activities.
- Reporting. Turning the data into decisions: status reports, variance analyses, trend charts, and forecasts, delivered on a cadence stakeholders can rely on.
- Change management. Controlling scope: logging every change, assessing its time and cost impact against the current baseline, and re-baselining deliberately instead of letting the plan drift informally.
Project controls vs project management
The two terms get used interchangeably, but the distinction is useful. Project management decides; project controls informs the decision. The project manager owns outcomes — negotiating with subcontractors, resolving conflicts, choosing mitigations, managing the client. Project controls owns the instruments: the schedule, the progress data, the forecasts, the variance analysis.
A helpful analogy is the cockpit. The project manager flies the aircraft; project controls builds and maintains the instrument panel. A skilled pilot with no instruments can fly by feel in clear weather — which is roughly how small projects survive without formal controls. But as size, duration, and complexity grow, weather closes in, and flying by feel becomes how projects end up months late without anyone being able to say when the lateness started.
On large programmes, controls is a dedicated team. On smaller ones, it is a hat the PM or a planner wears. Either way, the function is the same: keep an accurate, current, quantified picture of where the project is and where it is heading.
The cadence of good controls
Project controls is not a document set; it is a rhythm. Mature teams run three interlocking loops:
Daily: capture reality
Progress, manpower, blockers, and issues flow in from the work face every day — ideally straight into the scheduling system, as described in our DPR template and best practices guide. The daily loop is short and unceremonious: what happened, what's blocked, who needs to act today. Issues raised here are hours old, not weeks old, which is precisely what makes them cheap to resolve.
Weekly: re-forecast and steer
Each week, the accumulated actuals update the forecast: which activities are trending late, where float is eroding, which risks have grown teeth. The weekly loop is where mitigation decisions get made — resequencing, resourcing, escalation — while the monthly report is still four steering opportunities away.
Monthly: baseline and account
Monthly, the project formally measures itself against the baseline: schedule variance, cost performance, change register, re-baselining where authorized. This is the contractual and executive layer — the one most organizations already have. The failure mode is running only this loop, which turns controls into monthly archaeology.
If your only control loop is monthly, your fastest possible reaction time to any problem is a month. Most schedule disasters are just small problems that got a month older, twelve times.
KPIs that actually matter
Controls teams can drown in metrics. A short list, watched consistently, beats a dashboard nobody reads:
- Schedule health (SPI-style). Earned progress against planned progress, whether expressed as a classic schedule performance index or a simpler percent-complete-vs-planned measure. The absolute number matters less than the trend — a project drifting from 0.98 to 0.91 over six weeks is telling you something no status meeting will.
- Critical-path stability. How often the critical path changes and how much total float the near-critical paths are losing. A stable path with healthy float is a controllable project; a churning path with evaporating float is a project living on luck.
- Issue aging. The age profile of open issues and unanswered requests, especially those attached to critical or near-critical activities. Aging issues are the leading edge of future delay — the mechanics are covered in how AI predicts construction delays.
- Forecast reliability. When your team forecast a finish date last month, how right were they? Tracking forecast error over time is the most underused KPI in the discipline: it tells you how much to trust every other number, and it improves reporting behaviour all by itself.
- Reporting latency. The lag between something happening on site and it appearing in the controls data. If the answer is "days," your other KPIs are describing the past.
How modern software automates the discipline
Historically, the limiting factor in project controls wasn't knowledge — the methods have been documented for decades — it was labour. Collecting progress, updating networks, chasing issue owners, and assembling reports consumed so many hours that most teams could only afford the monthly loop. Modern project controls software changes the economics of each loop:
- Capture is built into the work. Site engineers update tasks and raise issues from the work face in the same tool that holds the schedule, so the daily loop stops depending on transcription.
- Forecasting is continuous. With progress flowing in daily, the schedule re-forecasts itself; the weekly loop starts from a current picture instead of spending its first hours reconstructing one.
- Escalation is automatic. Issues carry priority and severity, and unanswered requests escalate on rules you configure — the chasing that used to consume controls staff simply runs in the background.
- Prediction augments measurement. AI trend analysis over progress rates, issue aging, and float erosion surfaces problems before they register as variance — moving controls from detecting slippage to anticipating it.
- Reports assemble themselves. Status summaries, risk narratives, and variance explanations are generated from live schedule data and reviewed by humans, rather than built by hand from stale exports.
None of this removes the need for judgment — deciding what a variance means and what to do about it remains a human craft. What the software removes is the clerical burden that kept that craft starved of current data. That is the design philosophy behind Gantivity: one system where the schedule, the daily progress, the issues, and the reports are the same living dataset, so the discipline of project controls becomes something a team of any size can actually run.