A construction programme should be much more than a contractual submission or a colourful Gantt chart.

Done properly, it is one of the most important management tools on a project. It should explain how the work will be delivered, identify the activities controlling completion, highlight emerging risks and give the project team enough information to act before delay becomes unavoidable.

The problem is that a programme can look detailed and still provide very little real control.

Understanding the warning signs early can make the difference between managing a problem and explaining a delay after it has already occurred.

1. The programme has activities — but weak logic

A programme is only as reliable as the logic connecting its activities.

Every activity should have a clear relationship with the work that comes before and after it. When activities have missing predecessors, missing successors or unrealistic relationships, the programme may produce dates that look credible but do not represent how the project will actually be delivered.

Typical warning signs include:

• Activities with no predecessor or successor

• Excessive use of hard constraints

• Large numbers of activities linked only by Finish-to-Start relationships

• Logic that does not reflect actual construction sequencing

• Activities that can apparently move without affecting anything else

• Milestones that are not connected to the work required to achieve them

The question should always be:

Does the programme logic reflect how the project will actually be built?

2. The critical path does not make sense

The critical path identifies the sequence of activities that is currently driving project completion.

If a critical path runs through minor or unlikely activities while major construction work appears to have substantial float, the programme deserves closer examination.

A credible critical path should normally be understandable when compared with the physical construction sequence.

For example, depending on the project, it may move through:

• Design completion

• Approvals

• Long-lead procurement

• Site establishment

• Structural works

• Services installation

• Testing and commissioning

• Practical completion

The precise sequence will vary from project to project, but the critical path should tell a coherent delivery story.

If it does not, the programme may not be giving the project team a reliable forecast.

3. Float is being misunderstood

Float is often treated as spare time.

That can be dangerous.

Float is the amount of scheduling flexibility available before an activity affects another milestone or the project completion date. It can disappear quickly when activities are delayed or when the programme is updated.

Large amounts of float should therefore be understood rather than simply accepted.

Questions worth asking include:

• Why does this activity have so much float?

• Is the logic correct?

• Is there a missing relationship?

• Is the activity genuinely non-critical?

• Has a constraint artificially changed the calculated float?

• Has progress elsewhere shifted the critical path?

Float is useful information, but only when the underlying programme logic is sound.

4. Reported progress does not reflect what is happening on site

One of the strongest programme controls is accurate progress status.

If the programme says an activity is 80% complete, there should be reasonable evidence supporting that assessment.

Depending on the activity, evidence might include:

• Site observations

• Quantity installed

• Inspection records

• Delivery records

• Completed drawings

• Procurement status

• Testing results

• Subcontractor reporting

• Photographic evidence

Subjective progress percentages can create a false sense of performance.

A project can appear to be tracking reasonably well in the programme while the physical work tells a very different story.

5. Planned progress and actual progress are drifting apart

A good update should make variance visible.

If activities repeatedly finish later than planned, milestones continue to move or the project consistently achieves less work than forecast, the programme is providing an early warning.

The key is not simply to record the variance.

The project team needs to understand:

• What caused it?

• Which future activities are affected?

• Has the critical path changed?

• Is available float being consumed?

• Does the completion date remain achievable?

• What action is required now?

Small variances can become major delays when they are repeatedly carried forward without corrective action.

6. Long-lead procurement is disconnected from construction

Construction programmes sometimes focus heavily on-site activities while giving insufficient attention to procurement.

That creates significant risk.

Critical equipment, materials and specialist subcontract packages may require:

• Design development

• Technical submissions

• Client approval

• Shop drawings

• Manufacture

• Factory testing

• Shipping

• Customs clearance

• Site delivery

• Installation

• Commissioning

If those steps are not properly represented in the programme, procurement delay can appear suddenly even though the risk existed months earlier.

Long-lead procurement should be connected directly to the activities that depend on it.

7. Approvals and constraints are not visible

Projects rarely fail because construction activities exist in isolation.

Progress often depends on information, decisions and access.

Typical constraints include:

• Design approvals

• Client decisions

• Authority approvals

• Access restrictions

• Utility relocations

• Possession windows

• Temporary works

• Interface requirements

• Material approvals

• Subcontractor mobilization

• Environmental constraints

• Property or stakeholder issues

A programme that ignores these dependencies may show an achievable construction sequence while overlooking the events actually controlling the work.

These constraints should be identified early and actively managed.

8. The recovery programme is simply more optimistic

When a project falls behind, the response is often a recovery programme.

But changing future dates is not a recovery strategy.

A credible recovery programme needs to explain how time will actually be recovered.

That might involve:

• Resequencing work

• Increasing resources

• Additional shifts

• Parallel work fronts

• Alternative construction methodologies

• Accelerated procurement

• Earlier design release

• Removing constraints

• Changed subcontract strategies

• Increased supervision or management focus

The programme should demonstrate the relationship between the proposed action and the time being recovered.

If the revised programme simply contains shorter durations without a credible operational basis, it is not a reliable recovery plan.

What contractors should be reviewing

Contractors should not wait until the monthly programme update to discover that delivery is slipping.

Programme review should form part of normal project management.

That includes regularly checking:

• Critical and near-critical activities

• Planned versus actual progress

• Milestone performance

• Procurement status

• Design and approval dates

• Constraints and unresolved decisions

• Subcontractor performance

• Changes to float

• Emerging delay events

• Forecast completion

• Required recovery actions

The programme should help the delivery team decide what needs attention now.

What client-side teams should be reviewing

Developers, project managers, superintendents and other client-side representatives should also look beyond the headline completion date.

A programme review should consider whether:

• The baseline programme was credible

• Logic reflects the intended construction sequence

• Progress is supported by evidence

• The critical path is reasonable

• Procurement is adequately represented

• Delay events have been incorporated appropriately

• Constraints are visible • Recovery actions are credible

• Forecast dates remain achievable

• Programme changes are properly explained

The purpose is not to manage the contractor's programme on their behalf.

It is to understand whether the information being relied upon provides a credible picture of project status and future risk.

A simple programme health check

Even a relatively short independent review can reveal significant issues.

A programme health check can examine areas such as:

• Logic integrity

• Open ends

• Constraints

• Activity durations

• Critical path

• Near-critical paths

• Float distribution

• Progress status

• Milestone movement

• Procurement

• Design and approvals

• Delay events

• Recovery measures

• Forecast completion

The result should be a clear explanation of what the programme is saying, where the risks are and what needs further attention.

The value is in early warning

The real value of a construction programme is not proving afterwards that a project was delayed.

Its greatest value is identifying problems early enough for the project team to do something about them.

A strong programme provides visibility.

It tells the team what is controlling completion, where performance is slipping, which risks are emerging and where management attention needs to be focused.

That is when a programme becomes more than a reporting requirement.

It becomes a project-control tool.

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

The objective is simple: clearer programme visibility, earlier identification of risk and better-informed project decisions.