How to Scope a Software Project So It Doesn't Take 6 Months to Start

The most expensive phase of most enterprise software projects is the one that produces zero working code. The discovery phase. Israeli CTOs routinely watch six months disappear into workshops, requirements documents, stakeholder interviews, and architecture committees — before a single line of code gets written. By the time delivery starts, the business need has shifted, key people have moved on, and the project has acquired enough political baggage to sink itself. Here is why this happens and how to stop it.

Why Discovery Phases Drag On

Three forces conspire to make discovery slow:

• The vendor is billing by the hour. A vendor on time-and-materials has every incentive to extend discovery. More workshops mean more invoices. Nobody admits this out loud, but the math is the math.
• The client is afraid to commit. Once you sign off on a specification and a price, you own the consequences. Endless discovery is a way of postponing accountability. It feels productive because there are meetings. It is not productive.
• Nobody knows when discovery is done. Without a clear definition of "scoped," the requirements document keeps growing. Every stakeholder adds their wish. The 40-page document becomes a 120-page document, then a 200-page document, and somewhere in there the project quietly dies.

The result: a "discovery phase" that becomes a discovery industry. Documents nobody reads. Architectures nobody implements. And six months later, a kickoff meeting where everyone pretends this is the beginning.

What a Good Scoping Process Looks Like

A disciplined scoping process takes two to three weeks. Not two to three months. Two to three weeks. Here is what it produces:

• A written functional specification — what the system does, who uses it, what the edge cases are. Tight. 15 to 30 pages, not 200.
• An architecture sketch — the major components, the integration points, the data model at a high level. Enough to estimate, not enough to constrain implementation choices.
• A delivery plan — phases, milestones, dependencies, and what gets demoed when.
• A fixed-price estimate — a number the vendor commits to, with the scope that number covers explicitly documented.
• A risk register — the three to five things most likely to blow up the project, and how they get managed.

Two to three weeks. Five deliverables. A clear go/no-go decision at the end. That is what good looks like.

How the 2-3 Week Process Actually Runs

The cadence matters as much as the deliverables. A good discovery runs like this:

• Week one. Three to five focused stakeholder interviews — not all-hands workshops. The vendor's tech lead and project manager attend. They listen more than they talk. By end of week one, the vendor has a draft functional spec circulating for review.
• Week two. Architecture and integration deep-dive with your tech team. The vendor produces the architecture sketch and identifies the integration risks. The functional spec gets a second pass based on stakeholder feedback.
• Week three. Estimation, risk register, delivery plan. Final review session with the decision-makers. Signed proposal at the end of the week, or a clean no-go with the discovery deliverables handed over either way.

That last point matters. Even if you choose not to proceed, you walk away with a written specification you own. That alone is worth the cost of discovery.

A Checklist for Evaluating a Vendor's Discovery Process

Before you sign anything, ask the vendor these seven questions. Their answers will tell you whether their discovery will produce results or burn your calendar.

• How long does your discovery phase typically take? (Acceptable answers: two to four weeks. Anything over six weeks for a non-trivial project means they are not disciplined.)
• What deliverables do we get at the end of discovery, and can I see an anonymized example from a previous client?
• Does discovery end with a fixed-price estimate for the build phase?
• Who from your team participates in discovery, and will the same people be on the build?
• How many stakeholders from our side do you actually need to interview? (If the answer is "as many as possible," that is a red flag. A good vendor knows three to five focused conversations beat fifteen shallow ones.)
• What happens if, at the end of discovery, we decide not to proceed? Do we own the deliverables?
• What is the cost of discovery, and is it fixed or hourly? (Fixed is a strong positive signal.)

The Honest Test

A vendor who runs a tight two- to three-week discovery, produces real deliverables, commits to a fixed price, and lets you walk away with the specification if you don't proceed — that vendor is operating with confidence. They have done this before. They know their numbers. They are not afraid of accountability.

A vendor who needs three months of workshops to scope a project they could be billing on already is telling you something important about how the build phase will go. Listen to that signal early. Six months not spent on the wrong project is six months gained.