Before the Model

The meeting always starts the same way.

A VP of marketing asks for a dashboard to track customer engagement. A product leader wants a churn prediction model before the next board cycle. A digital transformation committee has a budget for a GenAI pilot and three months to show results. A pricing team wants optimization analysis before Q3 planning.

Each request lands with urgency. Each sound reasonable. And in each case, the analytics team starts doing what it does well: scoping data, evaluating methodology, assigning resources. What the team almost never does is stop to ask whether the decision that prompted the request has been defined.

Asking, “What should we build?” doesn’t address some fundamental questions, including: What is the decision? Who owns it? What options are on the table? What would change the outcome? In most cases, no one in the room can answer those questions cleanly.

The request moves forward anyway.

An Upstream Failure

When analytics projects underperform or fail outright, the post-mortem tends to focus on execution: data quality issues, model drift, poor adoption, stakeholder misalignment. These are real problems. But they are rarely where the failure originates.

A 2025 S&P Global Market Intelligence study found that the share of companies abandoning the most AI initiatives before production rose from 17% to 42% year over year.1 Organizations scrapped an average of 46% of projects between proof of concept and broad adoption.¹ The study also found that lower-failure organizations used a more systematic approach to project prioritization, incorporating compliance, risk, and data availability criteria before committing to execution. What the study describes, without using the term, is an upstream framing failure. Teams are not abandoning projects because of poor modeling. They are abandoning them because the problem was never defined well enough to survive contact with reality.

In Good Strategy Bad Strategy: The Difference and Why It Matters, Richard Rumelt identifies the same failure mode in strategic planning: the confident execution of a plan with an underlying premise that was never examined.² In these cases, activity replaces strategy. Work replaces thought. The parallel to analytics is direct: technically sound execution on a poorly framed problem is not a partial win. It is a complete miss.

Tversky and Kahneman's research on framing effects makes this concrete.³ How a decision problem is presented shapes which options appear available, which trade-offs seem acceptable, and which outcomes are even considered. Analytics work inherits the frame of the question it was handed. If that frame is wrong, no downstream sophistication corrects it.

Why Business Problem Framing Is Determinative

The INFORMS Analytics FrameworkTM organizes analytics practice into seven domains: business problem (question) framing, analytics problem framing, data, methodology (approach) framing, analytics/model development, deployment, and analytics solution life cycle management.

Domain I is business problem (question) framing. It sits first in the framework not as a formality, but because it is structurally determinative. Every decision made downstream is bounded by the clarity of the problem definition that precedes it. No methodology selection, no modeling accuracy, no deployment discipline compensates for a poorly framed business problem. An analysis can be rigorous, reproducible, and well-communicated and still produce no business value because it answered the wrong question.

Domain I asks practitioners to establish the business context, identify the decision the analysis is meant to support, clarify who owns that decision, and understand what constraints are in play before any analytical work begins. This is not soft work. It is diagnostic work, and it is where most projects are won or lost.

The transition to Domain II, analytics problem framing, is where the work becomes technical: What is the analytical question that corresponds to the business question? What type of analysis is appropriate? What would a useful output look like? These two domains together define the scope of everything that follows.

When practitioners skip Domain I, they typically discover its absence somewhere in Domains IV-VII, at the point where the work is already done and stakeholders cannot agree on what to do with it.

Five Signs the Business Problem Is Not Yet Framed 

The deliverable is named before the decision is named. The request specifies a dashboard, a model, a report, or a pilot. No one has articulated what decision this output is intended to support. Success is defined as shipping the analysis, not improving a decision. The team’s stated goal is delivery. Whether the output changes any action is treated as a post-delivery question.

Stakeholders disagree on what action will follow. In the churn model scenario, will marketing suppress offers to high-risk customers, or will customer success prioritize outreach to them? These are different interventions requiring different model specifications and different success criteria.

