The systems behind a more controlled project

Project controls compare the agreed plan with reliable evidence of what has happened, forecast what is likely to happen next and support corrective decisions. The system covers more than the schedule. Scope, time, cost, risk, change, progress, information and decisions must use compatible definitions so the team is not comparing different versions of the project.

The Association for Project Management describes project controls as the analytical part of project management, covering scope, time, cost, risk, change, reporting, performance, decision-making and information management. This is a useful boundary: controls produce decision-quality information, while project leadership remains accountable for acting on it.[1]

A baseline is more than a saved programme file. It is the approved reference for what will be delivered, how the work is broken down, when it is planned, what assumptions apply and how changes will be controlled. If scope items cannot be traced to activities and responsible packages, progress percentages will look precise while remaining untestable.

For each control account or work package, define the deliverable, owner, acceptance evidence, planned dates, budget or quantity basis where applicable and related risks. Record the basis of the plan: calendars, productivity assumptions, procurement lead times, access constraints, approvals and imposed milestones.

A schedule should explain the sequence of delivery, not simply display target dates. Activities need clear scope, realistic duration, responsible resources and logical predecessors and successors. Procurement, design, approvals, temporary works, testing and handover belong in the same logic when they control construction.

The US Government Accountability Office groups reliable schedule practice into four characteristics: comprehensive, well constructed, credible and controlled. Its guidance emphasises complete activities, logical sequencing, a valid critical path, risk analysis, regular status updates and maintenance of the baseline.[2]

A reliable weekly cycle creates rhythm: set the data date, collect evidence, validate actual starts and finishes, estimate remaining duration, update logic, review critical and near-critical paths, assess risks and changes, agree actions and issue a concise narrative. The schedule, action log and dashboard should describe the same position.

Progress should be evidenced by measurable completion criteria. “Foundation 80% complete” is weak if the basis changes from week to week. Quantities installed, inspection acceptance, earned milestones or defined weighted steps provide a more stable basis. Remaining duration should reflect current productivity and unresolved constraints rather than automatically shrinking with time.

A risk is an uncertain event that may affect objectives; an issue has already occurred; a change alters an approved baseline or requirement. The records can be separate, but their relationships should be visible. A materialised risk may become an issue, trigger a change request and alter the schedule forecast.

For each proposed change, record the originating requirement, reason, options considered, technical review, cost and time assessment, risk effect, affected documents and approval status. Until approved, keep it distinguishable from the baseline. After approval, update every affected control system so the project does not operate with a changed drawing and an unchanged programme.

The UK Project Routemap focuses on setting up projects for success through capability, governance, requirements, risk and delivery strategy. Its central lesson is that control quality is established early; dashboards introduced after responsibilities and decision rights have become unclear cannot repair the governance gap.[3]

A progress report states what happened. A control report explains what the evidence means for the next milestone and what decision is required. Forecasting should use the current sequence, remaining quantities, actual productivity, procurement status, access constraints and risk exposure.

Use ranges where uncertainty is material. A single completion date can conceal the difference between the logic-based forecast and management’s target. Keep both visible: the forecast shows the current likely outcome, while the target frames the recovery decision. Changing the forecast to match the target removes the warning function of project controls.

Lagging indicators confirm outcomes already experienced, such as milestone variance, installed quantity or cost incurred. Leading indicators show conditions likely to affect future outcomes, such as overdue design decisions, long-lead items without approval, work fronts without access or a rising number of unresolved high-impact risks.

Every dashboard element should answer one of four questions: Are we on the approved plan? What changed? What is likely to happen? What decision or action is due? If a chart cannot support one of those questions, it may belong in an analytical drill-down rather than the management view.

Keep definitions visible. “Progress,” “approved change,” “critical,” “overdue” and “forecast finish” must mean the same thing across reports. Show the data date, baseline version, update status and source system. A polished visual with stale or manually reconciled data creates false confidence.

A small project may need a controlled schedule, drawing register, risk and change logs, action tracker and a repeatable reporting pack. A larger programme may require integrated cost, schedule, document, field and portfolio platforms. In both cases, begin with identifiers and ownership: work breakdown codes, document references, contract packages, locations and accountable roles.

ISO 19650-1 provides a useful information-management principle: information should be exchanged, recorded, versioned and organised through a defined framework. Integration should preserve those controls. Automatically moving inconsistent data between systems only distributes uncertainty faster.[4]

At minimum, establish an approved scope and responsibility matrix, a logic-linked programme, drawing and submittal registers, risk and issue logs, change control, progress evidence, decision and action tracking, and a reporting calendar. Assign an owner and review frequency to every record.

The system is working when the team can explain the current forecast, the reasons for variance, the decisions needed and the evidence behind each statement. It is not working when reports require manual reconciliation meetings before anyone trusts them.