A project does not always get delayed because the plan was weak.
Many times, the plan exists. The engineering team is working. Procurement has its tracker. Contractors are updating their milestones. Operations is preparing separately. Every team can explain its own progress. And yet, the final project date still moves.
That is where complex projects become difficult.
A recent UK battery manufacturing project is a useful reminder. The large battery facility changed its construction partner and delivery model after the programme moved from the original 2026 expectation into 2027. The stated need was for a different construction delivery model for the next phase of development, after redesign, contractor changes and package-level disruption had already affected the project rhythm.
This is not only a construction lesson. It is a project governance lesson.
Project delays often build in the gaps between functions. One team may complete its part, but a late design change may hit procurement. One supplier delay may affect three downstream activities. One approval may wait because ownership is unclear. One contractor may assume another contractor owns an interface. Reviews may show progress, but nobody may be challenging the total critical path.
The familiar situation then appears: everyone can explain their own delay, but nobody owns the total delay.
The project delay test: are you reviewing progress or risk?
The usual project review asks, “What did we complete?” That question is important, but it is not enough. A better project governance rhythm also asks, “What can still make us late?”
This difference matters because many project dashboards create comfort. A large part of the dashboard may look green because most activities are moving. But a project does not slip because every activity is late. It can slip because one critical dependency is late. That is why complex projects need an integrated view, not only departmental updates.
A project head or promoter should be able to see five things in one place:
- key milestones
- dependencies between teams
- owners for each critical activity
- slippages and their downstream impact
- recovery action for every major risk
Without this view, every function continues to manage its own piece while the project risk keeps growing between the pieces. The problem is not always lack of effort. In many projects, people are working hard. The issue is that work is not integrated strongly enough.
One project view:
The first discipline is to bring everyone onto one project view.
Engineering, procurement, vendors, contractors, finance, compliance, operations and project leadership should not run separate versions of the truth. Separate trackers may help departments manage details, but the leadership view must connect those details into one project map.
This map should show what depends on what.
If a design approval moves by ten days, what procurement item gets affected? If a supplier misses dispatch, what site activity stops? If civil work is delayed, which installation activity becomes impossible? If one contractor misses an interface point, which other contractor gets blocked?
This is the difference between activity tracking and project integration.
- Activity tracking tells you what each team is doing.
- Project integration tells you whether the final date is still protected.
Critical path discipline:
A project review should not spend equal time on every item.
Some delays are inconvenient. Some delays are dangerous. The dangerous ones are those that touch the critical path, which means the chain of activities that directly affects the final completion date.
If leadership does not review the critical path separately, the project may look busy but still become late.
A small pending item can carry large consequences if it sits on the critical path. A large activity may be less urgent if it has float. This is why project reviews must separate noise from risk.
The practical question is simple: if this activity slips, can it move the final date?
If yes, it needs early attention. If no, it can be managed within the project rhythm. This prevents the review from becoming a long reporting meeting. It turns the review into a decision meeting.
Handoff ownership:
Many project delays happen at handoffs.
Engineering completes a drawing, but procurement receives the change late. Procurement places the order, but logistics is not aligned. Contractor A finishes a section, but Contractor B says the interface is not ready. Operations prepares for commissioning, but site readiness is not complete.
Each team may say, “Our part was done.” But the project does not care whose part was done. The project cares whether the handoff worked. That is why every major interface needs an owner.
For example:
- engineering to procurement
- procurement to vendor
- vendor to site
- contractor to contractor
- project team to operations
- finance to procurement
- compliance to execution
- installation to commissioning
When nobody owns the space between functions, delay sits there quietly.
A clear handoff owner should check whether the next team has received what it needs, whether the input is complete, whether the timing is understood and whether any downstream risk has started. This role is not clerical. It is a project-control role.
Escalation by impact, not emotion:
Many projects escalate too late. The issue is discussed at team level. Then it is mentioned in a review. Then people wait for an update. Then the delay becomes visible. Then leadership gets involved. By then, recovery options are already fewer.
A better escalation system is based on impact, not noise.
If an issue can affect the critical path, it should be escalated early. If it can affect cost significantly, it should be escalated early. If it can block commissioning, statutory approval, customer commitment or supplier sequencing, it should be escalated early.
Escalation should not mean panic. It should mean visibility while there is still time to act.
This is where many project reviews fail. They report delay after it has happened. Strong governance identifies the condition that can create delay before the delay becomes unavoidable.
The review question should be: what has not yet gone wrong, but can still hurt the final date?
This question changes the tone of the meeting. It makes people think ahead, not just explain behind.
Recovery action with every major risk:
A project risk without recovery action is only an explanation waiting to happen.
If a supplier is late, what is the alternate plan? If approval is stuck, who can unblock it? If a contractor is slipping, what resources can be added? If a design change has affected procurement, which activities can run in parallel? If commissioning readiness is weak, what can be advanced now?
Every major risk should come with three things:
- the impact on the final date
- the owner responsible for recovery
- the action needed to reduce or absorb the delay
This is important because many reviews stop at issue identification. People explain the risk, but they do not commit to recovery. That creates awareness, not control.
Control starts when every serious risk has an owner and a recovery path.
The CEO’s project governance lens:
For promoters and CEOs, project governance cannot stop at asking whether each department is on track.
That question is too narrow. A better governance lens has 4 parts:
1. Final date protection: is the project still protecting the promised commissioning date, or are teams only protecting their individual milestones?
2. Dependency visibility: which activities depend on another team, vendor, contractor or approval, and are those dependencies actively tracked?
3. Early warning quality: are risks being reported early enough for recovery, or only after the delay has already become visible?
4. Recovery discipline: does every critical issue come with a recovery action, or only an explanation?
This gives leadership a better grip on the project.
A CEO does not need to enter every technical discussion. But the CEO must know where the final date can move, who owns that risk and what recovery action is being taken. That is the difference between project reporting and project governance.
The mistake of green dashboards:
One of the most dangerous things in a complex project is a dashboard that looks mostly green but does not show critical dependency risk.
A project can be 90% green and still be in trouble. If one delayed item blocks commissioning, the green items do not protect the final date. If one supplier delay affects three downstream activities, the individual department updates may not show the real risk. If one contractor handoff is missed, multiple teams may lose time.
That is why project reviews should not only count completed tasks. They should study movement risk.
Ask:
- which activity has no float left?
- which dependency is not yet confirmed?
- which approval can block the next stage?
- which supplier delay can affect downstream work?
- which contractor interface is unclear?
- which activity looks green but has hidden risk?
- which recovery action is already late?
These questions make the review sharper.
They also make the project team more honest, because the focus shifts from defending status to protecting the outcome.
The practical governance rhythm:
A complex project needs a rhythm that separates routine tracking from leadership decision-making.
Routine tracking can happen at team level. But leadership review should focus on exceptions, dependencies, escalation and recovery.
A practical rhythm can look like this:
- Daily or alternate-day exception check: this is for live issues that can block work immediately.
- Weekly integration review: this connects engineering, procurement, vendors, contractors, site, finance and operations into one project view.
- Fortnightly critical path review: this checks whether the final date is still protected and whether any activity has started threatening the path.
- Monthly governance review: this is for leadership decisions, budget impact, major risks, contractor performance, recovery action and commissioning readiness.
This structure prevents the project from being reviewed only through departmental updates. It also helps leadership act before the project becomes a rescue case.
The real project question:
Many projects do not fail because people do not work. They fail because the work is not connected tightly enough. They fail because every team watches its own piece, but no one watches the spaces between the pieces. They fail because issues are escalated after the impact becomes serious. They fail because reviews measure completed activity but not future delay risk. They fail because recovery action starts after the final date has already moved.
So the better project question is not only: “Is each department on track?”
The better question is: “What can still move our final date?”
That one question forces the project team to think differently. It brings attention to dependencies, ownership, interfaces, approvals, vendors, contractors, escalation and recovery. It also reminds leadership that governance is not about explaining why the date moved. Governance is about spotting what can move it while there is still time to recover.
That is where implementation-led project governance becomes important. The role of project leadership is not only to monitor progress. It is to integrate the pieces, protect the critical path and make sure every serious risk has an owner before it becomes a delay.
