Five Bonfire Night lessons for IT leaders: from choosing the right project to proving value after go-live. What makes an IT project rocket, not fizzle?
Ahhhh Bonfire Night! Great time of the year!
There’s something satisfying about a well-executed firework display, isn’t there?
You can become a kid again!
The anticipation, the timing, the coordination and, finally, that grand finale as the musical soundtrack reaches a crescendo.
What the audience sees is a few minutes of spectacle. What they don’t see is the planning, investment and countless decisions that made it possible.
IT projects aren’t so different. Although perhaps the stakes are rather higher than a slightly disappointing Catherine wheel.
This Bonfire Night, let’s consider five things that distinguish an IT project that rockets to success from one that simply flies and quickly fades, or (worse still) is a complete dud! Let’s not dwell on those, though; not returning to a dud is great advice!
1 – The Spark: Are We Starting the Right Projects?
Every firework display starts with an idea. In an organisation, that spark might be a business problem, a technology opportunity, a regulatory requirement or an ambition to transform how the business operates.
BUT a compelling idea doesn’t automatically justify an investment. Business cases are only as useful as the assumptions underpinning them, and committing resources to one initiative means they aren’t available for another. A project can have a perfectly credible business case and still be the wrong investment at the wrong time.
The question to ask: If we were making this investment decision today, with what we now know, would we still choose this project?
2 – The Preparations: Confidence Is Not the Same as Certainty
A firework display requires careful coordination. The sequence matters, the timing matters and the dependencies need to be understood. IT programmes are similar, although their dependencies are often less visible and considerably more difficult to control. Delivery commitments rest on assumptions about resources, suppliers, technical complexity and business readiness. Change any one of these, and the impact can ripple across the programme.
Yet project plans and reporting can create an impression of certainty that the evidence doesn’t support. This isn’t an argument against planning. It’s an argument for being honest about what a plan represents.
For senior leaders, the challenge is to make it safe to discuss uncertainty without it being read as a lack of control. Confidence should come from the quality of a team’s judgement and evidence, not simply from its willingness to commit to a date.
The question to ask: Are we looking at a realistic assessment of delivery confidence, or a commitment that has become increasingly difficult to challenge?
3 – The Safety Briefing: The Value of Knowing When to Challenge
No responsible firework display proceeds without an understanding of the risks involved. In IT delivery, that means more than maintaining a risk register or completing an assurance review. It means ensuring the information needed to make good decisions reaches the people who can act on it.
Delivery pressure changes behaviour. A milestone becomes politically important, a senior stakeholder has already announced a launch date, and gradually the conversation shifts from whether the evidence supports a decision to how the team can make it work.
This is where governance matters most. It should enable informed challenge, make accountability explicit and make it possible to raise concerns without bad news becoming unwelcome. Its quality is most apparent when the evidence is uncomfortable: does the organisation adjust its approach, or defend a position it has already committed to?
The question to ask: If the evidence suggested that our current approach was unlikely to succeed, would we be prepared to change course?
4 – The Countdown: Knowing When to Launch and When to Wait
My friend Gareth is a radio presenter and event host, and he tells of two fireworks displays where the decision to go was key. Once in Stockport, at a display on the Manchester airport flight path, he got halfway through the countdown when the tower ordered a halt. He spent five minutes standing on the roof of a Portabin trying to keep 10000 people engaged. Another time, a change of wind meant smoke from the display drifted onto a busy A-road, causing huge tailbacks but not, amazingly, an accident.
In our game, months of work converge on a decision with significant operational, commercial and reputational consequences. Customers are waiting, deadlines loom and delay is costly. The challenge isn’t to eliminate uncertainty before proceeding, which in complex environments may be unrealistic. It’s to understand what remains, assess its consequences and make sure the decision reflects the organisation’s appetite for risk. A launch date is a useful focal point, but it shouldn’t become a substitute for judgement.
Proceeding with clearly accepted risks and delaying can both be the right call. The quality of the decision lies in the evidence, the transparency of the trade-offs and the accountability behind it.
The question to ask: Are we proceeding because the solution is ready and the risks are understood, or because changing the date has become too difficult?
5 – The Grand Finale: Did the Investment Deliver?
The fireworks are over, the audience heads home and attention turns to the next event. In IT, go-live can have the same effect. The project team demobilises and the organisation moves on to its next priority.
BUT successful delivery and successful investment are not the same thing. A project can deliver everything specified, on time and within budget, and still miss the benefits originally anticipated. Adoption may be slower than expected, new processes may not embed, and benefits may depend on changes that were assumed rather than delivered. Realising them takes sustained ownership in the business, reliable measures and a willingness to ask whether the original assumptions still hold.
For CIOs and senior delivery leaders, that means connecting project governance more directly with investment governance. Milestones remain important, but they should sit alongside a clear view of the outcomes the organisation is trying to achieve.
The question to ask: Six or twelve months after go-live, what evidence would demonstrate that this project had been a success?
A FINAL THOUGHT: WHEN THE SMOKE CLEARS
So, this Bonfire Night, perhaps the most useful question isn’t whether your next IT project will go off with a bang.
It’s whether, when the fireworks fade, you’ll be able to demonstrate that the investment was worthwhile.
The real measure of success isn’t the spectacle of delivery. It’s the value that remains long after the grand finale.
Enjoy Bonfire Night.
Stay safe and well wrapped up!
Want to know if your next IT project will rocket or fizzle?
Every question in this blog is easier to answer with someone independent in the room. Someone without a launch date to defend or a business case to protect.
At Stoneseed, we help IT leaders test delivery confidence, strengthen governance and keep sight of the outcomes that matter long after go-live. Whether you need a fresh perspective through our Technical Advisory Service, experienced delivery leadership through PMaaS, or PMO support that connects project governance with investment governance, we’ll help make sure your grand finale is worth watching.
