Most failed technology projects were lost before any building began. They were lost in the gap between what a business asked for and what it actually needed. Project scoping closes that gap. It is the work of understanding the problem, defining the outcome, and agreeing what will be built before anyone writes a line of code.
We treat this as the most valuable phase of any engagement, not the preamble to it. The reason is simple. The cost of a wrong decision made in discovery is a conversation. The cost of the same decision found in build is a rebuild.
This article sets out what scoping and discovery involve, why understanding has to come before solving, and how a disciplined process protects a small business from spending well on the wrong thing.
What Project Scoping Is
Project scoping is the process of defining a project's objectives, deliverables, boundaries, and constraints before work begins, so that everyone agrees on what is being built and what success looks like. It produces a written scope of work: the document that records what is in, what is out, and how the result will be judged.
Scoping is the output. The discovery phase is how you earn it. Discovery is the structured investigation that uncovers the real problem, the people affected, the systems already in place, and the outcome the business is actually paying for. You cannot define a sensible scope for a problem you have not yet understood. The discovery process exists to make sure the scope describes the right work, not merely a plausible one.
The two questions sit side by side. Discovery asks what you need and why. The audit, which we come to below, asks what you already have. Together they replace assumption with evidence, and a guess about cost with a defensible estimate.
Why Understanding Has to Come First
Building before you understand is not faster. It is the most reliable way to be slow and expensive at the same time.
The largest study of its kind, an analysis of 1,471 IT projects by Bent Flyvbjerg and Alexander Budzier, found an average cost overrun of 27%. The average hides the real danger. One in six projects was a "black swan", with a cost overrun of 200% on average and a schedule overrun of almost 70%. These are not projects that drifted slightly over budget. These are projects that doubled in cost and ran the kind of overrun that ends a small business's appetite for the work entirely. The common thread is rarely a coding failure. It is a project that was poorly understood at the point it was committed to.
The Standish Group's CHAOS research, the long-running benchmark for IT project outcomes, makes the point from the other direction. In its 2009 figures, only 32% of projects succeeded, 44% were challenged, and 24% failed outright. When Standish ranked the factors that separate success from failure, the top three were User Involvement, Executive Support, and Clear Business Objectives. None of those three is a technical capability. Each one is decided during discovery, long before a developer is involved. Speed of execution does not appear on the list at all.
The lesson we draw from our own work matches the data. The constraint on most projects is not how fast the team can build. It is how well the problem was defined before they started.
What the Discovery Process Looks Like
Good discovery is a structured investigation, not an open-ended chat. In practice it works across a few connected areas, and the order matters because each one informs the next.
We start with the business itself. How does the company actually make money, where does growth come from, and which constraint is holding it back right now. A request for "a new website" often resolves, on examination, into a problem with conversion, or positioning, or a sales process that loses people after the first call. The stated request and the underlying problem are frequently different things.
From there, requirements gathering becomes specific. We map the process the project is meant to improve, end to end. What happens when an enquiry arrives. Who touches it. Where it stalls. What a good outcome would have looked like. Requirements gathering is the part most often rushed, and it is the part the evidence says matters most, because vague requirements are how a scope quietly expands until the budget is gone.
Then we define success in numbers, not adjectives. "A better website" cannot be delivered or measured. "Cut the time to respond to an enquiry from two days to two hours" can. Clear, measurable objectives are what let everyone agree, later, whether the project worked.
The output of all this is a scope of work that a non-technical owner can read and recognise as their own business. If they cannot, discovery is not finished.
The Audit: What You Already Have
An audit is the evidence-gathering half of discovery. Where the discovery process asks what you need, a digital audit asks what you already have, what it is costing you, and what is working. It is the difference between planning from memory and planning from facts.
A digital audit typically examines current performance, such as website traffic, conversion rates, and the real cost of acquiring a customer. It looks at the technical foundations, including hosting, data, security, and the integrations between tools. It inventories content and the systems already in place, and it asks a question owners rarely have time to ask: what are we paying for that we do not use.
In our work with small businesses, the audit is consistently the part that surprises people. We find companies paying monthly for software no one has opened in a year, sitting on customer data they have never analysed, and running manual processes that a single automation could remove. An audit turns those invisible costs into a list you can act on. Often it shows that the answer is not a new build at all, but better use of what already exists.
The audit also feeds the scope directly. You cannot connect systems through an API, or migrate data sensibly, if you have not first established what those systems are and what state the data is in. Skipping the audit is how a project discovers, in week six, a constraint that should have been known in week one.
Why So Many Skip This Step
If discovery is this valuable, the obvious question is why it gets cut. The honest answer is that it is hard to sell and easy to undervalue.
Clients want to see work being done. Mockups feel like progress. Code feels like progress. A week of questions can feel like delay, and an audit can feel like overhead, particularly to an owner who is paying by the hour and watching the clock. Many providers respond to that pressure by skipping straight to the deliverable, because that is what looks like value being delivered.
The trade is a poor one. Pendo's 2024 software benchmarks put a number on it: of every 100 features a product ships, only about six drive 80% of the usage, and the rest are rarely or never touched. Most of what gets built answers questions nobody was asking. That waste does not announce itself. It is the predictable result of starting to build before the requirements were properly understood. A short, deliberately unglamorous discovery phase is the cheapest insurance against it that exists.
We hold a plain view here. A provider who proposes a solution in the first meeting, before understanding your business, is guessing. Sometimes the guess is close. You should not pay for the times it is not.
How Scoping De-Risks the Work
A proper scope changes the shape of a project's risk. It moves the expensive decisions to the cheapest point to make them.
Three problems are designed out almost entirely. Scope creep loses its room to grow, because the scope of work names what is out as clearly as what is in, and every new request is then a visible, costed decision rather than a quiet addition. Misaligned expectations shrink, because the outcome was agreed in writing and in numbers before the build. Wasted spend falls, because building the wrong thing well is still building the wrong thing, and the audit caught most of those before they were funded.
This is also how a fixed, honest estimate becomes possible. A scope built on a real audit and clear requirements can be priced with confidence. A scope built on assumption produces the only two outcomes assumption ever produces: an overrun, or a cut corner. The 200% black-swan overruns in the Flyvbjerg study are what assumption costs when it goes wrong at scale.
None of this requires a long process. For a small business engagement, discovery and audit are usually a matter of one to two weeks. Set against a build that can run for months and a budget that cannot absorb a rebuild, that is a small, deliberate investment with an outsized return.
The Australian Picture
This matters more, not less, for a small business. Small businesses make up 97.3% of all Australian businesses, out of more than 2.7 million businesses, with the Australian Bureau of Statistics defining small as fewer than 20 employees. For nearly the entire market, a mis-scoped project is not a line item to be absorbed. It is real money that will not come back, spent by an owner who is often the strategist, the bookkeeper, and the salesperson at once.
The point sharpens with AI. Deloitte Access Economics estimates that if just one in ten Australian SMBs advanced one rung on the AI adoption ladder, $44 billion could be added to the economy each year. The same survey of more than 1,000 SMBs found two-thirds already using AI, yet only 5% "fully enabled" to realise its benefits. The gap between using a tool and getting value from it is precisely the gap discovery closes. The upside is large and conditional. Getting the scope right is the condition.
We see the AI version of the old mistake regularly. A business asks for a chatbot when the underlying problem is documentation no one can find, or asks to automate a process that should first be simplified. The technology is rarely the constraint. The clarity around it is.
The Enki Approach
We begin every engagement with discovery and audit, and we will tell you if the result is that you do not need what you came to buy. That honesty is the point of the phase, not a risk to it.
The process is deliberate. We understand the business and the problem first, audit what already exists, agree the outcome in measurable terms, and only then write a scope of work you can read and recognise. The build follows the understanding, never the other way around. This is the same discipline we apply across a unified strategy, a design system, and the wider practice of treating a business as a connected system rather than a list of parts. Understanding before solving is not a phase we sell. It is how we avoid selling you the wrong thing.