What We Ask Every Client Before We Write a Single Line of Code

Commissioning software for the first time can feel strange. You know what you need the thing to do, at least roughly, and you might even have a list. But when you are sitting across from a development team, being asked technical questions you were not expecting, it can be difficult to explain a process that mostly lives in your head and your team's shared way of working. It can feel like trying to describe your house to someone who has never seen it, in a language you only half speak.

Most people leave that first meeting wondering if they said the right things. The honest answer is that it does not matter as much as you might think, as long as the right questions get asked afterwards. And that part is on us, not you.

What we are actually trying to find out

The brief is a starting point, and often a useful one, but it is still only a starting point. What it rarely captures is the texture of how a business actually runs day to day. The step everyone takes before sending the report because something went wrong once and nobody wants it to happen again. The approval that exists because someone decided it should years ago, and it has simply stayed in place.

Then there are the parts of the process that work perfectly well on a quiet morning, but start to bend by Thursday afternoon when three things are happening at once. That is not something most people think to write down. Why would they? It is just how things work.

But those details are often the most important things for us to understand. The Standish Group found that 80% of software project failures come down to requirements issues, and in our experience the problem is rarely that the original spec was wrong in an obvious way. More often, it is that something important never made it into the spec at all, because nobody thought to ask or nobody realised it needed saying.

The thing about workarounds

Most businesses have workarounds. A spreadsheet that runs alongside the main system because the main system does not quite handle one particular thing. A manual check that happens before anything gets signed off. A way of doing something that began as a temporary fix and slowly became part of the process.

None of this is a problem in itself. Teams are resourceful, and they find ways to make things work. The issue comes when software is built around the official version of the process rather than the real one.

When automation is implemented properly, 77% of employees report saving up to 3.6 hours a week, which is close to a full working day back every week. When it is not, and when it is built around assumptions rather than reality, it often creates another layer of workarounds on top of the old ones. The team then has to adapt all over again, which is exactly what the software was meant to avoid.

What this looks like in a room

The first proper conversation we have with a client is not really about what they want built. It is about what life looks like right now, what is working, what is not, and where the team has learned to work around the system rather than with it. ThoughtWorks describe this as the discovery phase, and make the point that fixing something at this stage costs a fraction of fixing it once it has already been built around. We have found that to be true, consistently, across every kind of project we have worked on.

It can feel like a slow start, especially when you came in with a clear list and expected to be talking about timelines. But the questions are not a delay. They are how we make sure that what gets built actually fits the business, not just the document you arrived with.

We have been doing this for a long time, and that starting point has never changed. Begin with what the business needs to achieve, really understand it, and let everything else follow from there.

Including, eventually, the software.