Running a Discovery That Produces a Real Scope

Published by CodeNicely, the product studio founded by Meghal Agrawal and Ujjwal Agrawal in 2017

For: A VP of Product or COO at a 500-person US enterprise who has been burned by a vague SOW on a prior build and is now gating the next engagement behind a paid discovery — but has never run one before and does not know what a good output looks like

A discovery produces a real scope only when it ends with four artifacts: a feature list with acceptance criteria per story, an architecture decision record covering compliance and integrations, a fixed-price SOW, and — the one most buyers miss — a priced change-order threshold written into that SOW. Without the threshold, the discovery document legally functions as a letter of intent. The vendor can re-estimate anything the moment build begins, and you have no contractual basis to push back.

If you are gating the next engagement behind a paid discovery because the last fixed-bid SOW blew up on you, the instinct is right. The data backs it. McKinsey and Oxford studied 5,400 large IT projects and found the average ran 45% over budget and delivered 56% less value than predicted, with 17% becoming black swans at 200–400% overrun. The Standish CHAOS Report pins unclear requirements as the #1 cause of failure at 39%. Teams that invest 8–14% of budget in a proper discovery hit 73%+ budget adherence versus the 29% industry norm.

The discovery works. A bad discovery does not. This is the process to run a good one — as the buyer, not as the engineer.

Step 1: Scope the discovery before you pay for it

Treat the discovery itself like a mini-SOW. Before you cut the PO, agree in writing on: the exact deliverables (named below), the number of workshop hours with your SMEs, which of your systems the vendor gets read access to, and the acceptance criteria for the discovery itself. Yes — acceptance criteria for the discovery. If the vendor cannot tell you what "done" looks like for a scoping exercise, they will not know what "done" looks like for the build either.

The deliverable list should be explicit. At minimum:

• A prioritized backlog with acceptance criteria per user story, not just epics
• An Architecture Decision Record (ADR) covering data model, integration pattern per external system, hosting topology, and compliance posture (SOC 2, HIPAA, PCI as applicable)
• A risk register with mitigation owners
• A fixed-price SOW for the build, with a stated change-order threshold
• A test strategy, including which environments the vendor will stand up and who owns UAT

Anti-pattern: paying for a discovery whose output is described as "wireframes, user journeys, and a high-level proposal." That is a sales artifact. You will not be able to hold anyone to it.

You'll know this step is done when the discovery SOW itself lists the five deliverables above by name, and your procurement or legal team has signed it.

Step 2: Force compliance architecture into week one, not week six

This is where most enterprise discoveries quietly fail. The vendor runs four weeks of product workshops, produces lovely Figma frames, and then — in the final week — mentions that SOC 2 and HIPAA "will be addressed during build." They cannot be. Not without restarting the clock.

SOC 2 Type II audits evaluate operating effectiveness over a 6-to-12-month observation window. If you decide six weeks into build that you need audit logging on every PHI read, encryption-at-rest with customer-managed keys, and segregated prod access — you are rebuilding plumbing and your SOC 2 observation window resets. And SOC 2 is not HIPAA. SOC 2 does not cover BAAs, minimum necessary standard, patient rights, or breach notification timelines. These are separate scoping gates. If your product touches PHI, both get decided in discovery or neither gets decided correctly.

Put a specific checkpoint on the discovery calendar in week one: a 90-minute architecture session where the vendor's tech lead walks your security or compliance officer through the proposed data flow, identifies every point where regulated data enters or leaves the system, and names the control for each. The output is an ADR, not a slide.

Anti-pattern: letting the vendor defer compliance to "an addendum." Addenda are where margins go to die and where change orders get born.

You'll know this step is done when you have a one-page data flow diagram with every regulated data touchpoint annotated, a named control, and the sign-off of your internal security lead.

Step 3: Write acceptance criteria at the story level, not the epic level

"User can log in" is an epic. "User can log in via SAML SSO using Okta as IdP, with session expiry of 8 hours, MFA enforced for admin roles, failed logins logged to CloudWatch with alerting after 5 attempts in 10 minutes" is an acceptance criterion. The second one is testable. The first is litigable.

