What project controls really is

Video lecture

10 chapters · about 9 min · full transcript

Coming soon

Chapter 1 of 10

What project controls really is

Plan, baseline, measure, analyse, forecast, act
Five questions every controls team must answer
A health check you can run this week

The narrated lecture is in production

Every chapter is scripted and ready. Browse the chapters and read the full transcript now — the video will appear here when it’s published.

Chapters

Transcript of the narration, chapter by chapter.

0:00 What project controls really is

Here's a story you may recognise. A project reports green in January. Green in February. Green in March. And then, in April, it is suddenly, shockingly red. Everyone asks the same question. How did we not see this coming? The honest answer is usually this. The project was red for months. The system simply could not see it. In this lecture I'm going to show you what project controls really is, why it is not the same as reporting, and how to run a quick health check on any project using the control cycle. By the end, you'll be able to look at a monthly report and tell, within a few minutes, whether it is a genuine control tool or just a well-formatted history lesson.

0:54 Why it matters

So why does this matter? Because a report tells you what happened, and controls tells you where you are heading and what to do about it. Think of driving a car. Reporting is the rear-view mirror. Useful, but you would never drive by it alone. Controls is the windscreen, the sat-nav and the brakes together. Here's the uncomfortable truth in many organisations. The controls team spends most of its month collecting and cleaning data, and almost no time on analysis or action. That's upside down. The value is created in three steps: understanding why you differ from plan, forecasting where you will finish, and triggering decisions early enough to matter. If a team is buried in data collection, that is exactly where automation, and later AI, earns its place.

1:50 The control cycle

Let's build the model. I call it the control cycle, and every mature controls system runs some version of it. First, plan: what are we delivering, by when, and for how much? Second, baseline: which version of that plan do we formally measure against? That's the performance measurement baseline, or PMB. Third, measure: what has actually happened, in progress and cost? Fourth, analyse: why are we different from plan? Fifth, forecast: where will we finish if nothing changes? And sixth, act: what are we going to do about it? Then the loop repeats, usually weekly for the schedule and monthly for cost. Here's the key idea. A cycle is only as strong as its weakest step. A beautiful plan with no baseline discipline is useless. Brilliant analysis with no action is just commentary.

2:48 The five questions

Now, a simple test you can apply to any controls function. Can it answer five questions, at any moment, with evidence? One. Where are we? Two. Where should we be by now? Three. Why is there a difference, and I mean the root cause, not the symptom. Four. Where will we end up, ideally as a range rather than a single hopeful number. And five. What are we doing about it, with named owners and dates. Most reports I review handle questions one and two quite well. Question three is often weak. Questions four and five are frequently missing entirely. And that's the tell. If a report cannot answer question five, it is a history lesson. Keep these five questions in your head, because we will come back to them in every module of this course.

3:47 Worked example one: a small fit-out

Let's make this concrete with a simple example. The numbers are illustrative. A retail chain is refitting a shop over six months with a budget of two hundred thousand pounds. At month three, the report says spend is one hundred and ten thousand, the timeline is half gone, so we're roughly on track. Is that right? Pause for a second and think about what's missing. We know what was spent. We know how much time has passed. But we don't know how much work has actually been done. When the controls lead measures it objectively, the finished work is worth eighty thousand of the budget. So we have spent one hundred and ten thousand to achieve eighty thousand of planned work. That's a thirty thousand overspend on what was delivered, hidden behind a comfortable 'on track'. Same data, different question, completely different story.

4:49 Worked example two: Gulf Horizon Facilities

Now a more realistic scenario. Gulf Horizon Facilities is a fictional contractor in Dubai delivering a fourteen-month office fit-out. The client complains that reports always look green until they're suddenly red. A new controls lead runs a health check against the cycle. Plan: a work breakdown structure exists, but some work packages run for more than three months, so progress can only be guessed. Weak. Baseline: the schedule has been re-baselined twice without any approved change. Poor. Measure: supervisors report a subjective percent complete. Weak. Analyse: variances are listed, but no root causes. Weak. Forecast: the estimate at completion equals the budget every single month. Poor. Act: there is no action log at all. Poor. The diagnosis writes itself. The project never went suddenly red. The system was blind. And every fix is something we'll cover in this course.

5:49 Watch me do it: a ten-minute health check

