Major Airport Development: Programme Governance and Integrated Delivery Beyond Project Controls

Across the world, governments and airport operators are investing in new terminals, runways and entire greenfield airports to meet growing demand for air travel. These are among the most complex undertakings in the built environment. Yet they are frequently managed as if they were simply a large collection of construction contracts, each with its own schedule, budget and progress report. That approach misses the essential point. A major airport development is the coordinated delivery of an operational ecosystem, in which infrastructure, specialist systems, people, procedures, commercial objectives and regulatory requirements must all come together on a single opening date.

Delivering that outcome requires more than competent project controls. It requires programme governance that makes decisions clear and timely, an integrated view of schedule, cost, risk, change and interfaces, and a deliberate path from construction completion to operational readiness. The organisation best placed to provide that integration is a Programme Management Office (PMO) positioned at programme level, with the authority, standards and credibility to connect the parts into a whole.

This comprehensive blog will explore why airport development programmes behave differently from conventional projects, how a governance framework should be structured, and where the PMO should sit within it. We will examine integrated programme controls, including the Integrated Master Schedule and Earned Value Management; how schedule performance is diagnosed and recovered; how risk cascades from enterprise decisions into programme and project exposure; how change and interfaces are prevented, controlled and resolved; and why systems integration and Operational Readiness and Airport Transfer (ORAT) define the real outcome. We will then turn to executive reporting as decision support, and to the first 90 days of a newly appointed Head of PMO. Whether you are a programme director, PMO lead, project controls professional, commercial manager or operational stakeholder, understanding how programme governance turns many projects into one operational airport is key to protecting both the opening date and the investment.

1. Why Airport Development Programmes Are Different

Airport development differs from conventional building and infrastructure work because the final product is not a completed structure. It is a functioning transport and commercial ecosystem. A terminal, runway, taxiway, apron, baggage handling system, security infrastructure, utilities network, road connection and operational support facility may each be delivered as a separate project or package, but they must work together as one airport.

This has a direct and often underestimated consequence: the completion of an individual package does not mean that the airport can operate. A terminal may be physically complete while its baggage system, passenger processing, security, ICT or building management systems remain untested. Airfield infrastructure may be built while operational approvals, emergency response arrangements or supporting systems are not yet ready.

A major development typically includes many interdependent projects: terminal buildings, airside infrastructure, utilities, roads, car parks, cargo facilities, support buildings, ICT, security, baggage handling and operational systems. These may have different designers, contractors, procurement strategies, delivery schedules and acceptance criteria. The programme challenge is to ensure that their individual outputs combine into a coherent operational outcome. A package can be on schedule and within budget while the programme is at risk because a dependency it relies on, or that relies on it, has not been delivered. Programme success must therefore be assessed at the level of the integrated airport, not by adding together package-level progress reports.

The opening date is the defining commitment. It depends on construction completion, systems integration, commissioning, regulatory approvals, operational trials, staffing, training and stakeholder readiness, so it is influenced by far more than the progress of the largest contracts. The Integrated Master Schedule must connect design, procurement, construction, utilities, testing, commissioning, operational access and ORAT milestones, and it should expose the dependencies that determine whether the airport can open rather than merely summarise contractor schedules.

The stakeholder environment compounds the difficulty. Airport operations, airlines, ground handlers, aviation authorities, security agencies, immigration and customs, emergency services, local authorities, utility providers, retailers and concessionaires each have distinct responsibilities, operating requirements and approval processes. A late operational or regulatory requirement can ripple into terminal layouts, design, procurement, construction, testing and cost. Stakeholder engagement is therefore a delivery discipline, not a communications exercise.

Airports are also commercial environments. Decisions about retail, food and beverage, passenger services, airline facilities and terminal space shape both the physical design and the operating model. Reallocating space between retail and food and beverage, for example, can cascade into architectural layouts, MEP services, HVAC loads, finishes, procurement and construction sequencing. The programme must balance commercial flexibility against design maturity, procurement commitments, construction progress and the need to protect the opening date.

Finally, modern airports depend on numerous interconnected systems: baggage handling, passenger processing, security, access control, CCTV, fire alarm, HVAC, building management, electrical distribution, passenger information and airport operational systems. Installing and testing each one individually does not prove that the integrated airport will perform. Systems integration is as important as construction.

Figure 1: The airport as an operational ecosystem. Infrastructure, specialist systems, people and procedures, stakeholders, commercial objectives and regulatory approvals must converge on one operational outcome; no single package delivers the airport on its own.

