We didn't start with a methodology. We started with a spreadsheet of failed projects and a question: why does enterprise software delivery go wrong so consistently? Over five years, we built an answer. Not a framework you buy. A set of principles we tested across 200+ engagements until they stopped failing.
The Problem Statement
In 2018, we'd been building enterprise software for seven years. We'd seen enough wreckage to know the industry had a structural problem. Not a technology problem. Not a people problem. A delivery problem. So we started by mapping the patterns of failure.
Article
Chapter 1 - Jan 2018. The diagnosis.
Why Enterprise Projects Still Fail (And What We Do Differently)
The Methodology Debate
Every enterprise team argues about waterfall vs agile. We argued too, until we realised the argument itself was the problem. Neither works in isolation. Enterprise needs strategic discipline (waterfall's gift) and rapid feedback (agile's gift). We took both and threw away the dogma.
Perspective
Chapter 2 - Mar 2018. The reframe.
Waterfall vs Agile Is the Wrong Question
The Non-Negotiable Habit
Of everything we've built into our delivery process, this is the one we'd keep if we could only keep one. Every two weeks, the client sees working software. Not a status report. Not a slide deck. Working software. It catches misunderstandings before they compound.
Take
Chapter 3 - Apr 2018. The habit.
The Client Should See Working Software Every Two Weeks
The Full Framework
By the end of 2018, the pieces had come together. Vision sets the destination. Roadmap breaks it into phases. Execution delivers continuous feedback. Three layers, each reinforcing the others. This is the post where we wrote it all down.
Perspective
Chapter 4 - Dec 2018. The framework.
Vision, Roadmap, Execution
Starting Right
A framework is only as good as how you start. Discovery is the single biggest predictor of project success. Not a 200-page requirements document. Two to four weeks of structured investigation that builds shared understanding before a single line of code gets written.
Guide
Chapter 5 - Jan 2019. The starting point.
Discovery Done Right (How We Start Every Project)
Managing Change
Good projects generate scope change. That's not a problem to solve. It's a signal that the client is engaged and the work is surfacing real needs. The question isn't how to prevent scope creep. It's how to absorb change without losing control.
Guide
Chapter 6 - Oct 2019. The change process.
How We Handle Scope Creep (Without Saying No)
The Hardest Decision
Three years later, we applied everything we'd learned to the highest-stakes enterprise decision: rebuild or extend? Most rebuilds fail. Not because the technology is wrong, but because organisations underestimate the complexity hiding in legacy systems. This post maps the failure pattern and offers a framework for the decision itself.
Article
Chapter 7 - Feb 2022. The stress test.
Why Most Enterprise Rebuilds Fail
Why This Series Exists
These seven posts represent how our delivery methodology actually formed. Not in a workshop. Not from a book. From building things that worked, studying things that didn't, and writing down what we learned before we forgot it.
If you're planning a large enterprise project, read them in order. If you're mid-project and something feels off, start with Chapter 1 and see if any of the failure patterns look familiar.
Every methodology sounds good in a slide deck. Not because it's clever, but because it's honest about what actually goes wrong.
Isaac RolfeManaging Director