Most data projects don’t fail at the technical layer. They fail at the seams between phases — where a vague brief metastasizes into a six-month build, or a working pipeline ships without anyone agreeing on what success looks like. The fix isn’t more rigor inside each phase; it’s a hard gate between phases with named exit criteria that anyone on the project can recite. Four gates, in order: discovery, scope, build, ship. If a project can’t pass the gate, it doesn’t advance. It either loops back, gets descoped, or gets killed.

Gate 1: Discovery

Discovery is the cheapest phase to get wrong and the most expensive one to skip. It exists to answer a single question: is there a real problem here that is worth solving with the proposed approach? Most discovery failures look like a stakeholder describing a dashboard they want, a team agreeing to build it, and nobody asking what decision the dashboard is supposed to support.

Exit criteria:

  • A one-page problem statement naming the decision the work supports, the person who makes that decision, and the cadence on which they make it.
  • A documented current-state baseline — what the decision-maker uses today, even if the answer is “gut feel” or “an exported CSV.”
  • A named business sponsor with budget authority who has signed off in writing.
  • An explicit non-goal list — at least three things the project will deliberately not do — to prevent scope drift before it starts.
  • A written hypothesis about expected impact, even if the number is rough. “We think this saves the ops team four hours a week” is a hypothesis. “It will improve visibility” is not.

If any of these are missing at the gate review, the project goes back into discovery. It does not get a scope document.

Gate 2: Scope

Scope translates the validated problem into a buildable thing. The failure mode here is a scope document that reads like a wishlist — every stakeholder’s favorite chart, every adjacent dataset, every “while you’re in there” request. A good scope doc is shorter than people expect and explicitly says no to more than it says yes to.

Exit criteria:

  • A data contract for every source system the project depends on: source of truth, refresh cadence, owner, known quality issues, SLA.
  • A target data model with grain, primary keys, and slowly-changing-dimension policy named per table. No hand-waving “we’ll figure out the model during build.”
  • Acceptance tests written in plain language before any code is written. “Order count for last 30 days matches Shopify admin within 0.5%” is an acceptance test. “Data is accurate” is not.
  • A deployment target named — which warehouse, which BI tool, which notification channel, which access pattern.
  • An estimate range, not a point estimate. If the team can’t bound the work between an optimistic and pessimistic number, the scope isn’t tight enough yet.
  • A kill criterion: the condition under which the project should be stopped mid-build rather than finished. Most projects don’t have one and that’s why most projects ship even when they shouldn’t.

Gate 3: Build

Build is where most teams over-invest in process and under-invest in feedback. The exit criteria here are not about code quality in the abstract — they’re about whether the thing being built actually behaves the way the scope document promised.

Exit criteria:

  • All acceptance tests from the scope gate pass on real production data, not on synthetic samples or a partial backfill.
  • Pipeline observability in place before launch: row counts logged, freshness monitored, failures route to a real human within an SLA. A pipeline with no monitoring is not done; it’s a future incident.
  • Documentation that a successor engineer could use to make a non-trivial change in under two hours. If only the original author can modify the work, the work is not finished.
  • The decision-maker named in discovery has used the deliverable on real data, in front of the build team, and confirmed it answers their question. Not “looks good” — used it to make a real call.
  • A rollback plan. Every change has one path forward and at least one path back.

Gate 4: Ship

Shipping is not a deploy event; it’s a handoff event. The exit criteria measure whether the work has actually transferred from the build team to the operating team — or whether the build team is now permanently on the hook for support.

Exit criteria:

  • Runbook covering the three most likely failure modes, written by the build team and dry-run by the operating team.
  • An owner named for the deliverable post-ship — not the consultant, not the original sponsor, but the person who gets paged when it breaks.
  • A 30-day usage check scheduled. If nobody uses the deliverable in the first 30 days, that is a signal, not a footnote.
  • A post-mortem on the original impact hypothesis from discovery. Did the predicted impact materialize? If not, why not? This is the loop closure that makes the next project’s discovery phase more accurate.

The gates work because they’re boring. Nobody gets famous for writing a tight non-goal list or scheduling a 30-day usage check. They work because they prevent the failure mode that nobody talks about in case studies — the project that technically delivered, on time, on budget, and changed nothing about the business.