By Maria Mothibeli, Head of Operations at SPM
Many operational failures are blamed on execution when the real problem started long before a team ever arrived on site.
By the time a project begins slipping, the issue is often already embedded in the way the work was planned, scoped, sequenced, or handed over. The delay may only become visible during execution, but visibility and origin are not the same thing. Operations is simply where the consequences surface.
That reality is often overlooked.
In many organisations, there is an assumption that if a problem shows up during delivery, it must be a delivery problem. The site team is scrutinised. Execution is questioned. Pressure is applied to “recover lost time.” What receives far less scrutiny is whether the work arrived at operations in a condition that made successful delivery realistic in the first place.
In our experience, ambiguity remains one of the most common reasons work becomes more difficult than it needs to be.
It enters through scope that is not fully defined, timelines accepted before they are properly interrogated, responsibilities that are assumed rather than clarified, and plans built on optimism instead of operational reality. None of that feels catastrophic in the early stages. In fact, projects can appear to be moving well. There is momentum. Meetings are happening. Decisions are being made. Work is progressing.
Then execution begins, and the gaps reveal themselves.
Teams discover that assumptions differ between stakeholders. Constraints were not properly considered. Dependencies were underestimated. The plan looked workable on paper, but not in practice. What should have been straightforward now requires rework, clarification, adjustment, and unnecessary firefighting.
At that point, what is often labelled as “poor execution” is operations trying to deliver through conditions that were compromised from the outset.
This is why experienced operational teams ask difficult questions before work starts. They challenge assumptions. They interrogate sequencing. They test whether timeframes are realistic and whether the scope is sufficiently defined to support clean execution. That should not be mistaken for resistance. It is one of the most practical forms of risk management available in any delivery environment.
The problem is that in some businesses, operational challenge is still misunderstood. Pushback from operations is seen as negativity. Questions are interpreted as obstruction. Caution is viewed as a lack of urgency.
In reality, experienced operations people usually raise concerns because they can already see where the plan is likely to break down.
That perspective is earned through repeated exposure to what happens when assumptions go untested and details go unresolved. It is not pessimism. It is pattern recognition.
The strongest delivery environments understand this. They involve operations early, not simply to execute the plan, but to help shape it. They recognise that operational teams are not there merely to carry out decisions made elsewhere. They are there to apply practical judgement before avoidable mistakes become expensive ones.
There is often pressure in business to move quickly, to show progress, to maintain momentum. But starting work before the necessary clarity exists is not speed. It is simply borrowing problems from the future.
Those problems eventually arrive. They arrive as delays, cost overruns, rework, frustration, and strained relationships between teams that should have been aligned from the start.
Operations will always have to deal with genuine complexity. Site conditions change. Constraints emerge. External factors shift. That is the nature of project delivery.
What operations should not have to do is compensate for preventable uncertainty created upstream.
When ambiguity enters planning, it does not remain there.
It follows the work all the way into execution.
And by then, everyone pays for it.