Most technical projects fail at the scoping phase, not the execution phase. The project that ran over by six months, produced something that didn’t quite match expectations, or got cancelled partway through — in nearly every case, the root problem was established in the first few weeks, before most engineers started working.
Scoping isn’t writing a requirements document. It’s the thinking process that determines whether a project has a coherent, achievable definition before resources are committed to it. Done well, it prevents three months of work from being thrown away. Done poorly — or skipped — it virtually guarantees it.
What Good Scoping Accomplishes
A well-scoped project has:
- A clear problem definition that everyone agrees on
- Explicit boundaries for what’s in scope and what isn’t
- Known unknowns (risks and questions that aren’t answered yet) made visible
- A feasibility assessment: can this be done in the available time with the available team?
- Success criteria that are measurable before execution begins
A poorly scoped project has one or more of these missing or ambiguous. Teams that skip scoping usually realize their mistake around the halfway point, when the assumptions they made at the start have accumulated into something that doesn’t quite work — and the time to revisit them is already past.
Step 1: Define the Problem Before the Solution
The single most common scoping error is defining the solution before the problem. Someone says “we should rewrite the service in X” or “we need a new data pipeline” — and the project gets scoped around implementing that solution, rather than around solving the underlying problem.
The fix: start every scoping conversation with the question “what problem are we actually solving?” and refuse to answer that question with a solution.
Good problem definition looks like: “Database query latency has increased 3x over the last quarter and is now causing ~15% of user-facing API calls to time out. This is generating support escalations and we have evidence it’s affecting retention in the signup flow.”
Bad problem definition looks like: “We need to migrate from Postgres to Cassandra.”
The first is a problem. The second is a proposed solution. Those are different things, and conflating them leads to projects that implement the solution perfectly while failing to address the problem.
Step 2: Write the Non-Goals
The most important thing you’ll write in a scoping document is the non-goals section. Non-goals are explicit statements about things this project will not do, even though they might seem related.
Non-goals prevent scope creep, align stakeholders, and force a conversation about priority that often gets skipped. If you write “this project will not address performance on mobile devices,” someone might disagree — and that disagreement is better to have at the scoping phase than six weeks into implementation.
Good non-goals are specific and might be controversial:
- “This will not support multi-region deployment in the initial release”
- “We will not migrate existing data — this covers new data only”
- “This does not include the admin interface — that is a follow-on project”
Vague non-goals are useless:
- “We’re not trying to solve every edge case”
- “This is just phase one”
The specificity of non-goals is a direct measure of how clearly the scope has been thought through.
Step 3: Surface the Unknowns Early
Every project has unknowns. The question is whether you surface them at the scoping phase, when they’re cheap to address, or during execution, when they’re expensive.
Create an explicit list of known unknowns — things that are uncertain and need to be resolved before or during the project:
- Technical unknowns: “We haven’t confirmed that the third-party API can support our required throughput”
- Dependency unknowns: “The data schema migration requires coordination with the iOS team, whose timeline is unclear”
- Requirement unknowns: “We don’t know whether this feature needs to support the legacy customer format”
For each known unknown, identify:
- What would we need to know to resolve this?
- Who can answer it?
- Can we answer it before the project starts? If not, when?
Some unknowns are blockers — the project can’t proceed without resolving them. Others are risks — the project can proceed but the outcome depends on how they resolve. Distinguishing these two categories is critical for the project plan.
Step 4: Identify Dependencies and Owners
Projects that span multiple teams have dependency risk that single-team projects don’t. For each cross-team dependency:
- What specifically does this team need to deliver, and by when?
- Have they committed to this dependency explicitly, or is it assumed?
- What’s the risk if they slip?
- Is there an alternative path if they can’t deliver?
The last question is often skipped. “Team X will deliver the API in Q2” frequently translates to “if Team X slips, our project is blocked.” That’s a risk that should be documented and shared with stakeholders — not a hidden assumption in the project plan.
For dependencies on external systems (third-party APIs, vendors, regulatory decisions), the same logic applies. Map them explicitly, assess the slip risk, and identify alternatives or contingencies.
Step 5: The Scope Stability Test
Before finalizing scope, run it through a stability test: what set of events would cause this scope to change mid-project?
Possible answers:
- “If the API performance numbers don’t meet targets during testing” — this is a technical risk that should be in your known unknowns
- “If product decides to add a new user segment” — this is a stakeholder alignment risk; make sure product has signed off explicitly
- “If we discover the database schema is more complex than expected” — this is a technical unknown; add a discovery spike to address it before committing to the full scope
A project whose scope would change under foreseeable conditions hasn’t been properly scoped. Either those conditions need to be resolved first, or the scope definition needs to explicitly account for them.
The Minimum Viable Scope
One of the most useful questions in any scoping conversation: what is the minimum version of this project that would be valuable?
This question forces prioritization. It distinguishes what’s essential from what’s nice-to-have. And it often reveals that the first deliverable can be much smaller than what was originally proposed — which means value can be realized sooner and the full project can be phased more manageably.
Minimum viable scope isn’t about cutting corners. It’s about being explicit about what the initial investment commits to, and what future iterations would build on top of it. A project that delivers value in increments is usually more successful than one that delivers everything at once — because it creates checkpoints where learning can be incorporated.
When Scoping Breaks Down
Scoping fails in recognizable patterns:
The solution-first trap. The project starts from a proposed solution rather than a problem. The solution may be the right one — but the project lacks the shared understanding of the problem that would allow the team to make good judgment calls when the solution turns out to be harder than expected.
Assumed consensus. The scoping conversation happened among a subset of stakeholders, and the others “agreed” via silence rather than explicit buy-in. The disagreement surfaces later, usually at the worst possible time.
Unknown unknowns treated as known. The scope is presented as certain when it depends on unresolved technical questions. When those questions resolve against the assumed answer, the scope is wrong — but the project is already underway.
Unbounded success criteria. “Make the system faster” or “improve reliability” — without specific targets, there’s no shared understanding of when the project is done. This is how projects run indefinitely without delivering value.
What to Do With a Poorly Scoped Project
If you’re joining a project that’s already underway with poor scoping, the right move is to surface the problem rather than push through it. Convening a scoping retrospective — “let’s take two days to make sure we agree on what we’re building before we go further” — is nearly always worth it, even if it creates friction.
The alternative — continuing without addressing the scoping problem — typically results in much more expensive scope corrections later. Two days of rework at the start beats three weeks of rework at the end.
VividMap helps you track the scoping decisions, unknowns, and tradeoffs in your projects over time — so the reasoning behind technical decisions is visible when you need to explain or revisit them. See how it works.