Why big programmes suck – and what you can do about it

Photo by Christina @ wocintechchat.com on Unsplash

A lot of the time digital and technology work doesn’t produce the hoped for results because it’s part of a big programme. Lots of organisations love a big programme. They are useful ways of unlocking money from capital pots, they can make those involved feel pretty good about themselves when talking about big numbers and big deliverables, and they often give off the whiff of something being done properly. So why, then, do they so often go badly wrong?

I’ve dug out 5 reasons why that’s the case, along with some ideas for mitigating them.

1. Unrealistic expectations

Big programmes are, well, big. And that bigness has to be justified somehow, which means that a lot of those involved are likely to have overblown expectations about what will result from all of this activity. Often this comes down to money – to unlock it, you have to offer some tempting results to justify it. The trouble is that these expectations are often just wildly over optimistic – never allowing for the kind of learning and adjustment needed for pieces of work that can last for years. Potential outcomes become, through some weird form of osmosis, definite outcomes.

Often this is driven by engagement with vendors of technology who do love to promise the earth in the name of bagging a contract, and the reality is never as it may have felt during those pitching sessions. If you’re at a programme kick off session, where expectations are set like “we will have fully automated finance processes!” or “we will have a single customer record!” then start buffing up your LinkedIn profile.

2. False certainty

Leading on from the unrealistic expectations is the false sense of certainty that is created around a particular programme. It becomes inevitable that things will go well, that the outcomes envisaged (guessed at?) during the start up phase are both necessary and achievable. Those savings will happen! The take up of the new services will definitely be high! Why? Because my spreadsheet says so, and it cannot be wrong!

Plans are the classic example of this. Plans covering a period of time more than about a month are nothing more than guesswork. This is fine – as long as it is acknowledged, and nothing taken as set in stone until they can be refined within a more realistic timescale. But that is rarely the case. The new payroll system is going live in 8 months, 2 weeks and 3 days and that’s the end of it.

The result of this is either that at the last minute those deadlines need adjusting, giving the programme and those involved in it a sense of failure, or (even worse) corners get cut to make it happen as it was promised – resulting in a shonky outcome that nobody likes – giving (you guessed it) the programme and those involved in it a sense of failure.

3. The mechanics of programme management become a measure of success

This is an odd one, but I have seen it happen so many times. People can sometimes really fetishise the gubbins of running a programme, and allow the various mechanisms to become the most valued outputs from the work. This idea that the programme is running well because stuff has happened – where all the stuff is that the highlight reports have been completed on time, that the risk register is bursting at the seams, that the board meetings have been booked for the next 36 months… none of this is unimportant, but it can often become a huge distraction from doing the actual work and keeping on top of whether that is going well or not.

Often in bigger programmes the people keeping the beast fed and watered – the programme director, project managers, coordinators and so on – have their role elevated to a position that they feel the need to justify. I’ve been in that place, and it’s awful. I felt like I needed to talk about my RACI document like it was the most important thing in the world. I knew it wasn’t, and that me talking about it took attention away from the stuff that really mattered, but at the time I didn’t feel confident doing anything about it. When the mechanics of running a programme distract people from the thing the programme is meant to actually be delivering, you know you have a problem.

4. Decision making is detached from experience

Big programmes tend to have different levels of governance, because of the bigness. You tend to have strategic boards where people make decisions about detail they don’t really understand, and more operational ones where people tear their hair out because all these decisions seems to contradict each other, or just don’t make any sense at all. There are programmes where testing isn’t done to save time, or where change and adoption is ignored in favour of keeping within the agreed budget. Of course, the fallout from these decisions sends the programme spiraling in terms of time and cost once they bite, and then everyone just looks at each other.

In big programmes the decisions are so often made by the most senior people, not the people who know the most about that thing, and what the decisions are. Often those decisions are facilitated by people whose interest is in seeing the programme be on time, or in budget, and who therefore will try and encourage decisions that support those outcomes.

5. Too big to fail

Not only too big to fail, but also too big to be even considered as failing. In other words, too big to pivot. So many times the fear of admitting that wrong paths have been taken, money and time spent on the wrong things, and so on, leads to just pressing on anyway, in the hope that somehow things will sort themselves out (spoiler: they never do).

How many times on a large programme has the board decided that it’s just not the right approach anymore, and stopped the work? Or at least realised that things would need a major tweak to actually deliver something close to the expected outcomes? Not many, if any.

What’s more, too big to fail often means that failed programmes are considered successes, or spun to look like them. What never happens is a proper, candid assessment of where things went wrong, what might have been improved, why the wrong decisions got made. People generally get a bit embarrassed and want to move on. Understandable, but the problem is that nobody learns, and everyone is doomed to repeat the same mistakes over and over again.

What you can do about all of this

The most important thing you can do is to try and get everyone to calm down and make things smaller. Try and get them to reduce their ambition. Go for a cheaper budget. Aim to do something simple that has a high chance of working, and then move on from there.

Big programmes create their own unique set of risks. There’s too little visibility. There’s too much going on for people to get their heads around. There’s too much admin.

This is about introducing an agile mindset into programme and project planning. That doesn’t mean to say everything should be run using scrum or kanban (insert your own preferred agile flavour here) but rather that the high level principles that agile teaches us are applied to the problem you are trying to solve.

Most importantly, for me:

  1. Deliver working solutions quickly, and learn from them
  2. Work collaboratively within multidisciplinary teams
  3. Be adaptive to change

Don’t allow people to claim that a problem is too big to be broken down into smaller ones. It isn’t true. If a problem is big then it has to be broken down into smaller ones! There’s no other way to do it.