Project Delivery · Project Control Methods
Project Progress Monitoring, Tolerances and Exceptions
Progress control compares actual achievements and credible forecasts with authorised plans, tests continued viability and directs decisions to the correct management level. Its central mechanism is delegated tolerance: teams and managers act freely inside agreed boundaries, while forecast breaches trigger timely exception reporting and revised authority.
Executive summary
What this guide enables
Progress control compares actual achievements and credible forecasts with authorised plans, tests continued viability and directs decisions to the correct management level. Its central mechanism is delegated tolerance: teams and managers act freely inside agreed boundaries, while forecast breaches trigger timely exception reporting and revised authority.
Learning outcomes
- Establish product, plan and business baselines for progress control.
- Use time-driven and event-driven controls for different decision needs.
- Define and delegate tolerances across project, stage and work-package levels.
- Forecast, correct and escalate exceptions with decision-ready evidence.
Control guidance
Progress is evidence against an authorised baseline
Progress control asks where the project is now, where it is going, whether the forecast remains acceptable and whether further action is required. It measures actual achievements against product and plan baselines, forecasts time, cost, quality, scope, benefit and risk outcomes, and tests whether the project remains justified. Status reporting without a decision rule is observation; control connects the evidence to authority and action.
Product completion is the strongest unit of progress because it can be defined and verified. Effort spent or subjective percentage complete may help local management but can conceal remaining uncertainty. A product that is created but not reviewed is different from an approved product; an approved component is different from an accepted final product. Define status categories and data dates consistently across teams.
The level of plan detail determines the level of control. The governing body needs project and stage forecasts, not every task. The project manager needs enough product, dependency, resource, cost, quality, risk and issue detail to control the current stage. Delivery leads need detailed work-package information. Reporting should roll up from controlled evidence without losing material exceptions.
Baseline
The approved product, plan, budget, tolerance and business justification used for comparison.
Actual
What has occurred and what evidence confirms completion, cost, quality or decision.
Forecast
The current best estimate of future outcome based on remaining work, risk and constraints.
Variance
The difference between baseline and actual or forecast, with cause and consequence.
Tolerance
The authorised range within which a manager may act without escalation.
Exception
A forecast that an authorised tolerance will be exceeded, requiring higher-level decision.
Control guidance
Establish the control baselines
The project initiation baseline defines how progress will be controlled and contains or references the project plan, business case, product definition, management approaches, controls, roles and tolerances. The stage plan provides the current detailed baseline. Work packages provide delivery-level authorisation. Product descriptions establish quality and scope; registers establish current issue, risk and quality status; the benefit approach establishes value measures and review timing.
A baseline needs approval, version, status date, owner and change route. It should not be overwritten by each forecast. Preserve original and approved revised baselines so governance can understand performance and decision history. Rebaselining can be legitimate after an approved exception or change, but it must not erase the fact that a previous commitment was not achieved.
Define control frequency and reporting content during initiation and refine it at stage boundaries. High uncertainty or short decision lead time may require frequent checkpoints. A stable long-lead activity may need less frequent routine reporting but specific event alerts. Identify the source system for each measure to avoid competing versions of status.
Control baseline readiness
- Project and current-stage plans are approved and versioned
- Products, criteria, acceptance and configuration are defined
- Time, cost, quality, scope, benefit and risk tolerances are measurable
- Work packages align with stage products and tolerances
- Status date, progress rules and forecast methods are agreed
- Report audiences, frequency and event triggers are documented
- Issue, risk, quality and lesson records are current
- Business-case and benefit measures have owners
Control guidance
Time-driven and event-driven controls
Time-driven controls occur at a predefined frequency. Delivery leads provide checkpoint reports to the project manager, and the project manager provides highlight reports to the governing body. Their frequency can differ by work package and stage. The report should be concise and exception-oriented, covering product achievements, next work, actual and forecast position, quality, issues, risk, corrective action and decisions needed.
Event-driven controls occur when a defined event happens: a stage boundary, product completion, issue requiring formal decision, forecast tolerance breach, exception-plan request or closure recommendation. They cannot wait for the next routine report if delay would reduce response options. Event triggers should be understood by the person closest to the evidence.
Registers, daily logs and dashboards are information sources, not automatically controls. They become part of control when someone reviews them against a rule and has authority to respond. Meetings are also not controls by themselves. A useful meeting has a defined input, decision purpose, authority, record and follow-up.
| Control | Type | Producer and audience | Purpose |
|---|---|---|---|
| Checkpoint report | Time-driven | Delivery lead to project manager | Work-package product and forecast control |
| Highlight report | Time-driven | Project manager to governing body | Stage health, forecast and emerging exposure |
| Stage-end report | Event-driven | Project manager to governing body | Performance, products, lessons and decision at boundary |
| Issue report | Event-driven | Project manager to decision authority | Impact and options for a significant issue |
| Exception report | Event-driven | Manager to authority that set tolerance | Forecast breach, impact, options and recommendation |
| End-project report | Event-driven | Project manager to governing body | Performance, acceptance, residual work and closure readiness |
Control guidance
Delegate authority through tolerances
The commissioning authority sets project tolerances for the governing body. The governing body sets stage tolerances for the project manager. The project manager sets work-package tolerances for delivery leads. Tolerances may cover time, cost, quality, scope, benefits and risk. They establish limits of delegated authority and should be consistent: lower-level tolerance and cumulative exposure must fit within the manager's own boundary.
A tolerance is not a target. The plan defines the expected outcome; tolerance defines the range that can be managed without higher approval. Use upper and lower boundaries where both matter. Early delivery can create resource, cash-flow or operational problems, so a lower time tolerance may be relevant. Benefit tolerance may be a range or minimum outcome. Risk tolerance may refer to exposure, mandatory escalation categories or appetite thresholds.
Forecasting must be frequent and credible enough to detect a threatened breach. A manager should not contact the authority for every variance, but should escalate when the best current forecast indicates they cannot deliver within the delegated envelope. The report should state the latest decision date so escalation itself does not consume the remaining recovery window.
| Level | Tolerance setter | Manager inside tolerance | Forecast breach routed to |
|---|---|---|---|
| Project | Commissioning or programme authority | Governing body | Commissioning or programme authority |
| Stage | Governing body | Project manager | Governing body |
| Work package | Project manager | Delivery lead | Project manager |
If forecast outcome exceeds any delegated tolerance, current authority is insufficient and an exception must be raised.The authority may decide that a revised tolerance or plan is appropriate, but the manager should not assume that approval.
Control guidance
Review and forecast progress
A status review combines product completion, schedule, resources, cost, quality, configuration, issues, risks, decisions, lessons and business-case signals. Update actuals first, then estimate remaining work using current knowledge. Explain variance drivers and whether corrective actions are effective. Trend matters: a stage can still sit inside tolerance while repeated slippage shows that the boundary will soon be threatened.
Forecasts should include commitments and estimate to complete, not only actual spend. Schedule forecast should reflect resource and dependency constraints. Quality forecast should consider open reviews, defects and acceptance, not only tests completed. Benefit forecast should consider adoption and operational readiness. Risk forecast should reflect response progress and residual aggregate exposure.
Corrective action can be taken inside authority: resequence work, clarify scope, resolve a dependency, adjust resources, strengthen a risk response or modify a team plan. It should be recorded, assigned and checked. A corrective action that changes an authorised baseline follows change control; an action that cannot keep the forecast within tolerance supports an exception report.
| Control question | Evidence to inspect | Decision or response |
|---|---|---|
| What has been achieved? | Approved product status, actual dates, cost, quality and decisions | Confirm current position |
| What remains? | Remaining products, effort, dependencies, approvals and resource availability | Build credible forecast |
| What threatens the forecast? | Issue, risk, trend, quality and supplier evidence | Correct, respond or escalate |
| Does the project remain viable? | Business-case, benefit, risk and operational evidence | Continue, reshape or recommend closure |
Control guidance
Raise and decide an exception
The exception report describes the cause, affected plan and tolerance, consequences across all objectives, available options, effect on business justification and risks, and a recommendation. It should explain action already taken, the decision deadline and whether work can safely continue while governance considers the response. It is not merely a notification that a date changed.
The authority may approve corrective action, adjust tolerance, change scope or priority, request more information, direct an exception plan, pause work or escalate farther. If an exception plan is required, the project manager prepares a replacement for the affected stage or project plan. The governing body then authorises, rejects or modifies it. Until new authority exists, the project manager must respect the existing boundary and any direction given.
An exception can also arise from quality, scope, benefit or risk even when time and cost appear healthy. Dashboards that show only schedule and spend can therefore create false confidence. Governance reports should highlight the performance dimension most likely to determine project value, not only the easiest data to collect.
Forecasting before an actual breach
Situation: A stage is currently three days behind its baseline but still inside a five-day upper tolerance. Updated remaining-work estimates show a key approval will make the stage eight days late unless scope or sequence changes.
- The project manager uses the eight-day forecast, not the current three-day variance, as the control position.
- Local recovery options are tested across quality, cost, risk and benefits; none keeps the stage within the authorised time boundary.
- An exception report explains impact, options, recommendation and the last date for a useful decision.
- Governance selects a reduced-scope option and requests an exception plan; product and benefit baselines are updated through change control.
Control outcome: Escalation occurs while choices still exist, and new authority is explicit rather than assumed.
Control guidance
Lessons, reporting quality and common questions
Lessons should be captured from forecasts, controls and decisions throughout the project. If a checkpoint repeatedly fails to reveal remaining work, improve its format. If an estimating assumption was wrong, update later-stage planning. If governance decisions arrive too slowly, adjust the escalation lead time or availability model. The lessons report at stage or closure consolidates learning, but it should not be the first time the project acts on it.
Reporting quality depends on relevance, timeliness, consistency and traceability. A concise report that links to controlled evidence is stronger than a large presentation copied manually from several systems. State the data date, baseline version, forecast confidence, key assumptions and decisions required. Use accessible text and labels rather than colour alone.
| Control area | Weak practice | Working practice | Strong practice |
|---|---|---|---|
| Status | Subjective percentages and activity narrative | Actuals and product milestones are tracked | Product, quality and configuration evidence determine status |
| Forecast | Baseline dates are repeated | Remaining work is estimated | Resource, dependency, risk and trend evidence drive scenario forecasts |
| Tolerance | Every variance escalates or none does | Boundaries are documented | Six-dimension forecast breaches trigger timely decisions at the correct level |
| Reporting | Reports are manually recreated and historic | Regular reports use a standard format | Time and event controls provide decision-ready, traceable information |
Is a daily log a formal progress report?
No. It can record actions and observations, but formal control reports have defined producers, audiences, content and triggers.
Can tolerance be changed?
Yes by the authority that set it, after understanding impact and preserving the decision record. A manager cannot expand their own authority.
Does an exception mean project failure?
No. It means the existing delegated plan cannot be achieved within tolerance and a higher-level decision is required.
Should reports show actual or forecast?
Both. Actuals establish current position; the forecast supports decisions about the future.