This is why a programme-level PMO is essential. It provides the integrated view that individual project teams cannot always maintain, connecting governance, schedule, cost, risk, change, interfaces, systems integration and operational readiness. Its purpose is not to add bureaucracy but to help the programme identify dependencies, make timely decisions and protect the intended outcome: a safe, secure, compliant, commercially viable and operationally ready airport, delivered within the approved strategic, time and cost objectives.

2. Establishing an Effective Programme Governance Framework

Governance is the framework of structures, policies, procedures, decision-making authorities and accountability mechanisms through which a programme is directed, controlled and kept aligned with its strategic objectives. It establishes who has authority to decide, who is accountable for outcomes, how decisions are made and how performance is assured.

Governance should be distinguished from management. Governance sets direction, authority and accountability. Programme management plans and delivers the work. The PMO integrates information, controls, coordination and decision support within the authority assigned to it. Confusing these roles is a common source of friction, particularly when a PMO is assumed to hold approval powers it was never given.

A typical structure includes a Board or Investment Committee, a Steering Committee or executive oversight body, programme executive leadership under a Programme Director, the PMO, and the project, package and functional delivery teams. The precise structure should reflect programme scale, organisational arrangements and delegated authority. It should provide clear reporting lines and escalation routes without creating unnecessary approval layers.

Figure 2: An illustrative governance hierarchy, from Board or Investment Committee through Steering Committee, Programme Director and PMO to the delivery teams, with the typical contribution of each level. The exact structure should reflect programme scale and formal delegation.

The Delegation of Authority (DoA) defines the decisions that individuals and committees may make. It should cover financial thresholds, technical approvals, scope changes, procurement decisions, contractual matters and other material programme decisions, and it must be clear, documented and understood by everyone who prepares, assesses, recommends, approves and implements decisions. These roles are rarely held by the same person. A technical team may assess a proposal, commercial and controls teams may evaluate its cost and time implications, programme leadership may recommend a course of action, and an authorised committee may approve it.

Accountability for outcomes and responsibility for activities must also be clear. A RACI matrix, identifying who is Responsible, Accountable, Consulted and Informed for key processes and deliverables, helps, but only if it is practical, maintained and aligned with actual authority rather than produced for compliance.

Stage gates provide structured decision points across the lifecycle, ensuring that the programme is sufficiently defined and mature before major commitments are made. A representative sequence runs from strategic definition and business need, through feasibility and options assessment, concept development and scope definition, design maturity and procurement readiness, contract award and mobilisation readiness, and construction, integration and delivery assurance, to testing, commissioning and operational readiness, and finally handover, acceptance and close-out. Each gate should have defined entry criteria, required evidence, decision authority and documented outcomes, and reviews should be proportionate to risk and complexity.

Figure 3: The stage-gate sequence, from strategic definition to handover and close-out. Each gate requires entry criteria, evidence, a decision authority and a documented outcome, with review effort proportionate to risk and complexity.

Decisions need their own discipline. A decision register should record the decision required, background, options, recommendation, responsible authority, required date, actual decision date and resulting actions. Decisions not made within the required timeframe become programme constraints in their own right, so escalation thresholds and turnaround expectations should be set. Risk acceptance, change approval, procurement, claims and commercial matters should likewise follow defined processes that state who assesses, recommends and approves each category, and how its consequences are reflected in the baseline.

Governance should also include assurance that processes are followed, that information is reliable and that decisions remain aligned with objectives: schedule, cost, risk and design reviews, stage-gate assessments and independent technical or operational reviews. The PMO commonly facilitates all of this by preparing decision papers, maintaining registers, coordinating reviews, tracking actions and reporting compliance. It does not automatically hold approval authority; that depends on the programme charter and formal delegation.

Above all, governance should enable delivery. Excessive approval layers, unclear responsibilities and repetitive reporting undermine it. Governance should be strong enough to protect the programme and efficient enough to keep it moving.

3. Positioning the PMO at Programme Level

The term PMO covers several different functions, and an airport programme needs to be clear which it is building. A Project PMO supports the management of an individual project. A Programme PMO coordinates multiple related projects and manages their interdependencies in pursuit of a common outcome. An Enterprise PMO typically operates at organisational or portfolio level, supporting investment prioritisation, strategic alignment and portfolio governance.

Figure 4: Project, programme and enterprise PMO. Each serves a different level of the organisation; airport development usually needs programme-level integration because many projects must converge on one operational outcome.

Airport development usually requires programme-level integration, because multiple projects and specialist packages must converge to deliver an operational airport. The PMO must understand not only whether each package is performing, but also whether the combined programme remains capable of achieving its objectives. The distinction between project performance and programme performance is the heart of the matter. A terminal package may be progressing well against its own baseline, while delayed utilities, airside access, specialist systems or regulatory approvals threaten the opening date. Programme management exists to identify these cross-project consequences before they become critical.

