A construction programme should do far more than satisfy a contractual submission requirement. It should provide a realistic, transparent and actively managed view of how the work is intended to be delivered — and whether the project is still capable of achieving its key milestones.

For project managers, contractors, developers and client-side teams, reviewing a programme properly means looking beyond the number of activities or how professional the Gantt chart appears.

A meaningful review should test whether the programme actually represents the project.

Here are 10 areas worth checking.

1. Is the baseline programme credible?

The baseline establishes the original delivery plan against which future progress and delay will usually be assessed.

Start by asking whether it was realistic in the first place.

Check:

• Contract commencement and completion dates

• Key contractual milestones • Design and approval periods

• Procurement lead times • Construction sequencing

• Testing and commissioning

• Handover and close-out activities

• Allowances for access, approvals and known constraints

If the original baseline was unrealistic, every subsequent progress comparison becomes less useful.

A detailed programme is not necessarily a credible programme.

2. Does the logic reflect how the project will actually be built?

Programme logic is one of the most important areas to review.

Activities should have logical predecessors and successors that reflect the physical and procedural sequence of the work.

Look for:

• Activities with no predecessor

• Activities with no successor • Excessive hard constraints

• Missing interfaces between trades • Unrealistic sequencing

• Important activities disconnected from completion

• Logic that does not reflect actual site methodology

The programme should tell a coherent construction story.

If an experienced project team cannot understand how the sequence is supposed to work, the logic deserves closer examination.

3. Does the critical path make sense?

The critical path identifies the chain of activities currently controlling the project completion date.

A reviewer should not simply accept whichever activities the scheduling software identifies as critical.

Ask:

• Does the critical path reflect the major remaining construction sequence?

• Are design or procurement activities genuinely driving completion?

• Are key commissioning activities included?

• Has the critical path changed since the previous update?

• Are there near-critical paths that could become critical shortly?

The critical path should be technically credible and understandable when compared with what is actually happening on the project.

4. What is the float telling you?

Float provides useful information about schedule flexibility.

But it must be interpreted carefully.

Review:

• Activities with unusually high float

• Activities with negative float

• Near-critical activities

• Significant changes in float between updates

• Whether constraints are distorting float calculations

• Whether important activities appear to have unrealistic amounts of flexibility

A large float value does not automatically mean an activity is low risk.

It may indicate missing logic.

Likewise, disappearing float can be an early warning that project flexibility is being consumed even before the contractual completion date moves.

5. Is the reported progress supported by evidence?

The programme update should reflect actual project status.

Review whether reported percentages and completion dates can be supported through reasonable evidence.

Depending on the activity, this may include:

• Site observations

• Installed quantities

• Daily reports

• Inspection records

• Procurement records

• Approved drawings

• Delivery documentation

• Testing records

• Photographs

• Subcontractor reporting

Be particularly careful with activities repeatedly reported as 80% or 90% complete without reaching actual completion.

Progress should reflect measurable achievement rather than optimism.

6. Are procurement and design properly integrated?

A programme that focuses only on construction activities is incomplete.

Many projects are driven by events that occur months before physical installation.

Review whether the programme properly includes:

• Design development

• Design reviews

• Client approvals

• Shop drawings

• Material submissions

• Long-lead procurement

• Manufacture

• Factory testing

• Shipping and delivery

• Installation

• Testing and commissioning

These activities should connect logically to the construction work that depends on them.

If a major item is required on site in six months but its design, approval and manufacturing process is absent from the programme, the risk is being hidden rather than managed.

7. Are project constraints visible?

Every project has constraints.

The question is whether they are actively represented and managed.

Typical constraints include:

• Design information

• Client decisions

• Authority approvals

• Utility interfaces

• Access restrictions

• Possession or shutdown windows

• Temporary works

• Property access

• Environmental approvals

• Specialist subcontractors

• Material availability

• Third-party interfaces

If a project team knows that an unresolved issue could stop work, that issue should be visible somewhere in the planning and control process.

A programme should help bring constraints forward, not allow them to remain hidden until they affect construction.

8. Are milestones being achieved?

Milestones provide a simple way of identifying whether performance is changing over time.

Compare:

• Original baseline milestone dates

• Previous forecast dates

• Current forecast dates

• Actual achieved dates

Repeated milestone movement is often more significant than one isolated delay.

Look for trends.

If important milestones are gradually slipping every month while the final completion date remains unchanged, the programme may be absorbing risk without showing a credible explanation of how that time will be recovered.

9. Is the recovery strategy credible?

When a project falls behind, the programme should explain how the delay will be addressed.

A recovery programme should contain identifiable management actions.

Examples include:

• Additional resources

• Additional shifts

• Parallel work fronts

• Resequencing

• Changed methodologies

• Accelerated design release

• Alternative procurement strategies

• Earlier subcontractor mobilization

• Removal of constraints

• Increased management or supervision

Shortening activity durations without explaining how the work will physically be completed faster is not a recovery strategy.

A credible recovery programme should connect the proposed action to the time being recovered.

10. Is the forecast completion date still realistic?

Ultimately, the programme must provide a credible view of where the project is heading.

Ask:

• What is currently controlling completion?

• What work remains?

• Is current productivity sufficient?

• Are key procurement items on track?

• Are approvals achievable within the available time?

• Are remaining activity durations realistic?

• Has contingency or float already been consumed?

• Are proposed recovery measures actually being implemented?

• Does the forecast align with what is visible on site?

The most important question is not simply:

What completion date does the programme show?

It is:

Based on the evidence available today, is that date genuinely achievable?

Programme review should lead to action

A programme review has limited value if it simply produces another report.

The purpose should be to identify issues early enough for the project team to respond.

A useful review should provide clarity on:

• Current programme health

• Critical and near-critical activities

• Emerging delay risks

• Milestone performance

• Procurement and design exposure

• Constraints requiring management action

• Progress credibility

• Recovery requirements

• Forecast completion risk

That information allows decisionmakers to focus attention where it can still make a difference.

The programme should be a management tool

A strong construction programme is not simply something prepared for the client once a month.

It should be actively used by the team delivering the work.

It should connect design, procurement, construction, commissioning, constraints, progress and management action into one coherent view of the project.

When reviewed properly, it provides something extremely valuable:

Early visibility of where a project is heading before the outcome becomes unavoidable.

CPS Management provides independent programme reviews, programme health checks, critical-path and progress analysis, recovery reviews and programme assurance for contractors, developers and client-side project teams.

The objective is to turn programme information into clear, practical management decisions.