There’s a scene I’ve watched play out umpteen times over the past three decades. The setting is the boardroom, and the starring role is played by a question that I’ve seen posed by some of the most astute non-execs I’ve had the pleasure of knowing. Usually it is directed to the member of the c-suite who is designated as the executive sponsor of the current over-running, over-spending, slippage-laden transformation programme.

One of my (many) formative experiences in programme delivery was working with a banking client in 2018 right when TSB’s troubled data migration hit the headlines. It was variously described as a ‘meltdown’ and a ‘fiasco’ in the popular press, who carried stories on a daily basis ranging from customers being unable to pay their mortgages or access their accounts, through to one mythical account holder who had supposedly found an extra £5M in his bank account.

When a programme is over-running and over-spending, the situation can be heavily compounded by the organisational reaction. It’s a bit like being in an escape room where you have been conditioned to believe that there are only three levers marked cost, time and outcome.

How do you persuade your team-mates not to touch those levers, and what other levers might be in the room?

The answer is of course yes, but is it also sapping the organisation’s attention, energy and intellect at the expense of other more important things such as strategy, customer focus and genuine evolution of the business’s operating model? Profits aside, what are the wider impact of defective change? What is the trajectory of defective change, and most importantly, what’s the solution?

Anybody who has attended a programme management event in the last ten years has probably witnessed at least one debate on the definition of programme assurance. Usually it’s an ideological battle between various camps of theorists and methodologists, where words like ‘confidence’ and ‘likelihood of success’ are bandied about quite liberally.

It’s forever been a mystery to me, but programme steering committees always seem to want to talk about risks instead of issues. Logic would suggest that the thing that is biting the programme’s bum is probably more important than the thing that might, but if risks have a poor cousin, it’s definitely issues. And that’s a real shame for the programme, because risks don’t kill programmes. They become issues and then they do.

In my earlier life, I cut my programme manager teeth within the Big 4, where I learned a very important lesson that stakeholder engagement isn’t just about the who and the why, but also the when. I was working within tax technology. Tax applications are rather like fine wines – they don’t travel well – because of the differences in taxation between different countries.

The test phase of a programme is never a straightforward experience: The complexities of the data, the processes, user permissions, the need for subject matters experts who have day-jobs and the set-up of environments all combine to make it one of the most challenging phases, and it comes usually at a point where time is short, corporate patience is thin and the programme team are tired. None of these things are ingredients for a happy ship. However, there are ways for a programme to make it easier, as an experience with a client three years ago illustrated.

There’s an old adage that programme slippage is a bit like carbon monoxide poisoning: It’s cumulative, often invisible and there are few warning signs prior to the unconscious drift into the fatal moment. In a programme, the analogy is all of those instances where the small deadlines were missed; a week here, a couple of days there.

“Should I replace my programme director?”

Almost always, the answer is ‘no’. Here are a few reasons as to why, followed by the four exceptional circumstances under which maybe you should replace them.

One of the most striking aspects of distressed programmes – the ones that materially overrun and overspend – is the extent to which risk management simply falls into disuse. Right when the programme is at its most reactive, and therefore desperately needs mechanisms to capture and deal with risk effectively, its ability to do so is not just poor, it is demonstrably AWOL. Passive acceptance of risk as a mere occupational hazard has become the order of the day, and the programme is unable even to articulate its cumulative risk exposure.

Being ‘a programme geek’ at social events is rather like being a doctor. Whereas doctors get a constant unsolicited litany of guests’ medical symptoms, programme geeks instead get to hear all about ‘the programme that goes wrong’; the tale of the high-stakes, transformational initiative at work that is taking three times as long, costing three times as much, delivering only a third of what it promised, and more importantly is draining the life-force and good humour out of the organisation.

What started life as a joke from the movie ‘Airplane!’ created some great insights into management behaviours in a crisis. For those who've never seen the aviation comedy classic ‘Airplane!’, there’s a scene where, faced with improbably incapacitated pilots at 40,000 feet, the flight attendant keys the microphone and 'gentilely' asks the passengers if any of them can fly a plane. Cue comedic panic…

The Outset – the beginning of a new programme – may look superficially like a greenfield experience, but it rarely is. It typically follows rapidly on the heels of the previous programme, which often means that the organisation is freshly scarred by whatever transpired before – the overspend, the organisational burnout, and above all, the belief that “we’re just not very good at change.”

The onset is the point in a programme where initial symptoms of potential failure start to emerge. Anyone who has ever experienced this situation will tell you that it is almost impossible to identify the moment at which the situation crystalised, and that’s for two reasons: The first is that the symptoms are cumulative – no single symptom on its own equals ‘failure’, but the accumulation of symptoms could, combined, mean that the programme will not be able to deliver the outcome within the agreed timeframe and at the agreed cost.

A reset typically occurs when a programme that has been struggling to meet its milestones and control its spending finally exceeds the elastic limit of optimism and cannot proceed any further without major revisions to timeframe and budget. For the executive sponsor, it’s the biggest single test of programme leadership.

A Special Forces’ selection exercise from the 1980s provides a unique perspective on how people respond to change. And it has big implications for the role of change management within a programme.

The Guggenheim museum in Bilbao is a stunning piece of architecture that plays host to an impressive art collection. It’s a shining jewel in the local economy and identity and even starred in a Bond movie opening sequence. And it very nearly didn’t get built at all because the business case was initially misunderstood.

Our engagements most often begin when a programme has reached crisis point. One of the most important things to understand in that situation is the extent to which the programme has a plan and is executing it. You might think that we assess that by asking for the plan, but there’s a quicker, more reliable way: We just go to one of the regular team meetings, and sit in quietly.

A few years ago I was in Canary Wharf at a casual drinks reception with senior technologists representing the various corporate residents of the Wharf. Part-way through the evening, the conversation turned to their disappointment with their outlay on various technologies, specifically the fact that these technologies hadn’t delivered the transformative change that they had hoped for. So I started to ask a few challenging questions:

One of my formative experiences of this was twelve years ago having just arrived on a programme. I was the seventh person to sit in the hot-seat, and one of my objectives was to ensure that there was never an eighth. Pivotal to that objective was the performance of the SI (Systems Integrator), who by this stage of the programme, was not much loved. The client view of the supplier was that they were drawing out the programme in order to maximise their revenue, and that they therefore had no particular interest in seeing the programme conclude.

Controversial statement: Programmes should be fun. If you’re on a programme, you get to play a front-line role in removing all of the frustrations of your working life; the clunky applications with their long wait times and counter-intuitive interfaces, the arcane processes layered with workaround band-aids, the non-sensical org structures that mean everything takes three times as long.