I've spent the last several years deep in the trenches of enterprise IT architecture — managing requirements, navigating cloud migrations, and solving the "impossible" problems that keep senior leadership up at night.
Lately I've been reflecting on a pattern I keep seeing: why do some projects save £100k or more, while others become money pits that miss every deadline?
The answer, almost every time, is the same.
It's not a technical failure
When a project goes wrong, the post-mortem usually points at something technical. Wrong technology choice. Poor integration design. Underestimated complexity.
But in my experience, those are symptoms. The root cause is almost always the decision logic at the start.
Projects fail before they begin. They fail in the requirements phase, in the scoping conversation, in the contract negotiation, in the assumption that "we'll figure it out as we go."
The red flags I've learned to spot
Over years of working across programmes of different sizes and sectors, I've documented the patterns that predict failure. They show up early — you just have to know what you're looking at.
Requirements that nobody owns. If no single person can tell you what "done" looks like, you don't have a project. You have a wish list with a budget.
Contracts signed before capabilities are understood. I've seen organisations accept work hoping they'll somehow turn it around. Sometimes they do. More often, the project is underwater before the first sprint.
No connection between pre-sales and delivery. In consulting, this is endemic. The people who win the work and the people who do the work often never speak. The gap between what was promised and what's possible only becomes visible once you're committed.
IT changes with no corresponding business changes. Technology is the easy part. If the people and processes aren't changing alongside the systems, you're building something nobody will use.
NFRs treated as an afterthought. Performance, security, scalability — if these aren't in the design from day one, they become crisis items at the worst possible moment. I've seen this play out too many times to count.
What actually works
The projects I've been part of that delivered real value had a few things in common.
They started with a brutally honest risk assessment — not to create paperwork, but to surface the unknowns before they became surprises. They had clear requirements owned by real people who were accountable for them. They kept pre-sales and delivery in the same conversation. And they planned for business change, not just technology change.
None of this is complicated in theory. All of it is hard in practice.
Over the coming weeks I'll be sharing the specific frameworks and red flags I've documented from past projects — the things I wish I'd known earlier, and the lessons that only come from doing the work.
If you're a director or architect navigating these challenges, I'd genuinely love to hear which part of the process is giving you the most friction right now.