Scoping is where most capacity-saving arrangements quietly fail. The discovery phase runs on workshops, and workshops run on your senior engineers' calendars, so the exercise meant to free your team spends three weeks of it before any code is written.
It does not have to work that way. A competent external team can scope from artefacts you already have, plus one day of questions. What follows is what that requires from you, and what it gets you.
Key takeaways
- Scoping from documents beats scoping from meetings: Your system already describes itself.
- One day of questions, not a workshop series: Anything more means they are learning at your expense.
- Decide the interface, not the architecture: The boundary is the scoping question that matters.
- The output should be refusable: A scope you cannot say no to is not a scope.
What an external team can read without you
Most of what a workshop extracts is already written down somewhere:
- The database schema. The most honest description of what a business actually does, and it is rarely wrong the way documentation is.
- API definitions and integration points. What the system already exposes and what it depends on.
- The issue tracker. What breaks, how often, and which areas consume attention.
- Repository history. Which parts change frequently, which are stable, which nobody has touched in two years.
- Deployment configuration. How things run, where, and with what.
- Recent incidents. Usually the fastest route to understanding where the system is fragile.
Giving read access to these takes an hour of someone's time. Explaining the same material in meetings takes weeks and produces a worse picture, because it is filtered through what people remember to mention.
What you do have to supply
The business outcome
One or two sentences, written by you, describing the change you want in the business rather than the software you want built. This cannot be derived from the schema and nobody else can write it.
One day of questions
A block of time with the one or two people who know the system best. Real questions from people who have already read the material, not an introduction.
The test of whether an external team is doing this properly: the questions should be specific and slightly uncomfortable. "Why does the orders table have two status columns" is a team that has read your system. "Can you walk us through your business" is a team that wants you to do the work.
A decision-maker for the boundary
Someone who can answer interface questions within a day. This is the only ongoing commitment, and it is hours a month.
Your constraints
The things that are not negotiable: a regulatory requirement, a platform you must integrate with, a date that exists for a real business reason, a technology you have standardised on. Say these at the start. Discovering them at week six is how scope gets redone.
Decide the interface, not the architecture
The question that actually needs answering is not "how should this be built". It is "where does this new thing end and our system begin".
Settle four things and the rest can follow later:
- What the new product may read, and through what route.
- What it may write, if anything.
- What it must never do. Usually no schema changes, no writes to core tables, no heavy queries against production.
- Who decides when either side needs to change.
This is a few hours of work between two technical people. It is also the thing most often deferred, because it feels like a detail next to the architecture discussion, and it is the only part that has to be agreed before work can start.
What a good scope output looks like
You should be able to refuse it. That means it contains specifics: what is in the first release, what is explicitly excluded, what assumptions it rests on, what would change the estimate, and a range rather than a single date.
A scope document that could describe any project is not a scope, it is a proposal. The useful version names things about your business that would be wrong if applied to someone else's.
It should also state what the external team still does not know, and what would resolve it. That list is a better indicator of quality than the confident parts.
Ali Boran Gazel