To do that, the Programme PMO must integrate the principal management disciplines: scope, schedule, cost, risk, change, interfaces, procurement, commercial performance, systems integration and operational readiness. It establishes common standards and reporting rules so that information from different projects can be compared and consolidated meaningfully. An integrated programme management framework typically rests on common WBS, CBS, coding and reporting structures; an Integrated Master Schedule with package dependencies and key milestones; consistent progress measurement and validation; an integrated view of budget, commitments, actuals and forecasts; programme-level risk, change and interface management; coordination of systems integration, commissioning and ORAT; and executive reporting and decision management.

Figure 5: The PMO as an integration hub, connecting scope, schedule, cost, risk, change, interfaces, procurement and commercial performance, systems integration and operational readiness through common standards and reporting rules.

The PMO's emphasis evolves over the lifecycle. Early on, it focuses on governance, scope definition, baseline development and procurement strategy. During design and construction, controls, risk, change and interfaces dominate. As completion approaches, systems integration, commissioning, stakeholder readiness and operational handover become increasingly important. A PMO designed only for the construction phase will be poorly equipped for the final, decisive stage of the programme.

Its effectiveness should be judged by the quality of its contribution to programme outcomes: credible forecasts, timely decisions, effective escalation, improved integration, better risk visibility and readiness for operations. The number of reports produced or procedures issued is not, by itself, a measure of value. The PMO earns its place by integrating projects so that they deliver the programme outcome, not by consolidating project reports.

4. Integrating Programme Controls

Integrated controls begin with a consistent Work Breakdown Structure (WBS) and Cost Breakdown Structure (CBS). These provide a common framework for organising scope, schedule, cost and progress information, and coding should allow that information to be analysed by project, package, facility, discipline, contract and other useful dimensions. Without a shared structure, package data cannot be meaningfully compared or rolled up.

The Integrated Master Schedule (IMS) should connect design, procurement, construction, utilities, access, testing, commissioning, approvals and ORAT. Primavera P6 is commonly used for complex infrastructure scheduling, but the tool alone does not create an integrated schedule. Logic, calendars, coding, status rules, progress evidence and interface dependencies must be properly managed. Package schedules should be connected through predecessor and successor relationships, and the IMS should expose the critical and near-critical paths and the milestones that determine overall completion and opening.

Cost management should connect the approved budget with contract commitments, actual expenditure, approved changes, forecast remaining work and potential exposure. Each element tells management something different: the approved budget is the authorised financial provision; commitments are the contractual and purchase obligations entered into; actual cost is the expenditure incurred to date; the Estimate to Complete (ETC) is the forecast cost of remaining work; the Estimate at Completion (EAC) is the forecast total cost; and contingency and exposure show the remaining provision and potential additional liabilities. The PMO should maintain continuous visibility of ETC, EAC and contingency consumption.

Figure 6: One coding structure feeding schedule, cost and performance. A common WBS and CBS allow the IMS, the cost picture (budget, commitments, actuals, ETC, EAC) and earned value to be read against the same scope.

Earned Value Management (EVM) combines scope, schedule and cost performance. Planned Value (PV) is the budgeted value of work scheduled; Earned Value (EV) is the budgeted value of work actually accomplished; and Actual Cost (AC) is the cost incurred to achieve that work. Schedule Variance is EV minus PV, and Cost Variance is EV minus AC. The Schedule Performance Index (SPI) is EV divided by PV, and the Cost Performance Index (CPI) is EV divided by AC.

To illustrate, if PV is ₹500 crore, EV is ₹400 crore and AC is ₹450 crore, the programme has earned less value than planned and spent more than the budgeted value of the work performed. SPI is 0.80 and CPI is approximately 0.89. Both indicate adverse performance, but neither should be over-read. SPI is not a direct percentage measure of completion delay, and CPI alone does not determine final cost. These indicators reveal trends; they must be interpreted alongside critical path analysis, remaining scope, resource constraints and forecast assumptions.

Figure 7: Earned value in concept. Planned value, earned value and actual cost are plotted against time; the gaps at the status date show schedule variance (EV minus PV) and cost variance (EV minus AC). The curves are schematic and carry no values.

Progress rules must be consistent across packages. Engineering progress may be measured through deliverable milestones; procurement through defined stages such as approval, manufacture, inspection and delivery; construction through installed quantities and verified work; and commissioning through test completion and acceptance criteria. Financial progress should never be treated as a substitute for physical progress.

Forecasting should consider current performance, remaining scope, the critical path, resource availability, procurement constraints, changes, risks and recovery assumptions. Where appropriate, quantitative schedule and cost risk analysis can support confidence ranges such as P50 and P80, but these complement, rather than replace, professional assessment of schedule logic and programme conditions. Primavera P6, financial systems, document management, risk registers and business intelligence platforms such as Power BI can provide a connected reporting environment, provided the underlying data is governed and validated. AI may help summarise information or identify patterns, but its outputs require professional review and traceability.

