The Scale Challenge
When a national telecommunications operator commits to rolling out fiber-to-the-home across an entire country, the project transforms from a construction programme into a national infrastructure campaign. I spent ten years inside exactly such a programme — the STC national FTTH rollout across Saudi Arabia — and the lessons from that experience reshape how I approach every project controls challenge today.
A national FTTH rollout is not one project. It is hundreds of micro-projects stitched together by a master schedule, a shared supply chain, and a common quality framework. At peak, we were managing over twenty concurrent active sites across multiple cities, each at different stages of design, permitting, civil works, cable installation, splicing, testing, and activation. The complexity is not in any single step — it is in the orchestration.
Master Network Design: Starting From the Top
Before a single trench is dug, the master network design must be complete. This is where the programme architecture is defined: where the optical line terminals (OLTs) will sit in the central offices, how the fiber distribution network fans out from there, where the splitter cabinets will be placed in neighborhoods, and how the drop cables reach individual homes. Every decision at this level cascades down to thousands of site-level activities.
The master design is driven by demand forecasting — predicting which neighborhoods will have sufficient take-up to justify the infrastructure investment. In the STC programme, we used a combination of demographic data, existing copper-line penetration, competitive analysis from rival operators, and regulatory targets to prioritize rollout zones. The demand model directly feeds the project schedule: areas with higher predicted take-up get scheduled first, creating an early revenue stream that helps fund the later phases.
What makes this challenging from a project controls perspective is that the demand model is never perfectly right. Neighborhoods that looked promising on paper sometimes had low actual take-up because of building access restrictions, landlord resistance, or simply competitive overbuild. The controls system must be agile enough to reallocate resources when the demand picture shifts, without losing visibility of the overall programme trajectory.
The Permitting Gauntlet
In Saudi Arabia, as in most countries, the permitting process is the single biggest source of schedule risk in an FTTH rollout. Every municipality has its own requirements, its own approval timelines, and its own interpretation of national regulations. A trench permit that takes two weeks in one district might take eight weeks in the neighboring one — not because the work is different, but because the administrative process differs.
The key to controlling this risk is a permit tracking system that treats every permit as a critical-path item with its own mini-schedule. Each permit has a submission date, a expected approval date, a follow-up protocol, and an escalation path. When a permit stalls, the escalation must be immediate — not after it has already delayed the civil works by three weeks.
In the STC programme, we built a permit dashboard that showed the status of every active permit across all sites, color-coded by days pending. Any permit sitting for more than ten days without movement was flagged red and automatically escalated to the municipal liaison team. This single control mechanism reduced permit-related delays by approximately forty percent in the first six months of implementation.
Site-Level Execution: Where the Programme Meets the Ground
Each FTTH site follows a standard workflow: detailed design, permit acquisition, civil works (trenching and duct installation), cable pulling, splicing, testing, and activation. The workflow is well-understood — the challenge is executing it across twenty or more sites simultaneously while maintaining consistent quality and schedule.
The most effective approach I found was to standardize the site workflow into a set of discrete work packages, each with its own acceptance criteria and quality checks. A site does not move from civil works to cable pulling until the civil works package has been inspected and signed off. This sounds obvious, but in practice, the pressure to accelerate often leads to overlapping phases — cable pulling starting before duct installation is fully complete — and the result is almost always rework.
The project controls system must track each site through these work packages independently. A site-level dashboard showing the current stage of each site, with the planned versus actual dates for each work package, gives the programme team immediate visibility of where things are slipping. When a site falls behind, the question is not just "how do we catch up?" but "what is the root cause?" — is it a resource shortage, a quality issue, a permit delay, or a design problem?
Supply Chain: The Hidden Critical Path
Fiber cable, ducts, splitters, OLT cards, ONT units — the materials list for a national FTTH rollout runs into thousands of line items. The supply chain is often the hidden critical path: a single delayed component can halt activation across multiple sites.
In the STC programme, we managed supply chain risk through a combination of long-lead procurement (ordering critical items six months ahead of need), dual-sourcing for key components, and a buffer stock at the regional warehouses. The project controls system integrated with the procurement system so that any material shortage was visible on the same dashboard as the schedule status — a site might be ready for cable pulling, but if the cable is not in stock, the site is not actually ready.
Quality Assurance: The Last Line of Defense
FTTH networks are built to last twenty-five years or more. A poor splice, a poorly installed duct, or a misaligned splitter will cause problems for the entire life of the network — and the cost of fixing a defect after activation is ten to twenty times the cost of getting it right during construction.
The quality assurance framework must be built into the workflow, not bolted on at the end. Every work package has acceptance criteria. Every splice has a test result recorded. Every site has a punch list before final acceptance. The project controls system tracks quality metrics alongside schedule metrics — a site that is on schedule but failing quality checks is not actually on schedule, because the rework will push it back.
The Programme Control Room
What ties all of this together is what I call the programme control room — a centralized function that has visibility of every site, every permit, every material delivery, and every quality issue. This is not a physical room (though it can be); it is a management discipline. The control room produces a daily status report, a weekly programme review, and a monthly executive briefing. It is the single source of truth for the programme's status.
In the STC programme, the control room function was the difference between managing twenty sites and drowning in twenty sites. When a site manager raised a flag, the control room could see whether it was an isolated issue or a pattern across multiple sites. When an executive asked for a status update, the answer came from a single, trusted data source — not from five different spreadsheets compiled by five different teams.
Lessons That Travel Beyond Telecom
The controls framework I built for the STC FTTH programme has traveled with me to every subsequent project — hospitality fit-outs, healthcare infrastructure, railway signaling, building management systems. The specifics change, but the principles hold: standardize the work packages, track every site independently, integrate supply chain with schedule, build quality into the workflow, and maintain a single source of truth. That is how you control a national-scale infrastructure programme without losing your grip on the details that matter.