Let me show you exactly how I'd run this in ten minutes. I open last month's report next to a simple spreadsheet with six rows, one per step of the cycle. For each step I give a score from one to five, and here's the rule: I must write the evidence next to the score. Plan, three: the work breakdown exists but two packages are too big. Baseline, two: I can see a changed finish date with no change record. Measure, three. Analyse, two: variances with no causes. Forecast, one: the estimate at completion has equalled the budget for five months. Act, two. Now I sort by score. The weakest step is forecast. So I write one action, not ten. Introduce a formula-based forecast range at next month's review, owned by the cost controller, due on the fifteenth. That's it. One honest score, one action, one owner.

6:53 Common mistakes

Let's look at the mistakes I see most often. First, the schedule and the budget live in different tools, owned by different people, and nobody ever reconciles them. Integration is the whole point of controls. Second, the forecast equals the budget because 'we'll recover'. Hope is not a forecast. Third, re-baselining to make variances disappear. A baseline should change only through approved change, otherwise you have what people call a rubber baseline. It stretches to fit whatever happened. Fourth, measuring effort instead of results. Hours spent tell you how busy people were, not what they achieved. And a bonus mistake: collecting far more data than anyone ever analyses. If a number is never used in a decision, ask why you're collecting it.

7:46 Where AI fits

So where does AI fit into this? In twenty twenty-six, AI tools can draft variance narratives, flag anomalies in cost data, spot schedule logic problems and summarise risk registers in seconds. That's genuinely useful. But notice where it helps most: in measuring and analysing. It speeds up the first half of the cycle so that people can spend more time on forecasting and acting, which is where judgement and accountability live. AI doesn't remove the need for the control cycle. It makes a well-run cycle faster. And it makes a badly run cycle produce confident-sounding nonsense faster too. We'll return to this properly, with governance, in the final module.

8:33 Recap and try this now

Let's recap. Project controls is not reporting. It's a cycle: plan, baseline, measure, analyse, forecast and act, repeated every period. You can test any controls system with five questions, and the last one, what are we doing about it, is the one most often missing. Watch for the classic mistakes: unreconciled schedules and budgets, forecasts that equal the budget, rubber baselines and effort masquerading as progress. Here's your try-this-now. Pick a project you know, real or imagined. Score it from one to five on each of the six steps, write one line of evidence for each score, and write one improvement action for the weakest step. It takes ten minutes, and it will tell you more than most monthly reports.

Controls is not reporting

Many organisations think "project controls" means producing a monthly report. Reporting is only the visible tip. Project controls is the discipline of establishing a plan (the baseline), measuring actual performance against it, understanding why the two differ, forecasting where the project will finish, and helping managers take corrective action early enough to matter. A controls team that only reports history is an accounting function; a controls team that forecasts and triggers decisions is a management function.

The central idea is simple: you cannot control what you have not planned, and you cannot plan what you have not defined. That is why controls always starts with scope, then schedule, then cost, then risk, and then ties all four together in an integrated baseline.

The control cycle

Every mature controls system runs the same loop, whether the project is a metro line in Riyadh, a hospital fit-out in Manchester, a data centre in Texas or a software rollout for a bank in Lahore.

Step	Question it answers	Typical output
1. Plan	What are we delivering, by when, for how much?	WBS, schedule, budget, risk register
2. Baseline	What do we formally measure against?	Approved performance measurement baseline (PMB)
3. Measure	What has actually happened?	Progress, actual costs, timesheets, quantities
4. Analyse	Why are we different from plan?	Variances, root causes, trends
5. Forecast	Where will we finish if nothing changes?	EAC, forecast completion date, risk-adjusted ranges
6. Act	What will we do about it?	Recovery plans, change requests, re-sequencing

The loop repeats every reporting period, usually weekly for schedule and monthly for cost. The value is created in steps 4 to 6. If your team spends 80% of its time collecting data (step 3), that is a signal to invest in data quality and automation, which is exactly where AI and modern tooling help most.

The five questions every controls function must answer

A useful test for any controls system is whether it can answer these five questions at any moment, with evidence:

Where are we? (actual progress and cost to date)
Where should we be? (the baseline for this point in time)
Why is there a difference? (variance explanation with root cause, not symptoms)
Where will we end up? (forecast cost and date, ideally as a range)
What are we doing about it? (owned actions with dates)