The purpose of programme controls, in the end, is to show where the programme is heading, why its position is changing and what action is needed. A mature controls function is forward-looking and exception-based, not a historical reporting factory.

5. Schedule Performance and Programme Recovery

A package can report acceptable progress while the integrated programme is delayed. The PMO must therefore assess both package-level performance and the consequences of package dependencies. A delay that is absorbed within one package's float may be harmless; the same delay on an activity that enables another package's testing may push the opening date.

Figure 8: Project delay versus programme delay. A package can appear on track against its own baseline while a late handover to a receiving package moves the integrated path to opening; recovery begins with validated progress and accurate diagnosis.

The first step is to validate reported progress before diagnosing delay. Progress should be checked against physical quantities, approved deliverables, inspection records, procurement evidence and actual site conditions. Differences in measurement rules can make package reports incomparable. The objective is to establish a reliable status, not to assume that a contractor has overstated progress.

Next come the root causes. Common causes include incomplete or late design, procurement delays, resource constraints, access restrictions, productivity problems, utility dependencies, stakeholder approvals, late changes and unresolved interfaces. The analysis should identify the activities affected and whether they are critical or near-critical.

Recovery should then be based on the logic of the integrated programme. The PMO should examine predecessor and successor relationships, float, access constraints, procurement lead times, approvals and the dependencies between providing and receiving parties. Give-and-take milestones should define what is to be provided, by whom, to what acceptance criteria and by when.

Potential recovery measures include additional resources, extra shifts, resequencing, parallel working, alternative construction methods, procurement acceleration, design and approval acceleration, improved access and prioritisation of critical facilities. Each should be tested for feasibility, cost, safety, quality, productivity and downstream impact. A recovery programme should identify the actions, resources, logic changes, milestones, assumptions and responsible parties needed to improve the forecast. It should be realistic, resource-loaded where appropriate and monitored against measurable milestones. A recovery schedule that simply compresses durations without a credible execution strategy is not a recovery plan.

Figure 9: The recovery cycle: validate progress, diagnose root causes, analyse the critical path and dependencies, test and select recovery measures, issue an owned recovery programme, then monitor whether forecast dates stabilise and adjust when assumptions fail.

Recovery and contractual entitlement are related but distinct. The immediate programme priority may be to protect the opening date, while entitlement and responsibility are assessed separately. Delay events should be analysed under the actual contract, including notice requirements, causation, criticality, mitigation and any applicable concurrency provisions. The FIDIC Red, Yellow and Silver Books generally allocate design and performance risks differently, but the executed contract, its Particular Conditions, amendments and the procurement strategy determine the actual obligations. The name of the form is not enough to establish entitlement.

Finally, the PMO should compare actual performance against the recovery plan, assess whether forecast dates are stabilising and judge whether mitigation is producing the intended result, adjusting actions when assumptions prove wrong. Effective recovery begins with accurate diagnosis; without understanding the cause and programme consequence of delay, recovery measures risk treating symptoms rather than the underlying problem.

6. Enterprise-to-Programme Risk Management

A risk is an uncertain event or condition that may affect objectives; an issue is a matter that has already occurred and requires action. The distinction matters because risks call for proactive responses, while issues call for resolution and control. In airport development the relevant categories are broad: strategic and business, funding and financial, design, construction and productivity, procurement and supply chain, regulatory, stakeholder, operational readiness, safety and security, and external risks such as currency movements or changes in policy.

What distinguishes a programme approach is the recognition that risk cascades. Enterprise decisions create risks and requirements for the programme, and programme decisions create them for projects. A change in commercial strategy favouring retail over food and beverage, for example, may affect terminal space allocation, passenger flows, architecture, MEP services, HVAC, procurement and construction sequencing. That consequence must be assessed across the programme rather than left inside one design package. Before such a decision is approved, the potential strategy change may be treated as an emerging risk or uncertainty. Once approved, the resulting scope modification enters formal change control, while the risks of implementing it continue to be managed through the risk process.

Figure 10: The enterprise-to-programme-to-project risk cascade. An enterprise decision, such as a shift in commercial strategy, becomes an emerging programme risk; once approved it enters change control, and its effects on design, services, procurement and sequencing are managed at project level.

Risk governance and risk management are both needed. Governance establishes risk appetite, tolerance, ownership, escalation thresholds and the authority to accept or treat exposure. Management is the operational process of identifying, assessing, responding to and monitoring risks. Structured identification workshops should bring in technical, commercial, operational and stakeholder perspectives, and risks should be written in a cause, uncertain event and consequence structure, which separates the underlying cause from the event and its effect on objectives.

