Talha Asif — Infrastructure & PMO Executive

Blog

  • Relocating to Riyadh: Learning an Entirely New Professional Operating System

    What I Prepared For and What Surprised Me

    When my family and I relocated to Riyadh in early 2025, I had prepared for the practical challenges: finding housing in a good school catchment area, sorting out the residency paperwork, researching the business registration requirements, lining up initial meetings before we arrived. I thought I was reasonably well prepared.

    What I was not prepared for was how different the texture of professional life would be. Not in ways that are better or worse than the Canadian professional environment I came from — just genuinely different in ways that take time to understand and genuinely adapt to, not just intellectually acknowledge.

    Decision-Making Pace

    The pace of organizational decision-making in the Saudi private and semi-private sector surprised me. When the right principal is in the room with genuine authority to act, decisions that would take weeks of committee review in a Canadian government context can happen in hours. For someone who spent years managing projects within Metrolinx’s governance framework — a structure designed for a provincial government agency with accountability to elected officials and public scrutiny — that speed is genuinely exhilarating.

    What takes longer is trust development. Business relationships in Saudi Arabia follow a different trajectory than their Canadian equivalents. In Toronto you can often move from initial meeting to commercial discussion in a relatively compressed timeline if the professional fit is clear. In Riyadh, the relationship needs to be established before business becomes a natural topic. That is not a cultural barrier. It is a different sequence — one where the investment in understanding each other as people comes first, and the professional collaboration follows naturally from that foundation. Professionals who try to skip that stage consistently underperform those who invest in it.

    The Language of Informal Relationships

    I arrived thinking that language would be my most significant barrier. I do not speak Arabic. I assumed that would be a constant obstacle in a country where Arabic is the language of government, daily life, and cultural life.

    In practice, the professional infrastructure and construction sector in Riyadh operates largely in English at the senior level. The language barrier I encounter is not in the formal meeting. It is in the informal conversation before and after the meeting — the human texture of relationship-building that happens in Arabic and that I cannot fully participate in. That matters more than I initially appreciated. Context gets built and relationships deepen in those informal moments. My Arabic deficit is felt there in a way it is not in the meeting room itself.

    My adjustment has been to invest in being present for those informal moments even when I cannot fully participate linguistically — to listen, to watch, to ask questions when appropriate, and to acknowledge honestly what I am still learning. It is a slower path. But it has been a more genuine one.

    Physical Scale and Ambition

    The physical scale of ambition in Riyadh has recalibrated my professional reference frame in ways that are difficult to convey without experiencing it directly. In Canada, a major infrastructure program at CAD 500 million is considered transformational. In Riyadh, programs at that scale are mid-tier. NEOM, Diriyah Gate, Red Sea Project, Qiddiya — these programs are operating at a scale that has no parallel anywhere else in the world right now.

    That recalibration changes what I bring to conversations. The framework I used for thinking about program complexity, risk management, and delivery governance needed to expand to match the scale of what is being attempted here. That expansion has been among the most professionally valuable aspects of the move.

    What I Would Tell Other Professionals Considering the Move

    It is more rewarding than it is difficult. But it is genuinely both. The professional opportunity in Riyadh for infrastructure and project management professionals with deep technical capability and the patience to build relationships properly is real and substantial. The scale of programs being delivered here creates demand for expertise that the Kingdom cannot yet fully supply domestically.

    Commit fully or do not come. The difference between professionals who are genuinely present in the market — living here, building relationships here, integrating into the city — and professionals who are passing through is visible and felt. My family is settled. My wife teaches. The children are in school. That commitment changes the quality of every professional relationship I have built here.

    Be patient with yourself and with the market. The recalibration takes time, and it should. A market that is building at this scale and this pace deserves professional humility from those of us who are learning it.

  • Saudi Arabia’s OTCC Framework: What Regulators Require and What It Means for Infrastructure Projects

    The Regulatory Context

    Saudi Arabia has one of the most developed OT cybersecurity regulatory frameworks in the Middle East. The National Cybersecurity Authority’s Operational Technology Cybersecurity Controls — known as the OTCC — establish the baseline requirements that critical infrastructure operators in the Kingdom are expected to meet. This is not a voluntary standard or a best-practice guideline. It is a regulatory expectation, and the NCA’s enforcement engagement across sectors has been progressively increasing.

    The OTCC applies to organizations that own or operate critical national infrastructure in Saudi Arabia: energy, water, transport, communications, health, and financial services. If you are delivering or operating infrastructure in any of these sectors in the Kingdom, the OTCC defines your regulatory baseline for OT security.

    The Five OTCC Domains

    OT Cybersecurity Governance is the first domain and the foundational one. It covers the organizational policies, roles, and responsibilities that define how OT security is managed at the institutional level. This includes having a designated OT security function — not just relying on the IT security team — documented policies for OT asset management, change control, and risk management, and integration of OT security into the organization’s overall risk management framework. Governance means accountability: someone in the organization needs to own OT security, have the authority to make decisions about it, and have the resources to execute those decisions.

    OT Risk Management is the second domain. It requires formal OT security risk assessments conducted on a defined cadence, maintenance of an accurate and current OT asset inventory (which most organizations do not have), and implementation of a risk treatment plan that addresses identified vulnerabilities in a prioritized and documented way. The risk management discipline the OTCC requires is not a one-time compliance exercise. It is an ongoing management practice that needs to be embedded in the organization’s standard operating procedures.

    OT Security Controls covers the technical measures that protect OT environments. Network segmentation between IT and OT networks is the most fundamental control — and the one most frequently absent in older facilities. Access controls including multi-factor authentication for remote connections. Configuration management for controllers and systems, ensuring that changes to OT system configurations are tracked, approved, and reversible. Patch management processes designed for the OT environment, which often cannot be patched on the same schedule as IT systems without affecting process continuity.

    OT Security Operations covers the monitoring, detection, and incident response capabilities that enable organizations to identify threats and respond to them. This is the area where most OT environments are most exposed. Network monitoring that is standard in enterprise IT — intrusion detection, anomaly alerting, traffic analysis — is frequently absent in OT networks. The monitoring gap is significant: you cannot detect and respond to threats you cannot see.

    OT Supply Chain Security addresses the security of third-party vendors, integrators, and service providers who have access to OT systems. This is particularly relevant for infrastructure projects where the controls vendor, commissioning team, and ongoing support provider all typically have remote access paths into the OT environment. The OTCC requires that these access paths be managed — not just opened and forgotten.

    What This Means for Project Design

    For infrastructure projects in design or construction, OTCC requirements translate into specific design decisions that need to be made while the project is still being engineered. Network architecture must provide appropriate IT/OT segmentation. Control system design must accommodate the access control requirements the OTCC specifies. Commissioning procedures must include OT security validation alongside process safety validation.

    The critical point is timing. These are not features that can be economically retrofitted after commissioning. They are design decisions. A network segmentation architecture specified at 30% design completion costs a fraction of what the same segmentation costs after a system has been commissioned with a flat network architecture.

    At Concept Dash, our OT cybersecurity team — working through our partnership with our NACSA-licensed cybersecurity partner — helps project teams translate OTCC requirements into design specifications and commissioning requirements before the design window closes. Reach out for a complimentary gap assessment if your infrastructure project has not yet addressed OT security in the design scope.

  • Riyadh Metro: What the World’s Largest Metro Construction Program Teaches About Multi-Package Delivery

    The Scale of the Ambition

    When Saudi Arabia’s government awarded the Riyadh Metro contracts in 2013, the program represented one of the most ambitious urban transit delivery decisions in history. Six metro lines. 176 kilometres of route. 85 stations. More than SAR 60 billion of construction contracts awarded simultaneously to five international consortia. And a delivery timeline that required a significant portion of the network to be operational within a decade.

    The delivery structure divided the network by corridor. The BACS consortium — a joint venture bringing together Bechtel, Almabani, CCC, and Siemens — took responsibility for Lines 1 and 2, the north-south and east-west spines of the network. The ANM consortium covered Line 3, the northern connector. The FAST consortium — combining FCC, Alstom, Samsung, Strukton, and Freyssinet — delivered Lines 4, 5, and 6.

    This multi-package structure was a deliberate choice. A single program management contractor managing the full network would have been the alternative — but the scale was too large and the timeline too compressed for a single entity to absorb the delivery risk. Dividing by corridor distributed the execution risk while maintaining a unified technical standard managed by the Royal Commission for Riyadh City as the program authority.

    What Made It Work

    The technical integration challenge — six lines from five consortia that needed to work as a seamless operational network — was addressed through a rigorous interface management framework. System-wide standards for track gauge, electrification, signalling, and rolling stock compatibility were established before the contracts were awarded. Each consortium built to those standards. The integration was achieved at the level of technical specification, not through a single delivery entity.

    The scale of international expertise brought to the program was exceptional. The consortium structure allowed Riyadh to draw on the combined experience of firms that had delivered metro systems across Europe, Asia, and the Americas. That expertise was not available in a single company. The multi-package approach made it accessible.

    The speed of delivery — from ground-breaking to initial operations on Lines 1-3 in under a decade — was enabled by parallel construction across all six lines simultaneously. A sequential delivery approach — complete one line, then start the next — would have been operationally simpler but would have extended the program by years. Parallel delivery required exceptional program management capability from the Royal Commission, but it achieved a network opening timeline that would have been impossible through any other approach.

    The Lessons That Apply Beyond Riyadh

    Interface management at program scale requires a dedicated function, adequate authority, and pre-agreed resolution mechanisms. When five consortia are building systems that need to work together, interfaces between their work packages are the single most dangerous source of delay and dispute. The Riyadh Metro program established an interface management framework that identified interface events, assigned ownership, and tracked resolution. That function needs to be resourced as a first-class program management activity, not a secondary coordination role.

    Owner capability must grow with program scale. The Royal Commission for Riyadh City developed substantial program management capability through the Metro delivery. That institutional growth — in commercial management, technical oversight, and stakeholder management — was a program outcome as valuable as the physical infrastructure. It positioned the Kingdom for the next generation of urban transit programs with a depth of institutional experience that did not exist before.

    Rolling stock and systems integration timelines control operational readiness more than civil works timelines. The most common source of metro opening delays globally is the integration of train control systems, rolling stock, and civil infrastructure into a functioning operational system. Building the systems integration timeline into the master program schedule from the beginning — with appropriate float and staged commissioning sequences — is essential for realistic operational readiness planning.

    The Western Station — Riyadh Metro’s most architecturally significant station, now complete and operational — represents the program’s highest-profile delivery. Its opening marks a milestone in a program that has genuinely transformed the mobility infrastructure of one of the world’s fastest-growing cities. The lessons of how it was delivered will inform transit programs across the region for the next generation.

  • Schedule Risk in Mega-Programs: Leading Indicators That Prevent Delay

    The Schedule Failure Pattern

    After managing rail corridor projects, highway rehabilitation programs, and billion-dollar transit delivery at Metrolinx, I have observed a consistent pattern in schedule failures on large infrastructure programs: the delay is visible in the data long before it is acknowledged in the report.

    The projects that finish late almost always showed warning signs six to twelve months before the delay became undeniable. Those warning signs were present in the schedule data, in the procurement lead time tracking, in the RFI log, and in the change order trend analysis. But the systems that would have aggregated those signals into an early warning were absent, or the culture that would have surfaced the warning to decision-makers was not in place.

    The problem on most delayed mega-programs was not that the delay could not have been seen coming. It was that no one was looking for it systematically and honestly.

    The Difference Between Leading and Lagging Indicators

    A lagging indicator tells you what has already happened. Schedule performance index, actual progress against planned progress, percentage complete — these are lagging indicators. They tell you, with accuracy, that you are behind. They do not tell you why, or how far behind you will be at completion, or what to do about it.

    A leading indicator tells you what is likely to happen if current conditions persist. A leading indicator for schedule risk might be the trend in RFI response time — if the designer is taking three weeks to respond to RFIs that should be turned around in three days, that is a leading indicator of design coordination problems that will create field disruption in 4-8 weeks. Or the trend in planned versus actual drawing release dates — if drawings are consistently releasing two weeks later than the schedule requires, the construction activities dependent on those drawings are carrying two weeks of unplanned float that will eventually become a delay.

    Effective schedule risk management requires both, with an emphasis on leading indicators proportional to the time horizon of the program. A mega-program with 48 months of construction remaining needs a robust leading indicator system. A program with 6 months remaining needs lagging indicators — there is no longer enough time for leading indicators to produce actionable early warning.

    Critical Path Monitoring

    The critical path is the sequence of activities that determines the project’s completion date. Monitoring the critical path means monitoring the activities on that sequence — their progress, their resource loading, their dependencies, and the float that separates them from near-critical activities that could become critical if conditions change.

    On complex mega-programs, the critical path is not static. It migrates as work advances, as sequence changes are approved, as acceleration or de-acceleration of different work packages changes the relative timing of activities. A project control system that identifies the critical path at baseline and monitors it without reassessing which path is actually critical at any given point in the project lifecycle is providing false assurance.

    I built Project Management dashboards at Metrolinx that integrated critical path monitoring with a four-week lookahead schedule, current EAC variance reporting, and change order trend analysis. That integration — seeing critical path progress, near-term lookahead, cost trajectory, and commercial trend in a single view — is what enables proactive management rather than reactive reporting.

    Recovery Planning: When to Invoke It and How

    Recovery planning — the development and analysis of schedule recovery strategies — should be triggered by leading indicator signals, not by the point at which delay has become undeniable. When the leading indicators are trending negative and the critical path analysis shows a completion exposure, that is the time to develop recovery options — before the delay has materialized in the schedule record.

    Recovery options fall into several categories: acceleration of critical activities through additional resources or extended work hours; sequence changes that allow work to proceed in parallel rather than in series; scope adjustments that defer non-critical scope elements to reduce the critical path duration; and commercial mechanisms that realign incentives toward delivery performance.

    Each recovery option has a cost, a feasibility constraint, and a time horizon for effectiveness. Recovery planning is the analysis of which options are available, what they cost, and which combination produces the best balance of schedule recovery and cost exposure. It is a professional planning discipline, not a crisis response exercise. Treating it as the latter produces worse outcomes than treating it as the former.

    Building a PMO Control System That Catches Problems Early

    The organizational capability that makes leading indicator monitoring possible is the program management office — specifically, a PMO with the analytical capability to synthesize data from multiple systems into early warning signals, and the organizational authority to surface those signals to decision-makers without them being filtered by project teams protective of their schedule.

    The PMO design choices that matter most for schedule risk management are: independent reporting authority (the PMO should report to program leadership, not to the project team whose schedule it is monitoring), analytical depth (schedule analysts who can interrogate the programme rather than just read it), integration with procurement tracking (schedule risk almost always has a procurement component), and a cadence of honest schedule assessment that is separate from the project team’s status reporting.

  • What an OT Security Assessment Actually Involves: A Practical Guide for Infrastructure Projects

    Making OT Cybersecurity Practical

    Over the past weeks I have made the case that OT cybersecurity is an engineering design problem, not an IT department problem. This article makes that case practical: what does an OT security assessment actually involve, what does it produce, and what does it mean for the way a project is designed and delivered?

    What an OT Security Assessment Is

    An OT security assessment is a structured evaluation of the cybersecurity posture of an operational technology environment. It covers the systems that control physical processes — PLCs (Programmable Logic Controllers), SCADA systems (Supervisory Control and Data Acquisition), DCS (Distributed Control Systems), SIS (Safety Instrumented Systems), HMI workstations (Human Machine Interfaces), and the network infrastructure that connects them.

    For infrastructure projects, the most relevant international framework is IEC 62443 — the international standard for industrial automation and control systems security. In Saudi Arabia, the NCA’s Operational Technology Cybersecurity Controls (OTCC) establish the regulatory baseline. These two frameworks overlap significantly and together define what good OT security looks like in this region and market.

    Scope of a Comprehensive OT Assessment

    Asset inventory and identification is the starting point. This sounds simple; it rarely is. Most operational facilities do not have an accurate, current inventory of their OT assets — what controllers they have, what software versions they run, how they are connected, who has access to them. Building that inventory is a prerequisite for everything else. Without it, you cannot assess vulnerability, cannot prioritize mitigation, and cannot demonstrate compliance.

    Network architecture review examines how the OT network is structured and how it relates to the corporate IT network and external connectivity. The fundamental principle of OT network security is segmentation — the OT network should be separated from the IT network by a defined boundary (typically a demilitarized zone) that controls and monitors the flow of information between them. Many operational facilities, particularly those built before OT cybersecurity became a serious design consideration, have flat network architectures where IT and OT systems are on the same network segment. This is the condition that made the Triton attack possible: the attackers could reach the safety controllers from the corporate network because the segmentation boundary did not exist.

    Vulnerability assessment identifies specific known vulnerabilities in the OT assets identified in the inventory. OT systems run specialized software, including real-time operating systems, controller firmware, and HMI applications that often run on versions of Windows that are no longer supported by Microsoft — because the OT vendor’s engineering software has not been updated to run on current Windows versions and the vendor’s update schedule is not aligned with Microsoft’s. This creates a patching problem that is fundamentally different from IT security: in IT, the answer to an unpatched operating system is to update it; in OT, the update may break the process control application, and the update cycle is measured in years, not months.

    Access control review examines who has access to OT systems and how that access is managed. Remote access — used by controls vendors for monitoring and support — is one of the most significant and most undercontrolled access paths in OT environments. Many OT systems have remote access channels installed by vendors during commissioning that remain active, unmonitored, and without multi-factor authentication for the life of the system.

    Incident response assessment covers the organization’s capability to detect, respond to, and recover from OT security incidents. In most OT environments, this capability is underdeveloped or absent. There is no OT-specific incident response procedure. There is no OT network monitoring that would alert operations staff to anomalous activity. The water treatment attack in Oldsmar, Florida succeeded in reaching the SCADA system because there was no monitoring that would have detected the intrusion — it was caught by a human who happened to be watching.

    Assessment Output and Project Integration

    A properly scoped OT security assessment produces a risk-ranked findings report, a gap analysis against the applicable framework (IEC 62443 and/or NCA OTCC), and a remediation roadmap that prioritizes findings by risk level and provides specific technical and procedural recommendations for each.

    For projects in design or construction, the assessment findings translate directly into design specifications. Network segmentation requirements become network architecture drawings. Access control requirements become commissioning standards. Monitoring requirements become scope items for the control system integrator.

    This is where the design stage timing matters most. Incorporating OT security requirements into the design scope costs a fraction of retrofitting them after commissioning. A network segmentation architecture specified at 30% design becomes a standard part of the control system procurement. The same requirement identified after a system has been commissioned requires physical network modifications, software reconfiguration, and often a controls vendor engagement that costs 10-20 times what the original specification would have cost.

    Concept Dash’s OT cybersecurity team offers complimentary gap assessments for infrastructure operators in Saudi Arabia. If your facility or program has not addressed OT security in the design scope, reach out before the design is committed — not after.

  • Australia’s PPP Maturity Journey: 30 Years of Lessons for Saudi Arabia’s P3 Program

    The Early Failures: Demand Risk and the Toll Road Experience

    Australia was among the first countries to develop a substantial P3 program for infrastructure delivery, beginning in earnest in the 1990s. The early transactions were focused on toll roads — an asset class where the demand risk case for private sector financing seemed clear. Build a road, charge users, let the private sector earn a return from the traffic it generates.

    Several of these early transactions produced serious financial problems. The Sydney Cross City Tunnel, the Lane Cove Tunnel, and the Brisbane Airport Link all experienced demand shortfalls severe enough to push concession companies into administration or financial restructuring. Traffic forecasts — used to justify the project’s financial structure — proved significantly optimistic. The private sector had accepted demand risk under the assumption that traffic would follow the infrastructure. In several cases it did not, at least not quickly enough to service the project’s debt.

    The political response was significant. Governments had guaranteed minimum revenue on some transactions and were called upon to make payments that had not been budgeted. Public perception shifted toward skepticism about whether private sector involvement produced value for taxpayers or simply shifted risk to them through the back door.

    The Adaptation: Availability Payments and Social Infrastructure

    Australia’s response to the toll road failures was to shift P3 activity toward social infrastructure — hospitals, schools, courts, correctional facilities, and public transport — using availability payment structures rather than user fee concessions.

    The availability payment model addressed the demand risk problem directly. Instead of the private sector earning revenue from users — and bearing the risk that user demand would not materialize — the government paid a service fee conditional on the asset being available and performing to standard. Demand risk stayed with government. The private sector bore construction risk and performance risk — risks they could actually manage.

    This shift produced much more stable outcomes. Social infrastructure PPPs delivered under availability payment structures in New South Wales, Victoria, and Queensland delivered assets on time and on budget at rates significantly better than equivalent public procurement. Performance monitoring frameworks kept concessionaires accountable through the operational phase. The experience built institutional confidence on both sides — government procurers who understood how to structure transactions and concessionaires who understood how to deliver them.

    The National PPP Guidelines

    One of Australia’s most significant contributions to global P3 practice was the development of standardized national procurement guidelines — the National Public Private Partnership Policy and Guidelines — establishing a consistent framework across all Australian jurisdictions.

    These guidelines established standard risk allocation positions across infrastructure types, reducing the transaction cost of P3 procurement by giving bidders predictable starting points. They required public sector comparator analysis — demonstrating that private finance produced genuine value relative to public procurement — as a discipline against optimistic assumptions about the cost of risk transfer. They established market engagement principles requiring government to consult with potential bidders during transaction development to test market appetite and identify structural barriers to competition.

    The standardization produced genuine efficiency gains. Transaction costs fell as bidders became familiar with the framework. Bid preparation costs declined as document formats and due diligence requirements became predictable. Competition improved as the market developed a class of experienced bidders who could assess and price P3 risk reliably.

    The Financing Market Depth

    One of the most significant differences between a mature P3 market and an emerging one is the depth of the domestic financing market. Australia’s P3 program developed alongside a deep superannuation fund sector — large institutional investors managing retirement savings with long investment horizons and preference for stable, inflation-linked returns that align well with availability payment P3 cash flows.

    This domestic capital base reduced Australia’s P3 dependence on international financing markets and produced more competitive financing terms than programs that rely primarily on bank debt. It also created a class of sophisticated infrastructure investors who understand the asset class and can deploy capital efficiently on new transactions.

    The Most Valuable Lesson

    The most important lesson from Australia’s P3 maturity journey is that getting the framework right takes iteration. No market gets it perfectly right the first time. What distinguishes markets that develop strong P3 programs is not that they avoided mistakes — Australia made significant mistakes — but that they learned from them systematically and adapted their frameworks in response.

    Saudi Arabia is moving faster than Australia ever did. The 220-transaction NPS target by 2030 is an ambitious pace that creates opportunity and risk simultaneously. The opportunity is transformational public asset delivery. The risk is scaling faster than the institutional capability to manage the program develops. Australia’s experience suggests that investment in institutional capability — in the people, systems, and frameworks that govern P3 programs through their operational phase — is as important as investment in the transactions themselves.

  • From PFI to PF2: What the UK’s Public Private Partnership Correction Teaches Saudi Arabia

    The PFI Model and What It Was Trying to Solve

    The UK’s Private Finance Initiative was launched in 1992 as a response to a genuine problem: the government wanted to invest in public infrastructure but was constrained by public sector borrowing limits. PFI offered a solution — private sector capital finances the construction of public assets, which are then leased back to the government over long concession periods in exchange for availability payments. The private sector bears construction and performance risk. Government avoids upfront capital expenditure. The public gets new hospitals, schools, and transport infrastructure.

    The logic was sound in principle. By 2018, the UK had signed more than 700 PFI contracts with a combined capital value of approximately £170 billion. Contracts spanning hospitals, schools, prisons, defence facilities, and transport infrastructure. Some of the world’s most complex infrastructure P3 transactions were structured under the PFI banner.

    What Went Wrong

    The problems that eventually undermined PFI’s political credibility were not accidental. They were structural features of the original model design that produced predictable outcomes over time.

    The refinancing windfall problem emerged clearly within the first decade of PFI contracts. Many early PFI transactions were financed at relatively high interest rates reflecting the uncertainty of a new and untested model. As the model proved itself and lender confidence grew, consortia refinanced their project debt at lower rates — generating significant financial gains that under the original contracts flowed entirely to the private sector. The National Audit Office documented cases where refinancing gains ran to tens of millions of pounds on individual transactions. Public perception of these gains — representing public subsidy being converted to private profit — created significant political damage.

    Flexibility constraints created operational problems that compounded over time. A hospital PFI signed in 1997 under a 30-year concession needed to manage the introduction of new medical technologies, changing clinical models, infection control requirements, and evolving maintenance standards. The contract’s variation mechanism — designed for occasional changes of limited scope — was not equipped to manage the pace and scale of change that healthcare delivery underwent. Simple changes that could be accomplished in a directly managed public facility in days required weeks of formal variation process and often resulted in pricing disputes. The transaction cost of managing contract variations became a significant operational burden on NHS trusts.

    The financing premium — the difference between PFI financing costs and equivalent public borrowing — proved larger and more persistent than the model’s architects anticipated. The National Audit Office estimated financing costs approximately 2-4% higher than public sector equivalent borrowing across the program. Across £170 billion of commitments, that differential compounds to an enormous aggregate cost over concession lifetimes.

    The PF2 Reform and Why It Fell Short

    The government’s 2012 PF2 reforms were a genuine attempt to address the most documented PFI problems. Public sector equity participation of 25% would give government a share of refinancing gains and a governance presence in consortium management. Risk transfer was to be refined toward risks the private sector could genuinely manage. Standardized contracts would reduce transaction costs. Benchmarking requirements would keep facilities management pricing competitive.

    The reforms were technically sound. But the political environment around PFI had deteriorated beyond the point where technical reforms could restore confidence. By 2012, PFI had become politically toxic in a way that transcended the specific structural problems. The announcement that no new PFI contracts would be signed effectively ended the program before PF2’s innovations could be tested at scale.

    Lessons for Saudi Arabia’s National Privatization Strategy

    Saudi Arabia’s NPS is structuring a P3 program with the full visibility of what went wrong in the UK. That visibility should be used deliberately, not merely acknowledged.

    Design risk allocation around what the private sector can actually control. Construction execution, lifecycle maintenance, and operational performance are risks the private sector manages well when the contract gives them genuine control. Regulatory risk, policy change, and public sector interface risks should be retained or shared — not transferred at a premium the concession cannot absorb.

    Build refinancing sharing from the beginning. This problem is entirely preventable through contract drafting. Revenue sharing, clawback provisions, and equity participation arrangements exist as well-documented contract structures. There is no reason for Saudi P3 contracts to recreate the UK’s refinancing windfall problem.

    Invest in contract flexibility architecture. The variation mechanisms in Saudi P3 contracts need to be designed for the pace of change in their sectors — particularly in health, education, and technology-dependent infrastructure. Pre-agreed pricing methodologies and structured variation procedures reduce the transaction cost of managing change throughout the concession period.

    The UK’s experience is not an argument against P3. It is an argument for structuring P3 correctly. Saudi Arabia has that opportunity. The question is whether the pace of the NPS program allows time to apply these lessons carefully as each sector is brought into the framework.

  • Availability Payment Regimes: How Performance Deduction Frameworks Shape Concessionaire Behaviour

    Why Availability Payments Work

    The availability payment model is the payment structure that makes P3 infrastructure delivery function in contexts where demand risk transfer to the private sector is inappropriate or unaffordable. Instead of the concessionaire earning revenue from users — and bearing the risk that those users will not appear in the numbers the financial model assumes — the government pays a service fee conditional on the asset being made available and performing to defined service standards.

    The model elegantly separates the risks the private sector can genuinely manage (construction quality, lifecycle maintenance, operational performance) from the risks it cannot (user demand, which is driven by public sector service and policy decisions). A hospital P3 concessionaire has no control over whether the clinical services in the hospital attract enough patients to justify the facility’s size. They do have control over whether the facility is clean, well-maintained, and operationally available to deliver whatever level of clinical service the health authority chooses to provide. The availability payment pays for the latter. The clinical activity risk stays with the health authority.

    How the Deduction Framework Works

    The availability payment is not a fixed annual fee. It is a baseline payment subject to deduction when the facility fails to meet the performance standards defined in the contract. The deduction framework is the mechanism through which the payment structure creates operational incentives for the concessionaire.

    Well-designed deduction frameworks share several characteristics. They are proportionate — the deduction for each performance failure reflects the severity of that failure’s impact on service delivery, not an arbitrary penalty that may be too small to motivate performance or too large to be commercially sustainable. They are certain — the concessionaire can calculate the financial consequence of any performance failure precisely, which allows them to make rational investment decisions about maintenance and operational staffing. They are focused — monitoring a small number of indicators that genuinely drive service quality produces better outcomes than monitoring a large number of indicators that create reporting burden without improving performance.

    Poorly designed deduction frameworks produce predictable problems. If deductions are too small relative to the cost of compliance, the concessionaire will rationally choose to accept deductions rather than invest in performance. If deductions are too large, the concessionaire will adopt risk-averse operational strategies that reduce service flexibility and add cost. If the monitoring framework is too complex, disputes about measurement methodology consume governance resources that should be focused on service delivery.

    The Response Time Trap

    One of the most common deduction framework design errors is calibrating response time requirements to the availability of resources in a high-performing major city. A requirement to restore a failed HVAC system in a hospital to full operation within 4 hours might be achievable in London or Toronto, where specialist maintenance contractors are available 24 hours. In a remote location, or during extreme weather, or during a period of supply chain disruption, that same requirement may be structurally impossible to meet regardless of how capable and well-resourced the concessionaire is.

    Deduction frameworks that do not account for location, access constraints, and supply chain realities produce deduction charges that the concessionaire disputes — correctly — as arising from conditions outside their control. The disputes consume governance resources. The relationship deteriorates. The contract’s commercial framework is undermined by provisions that were not designed for the actual operating environment.

    Designing for Saudi Arabia’s Infrastructure Context

    Saudi Arabia’s P3 program is deploying availability payment structures across a diverse portfolio of infrastructure types and geographic locations — from urban social infrastructure in Riyadh to remote industrial facilities in the Eastern Province. Calibrating deduction frameworks to the specific context of each concession — not importing frameworks developed for European urban programs and applying them to desert-climate, remote-location Saudi facilities — is essential for producing frameworks that actually incentivize performance rather than incentivize disputes.

    The frameworks being developed for Saudi Arabia’s water sector — building on three decades of BOOT experience — provide a valuable starting point. The commercial discipline embedded in those frameworks, and the institutional knowledge of what works and what does not in the Kingdom’s operational environment, should inform the structures being developed for new sectors as the NPS expands P3 delivery beyond water into health, education, and transport.

  • The OnCorr Model: What Metrolinx’s Mega Transit Contracts Teach About Large-Scale Delivery

    The Background

    To understand what OnCorr was designed to solve, you need to understand what came before it. Metrolinx had spent more than a decade delivering transit infrastructure through traditional procurement models — design-bid-build contracts, consultant-led design with contractor construction, sequential delivery stages. The results were mixed. Some projects delivered within budget and schedule. Many did not. And the scale of the programs being contemplated under Ontario’s transit expansion commitments — GO Regional Express Rail, the Ontario Line, the Eglinton Crosstown extensions — exceeded the capacity of traditional procurement to manage efficiently.

    OnCorr — the Corridor and Station Infrastructure programs — was Metrolinx’s response. Rather than procuring individual projects through traditional competitive tendering, the agency structured large-scale, long-term contracts covering entire transit corridors. The theory was that corridor-scale contracts would produce better outcomes: deeper contractor investment in the program, more efficient supply chain development, better coordination across interdependent work packages, and more meaningful risk transfer to parties with the capacity to manage it.

    The Consortium Structure

    OnCorr contracts were structured as joint ventures between major infrastructure firms with complementary capabilities. The corridor contracts attracted some of the most significant infrastructure companies active in the Canadian market.

    For Lines 1 and 2 (now identified as the Bloor-Danforth and Yonge-University subway corridors), the BACS consortium — bringing together major contractors with deep subway rehabilitation experience — took on the program. For Line 3, the ANM consortium led delivery. For Lines 4, 5, and 6 — the Sheppard, Eglinton, and Finch corridors — the FAST consortium structured the delivery approach.

    The consortium model was intended to concentrate capability. A single consortium responsible for a full corridor could develop systems knowledge, supplier relationships, and workforce capacity that individual project contractors could not. The theory was sound. The execution created challenges that were not fully anticipated at the time of contract structuring.

    What the Model Revealed

    Large transit programs are not merely engineering challenges. They are commercial, financial, and governance systems that need to function together across very long delivery horizons. The OnCorr model revealed several structural tensions that deserve serious analysis, particularly for anyone structuring ambitious transit programs in the Gulf.

    Corridor-scale contracts create market concentration in ways that reduce the competitive discipline that large programs normally benefit from. When a single consortium controls the delivery of an entire corridor — potentially across a decade or more of work — the owner’s leverage in commercial negotiations progressively diminishes as the program advances. The consortium has made significant system investments. Replacing them creates disruption that the owner cannot easily absorb. The contract must be designed to maintain commercial tension in the absence of competitive market pressure.

    Scope uncertainty in transit rehabilitation programs — where the condition of aging underground infrastructure is only fully understood once the work starts — creates systematic change order pressure that the commercial framework needs to be designed to manage. In a corridor-scale contract, that pressure accumulates across a very large scope base. Change management frameworks that work for individual projects may not scale to program-level delivery without modification.

    Governance at the program level is structurally more complex than project-level governance. The interfaces between the consortium’s delivery approach and Metrolinx’s operational requirements — maintaining service during construction, coordinating with other transit agencies, managing community impacts — require governance mechanisms that were still evolving as the programs advanced.

    Lessons for Saudi Arabia’s Transit Ambitions

    Saudi Arabia’s rail and transit programs — including Riyadh Metro’s ongoing expansion, Saudi Railway Organization programs, and the transit elements of giga-project delivery — face analogous structuring challenges. The scale is larger. The timeline is more compressed. And the institutional experience with transit P3 and progressive delivery is less developed than Canada’s, which itself was still learning.

    The lessons from OnCorr that apply most directly to the Saudi context: ensure that contract scope is as well-defined as possible before award, build structured change management frameworks that can handle scope evolution without creating adversarial dynamics, design governance structures that match the pace of progressive delivery rather than the cadence of traditional procurement review, and maintain commercial mechanisms that keep consortium performance incentivized across the full program duration.

    The OnCorr model’s ambition was correct. The execution challenges it encountered were instructive, not disqualifying. Saudi Arabia’s program authorities have the advantage of this experience to draw on as they structure their own corridor-scale delivery programs.

  • The Preconstruction Phase: Where Progressive Contracting Wins or Loses

    What Preconstruction Actually Is

    The most expensive mistake on a CMAR or Progressive Design-Build program is treating preconstruction as a formality — a period of CM engagement before the ‘real’ project starts. Preconstruction is not a courtesy invitation. It is the core delivery mechanism through which progressive contracting produces better outcomes than traditional procurement.

    Everything that makes progressive contracting superior happens in preconstruction — or it does not happen at all. Design decisions get informed by construction knowledge. Costs get tracked as they develop rather than discovered at tender. Risks get identified and mitigated while there is still design flexibility to address them. The GMP reflects reality rather than optimism. When preconstruction is done properly, construction proceeds with fewer surprises, fewer disputes, and better alignment between the cost committed and the cost delivered.

    Five Core Preconstruction Activities

    Constructability reviews are the foundational preconstruction activity. The CM’s construction specialists review design documents at each milestone with a single purpose: to identify design decisions that will create problems during construction. Not aesthetic issues. Not scope additions. Design decisions that are going to be difficult or expensive to build as drawn, or that will create safety, sequence, or access problems in the field.

    The value of constructability review is almost entirely a function of timing. A constructability comment at schematic design — before structural and mechanical systems are sized, before details are drawn — costs almost nothing to incorporate. The same issue identified at 90% design development requires a change to coordinated drawings, updated structural calculations, revised specifications, and a change order notice. The same issue identified after construction starts costs a change order, a delay, a crane stand-down, and a relationship problem. Early identification is where the value is created.

    Cost estimating in preconstruction is not a point-in-time activity. It is a continuous process, run in parallel with design development, that maintains a current and accurate assessment of where the project cost is tracking against the owner’s budget. The CM’s estimating team builds and updates the open-book estimate as design decisions are made, keeping the project’s financial trajectory visible in real time rather than as a surprise at GMP establishment.

    Value engineering is one of the most misunderstood activities in preconstruction. Genuine value engineering is not cost cutting. It is a structured analysis of design alternatives that identifies ways to achieve the same functional outcome with a different approach — one that costs less, takes less time, carries less risk, or is more buildable. When done properly, it produces alternatives that the designer and owner evaluate on their merits. When done poorly — which is common when the CM treats VE as a GMP negotiation tactic — it produces a list of scope reductions that the owner rejects and the CM uses as justification for a higher contingency.

    Schedule development in preconstruction means building a construction programme that reflects how the project will actually be sequenced and executed, not a theoretical schedule that satisfies a contract requirement. The CM’s planning team should be developing the construction method and sequence, identifying the critical path, and calibrating the programme against the resources that will actually be available. A schedule built this way is actionable. A schedule built to show the owner what they want to see is noise.

    Procurement planning addresses the materials, equipment, and subcontract work that need to be initiated before construction starts. Long-lead items — mechanical equipment, specialty materials, manufactured components — that require 16-24 weeks of lead time after order need to be identified and potentially ordered before the GMP is established, or the procurement timeline will control the construction schedule in ways that no amount of good programme management can resolve.

    GMP Timing: When to Commit

    The question of when to establish the GMP is one of the most important decisions in CMAR delivery. Establish it too early — at 40-50% design development — and the estimate is too uncertain, contingency is too high, and the GMP does not reflect reality. Establish it too late — at 95% design development — and the benefit of early contractor involvement has been largely consumed without the price certainty that the owner needs.

    The industry-standard range is 60-90% design completion, calibrated to the specific project type. Complex underground infrastructure warrants waiting for higher design maturity before committing. More straightforward above-ground programs can establish the GMP at lower design completion with acceptable contingency levels.

    Failure Modes

    The CM treats preconstruction as business development rather than delivery. They are focused on winning the GMP rather than producing value during preconstruction. Constructability reviews are thin. Cost estimates are padded. The schedule is aspirational. Problems that should be resolved during preconstruction arrive as construction-phase change orders.

    The owner is not available to make decisions. Preconstruction requires the owner to participate, not observe. When the owner’s governance process requires six weeks of review for every design decision, the collaborative tempo that makes CMAR valuable is impossible to achieve.

    The designer and CM do not genuinely collaborate. Constructability review degrades into a formality. The designer presents completed design. The CM comments. The designer’s response is minimal. The opportunity for genuine improvement is lost.

    For Saudi Arabia’s infrastructure programs — where the pressure to compress timelines and accelerate delivery is constant — the temptation to shortcut preconstruction is real and persistent. Resist it. The cost of rigorous preconstruction, typically 2-5% of total project value, is repaid many times over through cost certainty at GMP, reduced construction-phase change orders, and better schedule performance.

Powered by
►
Necessary cookies enable essential site features like secure log-ins and consent preference adjustments. They do not store personal data.
None
►
Functional cookies support features like content sharing on social media, collecting feedback, and enabling third-party tools.
None
►
Analytical cookies track visitor interactions, providing insights on metrics like visitor count, bounce rate, and traffic sources.
None
►
Advertisement cookies deliver personalized ads based on your previous visits and analyze the effectiveness of ad campaigns.
None
Powered by