If a monthly report cannot answer question 5, it is a history lesson, not a control tool.

Roles in a controls team

Titles vary by region and industry, but the functions are consistent:

Planner / scheduler builds and maintains the schedule, runs critical path analysis and updates progress.
Cost controller / cost engineer manages budgets, commitments, actual costs, accruals and cost forecasts.
Risk manager or analyst runs the risk process and quantitative analysis.
Change / document controller manages the change log, versions and approvals.
Project controls manager integrates all of the above and owns the story told to leadership.

On a small project, one person may wear all five hats. The discipline still applies; only the scale changes.

Worked example: a controls health check

Illustrative scenario. Gulf Horizon Facilities, a fictional contractor in Dubai, is delivering a 14-month office fit-out. The client complains that monthly reports "always look green until suddenly they are red". A controls lead runs a quick health check against the cycle:

Cycle step	Finding	Rating
Plan	WBS exists but work packages are too large (some over 3 months)	Weak
Baseline	Schedule was re-baselined twice without change approval	Poor
Measure	Progress reported as subjective "% complete" by supervisors	Weak
Analyse	Variances listed but no root causes	Weak
Forecast	EAC equals budget every month	Poor
Act	No action log	Poor

The diagnosis: the project never goes "suddenly red"; it was red for months, but the system could not see it. The fixes are the subject of this course: smaller work packages, baseline discipline, objective progress measurement, earned value, honest forecasting and an action log.

Common mistakes

Treating the schedule and the budget as separate documents owned by separate people, so they never reconcile.
Letting forecasts equal the budget because "we will recover". Hope is not a forecast.
Re-baselining to make variances disappear. A baseline changes only through approved change.
Measuring effort (hours spent) instead of results (work accomplished).
Collecting more data than anyone analyses.

Where AI fits

AI tools in 2026 can draft variance narratives, flag anomalies in cost data, suggest schedule logic issues and summarise risk registers. They do not remove the need for the control cycle; they speed up steps 3 and 4 so humans can spend more time on 5 and 6. We will return to this with proper governance in the final module.

Hands-on: build a control-cycle health check in Excel

Set up a one-sheet health check you can reuse on every project. Columns: A Step, B Question, C Score (1–5), D Evidence, E Action, F Owner, G Due.

A2:A7  Plan | Baseline | Measure | Analyse | Forecast | Act
C9     =AVERAGE(C2:C7)                                  overall maturity
C10    =INDEX(A2:A7, MATCH(MIN(C2:C7), C2:C7, 0))        weakest step
C11    =COUNTIF(C2:C7, "<=2")                            steps needing urgent work
D2:D7  Data validation: text length > 10 (forces written evidence)

Add conditional formatting on C2:C7 (red ≤ 2, amber 3, green ≥ 4). The formula in C10 returns the step to fix first; the rule "one action for the weakest step" keeps the exercise honest.

Second worked example: a software rollout

Illustrative. A Lahore-based bank is rolling out a new lending platform over nine months. The PMO runs the health check at month four:

Step	Score	Evidence
Plan	4	Release plan, WBS by capability, budget by workstream
Baseline	3	Baseline approved, but two scope additions not logged
Measure	2	Progress = tickets "in progress", no definition of done
Analyse	2	Burn-down commentary only
Forecast	2	Go-live date never re-forecast
Act	3	Action log exists, 40% overdue

Weakest step: Measure (tie broken by the team's judgement, because forecasting cannot improve until progress is measured objectively). Action: earn progress only for stories meeting the definition of done, starting next sprint.

How to measure success

Health-check average rising quarter on quarter.
Share of variances with a stated root cause (target: all above threshold).
Number of periods in which EAC equals BAC exactly (target: zero unless justified).
Lead time between a problem first appearing in data and a decision being taken.

Project controls = plan, baseline, measure, analyse, forecast, act, repeated every period.
Value is created in analysis, forecasting and action, not in data collection.
A report that cannot say what is being done about a variance is not a control tool.
Baselines change only through approved change control.

Pick a project you know (or an imaginary one). Score it 1–5 on each of the six control-cycle steps and write one improvement action for the weakest step.

Enrol for free to save your progress

Reading is always free. Enrol to keep your place, take the final assessment and earn a verifiable certificate.

What project controls really is