A useful register records a unique identifier, risk statement, category, cause, consequence, probability, impact, inherent rating, response, risk owner, action owner, due date, residual rating, proximity and status. The risk owner remains accountable for managing the risk; the PMO facilitates, challenges, consolidates and escalates.

Figure 11: A qualitative probability and impact grid. Risks are rated before and after response; those in the upper zone, or exceeding the current owner's authority, are escalated. The bands are illustrative and should follow the programme's own risk criteria.

Threat responses may include avoidance, mitigation, transfer or sharing, and acceptance; opportunities may be exploited, enhanced, shared or accepted. Actions should be specific, owned and time-bound, and their effectiveness should be reviewed rather than assumed. Risks should be escalated when they exceed agreed thresholds or threaten objectives beyond the authority of their current owner. For complex programmes, quantitative analysis, including Monte Carlo schedule or cost analysis, can help assess uncertainty and contingency requirements, though P50 and P80 outputs must be interpreted in context and supported by credible inputs.

Most importantly, critical risks should be linked to the schedule activities, cost exposure, change proposals and interfaces they affect. A risk register disconnected from the IMS and the cost forecast has limited value as a programme management tool.

7. Change Management: Prevention Before Control

Changes may arise from evolving business requirements, stakeholder requests, design development, regulatory requirements, site conditions, technical coordination, value engineering or unforeseen circumstances, and their consequences can reach across scope, cost, schedule, procurement, interfaces and operational readiness.

The most effective change management begins before construction. Stakeholder requirements should be identified, reconciled and translated into clear design and performance requirements, and airport operations, airlines, security agencies, emergency services, aviation authorities, local authorities and commercial stakeholders should be engaged early enough for their requirements to shape the design. Design maturity should be measured against defined deliverables and review criteria, and appropriate design freeze points protect procurement and construction from avoidable late change. A freeze does not eliminate future change; it marks the point after which any change requires explicit assessment of its consequences.

A formal change process identifies the proposal, establishes its origin and justification, assesses impacts, obtains the required approvals, issues clear instructions and updates the relevant baselines. A Change Control Board, or an equivalent mechanism, may review material changes within its assigned authority. Impact assessment should cover scope, technical compliance, safety, regulatory implications, operations, schedule, cost, procurement, contracts, interfaces, risk, quality and commissioning, quantified where reasonably possible and with transparent assumptions.

Figure 12: The change-control flow, from proposal and justification through full impact assessment, authorised decision, instruction and baseline update, with the distinction between a change, a modification to scope or requirements, and a claim, an assertion of contractual entitlement.

Not every clarification, design development or contractor submission is a compensable change. Under design-build or EPC arrangements, some design development and coordination may already be part of the contractor's obligation to deliver a complete facility meeting the Employer's Requirements. The FIDIC Red, Yellow and Silver Books allocate design and performance responsibilities differently in general terms, but the executed contract, its Particular Conditions and amendments govern the specific position, and they must be examined before entitlement is concluded.

Equally, a change and a claim are related but not interchangeable. A change is a proposed or instructed modification to scope or requirements. A claim is an assertion of contractual entitlement, often to additional time or money. Separate change and claims registers should be maintained and linked where relevant.

Approved changes should be reflected in the appropriate scope, schedule and cost baselines, while the original baseline and approved revisions remain visible, preserving traceability and showing how the programme has evolved. Late changes deserve particular scrutiny because they can affect procurement, rework, testing, commissioning and opening readiness. The programme should ask whether a proposed late change is essential for opening or could be deferred to a later phase, subject to safety, regulatory and operational requirements, and that decision should be evidence-based and taken by the appropriate authority. The objective is not to prevent all change. It is to prevent avoidable change, assess necessary change rigorously and implement approved change in a controlled manner.

8. Interface Management

An interface is a point of dependency or interaction between organisations, contracts, systems, facilities, activities or stakeholders. Airport programmes contain physical, technical, schedule, information, organisational, contractual, regulatory and operational interfaces in large numbers. A package may complete its own scope yet be unable to progress because it has not received information, access, utilities, approvals or physical works from another party. Unresolved interfaces create delay, rework, disputes and operational deficiencies, and their consequences often extend well beyond the immediate package.

An Interface Management Framework should define interface categories, identification methods, ownership, registration, assessment, resolution, escalation and closure. Interfaces should be identified during design and procurement, not only after construction conflicts arise. A practical register records a unique ID, description, category, providing party, receiving party, interface owner, required deliverable, required-by date, acceptance criteria, dependencies, status, risk, action owner, escalation route and closure evidence.