Data availability is mistaken for problem importance. The organization has good clickstream data, so the engagement dashboard gets built. The pricing optimization question, which would require data not currently in the warehouse, does not. The portfolio of analytics work reflects what is easy to measure rather than what matters to the business.

The model is scoped before the trade-off is understood. A GenAI pilot is approved for customer support deflection. The team begins evaluating models. No one has defined the acceptable error rate, the threshold for human escalation, or what cost-per-resolution comparison to human agents is. These are the trade-offs the decision-maker will evaluate. The model cannot be designed without them.

Any one of these patterns is a signal to stop and reframe before continuing.

A Better Sequence

Before analysis begins, seven questions should have clear answers, confirmed by the decision-maker.

• What decision needs to be made? Not what output is needed, but what choice is being made and when.
• Who owns it? One person, accountable for the outcome after the recommendation is delivered.
• What options are available? Many analytics requests implicitly assume a decision space that does not exist. The organization cannot act on a recommendation no one has the authority to implement.
• What evidence would change the decision? If the answer is “nothing” or “I don’t know,” the analysis will not be useful regardless of quality.
• What constraints matter? Timeline, budget, regulatory requirements, and organizational bandwidth all shape what recommendations are actionable.
• What would count as a useful recommendation? A specific action, a ranked set of options, a go or no-go judgment? The output format should follow the decision structure.
• What would tell us we were wrong? This is rarely asked. It is probably the most important question. A framing that cannot specify its failure conditions is not a framing; it is a hope.

Why This Matters More When Execution Accelerates

Generative AI and modern data infrastructure have made analytics execution dramatically faster. Teams that previously needed weeks to build and iterate on a model can now prototype in days. Dashboards that required engineering queues can be self-served.

Speed amplifies framing errors. The faster a team can build, the more output it can produce regarding an unexamined question before anyone notices the question was wrong. The cost of a framing failure in a slow organization is weeks of wasted work. In an organization with mature tooling and capable practitioners, it is months of technically excellent work pointing in the wrong direction.

This is not an argument against fast execution. It is an argument for front-loading the diagnostic work that makes fast execution worthwhile. An analytics team that can move quickly on a well-framed problem is a significant organizational asset. The same team moving quickly on a poorly framed problem is a liability that looks, for a while, like productivity.

The INFORMS Analytics Framework was designed to bring discipline to the full analytics life cycle. Domain I exists because the authors of that framework understood what practitioners still rediscover on every project: the work you do before the analysis determines the value of that analysis. Not as a matter of process hygiene, but as a structural constraint.

The Discipline Begins Before the Analysis

Analytics teams do not fail because they lack rigor. They fail when rigor is applied in the wrong question.

The discipline the INFORMS Analytics Framework describes begins in Domain I: with the business context, the decision structure, the options, and the constraints that make a recommendation actionable. Before data are selected. Before methodology is chosen. Before a model is scoped.

Frame the decision first. Then choose the data, the method, the model, and the deployment path. The sequence is not arbitrary. It is what separates analysis that generates value from analysis that generates findings no one knows what to do with.

Note: Frame Decisions by Virtual Strategy Tech is an independent platform and is not affiliated with, sponsored by, or endorsed by INFORMS. INFORMS materials are referenced or reproduced with permission where applicable.

References

1. S&P Global, 2025, “Generative AI Experiences Rapid Adoption, But With Mixed Outcomes – Highlights From VotE: AI & Machine Learning,” https://www.spglobal.com/market-intelligence/en/news-insights/research/ai-experiences-rapid-adoption-but-with-mixed-outcomes-highlights-from-vote-ai-machine-learning.
2. Rumelt, R. P., 2011, Good Strategy/Bad Strategy: The Difference and Why It Matters. Crown Currency.
3. Tversky, A., Kahneman, D., 1981, “The Framing of Decisions and the Psychology of Choice,” Science, Vol. 211, Issue 4481, pp. 453–458, https://doi.org/10.1126/science.7455683.