Roughly 80% of data science projects never reach production. The reasons rarely involve algorithms or computational power. They involve scope—projects that promised too much, addressed the wrong problem, or never defined what success actually meant.

Scoping is the unglamorous discipline that separates analytics teams that compound business value from those that perpetually rebuild proof-of-concepts. It happens in the first two weeks, often in conference rooms rather than notebooks, and determines whether the next six months produce insight or expensive disappointment.

The frameworks that follow address the three failure modes that account for most stalled initiatives: vague problems that resist analytical translation, ambitious scopes that ignore organizational reality, and success metrics that optimize for technical elegance instead of business outcomes. Each can be addressed in days, not quarters—if you know what to ask before the modeling begins.

Most data science projects begin with a request that sounds analytical but isn't. Help us understand our customers better. We need to use AI for retention. These are aspirations, not problems. The first scoping task is converting them into questions a model can actually answer.

The reliable translation tool is what practitioners call the decision-first interview. Instead of asking stakeholders what they want analyzed, ask what decision they will make differently once the analysis exists. If the answer is unclear, the project is premature. If the answer is concrete—which 5,000 customers should our retention team call next month—you have an analytically tractable problem.

Tractability has three components. The outcome must be measurable in available data. The decision must occur frequently enough to justify a model rather than human judgment. And the prediction window must align with when intervention is still possible. A churn model that flags customers the day they cancel is technically accurate and operationally useless.

Strong problem definitions also specify the counterfactual. What happens today without the model? Often the answer reveals that the existing process—a simple rule, a manager's intuition, a spreadsheet—performs surprisingly well. The project's value isn't the model's accuracy in absolute terms; it's the lift over what already exists.

Takeaway

A well-scoped data science problem names the decision that will change. If no one can articulate what they'll do differently with the output, no model—however accurate—will create value.

Once a problem is defined, feasibility determines whether it's worth pursuing now. The mistake teams make is treating feasibility as a question of model performance—can we hit 90% accuracy?—when the binding constraints almost always lie elsewhere.

A useful feasibility audit examines three dimensions in parallel. Data availability asks whether the historical record contains enough labeled examples, with sufficient quality and recency, to learn the pattern. Technical complexity asks whether the modeling task fits known approaches and available infrastructure. Organizational readiness asks whether downstream systems, processes, and people can absorb the model's output.

Of these, organizational readiness fails most often and is examined least. A fraud detection model that requires investigators to act within four hours dies if the team works business hours. A pricing recommendation engine fails if sales reps lack authority to override list prices. The technical work succeeds; the value never materializes.

The discipline here is a time-boxed assessment—two weeks, with explicit kill criteria. Pull a sample of the data and verify it contains what stakeholders described. Build a trivial baseline model to estimate the achievable signal. Map the operational workflow that will consume the predictions. If any dimension fails badly, redefine the project before committing further resources.

Takeaway

Feasibility is rarely about whether a model can be built. It's about whether the organization around the model can act on what it produces.

The gap between a model that performs well in evaluation and a model that creates business value is bridged by carefully designed success criteria. This is where analytical rigor must meet economic thinking, and where many projects quietly lose their way.

Effective success criteria operate at two levels. The technical metric—AUC, RMSE, F1—measures the model's predictive quality on held-out data. The business metric—incremental revenue, reduced fraud losses, hours saved—measures the value delivered when predictions drive decisions. Projects fail when teams optimize the first and assume the second follows.

Translation between the two requires explicit assumptions: the cost of false positives versus false negatives, the rate at which recommended actions are actually taken, the elasticity of the underlying business response. Documenting these assumptions during scoping forces a conversation about whether the project's economics work even with a moderately performing model. Often, simple math reveals that the use case can't generate enough lift to justify the effort, regardless of algorithmic sophistication.

The strongest success criteria also specify a measurement plan before development begins. How will incremental impact be isolated—a holdout group, a phased rollout, a pre/post comparison? Without this commitment upfront, post-hoc evaluations devolve into selective storytelling, and the project's true contribution becomes impossible to assess or replicate.

Takeaway

If you cannot describe how the model's business impact will be measured before you build it, you will not be able to describe it after either.

Project scoping is where data science earns its return on investment, long before the first model trains. The three disciplines—rigorous problem definition, honest feasibility assessment, and value-aligned success criteria—are not bureaucratic overhead. They are the leverage points where most projects are won or lost.

Teams that internalize these frameworks reject more projects than they accept. That selectivity is the point. A portfolio of well-scoped initiatives that ship and create measurable value beats a roster of ambitious experiments that never reach production.

The next time a stakeholder arrives with a request, resist the impulse to start modeling. Spend the first two weeks scoping. The work that follows will be faster, more focused, and far more likely to matter.