For every important interface, it should be clear what one party must provide and what another must receive. The deliverable should be specific and measurable, and give-and-take milestones should fix the required date and acceptance criteria. Critical interface milestones belong in the IMS, logically linked to the activities they enable. Permanent power availability, for instance, may be a predecessor to equipment testing, baggage handling system commissioning and integrated terminal trials. The schedule should show those relationships, rather than leaving interface dates in a separate list.

Figure 13: The interface register, with providing and receiving parties. Each critical interface has a defined deliverable, required-by date and acceptance criteria, and its milestone is linked in the IMS to the activities it enables, such as permanent power enabling testing, BHS commissioning and integrated trials.

An interface manager or coordination team should facilitate identification, communication and resolution. The role requires technical understanding, organisation, persistence and the ability to work across contractual and organisational boundaries, and interface meetings should focus on decisions and actions rather than status updates. The approach should be collaborative and solution-oriented, but coordination does not remove contractual responsibility; each organisation remains accountable for its defined obligations.

Critical interfaces should be assessed for probability, consequence and proximity. Dashboards may report open, critical, overdue, ageing and resolved interfaces, but a count of open items is not enough: management attention belongs on the interfaces that threaten critical milestones, commissioning or operational readiness. Interface management and systems integration are closely related but different. The first controls the boundaries and dependencies between parties, packages and systems; the second demonstrates that connected systems function together end to end. A successful airport programme needs both.

9. Systems Integration and Operational Readiness

A terminal may be structurally complete, the runway constructed and the major MEP systems installed, yet the airport may still be unable to operate. Operational readiness requires functioning systems, accepted facilities, trained personnel, approved procedures, prepared stakeholders and the applicable regulatory approvals. It helps to separate the stages clearly: construction completion, where physical works meet the defined contractual and technical standard; systems completion, where individual systems are installed, inspected and technically complete; systems integration, where connected systems demonstrate the required end-to-end functionality; commissioning, where systems and equipment are tested and shown to operate as intended; operational readiness, where people, processes, stakeholders and facilities are prepared; operational acceptance, where authorised parties accept the facility and systems for use; and airport opening, where operations commence subject to approvals and readiness requirements.

Figure 14: From construction completion to airport opening, with the six dimensions of operational readiness: facilities, systems, people, processes, stakeholders and regulatory approvals. Completion of the first step does not imply any of those that follow.

The systems involved are numerous: baggage handling, passenger boarding bridges, flight information displays, common-use passenger processing, security screening, access control, CCTV, fire detection and suppression, HVAC, building management, electrical distribution, elevators, public address, ICT networks, airport operational databases and airfield systems. Each may be delivered by a separate specialist, but the airport depends on their coordinated performance. A Systems Integration Plan should identify systems and subsystems, integration boundaries, technical interfaces, responsible organisations, information exchanges, integration sequence, testing requirements and acceptance criteria. A systems breakdown structure and integration matrix help show which systems must interact and who is responsible for proving it.

Testing and commissioning typically progress from Factory Acceptance Testing (FAT), delivery inspections and installation checks, through pre-commissioning, equipment and subsystem testing, system commissioning and interface testing, to Integrated Systems Testing (IST), performance trials and final acceptance, though the exact sequence depends on the system and contract. FAT verifies equipment or functionality before dispatch where required; Site Acceptance Testing checks installed equipment under site conditions; and integrated testing demonstrates that connected systems operate together. A fire alarm event, for example, should trigger the required sequence of notification, ventilation control, door release and evacuation-related functions in accordance with the approved design.

ORAT prepares the airport organisation, people, systems, stakeholders and facilities to commence operations. It must be planned from the early stages of the programme, not treated as a late exercise after construction. Participants may include airport operations, airlines, ground handlers, security, immigration and customs, emergency services, maintenance teams, baggage system operators, retailers, IT support and aviation authorities. Readiness has six dimensions: facilities that are complete, accessible, safe and suitable; systems that are installed, tested, integrated and accepted; people who are recruited, trained and competent; processes that are developed, approved and validated; stakeholders who are prepared; and regulatory approvals, inspections and requirements that are satisfied.

Operational trials may simulate passenger processing, baggage journeys, aircraft turnaround, emergency response, evacuation, power failure, system outages and security incidents. Each exercise needs clear scenarios, objectives, safety controls, observers and acceptance criteria, and findings must be assigned owners and tracked to closure. Conducting a trial is not the same as demonstrating readiness.

Operational stakeholders often need access before the entire programme is complete, so a phased handover strategy should define areas for early access, construction prerequisites, safety controls, inspections, documentation, acceptance criteria and outstanding works, with careful zoning where construction and operations coexist. ORAT activities, from operational concept development, procedures, recruitment and training to regulatory inspections, emergency exercises, trials and readiness reviews, should sit in the IMS, linked to their prerequisites. A delay in ORAT can threaten opening as directly as a construction delay.

