We placed three delivery leads into transformation programmes at three different Gulf banks within the same six-month window last year. Same region, same general scale of ambition, similar budgets. One programme held its timeline within a few weeks of the original plan. One slipped by a quarter but recovered. One is still being renegotiated. The difference wasn't the technology, and it wasn't the talent on the ground. It was the delivery model each leader chose, and how disciplined they were about running it.
Three models, three outcomes
Governance-heavy hybrid
Stage-gated, waterfall-structured at the programme level with agile delivery inside each work stream. Slower to start, but every governance forum had a decision-ready pack waiting for it. This is the model that held its timeline.
Agile-at-scale
Multiple squads, continuous delivery, sprint-based reporting up to a steering committee that was used to waterfall cadence. Strong on paper, but the mismatch between how the teams worked and how the board wanted to be briefed created friction that cost real time. This one slipped, then recovered once the reporting cadence was rebuilt to match what governance actually needed.
Vendor-led delivery
The systems integrator owned the delivery plan; the bank's delivery lead was positioned as an oversight function rather than the driving force. When priorities needed to shift mid-programme, the person nominally accountable didn't have the authority to actually shift them. This is the one still being renegotiated.
What actually separated the outcomes
It wasn't the model itself — all three are legitimate, and we'd recommend any of them depending on context. What mattered was whether the delivery lead built the muscle to run their chosen model with discipline, specifically in three areas:
Cadence that matches the audience, not the methodology. The agile-at-scale programme didn't fail because agile was the wrong choice — it struggled because the reporting cadence was built for the delivery teams, not for the steering committee that needed to make funding and risk decisions on a different rhythm. The leaders who held their timelines adapted their governance cadence to their stakeholders, not the other way around.
RAID logs that get used, not just maintained. Every programme we've seen keeps a risk and issue log. Far fewer actually route what's in it into real decisions before it becomes a problem. The difference between a RAID log as a compliance artefact and a RAID log as a genuine early-warning system is almost entirely about whether the delivery lead has the standing to escalate early, before an issue has become a crisis someone has to explain in a board pack.
The programmes that held their timeline weren't the ones with the fewest problems. They were the ones where problems got escalated three weeks earlier, while there was still time to do something about them.
Real authority, not delegated responsibility. The vendor-led programme's core weakness wasn't the vendor — it was that the internal delivery lead was accountable for outcomes without the authority to actually redirect the programme when it mattered. This is worth checking before accepting a mandate, not after: does the role as offered come with genuine decision rights, or with responsibility for a plan someone else controls?
What this means if you're evaluating a delivery mandate
When we're briefing candidates on a delivery leadership mandate now, the question we push hardest on isn't "can you deliver this" — most candidates at this level genuinely can. It's whether the role, as structured, actually gives you the standing to run the cadence, escalate early, and hold real authority over the plan. Get a clear answer to that before the offer, not three months into the programme.