Custom software projects that fail almost never fail because of bad code. They fail because the problem was not understood properly before the build started.
The brief described a solution. The team built it. Six months later, the software did exactly what was asked - and did not fix what was wrong. Because what was asked and what was wrong were not the same thing.
This pattern is not a failure of intent. The client described their problem as clearly as they could. The development team built what they were told. The failure was in the process between those two things - the stage where the real problem should have been understood before any design began.
Why briefs almost always describe the wrong thing.
People describe problems in terms of solutions. It is natural. When something is frustrating, the mind moves quickly to what would fix it. But the first solution that comes to mind is usually a solution to the symptom, not the cause.
"We need a reporting dashboard" - but the actual problem is that nobody agrees on which numbers are correct. Building a dashboard does not fix the underlying data conflict; it surfaces it more visibly.
"We need a mobile app" - but the actual constraint is that two back-end systems do not talk to each other. A mobile app built on top of disconnected data is still disconnected.
"We need this feature added" - but the feature is a workaround for a broken process. The software is now being asked to permanently encode the workaround rather than fix the process.
In each case, the client brief is accurate - it describes something they actually need. The problem is that it is not the right starting point for a build.
Five scoping mistakes we see most often.
These are not mistakes made by bad clients or careless developers. They are structural failures that occur when the scoping process is treated as a formality rather than the most important part of the project.
Treating the brief as a specification
The brief describes what the client wants. A specification describes what needs to be built. Moving from one to the other is the job of scoping - skipping it means building from an incomplete picture.
Skipping process mapping
How does the work actually flow today? Where does it break down? What are the edge cases? What must not be lost when the new system goes live? If you have not mapped the current process in detail, you are building a replacement for something you do not fully understand.
Not surfacing constraints early
Every project has hard constraints: legacy systems that cannot be replaced, regulatory requirements, data that does not exist in the format assumed, third-party integrations with undocumented behaviour. Finding these at week ten is far more expensive than finding them at week one.
Assuming the happy path is the whole path
Software that works perfectly for the standard case and fails at the edge cases is not finished. Edge cases are where operations break down. Discovering them in production is the most expensive way to learn about them.
Not agreeing on what success looks like
If success is not defined before the build starts, it will be defined after it finishes - by whoever is most dissatisfied with the outcome. Agreeing on measurable outcomes upfront gives the build a fixed target.
What proper scoping actually looks like.
Proper scoping is not a discovery workshop. It is not a questionnaire. It is a structured process of understanding the real problem before any solution is designed.
It starts with process mapping: how does work flow through the business today? Not the official version - the real version, including the workarounds, the exceptions, and the parts that only one person knows how to handle. This surfaces the things the brief did not mention, because the client has lived with them so long they have stopped noticing them.
It continues with constraint identification: what are the hard limits? What systems need to integrate? What data exists and in what form? What cannot change, and what must the new system accommodate?
It ends with outcome definition: what does success look like, specifically? What should the system do that the current process cannot? What should it stop requiring people to do by hand? What measurable change in the operation will confirm that the build solved the right problem?
This work takes time. It slows the start of the build. It also dramatically reduces the cost of the build - and the probability that the software delivers something useful.
The uncomfortable part of doing this properly.
Good scoping sometimes produces an uncomfortable finding: the thing the client asked to build is not the thing that will fix the problem. Or it will fix part of the problem - but the more important problem is elsewhere.
This conversation is easier to have before the build starts than after. It is also the conversation that determines whether a project ends with software that works and a problem that is solved - or software that works and a problem that remains.
We are not a feature factory. Before we design anything, we map the real process. The brief is the starting point. The job of scoping is to find out what it is not saying.
If you have a brief for a piece of software and want to know whether it describes the right problem, we can work through it - no lengthy proposal before we understand your situation.
Start a conversation →