Operations teams also need accurate asset registers, as-built drawings, operation and maintenance manuals, maintenance plans, warranty details, spare-parts information, equipment settings, training records and test certificates. These requirements should be defined early and verified progressively rather than assembled at the last moment. A readiness assessment should then evaluate facilities, systems, personnel, procedures, stakeholders, safety and security, regulatory status, maintenance arrangements and trials, classifying outstanding deficiencies by whether they prevent safe or compliant operation. Any acceptance of residual deficiencies must follow applicable requirements and the authority of the relevant decision-maker. The PMO's role is to integrate all of this with the wider programme, so that management receives an evidence-based assessment of opening readiness. A completed airport building is a construction achievement; a fully integrated, tested and operationally ready airport is a programme delivery achievement.

10. Executive Reporting and Strategic Decision Support

Major programmes generate large volumes of schedules, cost reports, risk registers, change records, interface information and commissioning data. The executive challenge is to convert this into a clear view of delivery confidence and the decisions required. An executive report should answer four questions: are we on track, what threatens delivery, what is being done, and what decisions are needed?

Five dimensions give that answer its structure. Schedule and opening confidence covers baseline, forecast, critical path, milestones, trend and recovery. Cost and financial performance covers original and current budget, commitments, actuals, ETC, EAC, contingency and exposure. Operational readiness covers facilities access, systems integration, commissioning, stakeholder preparation and approvals. Risks and interfaces covers critical exposure, trends, mitigation, overdue dependencies and owners. Changes and decisions covers approved and pending changes, escalations, decisions required and management actions.

Figure 15: The executive reporting pyramid. Project and package teams supply detailed delivery data; the PMO validates and integrates it into a programme view; executive leadership receives a concise account across five dimensions, with traceability preserved down the pyramid.

The reporting hierarchy matters as much as the content. Project and package teams provide detailed delivery information; the PMO validates and integrates it, assesses cross-package consequences and develops the programme view; and executive leadership receives a concise account of strategic performance, major exposure and decisions. Traceability should be preserved without overwhelming senior management with operational detail. That depends on consistent data: progress measurement, reporting periods, WBS and CBS coding, cost categories, schedule status rules, risk classifications and change definitions. Procurement progress should be measured through meaningful milestones rather than purchase order value alone, and commissioning progress through completed tests and acceptance criteria.

Executive reporting should show direction of travel, comparing forecast completion dates, EAC movement, contingency consumption, risk trends and readiness milestones across periods. SPI and CPI are useful indicators but do not independently determine the completion date or final cost. Reporting should also be exception-based: management attention belongs on matters outside agreed thresholds or threatening objectives. RAG status is useful only when supported by defined criteria and an explanation, and each material exception should state what happened, why, the impact, the response, the owner and whether intervention is required. Interfaces that threaten critical activities, commissioning or stakeholder access should be visible, and approved changes should be distinguished from pending proposals and contractor claims; a claim is an assertion of entitlement, not an approved cost, and potential exposure should be reported with its basis and degree of certainty.

Decision papers should set out the background, the decision required, options, implications, recommendation, deadline and authorised decision-maker, and a decision register should track submission, required and actual decision dates. Delayed decisions become constraints and should be escalated. Dashboards built on Primavera P6, financial systems, document management, risk registers and Power BI can support integration, but technology cannot compensate for poor source data, and AI-generated summaries need professional validation. As to cadence, package reviews may be weekly, programme performance reviews monthly or more often for exceptions, and executive or Board reporting as governance requires, while critical safety, regulatory, financial or milestone threats should be escalated immediately. The value of executive reporting lies not in the dashboard but in the quality and timeliness of the decisions it enables.

11. The First 90 Days of a Head of PMO

A newly appointed Head of PMO should understand the programme before changing it. The first 90 days can usefully be organised into three phases, understand, assess and strengthen, adapted to the programme's maturity and immediate delivery pressures.

Figure 16: The first 90 days of a Head of PMO: understand (days 1 to 30), assess (days 31 to 60) and strengthen (days 61 to 90), each closing with a defined output, from a structured understanding of the programme to a management-agreed improvement roadmap.

