Digital Project Success Means Stop Pretending You Can Predict Everything

23 Apr

Written By Thomas

Corporate digital projects fail all the time. Budgets spiral, deadlines slip and teams get blamed. But why?

This post explains why using the analogy of driving to Cornwall. Because why not…

If you want to know what it’s like running a digital project in a corporate, imagine being a car driver heading off on your family holiday.

You know that you live in Southgate in North London and that you’re heading for Perranporth on the Cornish Coast. You know that you need to arrive by 5PM as you are collecting the keys to a holiday cottage.

Planning

From this, you calculate that this means you should leave at 6AM to give you plenty of contingency. You also decide that you’re going to go via the M25, M3, A303 and A30. But you’ll have your SatNav switched on and your radio tuned for traffic updates, and will keep an eye on how things are going.

Now imagine that your spouse doesn’t drive themselves, doesn’t understand maps, doesn’t trust your ability and has decided that you need a more robust schedule so they can be confident they know it’s all going to plan. So they (from now on, we’ll assume that you are female and your spouse is male) have created a milestone plan:

At 0630 you must be at South Mimms.
At 0700 you must be passing the M40.
At 0730 you must be on the slipway joining the M3.
They also:
- calculate the mileage (to the nearest mile).
- Estimate your petrol costs.
- Decide on the precise venue for breakfast
  - and lunch
  - and tea.

And they write it all down in a Gannt chart.

You protest that this is madness. You know where Perranporth is and you can judge the best way to get there. But the best way may change according to circumstances and these constraints aren’t going to make it easier; they’ll actually make it harder.

But he’s unrelenting. He doesn’t want to get to 5PM and discover you’ve ended up in Dover. Given that he doesn’t understand driving and maps and stuff like that, how else will he know that you’re on track to achieve your goal than through clear time-bound milestones.

Reluctantly, you agree and get on with packing.

Grumpily.

Driving

The day of the journey starts badly.

The kids are in a strop and you leave at 0645 not 0630. At 0700 you haven’t even reached the M25, never mind South Mimms. By 0730, you’re passing Potters Bar when you should have reached the M40.

Your spouse is livid: given how many milestones you’ve missed, the chances of successful delivery look remote.

You try to explain that, actually, it’s completely fine and that nothing that matters has gone wrong. You’ve still got plenty of time to reach Perranporth.

Indeed, at this stage, what has happened is entirely irrelevant.

But he points out that you’re now 50% off target and your pleadings get lost in a hail of metrics.

As you continue around the M25, your SatNav and radio spark into life: there’s been an accident on the M3. The motorway is at a standstill. You quickly tell your spouse that you’ll divert via the M4 and M5. No harm done; you caught it in time.

He hits the roof. The M4 means an extra £40 in petrol. Not only are you late, you’re over budget!

Worse, he’s disbelieving: the road ahead looks fine, so surely this “accident” is just a blip?

And anyway, traffic? On a drive to Cornwall? Who could have possibly foreseen such an unprecedented event? If traffic was a risk, why didn’t you plan for it so you could stick to the milestone schedule despite the traffic?

You try reasoning. The original plan was an estimate, not a sacred text. Had you been asked, you’d have outlined a range of costs based on different routes, but even that wouldn’t have been certain (should you factor in the insurance excess in case of a minor scrape? You’re not planning to crash, but you might).

But he’s not hearing it. As far as he’s concerned, you’re spending more money to change a plan that’s already failing.

You’ve had enough. You pull into a lay-by, refuse to drive another mile, and demand a better system.

You get that he needs confidence that you’re on track. That, as a non-driver, he doesn’t understand maps, motorways or the realities of navigation. But by micromanaging every turn, he’s not helping. He’s making it impossible for you, the expert, to actually get to your destination.

The solution

You make a proposal.

From now on, you’ll be crystal clear what the next milestone looks like.

The M3 is a disaster, so you’re taking the M4. You’ll estimate where you’ll be in 30 minutes (Slough) and how much petrol you’ll have used. Then you’ll check again in another 30 minutes. And again. And again. This way, he can build confidence that you know what you’re doing, and if you misjudge something, you’ll figure out whether it’s a one-off or something to factor into future estimates.

