Construction Project Scheduling in GCC: How to Build a Primavera Programme That Actually Controls Your Project

Almost every GCC construction project has a Primavera file. Very few of them are controlling anything.

The pattern is familiar: the programme gets built during tender or mobilisation, submitted to the client, accepted, and then runs in parallel with actual construction — referenced only when someone needs to explain a delay. By month three, the baseline is 400 activities behind, nobody is recording actual start dates, and the PM is using WhatsApp messages and gut feel to track progress.

The Primavera file still exists. It just stopped being a tool.

This is about building a construction project schedule that stays useful — one that drives procurement decisions, surfaces delays before they become claims, supports FIDIC Clause 20 entitlements, and gives your PM a credible answer when the client asks where the project really stands.

Why Most Primavera Programmes Fail as Control Tools

Three structural failures account for most dead schedules on GCC construction projects.

Over-constraining. When planners apply "must start on" or "must finish by" constraints to activities that aren't contractual milestones, the critical path calculation becomes unreliable. If 60–80% of activities carry hard constraints, Primavera is computing nothing useful. Every activity looks near-critical, float numbers are meaningless, and the scheduler can no longer identify which delays are actually driving project completion.

Updating without site data. The programme gets updated from the project office, backward-calculating what percentage complete needs to be entered to match the progress report already written by the PM. This is reporting to the schedule rather than updating from it. Within a few cycles, the programme diverges from reality and loses its function as an early warning tool.

One level for everything. A single 1,500-activity file trying to serve the client, the commercial team, the PM, and the site supervisors simultaneously serves none of them well. The client needs a 30-line summary. The site supervisor needs a two-week task list. Building one programme to do both produces a document too detailed to review at steering level and too aggregated to plan site work from.

The Level 1–4 Hierarchy: Matching Detail to Purpose

The right architecture separates the schedule into four levels, each linked and each owned by a named person.

• Level 1 (Master Summary): 30–60 activities covering major phases and key milestones. The client-facing executive view — submitted at contract award, referenced at steering committee meetings. Not the tool for site management.
• Level 2 (Area or Package Breakdown): 150–300 activities broken down by discipline or subcontract package. The commercial director's view — where each package stands against programme and who owns delays.
• Level 3 (Working Programme): 500–2,000 activities with 2–10 day durations, logic-dense and resource-loaded at trade level. The operational schedule used by package managers. This is the primary EOT evidence document.
• Level 4 (3-Week Look-Ahead): Rolled from Level 3, owned by site supervisors, measuring Percent Plan Complete (PPC) weekly. The tool for daily planning decisions.

Changes at Level 4 propagate up to Level 3. Level 3 summary activities roll up to Level 2 and Level 1. The levels are linked — not four separate files managed independently.

Critical Path and Float: The Clause GCC Contractors Most Often Misread

The critical path is the longest chain of dependent activities carrying zero float. A delay to any critical activity delays project completion by the same number of days. Most construction planners understand this. What they miss is float ownership under FIDIC.

FIDIC contracts do not explicitly assign total float to either party. In practice, Aramco, NEOM, and ROSHN will argue that float belongs to the project — meaning contractor float is a shared buffer for owner-risk events as much as contractor-risk events.

The practical implication: do not assume you can absorb employer-risk delays using float you built into the programme. Document float at baseline. Track any reduction that results from owner-caused events — late RFI responses, delayed site access, client-requested scope changes. If a delay consumes float without pushing the project past the completion date, issue a FIDIC Clause 20.2 notice anyway. Float erosion is the early warning signal for entitlement; a notice preserves your position while the impact is still being absorbed.

On SAR 200M+ GCC projects, the difference between contractors who recover float-related losses and those who absorb them is almost entirely a documentation question — not an entitlement question.

Baseline Submission Requirements: Aramco, NEOM, and ROSHN

Each major GCC client has specific programme submission requirements. Getting these wrong delays contract finalisation and removes a baseline you can use for claims.

Saudi Aramco

SAEP-11 requires a Level 3 schedule within 30 days of notice to proceed. Activities must be resourced at craft level. Primavera native .xer format required. A critical path narrative is mandatory. Revisions require Engineer approval before the revised baseline takes effect. Submitting an update without formal acceptance produces a programme with no contractual standing.