Scope creep hit 52% of projects in 2024, up from 43% five years prior, with average overruns of 27%. Scope creep is not usually malicious. It is the gap between what the epic said and what the engineer had to assume. Close that gap in discovery and you remove the pretext.

Your job during discovery workshops is not to write the criteria — it is to interrogate them. For every story the vendor produces, ask: what is the expected input, the expected output, the failure mode, who sees the error, and what gets logged? If the vendor cannot answer in the workshop, the story is not ready to be estimated, which means it is not ready to be in the fixed-price SOW.

Anti-pattern: accepting a backlog where acceptance criteria appear only on the "top 10 stories" and everything else is a one-liner. Those one-liners are future change orders.

You'll know this step is done when every story in the build backlog has testable acceptance criteria, and your QA lead confirms they could write a test plan from them without calling the vendor.

Step 4: Demand a priced change-order threshold in the SOW

This is the non-obvious one. Even a beautifully-scoped discovery produces a build SOW that will, inevitably, meet reality. Requirements shift. Integration partners change APIs. Your own stakeholders discover a missing capability in sprint 3. The question is not whether change happens — it is who pays, and at what threshold the conversation becomes a formal negotiation versus absorbed scope.

The SOW must specify, in writing:

• A story-point or dollar band within which changes are absorbed by the vendor without a change order (e.g., "cumulative changes up to X% of contract value, or Y story points, are absorbed")
• A rate card for changes above that threshold, locked for the contract duration
• A named approver on each side for change orders
• A turnaround SLA for change-order estimates (e.g., 3 business days)

Without this clause, your discovery document is a letter of intent. The vendor can, with technical correctness, claim that any new detail that surfaces during build was "not in the discovery scope" and re-estimate. With the clause, you have a contractual pressure valve. Small changes flow through without ceremony. Big changes trigger a formal conversation at a known rate.

Have your lawyer review this clause specifically — the legal construction of "what counts as a change" versus "what counts as a clarification" is where enforceability lives, and generic SOW templates are weak here. This is not legal advice; it is a prompt to get actual legal advice on the one clause that matters most.

Anti-pattern: accepting a "T&M top-up" clause with no cap and no threshold. That is not a change-order mechanism — it is a blank check.

You'll know this step is done when your procurement lead can point to the clause, read it aloud, and explain exactly what triggers a change order and what does not.

Step 5: Run a joint estimation session, not a handoff

Most discoveries end with the vendor disappearing for a week to "produce the proposal." This is where fixed-bid numbers get inflated to cover the vendor's risk — risk that exists because you were not in the room when they estimated.

Instead, book a half-day joint estimation workshop as the second-to-last discovery activity. Your technical stakeholder (fractional CTO, engineering director, or security architect) sits with the vendor's tech lead and walks through each story. Ask: what is the complexity driver, what are the three assumptions baked into this estimate, and what would make it 2x or 0.5x? Capture those assumptions in the SOW as stated preconditions.

This does two things. It strips 10–20% of defensive padding out of the estimate because the vendor is not guessing about your environment anymore. And it converts hidden assumptions into stated ones, so if an assumption breaks, the change order is a conversation about the assumption, not a fight about the estimate.

Anti-pattern: receiving the proposal by email with a single blended day rate and a total. You cannot negotiate what you cannot see.

You'll know this step is done when your technical stakeholder can describe the three largest cost drivers in the proposal without opening the document.

Step 6: Do a pre-build dry run of the governance model

Before the build kicks off, run one two-week sprint cycle as a dry run — on discovery-phase work, not build work. Use the backlog grooming ritual, the demo cadence, the change-request process, the escalation path. You are stress-testing the governance model, not the engineering.

What you are looking for: does the vendor's PM actually run the change-order process the SOW describes? Do demos happen on the day they are scheduled? Does your own team show up to UAT? Most governance failures in the build phase are visible in the first dry-run cycle. Catching them before kickoff costs you a sprint. Catching them in month three costs you the project — and NIST research cited through 2024 shows fixing a defect after release costs up to 100x more than catching it at the requirements stage.

You'll know this step is done when one full sprint ceremony cycle has run end-to-end with no process improvisation needed, and both sides have signed off on the governance model.

What a discovery costs and how long it takes — the shape of the number