You’ll also keep him updated on whether any of this actually affects your real goal: getting to Perranporth by 5PM. Without obsessing over every missed checkpoint, you can stay focused on what really matters.

After bit (ok, a lot!) of persuasion, he grudgingly agrees to try it. He’s not happy, but he’ll play along.

What you’ve just done is invented agile.

Why this works

A few key points:

What you’ve not done is eliminate controls. Your spouse is entitled to oversight, but the focus has shifted to what actually matters: the end goal and the next steps, rather than irrelevant distractions.
You also haven’t eliminated planning. Of course, you should plan. Thoroughly. The key question is whether leaving Southgate at 6AM to reach Perranporth by 5PM is reasonable. Your spouse’s milestone plan helped test that. Even planning where to stop for lunch wasn’t a bad idea. But once the plan had served its purpose, it should have been thrown away. Agile doesn’t mean chaos, it means detailed planning followed by adaptation. One of my favourite quotes is from Gen Eisenhower: “plans are useless but planning is essential”. What’s true for D-Day is true for Digital.
And it doesn’t mean ignoring budgets. Your spouse was right to insist on one: your joint mistake was treating a best-case estimate as a fixed budget. A sensible budget assumes some delays, some diversions. If an accident leaves you stranded for hours and you need a hotel, that’s a necessary cost not a failure. Your spouse might not like it, but reality doesn’t care. The only alternative is abandoning the goal entirely: and even that wouldn’t erase the cost. But it would have been madness to budget for a hotel as it probably wouldn’t be needed.

In the scenario we’re describing here, you switched to the M4, got caught in a bit more traffic, had to shell out for the extra petrol and arrived in Perranporth at 4.24PM. But, of course, early on there was a moment of truth where the justifiable desire of your spouse for controls risked tying you to a plan that was no longer optimal and, had you not had your little talk, would have made you both grumpy - and late.

As it is, you’re right on time for a lovely holiday: and a much better relationship with your spouse…

Having spent a career in corporate transport before founding Snap, I’d heard a lot about agile development.

I also knew various corporate teams that professed to do it.

But it was only when entering Startupland that I properly understood agile development - and why it is so incredibly hard for corporates to actually do.

Most software development follows the traditional ‘waterfall’ method of project management (called waterfall because each element of the project cascades into the next). A waterfall plan is detailed and prescriptive. Everything is pre-planned with detailed milestones and sequences. This leads to a precise work schedule and a precise budget. If you are building something like Crossrail, you really need to use the Waterfall method!

Unfortunately, corporate software projects - which invariably use the waterfall method - frequently go ‘wrong’ - in the sense that neither the milestones nor the budget are achieved. Everyone gets very cross and insists on doing better next time. Unfortunately ‘better’ frequently means more milestones and tighter controls - which is the exact opposite of what is needed.

In both Arriva and the RDG, I’d been involved in software projects that made every mistake described above. When I founded a startup, I had to go through a big process of re-educating myself. I didn’t always find it easy. As a non-software engineer, it can feel really hard to let go of the milestone plan. I didn’t always succeed. But we always should.

Take Action: How to Apply This to Your Work

Digital projects fail not because teams lack skill, but because the process forces them to stick to a rigid, outdated plan. Success isn’t about predicting the future, it’s about responding to reality as it unfolds.

Here’s what you can do:

If it’s your project:

Budget for uncertainty. Don’t set budgets based on best-case scenarios, assume challenges, new information and some traffic on the M3 along the way.
Ditch failing plans when reality changes. Sticking to a failing roadmap doesn’t prevent problems: it creates them. Success comes from learning, adapting, and keeping the goal in sight.

If you’re monitoring the project:

Shift the focus from rigid milestones to real progress. Plans should guide, not dictate. Track only what matters: the end goal and what’s happening right now.
Don’t confuse estimates with commitments. A forecast is just that: a guess. Expect adjustments and make space for course corrections.
Trust the experts to adapt. If you’re not the one navigating, don’t micromanage every turn. Give the people doing the work the autonomy to adjust when conditions change.

Above all, for both sides, remember that - as Eisenhower said - “plans are useless but planning is essential”

The next time a project veers off course, ask yourself: Are we managing for success, or just managing the plan?