Professional philosophy
How I Approach Project Controls
Not a biography — the principles underneath the method. These are the positions that decide how a programme gets interrogated, where judgement is applied, and what project controls is ultimately for. Each links to the method, tool or evidence behind it.
Evidence before narrative
A claim, a progress figure or a recovery is a story until the programme and the contemporaneous record support it. The narrative is where you start looking, not where you stop.
Forensic Delay Analysis →A baseline is a control, not a filing requirement
If you cannot measure against it, it is not a baseline — it is a document that was accepted. Acceptance and control-usefulness are different questions.
Baseline Check →Progress must be capable of being challenged
A percentage you cannot evidence is one you cannot defend. Reported progress earns its place in the forecast only once it reconciles with the record.
Progress Integrity →Forecasts need logic, not optimism
A completion date held by a constraint is a hope with a date attached. A forecast is a calculation from remaining duration and logic — or it is nothing.
Forecast Integrity →Claims need programme evidence
Cause, effect and criticality, demonstrated in the contemporaneous programme — not asserted in prose. The gap between a claimed delay and a demonstrable one is where most of the argument lives.
291 → 64 case study →Dashboards should trigger decisions
If a report changes nothing, it is decoration with a licence fee. The test of a dashboard is the decision it provokes, not the number of measures it carries.
Executive Dashboard Check →Automation should strengthen controls, not automate weak ones
Automation raises the floor — applied to a sound check. Applied to a flawed one, it just produces bad controls faster, and with more apparent authority.
Digital Project Controls →Governance exists to create accountability
A common standard is what lets judgement be compared and acted on across a programme. At scale, consistency is itself a control.
16 → 1 case study →Assurance should lead to action
A score that does not change behaviour is not assurance — it is a number. The point of measuring schedule quality is the corrective action it drives.
100-Point Framework →Project controls exist to improve decisions
The output is a better decision, made in time. Everything else — the schedule, the dashboard, the assurance score — is in service of that, or it is overhead.
Decision Intelligence →