Published research puts a well-run discovery at 5–10% of total project budget, and Standish-derived data pushes the sweet spot to 8–14% for the budget-adherence benefit to show up. Duration for an enterprise-grade discovery with compliance scope typically runs four to eight weeks, but the range depends almost entirely on four things you control:

• How many of your SMEs are actually available for workshops (this is the biggest single driver — unavailable SMEs stretch timelines more than scope does)
• How many external systems you need integrated, and whether you own or merely use them (owning the API is a week; negotiating access to someone else's is a month)
• Your compliance footprint — SOC 2 alone, SOC 2 + HIPAA, or HITRUST adjacency. HITRUST initial certification runs $100K–$250K+ on its own and reshapes the architecture conversation
• Whether you have existing production data to migrate or you are greenfield

As an illustrative example: a two-integration greenfield MVP with SOC 2 scope and four available SMEs is a different shape of discovery than a six-integration replatform with HIPAA, legacy data migration, and SMEs available two hours a week. The first might be four weeks; the second is a different project. The two or three specifics that turn this into a real quote are: SME availability, integration count and ownership, and compliance footprint. Walk into a scoping conversation with those three answers and you will get a usable range in one call.

How CodeNicely can help

We have run this exact discovery structure for HealthPotli, an AI-driven e-pharmacy where HIPAA-equivalent data handling, drug interaction model integration, and third-party pharmacy APIs all had to be nailed down in the ADR before a single build sprint. The discovery produced the backlog, the compliance architecture, the fixed-price SOW, and the change-order threshold — in that order, as separate deliverables. That is the structure we would run for an enterprise buyer in your position.

If your build has a regulated-data dimension, the HealthPotli engagement is the closest analogue. If it is a fintech or ledger-heavy build, the GimBooks discovery process, which locked a YC-backed accounting SaaS scope before build, is a better reference. For enterprise buyers in the US specifically, our US-market practice runs discoveries with legal review of the change-order clause as a standard step.

The bottom line

A discovery that ends with wireframes and a proposal is a sales pitch. A discovery that ends with story-level acceptance criteria, a compliance ADR, a fixed-price SOW, and a priced change-order threshold is a scope. The difference is whether, six months into build, you are negotiating from a document or arguing about what it meant. Pay for the second one. Refuse the first.

Frequently Asked Questions

How much of my total project budget should go to discovery?

Published research across Standish CHAOS and Acquaint's 1,300-project dataset converges on 5–14% of total project budget, with the higher end correlating with meaningfully better budget adherence (73%+ versus the 29% industry norm). The driver is not the percentage — it is whether the discovery produces testable acceptance criteria and an architecture decision record, or just wireframes.

What is the difference between a discovery phase and a discovery sprint?

A discovery sprint is typically one to two weeks and produces a problem definition and high-level solution direction — useful at the idea stage. A discovery phase for enterprise software is four to eight weeks and produces a buildable scope: backlog with acceptance criteria, architecture decisions, compliance posture, and a fixed-price SOW with change-order terms. If you are gating a build behind discovery, you need the phase, not the sprint.

Should the discovery vendor also be the build vendor?

Usually yes, but only if the discovery SOW explicitly makes the build engagement optional and you retain full IP ownership of all discovery artifacts regardless of who builds. This preserves your ability to take the discovery output to a second vendor for a competing bid — which is the primary pricing-discipline mechanism available to you. Any vendor who resists this clause is telling you something.

What should a change-order threshold actually say in the SOW?

It should specify a cumulative absorption band (as a percentage of contract value or story points), a locked rate card for changes above that band, named approvers on both sides, and an SLA for the vendor to produce a change-order estimate. The legal construction of what counts as a "change" versus a "clarification" is where enforceability lives — have your lawyer review this clause specifically rather than relying on a template.

Can compliance architecture (SOC 2, HIPAA) really not be deferred to the build phase?

Not without cost. SOC 2 Type II evaluates operating effectiveness over a 6-to-12-month observation window, so controls added mid-build reset the audit clock. HIPAA requires BAAs, minimum-necessary data handling, and breach notification mechanisms that are architectural, not bolt-on. The decisions can be revisited, but the data model, access control model, and audit logging approach must be set in discovery or you pay the NIST 100x penalty later.