NEOM

4D BIM integration is required for major packages. Level 3 activities must carry WBS codes matching the NEOM project WBS structure. Monthly narrative reporting against baseline with variance explanation for any activity slipping more than 2%. The baseline-to-4D integration means delays have visual consequences — hard to explain away with percentage adjustments.

ROSHN

Level 2 at contract award, Level 3 within 21 days of site access. P6 export plus PDF summary. Progress updates submitted monthly, five days before the IPC cut-off. Milestone achievement tracked against a separate milestone register reviewed independently of the activity-level schedule.

In all three cases, the formally accepted baseline becomes the reference document for delay analysis. A programme emailed to the client "for information" without formal acceptance provides limited contractual protection. Contractors running SAR 500M+ portfolios across multiple Aramco, NEOM, and ROSHN projects need a baseline management workflow — not a project-by-project email chain.

Progress Update Discipline

A schedule is only as useful as its last accurate update. The update discipline is where most GCC programmes collapse.

Minimum viable weekly routine:

• Record actual start dates for activities that commenced this period — from site supervisor confirmation, not the planner's estimate
• Record actual finish dates for completed activities with the correct date — not the date the report was written
• Update remaining duration for in-progress activities based on site supervisor input, not formula-calculated percentage
• Apply productivity adjustment factors for activities affected by summer restrictions (0.70–0.80 for outdoor work June 15–Sep 15), equipment downtime, or subcontractor labour shortfalls
• Run the forward pass and calculate the new critical path
• Compare to baseline — any activity slipping onto the critical path warrants a written constraint record for FIDIC Clause 20.2 notice assessment

The update must come from site data. Updating the schedule to match a progress report already written is how GCC contractors destroy the evidential value of their own programme — turning the primary delay claim document into inadmissible self-serving narrative.

Connecting Schedule to Procurement, Cost, and Manpower

A construction schedule that lives only in Primavera is half-used.

Procurement integration. Activity start dates in the Level 3 become procurement triggers. Required-on-site dates for materials are back-calculated from the activity start: subtract lead time, submittal review period, and tender period to get the procurement initiation date. When the programme slips, the required-on-site date moves — and the procurement schedule needs to move with it automatically, not after a two-week lag when the site supervisor calls the procurement manager to say material isn't there.

Cost integration. A resource-loaded Level 3 produces a cost-loaded S-curve — planned value (PV) by week — which is the EVM baseline. Actual costs from work confirmations, timesheets, and POs give earned value (EV) and actual cost (AC). CPI and SPI derive from the same data set rather than two siloed systems requiring manual reconciliation at month-end.

Manpower integration. The resource histogram shows planned headcount by trade by week. Compare it weekly to the manpower deployed figure from daily logs or work confirmation sign-off sheets. If the site delivered 82% of planned headcount for two consecutive weeks, the programme needs to reflect that through revised durations — not absorbed silently until a milestone is missed.

Five Starting Steps

1. Audit your current programme for over-constraints. Filter Primavera for activities with constraints other than "start on or after NTP date." If more than 15% of activities carry hard constraints, the critical path is unreliable. Remove unnecessary constraints before the next update cycle.
2. Define the four levels and name an owner for each. The Level 3 needs a planning manager. The Level 4 needs a named site supervisor or package PM per area. Without ownership, updates happen when someone has time, not on a fixed cycle.
3. Formally submit and get the baseline accepted. If your current programme hasn't been formally accepted by the client, initiate that process now. An email chain is not an accepted baseline. The .xer file with a client acceptance letter and a signed schedule of key dates is what survives a commercial dispute.
4. Establish a weekly update cycle with a site data feed. Set the standard: foremen submit actuals by Monday morning. Planning updates the programme by Tuesday. Revised critical path distributed to package managers by Wednesday. Client update submitted on schedule.
5. Link programme milestones to procurement dates. Pick the ten longest-lead items on the project. Back-calculate their procurement initiation dates from the Level 3 activity start dates. Verify procurement has already actioned those items. Any gap at this point is a delay in the making.