During days 1 to 30, the task is to understand. That means the strategic objectives, scope, phases, capacity objectives, opening commitments and major milestones; the governance, DoA, organisation, stage gates, change and risk processes, escalation arrangements and how decisions are actually made; and the contracting and commercial environment, including package strategy, contract scopes, risk allocation, design responsibilities, interface obligations, variation mechanisms, extension-of-time provisions, claims exposure and long-lead procurement. It means meeting the Programme Director, project and package leads, planning and controls, commercial, engineering, procurement, construction, risk, interface, commissioning, ORAT, operations and finance stakeholders, and assessing team capability. And it means reviewing the baselines, registers, reporting standards and systems, including whether ORAT and systems integration are genuinely connected to the programme schedule. The output is a structured understanding of the programme and initial observations requiring further investigation.

During days 31 to 60, the task is to assess programme health. The credibility of the IMS should be tested for package coverage, logic, interfaces, critical path, procurement, testing, commissioning, approvals and ORAT. Cost forecasts, commitments, actuals, ETC, EAC, contingency, approved changes and claims exposure should be reviewed. The critical threats to delivery, such as design approvals, long-lead procurement, contractor resources, access, utilities, stakeholder decisions, interfaces, regulatory requirements and readiness constraints, should be identified, along with whether risk owners have credible mitigation plans and whether interface management is proactive. Change governance, decision turnaround, systems integration plans, operational trials, handover and readiness assessments complete the picture, together with the essential question of whether the PMO is providing integration and decision support or mainly producing reports. The output is a programme and PMO health assessment of strengths, critical weaknesses, immediate threats and prioritised improvements.

During days 61 to 90, the task is to strengthen. Improvements to schedule integration, progress validation, cost forecasting, risk and interface management, change control, decision management, systems integration, ORAT and executive reporting should be agreed; roles clarified where necessary; and capability gaps addressed. A practical improvement roadmap should set objectives, owners, target dates, resources and measurable success criteria, aligned with programme leadership and resisting the temptation to transform every process at once. The outputs are a PMO diagnostic, a baseline confidence assessment, critical risk and interface and operational readiness assessments, an executive reporting framework and the agreed roadmap.

Credibility throughout depends on transparency, professional independence, collaboration, accountability and delivery focus. The PMO must be able to challenge unrealistic forecasts and escalate concerns constructively while keeping the trust of the teams responsible for delivery. The common mistakes are familiar: changing processes before understanding why they exist, focusing on reporting rather than integration, policing rather than enabling, ignoring operational readiness, trying to solve every problem at once, identifying issues without assigning ownership, and measuring activity rather than improvement. The first 90 days should be measured not by how many changes are introduced, but by how much clearer the programme becomes and how much more confidence leadership has in its ability to deliver.

Conclusion: The PMO as the Integrating Engine of Airport Delivery

Major airport development is judged by the integrated outcome, not by the sum of completed contracts. Individual packages may meet their milestones while the programme remains exposed because utilities, specialist systems, approvals or operational stakeholders are not ready. The PMO's first responsibility is to maintain an integrated view of whether every component can come together to deliver the airport.

Governance provides the foundation: structures, authority, accountability, stage gates and escalation, with decision rights held by the authorities the framework defines and the PMO facilitating, informing and assuring. Integrated controls provide visibility and predictability: a common WBS and CBS, a logic-driven IMS, consistent progress measurement, earned value, ETC and EAC, all aimed at showing where the programme is heading and what intervention may be needed. Risk, change and interfaces must be connected rather than kept as isolated registers; enterprise decisions cascade into programme and project risk, necessary changes must be assessed and controlled, and interfaces must be identified, assigned and resolved, with their consequences reflected in schedule, cost and readiness forecasts.

Systems integration and ORAT define the real outcome. Infrastructure must be integrated, tested and accepted, and people, processes, stakeholders and facilities must be ready. Operational readiness is not a late add-on but part of the delivery strategy from the start. Executive reporting turns all of this into action by giving management a reliable view of what is happening, what is likely to happen and what decisions are required.

The PMO must also evolve, shifting its emphasis from definition and baselines to construction controls and then to integration, commissioning and readiness, and it must never lose sight of the human dimension. Programme delivery depends on people and organisations with different responsibilities and priorities; the PMO should promote clarity, trust, transparency, collaboration and accountability, connecting teams rather than isolating them behind procedures and reports. Its effectiveness should be judged by its contribution to governance, forecast reliability, decision timeliness, risk mitigation, interface resolution, change control, systems integration and operational readiness, not by its size or reporting volume.

In that sense, the PMO is the integrating engine of airport delivery. It connects governance with execution, projects with programme objectives, schedule with cost, risk with change, interfaces with delivery and construction with operational readiness. It does not replace project managers, technical specialists, commercial teams or operational stakeholders; it enables them to work within a coordinated programme. The measure of success is not a report that projects have been completed. It is an airport that is safe, secure, compliant, reliable, commercially viable and ready to operate, and that is what distinguishes an effective Programme Management Office from a conventional project controls function.