What 25+ Years Across Telecommunications, Infrastructure and Project Controls Taught Me About What Really Makes Projects Succeed
There is something misleading about the way we often talk about successful projects. We tend to describe success as though it were the natural consequence of having a good plan, a capable team and enough resources. We build schedules, assign responsibilities, establish reporting structures, create dashboards and define milestones, and then we expect the project to move logically from one stage to the next. In reality, that is only the beginning. The real difficulty starts when reality refuses to behave like the plan.
After more than twenty-five years working across telecommunications, digital infrastructure, FTTH/FTTx, OSP, ISP, 5G, Project Controls, PMO and large implementation environments, I have become increasingly convinced that the value of project leadership is not demonstrated when everything is going according to schedule. It becomes visible when the schedule begins to lose its connection with reality, when assumptions stop being valid, when different parts of the organization begin moving at different speeds, and when a project that still appears manageable on paper starts accumulating the conditions that can eventually make it very difficult to recover.
That perspective has been shaped by a career that began in a very different place. In 1999, I started as a maintenance engineer at Sheraton Cairo, working in an environment that operated continuously. The hotel could not stop because an engineering problem had appeared. Air-conditioning systems, electrical systems, mechanical systems and the wider building infrastructure had to continue functioning while the operation around them continued without interruption. Looking back, that first experience taught me something that remained relevant throughout every later stage of my career: infrastructure is not successful because it looks correct on a drawing or because an installation has been completed. It is successful when it continues to perform in the real environment in which it must operate.
That distinction became even more important when I moved into telecommunications and project controls.
When the Project Becomes Bigger Than the Plan
At Siemens in Cairo, where I worked from 2000 to 2004 as a Project Controller on OSP network implementation projects, including the expansion of the Shoubra exchange network and the Assiut exchange network, I learned the fundamentals of controlling a project: resources, budgets, progress, reporting, customer communication and alignment with the approved plan. But the more important lesson was not how to produce a report. It was understanding why the report existed in the first place.
A project report has little value if it simply describes the past. Its real value begins when the information inside it allows someone to make a better decision about the future. That idea stayed with me throughout my career. Project Controls, in my view, is not fundamentally a reporting discipline. It is a mechanism for creating visibility so that management can intervene while intervention is still useful.
That distinction becomes much more significant when a project becomes a portfolio.
From 2007 to 2017, I spent ten years in Saudi Arabia as a Senior Project Control Engineer supporting large-scale fixed-network implementation programs associated with STC. The complexity was not simply that the projects were large. It was that the portfolio contained many projects operating simultaneously, across different geographies, with different contractors, technical requirements, stakeholders, regulatory conditions and local constraints. One project might be moving quickly while another was being held by permits; one contractor might be reporting progress in a way that looked healthy while another was reporting against an entirely different interpretation of progress.
At that scale, inconsistency becomes a risk in itself.
The natural response to complexity is often to add more processes, more meetings and more reporting. But that does not necessarily create more control. Sometimes it simply creates more information. The solution we pursued was integration: a common reporting framework, consistent indicators, structured review cycles, risk assessment and a governance rhythm that allowed projects to be compared and managed as part of a portfolio rather than as unrelated individual activities.
That experience changed my understanding of what Project Controls should look like at scale. The goal is not to eliminate complexity. Large programs will always be complex. The goal is to create enough visibility to see through the complexity.
That may sound like a subtle distinction, but in practice it changes everything.
When leadership sees a project that is ninety percent complete, the number itself tells only part of the story. The remaining ten percent may contain the most difficult work, the most expensive interfaces, the most uncertain approvals and the greatest commissioning risk. A project can therefore look increasingly successful in terms of percentage complete while simultaneously becoming increasingly vulnerable in terms of what remains.
That is why experienced control functions have to look beyond status and begin looking at trajectory.
The critical question is not simply where the project is today.
It is where the project is heading.
The Problem Is Usually Somewhere Between the Activities
In January 2020, I joined Sabbour Consulting as Lead Consultant Project Manager on an OSP fiber-optic project in the New Administrative Capital. The objective was straightforward to describe: establish the fiber network and connect ministries to the data center and the main exchange.
But anyone who has worked on large infrastructure projects knows that the technical objective is rarely the difficult part.
Fiber installation itself is well understood. The real complexity was everything around it. Surveying, civil works, permitting, design approval, material inspection, document control, consultants, contractors, changing requirements and different workstreams all had to operate within the same physical environment. The challenge was not simply to make each team productive. It was to make the entire system work together.
That experience reinforced a principle that I now consider fundamental: many project problems are not technical problems. They are coordination problems that happen to appear in a technical project.
A technically correct drawing can still create a problem if it is approved too late. A material can arrive according to the procurement schedule and still be unusable if it fails acceptance. A civil team can complete its work successfully while unintentionally creating a constraint for the telecom team. A survey can appear accurate until installation begins. A contractor can achieve its own contractual milestone while creating a dependency problem for another contractor.
The project therefore has to be managed as a connected system.
This is one of the reasons I have always regarded document control as part of project control rather than as a purely administrative function. When every approved drawing, material acceptance, survey record, coordination decision and project document can be found quickly and traced correctly, the organization has something more valuable than an archive. It has memory. It can explain why a decision was made, what information was available at the time, which revision was approved and what was actually accepted. In a complex project, that traceability is part of control itself.
By the end of that project, the network had been implemented and the required connections established. But for me, the deeper lesson was not the completion of the fiber network. It was understanding that infrastructure projects are controlled through the management of everything surrounding the physical installation.
When Systems Work Individually but Fail Together
The same idea became even more obvious when I later worked as Lead Consultant Project Manager for the low-current systems of the Egyptian International Olympic Games City.
This was a completely different kind of project. Instead of focusing primarily on a fiber network, the work involved multiple systems that were individually complex but also deeply dependent on one another: fire alarm, access control, CCTV, gate barriers, time attendance, telephone, data communication and building management systems.
The most dangerous assumption in such an environment is that completing each system means the project is approaching completion.
It does not.
The real challenge is what happens between the systems.
A fire alarm system may operate perfectly on its own. An access-control system may operate perfectly on its own. CCTV can be fully installed and functional. A building management platform can be commissioned successfully. Yet the integrated environment can still fail if the interfaces between those systems are not properly designed, coordinated and tested.
That is where some of the most expensive failures in complex projects appear. They are not necessarily failures of components; they are failures of relationships between components. They emerge late because the individual systems can appear healthy until the moment they are expected to perform together. By then, contractors may be preparing to demobilize, budgets may be largely committed and correcting an interface problem can require redesign, remobilization and additional commissioning effort.
The lesson for me was straightforward but powerful: integration has to be treated as a deliverable in its own right.
That principle extends far beyond low-current systems. The same logic applies to data centers, smart-city programs, airports, hospitals, utility infrastructure and national telecommunications programs. The larger and more interconnected the project becomes, the less useful it is to think in terms of isolated discipline completion. The project ultimately succeeds or fails according to how well the pieces interact.
This also changes the meaning of “progress.”
Progress is not simply the sum of completed activities.
Progress is the movement of the project toward a usable outcome.
When the Environment Becomes Part of the Project
My experience on the Egyptian National Railways Modernization Project introduced another dimension of complexity.
In 2018, while working with FiberMasr as Senior Site Manager, I was involved in the implementation and testing of fiber-optic networks associated with railway infrastructure. On paper, this was still a fiber project. In reality, the operating environment fundamentally changed the way the project had to be planned and executed.
A railway is not an empty corridor waiting for construction activity. It is a live operating environment, with trains, safety requirements, restricted access, regulatory constraints and operational priorities that do not automatically adapt to the needs of the construction team.
Civil works must be coordinated with railway operations. Access to work areas is constrained. Cable handling has to be precise. Safety requirements are absolute. Testing and documentation are not merely quality activities; they become part of demonstrating that the infrastructure is safe and ready for operation.
That experience taught me that the environment itself can become part of the risk model.
A methodology that works well for an urban fiber deployment may not be appropriate for a railway. A planning assumption that is reasonable on an ordinary construction project may become unacceptable when the work takes place alongside a live operational system.
This is why project leadership requires context.
The technical solution matters, but so does the environment in which the solution has to exist.
That is equally true in airports, hospitals, industrial facilities, data centers and major smart-city programs. The same engineering principles may apply, but the operating conditions can change the project-control strategy completely.
Sometimes the Ground Is More Difficult Than the Plan
Before those later experiences, there was another project that shaped my understanding of field execution: the fiber-optic ring around the Khartoum area in Sudan.
Working as Senior Project Site Engineer, I was exposed to large-scale fiber installation under geographic, logistical and environmental conditions that could not be fully represented in a conventional project plan. Horizontal directional drilling, material movement, permits, field coordination, subcontractors, inspection and testing all had to work together in conditions where the gap between what was expected and what was actually happening could become significant.
The most important lesson was that difficult environments do not necessarily require more sophisticated plans.
They require stronger discipline.
When logistics become difficult, responsibility must become clearer. When the environment becomes unpredictable, communication must become more reliable. When field conditions change, quality verification becomes more important rather than less important. When multiple crews and subcontractors are operating across a wide geographical area, technical knowledge alone is not enough; coordination becomes a management discipline of its own.
Testing was a good example of this. OTDR measurements, insertion-loss testing and continuity checks were not treated as ceremonial steps at the end of installation. They were part of establishing confidence that what had been built actually met the required standard.
That is another idea I have carried forward: verification is not the end of control. It is part of control.
From Reporting to Anticipation
When I look across these different experiences, I see a consistent pattern.
At Siemens, the lesson was that project information should support decisions.
At STC, the challenge was transforming a complex portfolio into a system that could be seen and compared.
In the New Administrative Capital, the challenge was coordinating the interfaces surrounding the technical work.
In the Olympic City, it was understanding that system integration can become more difficult than individual system delivery.
On the railway project, the operating environment itself became a central project constraint.
In Khartoum, field discipline and adaptability were essential when reality refused to follow the assumptions built into the plan.
The technology changed dramatically across those years. Telecommunications moved from older network architectures toward fiber and IP. Testing evolved. Reporting evolved. Digital platforms became more sophisticated. Dashboards became more powerful. But the underlying challenge did not change.
How do you create enough visibility to understand what is really happening before the consequences become expensive?
That question is, in many ways, the heart of Project Controls.
Traditional reporting is largely descriptive. It tells management what happened.
A more mature control environment begins to ask what happens next.
What happens if this approval takes another month? What happens if productivity remains at its current level? What happens if the contractor recovers one workfront but loses another? What happens if the design change reaches procurement after a key manufacturing date? What happens if an unresolved interface remains unresolved until commissioning?
Those are not reporting questions.
They are decision questions.
And this is where I believe Project Controls is moving toward something broader: Project Intelligence.
The purpose of data is not to create increasingly sophisticated dashboards that nobody uses. The purpose of data is to make emerging patterns visible early enough to influence them.
The best control environment is therefore not necessarily the one with the greatest quantity of information. It is the one that reduces uncertainty at the moment when uncertainty matters most.
The Difference Between Managing Activity and Managing Outcomes
There is another distinction that becomes clearer with experience.
Projects can be extremely busy and still underperform.
Teams can be working long hours. Contractors can be mobilized. Meetings can happen every week. Reports can arrive on schedule. Drawings can be reviewed. Materials can be delivered. Progress can be reported.
And yet the project can still be moving away from its intended outcome.
This is why I have gradually become more interested in the difference between activity management and outcome management.
An activity can be complete without creating useful progress.
A cable can be installed but not properly tested.
A system can be commissioned but not integrated.
A contractor can achieve a milestone while another dependency becomes more constrained.
A report can be delivered while management remains unclear about what decision needs to be made.
The mature project leader therefore keeps asking a deceptively simple question: What does this actually mean for the project outcome?
That question changes how information is interpreted.
It changes how meetings are run.
It changes how risks are escalated.
It changes how contractors are managed.
And it changes what senior management expects from Project Controls.
What Experience Really Means
When I look back at my career, the titles tell only part of the story.
I started in operational maintenance. I moved into telecommunications with Siemens. I worked on large-scale fiber deployment in Sudan. I spent ten years in Saudi Arabia supporting fixed-network implementation programs. I worked on the New Administrative Capital. I led the implementation and integration of low-current systems at the Egyptian International Olympic Games City. I worked within the demanding environment of railway infrastructure.
The technologies, clients, organizations and environments were different, but the fundamental challenge remained remarkably consistent.
Something complex had to be turned into something that people could understand, coordinate, control and ultimately deliver.
This is why I no longer think experience should be described simply as the number of years someone has spent in an industry.
Twenty-five years means very little by itself.
What matters is what those years have taught you to recognize.
Can you see a problem before it becomes visible in the monthly report? Can you recognize when a contractor's apparent progress is masking declining productivity? Can you understand when a design issue is about to become a procurement problem? Can you recognize when a small interface problem today has the potential to become a commissioning crisis later? Can you create enough structure around a complex program without creating bureaucracy that slows the program down?
Those are harder questions than “How many years of experience do you have?”
And they are much closer to the real value of experience.
Controlled Execution
For me, controlled execution does not mean that everything happens exactly as planned.
That is not realistic on complex infrastructure programs.
It means that when reality begins to diverge from the plan, the organization can see the divergence, understand its significance, decide what needs to change, act quickly and then verify whether the action actually worked.
That is a fundamentally different way of thinking about project management.
It moves governance away from meetings that review yesterday and toward conversations that influence tomorrow.
It moves reporting away from producing information and toward reducing uncertainty.
And it moves project leadership away from managing activity toward protecting outcomes.
The principle can be expressed simply, but the discipline behind it is not simple: turn complexity into visibility, turn visibility into decisions, turn decisions into coordinated execution, and turn execution into measurable results.
That has been the common thread running through very different projects and very different stages of my career. It is also what continues to interest me most today as telecommunications and digital infrastructure programs become larger, more interconnected and more dependent on disciplined project governance.
The technology will continue to change. The tools will continue to improve. AI, digital workflows, advanced analytics and integrated project platforms will increasingly influence how projects are managed.
But none of those tools changes the fundamental responsibility of a project leader.
The responsibility remains to understand reality early enough to influence it.
Complexity is inevitable. Uncontrolled complexity is not.
And perhaps that is the clearest lesson twenty-five years of project delivery has taught me.
The strongest project organizations are not the ones that never encounter problems.
They are the ones that recognize problems early, understand what those problems mean, bring the right people together, make decisions while there are still options available, and remain disciplined enough to verify that the solution actually worked.
That is what controlled execution means to me.
And that is still the part of project leadership that interests me most.