The scoping phase of a project — defining what will be built, in what order, and at what cost — is where the foundation of success or failure is laid. We have seen projects derailed by poor scoping more than by almost any other cause. Unclear requirements lead to misaligned expectations. Optimistic estimates lead to budget overruns. Undefined priorities lead to the wrong things being built first.
We take scoping seriously and we invest real time in it.
Starting with Outcomes, Not Features
The first thing we try to understand is not what the client wants to build, but what they are trying to achieve. The distinction matters. Feature requests are often proxies for underlying goals — and sometimes the best way to achieve a goal is not the feature the client initially had in mind. Starting from outcomes keeps the conversation open and makes it more likely that what we build actually solves the real problem.
Prioritization Under Constraints
Every project has constraints — time, budget, or both. We help clients make explicit prioritization decisions under those constraints, rather than assuming everything on the list has equal weight.
The exercise we find most useful is simple: categorize every proposed feature as must-have, should-have, or nice-to-have, with the explicit understanding that nice-to-haves may not make it into the first version. This forces honest conversations about what is truly essential, and it creates a shared understanding of what happens if the project runs long.
Building in Contingency
We do not believe in estimates without contingency. Software development involves genuine uncertainty — requirements clarify, integrations turn out to be harder than expected, good solutions take longer to find than anticipated. An estimate that assumes everything goes to plan is not an estimate; it is a wish.
We build explicit contingency into every scope. The amount varies with the uncertainty of the work — well-understood work requires less cushion than novel or exploratory work. Clients sometimes push back on this, wanting a tighter number. We hold the line, because a realistic estimate that is met is far better than an optimistic estimate that is missed.