The Report Nobody Wanted (That Everyone Needed)

I’ve had some version of the same conversation dozens of times now.

A client gets in touch. They already know what they want – a new platform, a CRM, an AI layer, a customer portal, a new app. They’ve done some internal thinking, maybe spoken to a few vendors, and they’re ready to go. The request is simple: how quickly can you start building?

And I have to be the person who says, “not yet.”

Not because we’re slow, or because we follow processes for the sake of it. But because, almost without fail, what they’ve asked us to build isn’t actually the thing they need. Sometimes it’s close. Sometimes it’s not even in the same postcode.

The instinct to skip ahead

Here’s what I’ve learned: Organisations don’t always come to us with problems. They come with solutions they’ve already decided on – that’s normal. But the real problem sits underneath, often unnamed, sometimes actively avoided. And there’s a gap between the solution they’ve chosen and the problem they actually have, which is where projects go to die.

So before we build anything, we run a sort of diagnostic, called “Discovery” – We talk to the people doing the work – not just the people commissioning it. Sometimes we’ll talk to users or clients. We sit in the complexity for long enough to see what’s actually going on rather than what the brief says is going on.

What we find is usually one of a few things.

Tool sprawl – years of software decisions (sensible at the time) that have quietly created duplicated data, fragile or broken integrations, and people spending hours on workarounds that shouldn’t exist. Sometimes there’s a gap between what’s been standardised in policy and what’s happening on the ground. Or, sometimes, something disarmingly simple: one broken process creating downstream chaos across three or four departments that all think they have separate problems.

That rarely shows up in a brief. It shows up when you ask the right questions and when people feel safe enough to tell you what’s actually happening rather than what they think you want to hear. It shows up when you talk to multiple different groups within the organisation instead of just the decision-makers.

“You don’t find the latent problem in a boardroom. You find it three conversations deep, in the hallway, with someone who’s been working around it for years.”

The output of all of this talking and interviewing is what we call an inception report. It’s not a pretty slide deck. It’s not a summary of themes. It’s a document that names every significant challenge, traces where it came from, and pairs it with a specific recommendation – including what implementation looks like, roughly how long it takes, and what it costs. This is a practical, tangible roadmap to get an organisation from where they are, to where they need to be. It articulates the impact of a solution.

That specificity is deliberate. A vague recommendation is easy to shelve. A recommendation with a clear rationale, a rough cost, and a named consequence of doing nothing? That forces a real conversation. It’s harder to put off a decision when the cost of deferring it is sitting right there on the page.

And personally, here’s the thing that matters most to me about it: that document belongs to the client. They can take it to any implementation partner, any internal team, any future vendor. The thinking doesn’t walk out the door with us. Our client keeps the clarity, regardless of who does the building.

What’s the quickest way to create more problems?

Organisations that skip this step – or try to squeeze it into a week so it becomes superficial – tend to discover the cost later. Adoption is low because it solves a problem staff don’t actually experience, and nobody accounted for effective change management. They build dashboards nobody trusts because the underlying data was never cleaned. They invest in a system that technically works but practically changes nothing. People quickly go back to using spreadsheets with complex, delicate formulas because at least they can trust it.

“Those are signs of diagnostic failures, not just implementation failures. And it’s easy to blame the software for the new, growing set of problems.”

Humans at the heart of technology 

There’s one more thing I want to name, because it gets overlooked.

A thorough discovery process does something beyond producing a document. In my experience, it’s often the first time people within an organisation feel that their frustrations have been properly understood – not acknowledged in a meeting and then forgotten, but documented with enough precision to be acted on.

Several of the recommendations that come out of these processes echo things internal voices have been saying for years. The difference is that someone external has now validated them, structured them, and attached a plan.

That matters more than it sounds like it should. When people trust the process, they’re more supportive of the implementation. When they feel unheard, they resist it – sometimes loudly, more often quietly. The discovery phase is a valuable part of change management, whether anyone frames it that way or not.

The value of Discovery

I know the inception report isn’t the exciting part. Nobody’s commissioning a project because they’re looking forward to the discovery. But in my experience, it’s the thing that separates the projects that land from the ones that don’t.

The document isn’t the precursor to the work. For the organisations that use it properly, it’s the thing that makes implementation valuable.

If you’re clearer on what to build than why you’re building it, LET’S CHAT!