A programme may contain thousands of activities and show a completion date that matches the contract, yet still be unsuitable for managing delivery. The issue is not the appearance of the chart. It is the logic connecting design, reviews, procurement, construction, testing and handover—and whether the team can measure progress and explain deviations later.
Accepting a weak programme reduces the reliability of monthly reporting, makes the critical path harder to understand and leaves the owner facing disagreements that could have been identified earlier. Reviewing the programme does not mean imposing the reviewer’s construction methods on the contractor. The purpose is to establish whether it reflects the contractor’s scope, plan and obligations and can be maintained and measured.
Before the review: establish the basis of the programme
Compare the programme with the contract, scope, milestones, drawings, site conditions and procurement strategy. Identify the calendars, data date, measurement units, required level of detail and responsibility for each package. If contractual milestones do not agree or part of the scope is missing, correct the basis before relying on the remaining checks.
Distinguish the tender programme from the post-award baseline and short-term look-ahead schedules. They serve different purposes and require different levels of detail. A brief tender programme should not become the sole execution baseline without the necessary development and review.
The contractor should provide a basis-of-schedule narrative covering the execution strategy, work breakdown structure and coding, calendars, production rates, assumptions, exclusions and treatment of out-of-sequence progress. This makes the file’s logic understandable and auditable rather than leaving it as a collection of unexplained relationships.
1. Scope completeness
Build a checklist linking work packages to activities. Include design, reviews and permits, long-lead items, temporary works, testing, commissioning, training and handover. Structural construction may appear complete while a missing approval or system handover still prevents opening.
Avoid adding detail that the team cannot maintain. Each critical or measurable element should nevertheless be visible at a level that supports responsibility and progress measurement.
2. Relationship logic
Check whether activities follow an achievable sequence or have merely been linked to produce a preferred date. Activities with missing predecessors or successors, unusual relationships, hard constraints and long relationship lags can conceal incomplete logic.
For each major activity, ask: what makes it possible to start, and what subsequent work depends on its completion? If the delivery team cannot explain the relationship, it needs review even if the software can calculate it.
3. Constraints and assumptions
Show each material external constraint in the programme or connect it to a clear register: land access, utility diversion, authority approval, an owner’s decision or the availability of a work front. Forcing an activity onto a date does not resolve the underlying constraint and may prevent the programme from showing the effect of delay properly.
Record assumptions such as working hours, the number of available work areas and dates for owner-provided information. When an assumption changes, the team should be able to identify which activities need reassessment.
4. Realistic durations and production rates
Check activity duration against quantities, production rates, resources and available space. In a simplified example, completing 1,000 units in ten days requires resources and work fronts capable of supporting 100 units per day. Increasing labour on paper is not enough if access, lifting equipment or supervision cannot support that output.
Compare durations with the execution plan, procurement strategy and subcontract arrangements. Overly long activities can hide deviation; excessive detail in very short activities can make updating burdensome without improving decisions.
5. Design, reviews and procurement
A programme that begins only with site construction omits important potential sources of delay. Link shop-drawing preparation to review, resubmission and approval, followed by purchase order, manufacture, shipping, inspection, arrival and the required-on-site date.
Check that reasonable allowance has been made for resubmission cycles, especially for critical materials. Identify the party responsible for each review or approval so that later slippage does not appear as one unexplained block of delay.
6. Critical and near-critical paths
The critical path should emerge from the programme’s logic and durations, rather than being designated manually. Review its continuity from the data date to completion, low-float activities and the reasons that the controlling path changes between updates. A path passing through apparently unrelated activities or ending unexpectedly may indicate missing logic or distorting constraints.
Float does not automatically belong to one party. Its treatment depends on the contract, accepted programme and facts. Describe its position without making a general contractual ruling.
7. Resources and calendars
Check calendars for holidays, working hours, shifts and seasonal restrictions that actually apply to the project. A different activity or resource calendar can change the calculation without being obvious in the presentation.
For projects in Saudi Arabia, review the actual effect of public holidays, approved working hours, Ramadan arrangements, Hajj-related restrictions at relevant locations, heat exposure, authority permits, truck-access windows and closures. These are project-specific planning inputs; they should not be copied into every programme as universal restrictions.
Where resource or cost loading is required, it should agree with mobilisation and cash-flow plans. Unrealistic resource peaks or allocation of the same resources to simultaneous work fronts can expose a gap between the programme and the execution strategy.
Check seasonal restrictions against the relevant year, location and type of work. The end of a seasonal direct-sun work-ban period does not remove the need to assess heat stress and maintain appropriate precautions. Do not reuse an earlier project’s calendar without checking current working conditions.
8. Measurable progress
Define how each activity’s progress will be measured: completed quantities, an accepted milestone or weighted, identifiable steps. Subjective percentages can leave an activity at “90% complete” for weeks. Separate physical completion from acceptance where necessary: finishing work does not necessarily mean that its outcome has been accepted.
Define rules for updating actual starts and finishes, remaining durations, out-of-sequence activities and the data date. Consistent rules allow comparison between periods instead of changing the reporting basis each month.
The data date separates recorded actual progress from forecast work; it is not the date the file was saved. Sample activities for remaining work scheduled before that date or actual dates recorded after it. Request correction and an explanation of exceptions before using the update in the owner’s report.
9. Risks and recovery planning
The baseline cannot predict every event, but it should reflect known risks and responses that materially affect the plan. Connect critical procurement, interfaces and decisions to warning indicators, and define when the project needs a recovery scenario.
A recovery plan is more than compressed durations that restore the original finish date. Explain the proposed changes to sequence, resources, work fronts or methods, their implications for safety, quality and cost, and who is authorised to approve the actions.
A single calculated completion date does not establish the probability of achieving it. Where schedule risk analysis is needed, document uncertainty inputs, procurement and interface risks and the analysis method. Do not present a confidence level or time contingency as an established result without supporting data and specialist analysis.
10. File integrity and auditability
Request the native programme file, its narrative and the agreed checking reports, with a fixed revision and submission date. The reviewer should be able to trace a milestone through its activities, relationships, resources and assumptions and reproduce the calculation.
Review dangling relationships, long lags, mandatory constraints, open-ended activities, negative float and durations exceeding the agreed level-of-detail limits. Treat findings as exceptions requiring explanation. Numerical screening thresholds are not universal acceptance criteria or automatic grounds for rejection unless adopted by the contract or project procedure.
Images and PDFs are useful presentations, but they are not sufficient for auditing logic or comparing updates.
Issue the review outcome using the contract’s response categories
Do not finish with an unstructured list of comments. Use the response categories defined by the contract and document-control procedure. Do not invent a category such as “conditional acceptance” unless its consequences are defined. Explain whether a material omission in scope, logic or measurement prevents acceptance, or whether a comment can be closed without changing completion dates or obligations.
Maintain a record of the contractor’s response and the correction made within the programme file, not only in a covering letter.
After acceptance, the programme becomes a monitoring reference, while the contract remains the basis for rights and obligations. Acceptance does not relieve the contractor of responsibility for methods, production rates or resources. It does not amend the completion date or grant an extension of time without the separate contractual process. Our article on root cause analysis for project delays explains how updates and records support the review of actual deviation.
Quick warning signs
- A compliant finish date produced by numerous constraints rather than connected logic.
- Missing design, reviews or long-lead procurement activities.
- Durations unsupported by quantities or resources.
- Reported starts or finishes without measurement evidence.
- A discontinuous critical path that the team cannot explain.
- Mobilisation or procurement plans that do not agree with the programme.
- A PDF submission without an auditable native file.
- Updates that change methods or calendars without explanation.
Worked example: equipment arrives on the installation start date
In a hypothetical programme, an electrical panel arrives and installation starts on the same day. The programme omits receipt inspection and room readiness and does not connect manufacture to technical-submittal approval. Completion may look achievable on the chart, but the sequence is incomplete.
Request the prerequisites for each activity, connect them to the actual resources and calendars and recalculate the critical path. If the correction exposes negative float, explain the gap and evaluate feasible options, such as bringing forward a decision or opening an additional work front where practicable. Do not remove testing durations or impose a mandatory finish to conceal the problem.
The review output is a corrected activity sequence connecting technical-submittal approval, manufacture, arrival, inspection, room-readiness verification and installation, identifying each input’s owner and readiness evidence. Room preparation need not wait for equipment arrival: the delivery/inspection sequence and the room-readiness sequence must both satisfy the actual prerequisites for installation.
Review the effect on the completion milestone. A statement that the panel “will arrive on time” is not sufficient if installation prerequisites remain invisible. This example illustrates logic review; it does not prescribe standard durations for all equipment or represent a completed AYM project.
What should an independent reviewer be asked to deliver?
Specify the revision to review, data date, contractual milestones, measurement rules, native file and basis-of-schedule narrative. A programme review within the PMO scope should identify the issue, its effect, the required action and evidence of closure. Site supervision records can help verify production and inspection conditions within the appointment. Preserve the accepted baseline before incorporating any authorised change.
Executive takeaway
A programme suitable for acceptance is not necessarily the most detailed one. It is the one that best connects scope, execution strategy, resources, reviews and procurement, measures progress consistently and reveals the effect of change. Reviewing it before acceptance gives the parties a clearer basis for monitoring and decision-making.
Professional references and limits of application
Use the contract and the project’s controlled procedures to determine applicable requirements. General guidance does not establish the requirements of an individual appointment, change contractual response categories or transfer responsibility for execution methods to the reviewer. The examples are illustrative and are not reported AYM project outcomes.
- EXPRO National Manual for Project Management. Use the controlled procedures and issue applicable to the project. The public library is a reference entry point; it does not establish the latest issue of an individual schedule-preparation procedure.
- GAO Schedule Assessment Guide, GAO-16-89G, published 22 December 2015. A complementary methodological reference, not a general Saudi regulatory requirement.
- National Council for Occupational Safety and Health: end of the 2026 direct-sun work-ban period. A year-specific source supporting calendar review and continuing heat-stress precautions; do not carry its dates into later years without checking current requirements.
Discuss an independent baseline review
Need an independent view before accepting the baseline? Ask AYM to review programme logic, the critical path and progress-measurement readiness. Identify the submission revision, project stage and available records so that the review scope and deliverables can be defined before appointment.