A programme of that scale is not just bigger than what you have run before. It is fundamentally different in kind. The skills that got you there — delivery discipline, technical depth, the ability to manage a complex project — are necessary but not sufficient. What the scale changes is the nature of the job itself. I learned this the hard way, and I have watched many capable people learn it the same way since. These are the things I wish someone had told me before I started.
It's Not About Delivery — It's About Direction
Early on, we built a detailed master plan. It was impressive: hundreds of milestones, dependencies mapped, everything aligned. The kind of plan that looks like competence when you present it to a steering committee.
Three months in, a regulatory change landed. Six months in, the business priorities shifted. Nine months in, we had already reworked the roadmap twice.
That was the moment I understood what a large programme actually is. It is not a track you run along. It is a course you navigate continuously, with incomplete information, against conditions that keep changing.
You don't deliver a large programme in a straight line. You steer it through uncertainty — and steering is a different skill from executing.
The plan is still necessary. But its purpose is not to predict the future. It is to give you a baseline from which to recognise when reality has diverged — and to make the divergence visible quickly enough to do something about it.
Stakeholder Management Is the Job
I once sat in a steering committee where every executive around the table agreed with the proposed direction. The meeting ended on a positive note. I left feeling that we had genuine alignment.
Within 48 hours, I had three separate calls: one executive "clarifying concerns," another asking for changes, a third questioning the entire approach.
That experience changed how I think about steering committees. They are not the place where alignment happens. They are the place where alignment — if it exists — is confirmed. The real work happens in the conversations before, between, and after the formal meetings.
Alignment is not what happens in the meeting. It is what exists after the meeting is over — and it has to be continuously maintained, not assumed.
At scale, stakeholder management is not an activity that runs alongside the programme. It is the programme's most important work. The executive who feels unheard does not raise their concern at the steering committee — they raise it with the sponsor, or with the board, at a moment you did not choose and cannot control. Getting ahead of that takes consistent, deliberate effort.
The Plan Will Not Survive
On a large datacentre transformation programme, we had an extremely detailed rollout schedule — down to the weekend migration windows. The first few migrations went smoothly. Then one application failed during transition because of an undocumented dependency that nobody had known to test for.
That single issue cascaded: delayed subsequent migrations, forced re-sequencing of three workstreams, created tension between teams who had been waiting on the migration to proceed with their own work.
The plan wasn't wrong. It was incomplete — because complex reality always is. Every plan of a programme at this scale contains assumptions about what is known. What it cannot contain is the full inventory of what is not known. Some of those unknown unknowns will surface during execution, and they will not surface at convenient moments.
From that point on, I treated plans as guidance — not guarantees. The plan tells you where you intended to go. The programme tells you where you are actually going.
The difference between a programme that recovers well from plan deviation and one that doesn't is not the quality of the original plan. It is the speed of the response and the quality of the decision-making when things go off-script.
Complexity Is Your Biggest Enemy
There is a temptation, on a large programme, to match the scale of the challenge with an equally large governance and delivery structure. More workstreams, more vendor involvement, more reporting layers, more committees. It feels comprehensive. It is rarely manageable.
In one programme, we had 20+ workstreams, multiple vendors with different governance structures per stream, and a meeting schedule that consumed most of the available leadership bandwidth. Decisions slowed. Dependencies became unclear. The programme was well-documented but poorly controlled.
We made a conscious decision to simplify aggressively: reduced the workstream count, created clearer end-to-end ownership, standardised the governance model across the programme. The impact was immediate and significant.
Less structure actually led to more control. Complexity is not a sign of thoroughness. It is usually a sign that accountability has not been properly resolved.
The right number of workstreams is the minimum needed to represent genuine parallel work, not the maximum needed to represent every dimension of the problem. If a workstream does not have a clear owner who is accountable for its outcome, it is not a workstream — it is a reporting obligation looking for a home.
Communication Must Be Relentless
Early in my programme leadership career, I assumed that once something had been explained clearly, it was understood. I was wrong about this in a way that took me longer to correct than it should have.
On a major transformation, we introduced a new operating model. We presented it at leadership level, in workshops, in written communication. A few weeks later, I asked a mid-level manager to describe how it worked. His response: "I think it's something about centralisation, but I'm not entirely sure how it impacts us."
That conversation was a turning point. The model had been explained. It had not been understood. The distinction matters: a message delivered is not a message received, and a message received is not a message internalised.
Communication on a large programme is not a one-off event. It is a continuous loop. If something matters, you repeat it — in different ways, through different channels, at different levels — until it becomes second nature.
The people who most need to understand the direction are not usually in the rooms where it is articulated. They are in the middle layer of the organisation, receiving a filtered version of what leadership communicated, through a manager who may themselves be uncertain. Reaching that layer deliberately — rather than assuming cascade will deliver the message intact — is one of the most important communication disciplines on a large programme.
Not All Problems Should Be Solved Immediately
The instinct of an experienced programme leader, when a problem surfaces, is to resolve it quickly. On a large programme, this instinct is generally right — unresolved problems accumulate and compound. But it has a specific failure mode: forcing a decision before the decision is ready to be made.
In one programme, two senior stakeholders fundamentally disagreed on a key architectural decision. Every attempt to resolve it directly created more friction, not less. The debate was consuming energy the programme needed elsewhere.
We parked the decision temporarily and moved forward in parallel where we could. A few weeks later, external constraints changed — and the correct option became obvious to both parties without any further mediation.
Sometimes forcing a decision too early creates more problems than it resolves. The discipline is in knowing the difference between a decision that is blocked and one that is not yet ready — and having the confidence to sit with the latter long enough for clarity to emerge.
This is not an argument for avoiding decisions. Delayed decisions on a large programme are a serious risk, and most escalations are a consequence of decisions not being made rather than decisions being made wrongly. But the pressure to close every open question immediately — which feels like control — can produce premature decisions that need to be revisited, creating exactly the kind of rework and instability that the speed was supposed to prevent.
Leadership Gets Tested Under Pressure
There was a moment — late in a major programme — when a key milestone slipped. The issue itself was manageable. It was not, in technical terms, catastrophic. But the reaction around it was significant: escalations, concerns about wider schedule impact, pressure from senior stakeholders who had been waiting for that milestone as a signal of programme health.
In that moment, nobody in the room was looking for a technical analysis of what had gone wrong. They were looking for clarity about what it meant, calmness in the face of pressure, and confidence that the situation was understood and being managed.
Leadership is not most visible when things go well. It is most visible when they don't — and what people are looking for in those moments is almost never what they say they are looking for.
They say they want a root cause analysis and an updated timeline. What they actually need, before any of that, is to believe that someone is in control of the situation — not because all the answers are known, but because the person leading the programme is calm enough to find them. The technical response matters. The tone of the response matters more.
Looking back, the biggest misconception I carried into my first programme of this scale was thinking that success required control. It does not. Large programmes are not environments where control is achievable, except over a small fraction of what is happening at any given moment.
What they require is something different: the ability to navigate complexity without being paralysed by it, to align people who have different interests and priorities, and to make decisions under uncertainty — repeatedly, often imperfectly, always learning.
None of that is taught on a project management course. Most of it is only learned by doing it — and by paying attention to what actually happened, rather than to what the plan said was supposed to happen.