Decisions Aligned Across the Analytics Life Cycle

Good analytics can still solve the wrong problem when a business decision evolves, but the analytical question remains static. Consider a marketing team trying to figure out which advertising channel is making them the most money. In response, the analytics team develops an attribution model that ranks channel performance based on historical campaign and customer and conversion data.

As the work progresses, the real decision becomes clearer. Decision-makers are not simply trying to explain past conversions. They also need to allocate next quarter’s advertising budget. That decision must take into account existing contractual commitments, channel capacity, and long-term brand impact. The business is no longer just asking which channel made the most money, but instead where it should spend the next available advertising dollar. In this context, the model that accurately describes historical performance now offers insufficient guidance for the decision at hand.

I have seen variations of this pattern for more than a decade while building and leading enterprise analytics at Google and advising Fortune 500 companies at McKinsey. The issue is not necessarily weak analysis. The challenge is to keep problem framing active as analytics work moves from data and methodology to model development, deployment, and decision support.

How the INFORMS Analytics Framework Can Help

The INFORMS Analytics FrameworkTM (IAF) provides a useful structure for addressing this challenge. This structured approach consists of seven domains and helps teams navigate ambiguous analytics projects end to end, from business problem framing to ongoing management.¹

The first two domains, Business Problem (Question) Framing and Analytics Problem Framing, are especially important for ensuring alignment between analytics and decision-making. The Business Problem (Question) Framing domain guides teams to define the business problem statement, identify decision-makers and other stakeholders, and clarify how analytics could contribute. The Analytics Problem Framing domain then translates business needs into an actionable analytics agenda by defining objectives, inputs, outputs, assumptions, and constraints.¹

Importantly, the framework is iterative. Its guiding questions encourage teams to revisit earlier decisions as the solution develops. This is essential because business decisions live within volatile markets and changing organizations. As a team moves through the domains in the IAF, new insights or business priorities may alter the decision, requiring teams to adjust the original problem framing:²

• Data: Available data may contain biases or inaccuracies, exclude important populations, or lack the granularity required by the decision. Resolving these structural issues may take longer than the decision timeline allows. Instead of proceeding with a false sense of precision, the team may need to revisit the analytical problem statement and realign with stakeholders on the acceptable level of granularity and uncertainty.
• Methodology (Approach) Selection: A technically sophisticated method may be too difficult for non-technical stakeholders to interpret or too slow for the decision window. Additionally, factors such as stakeholder commitments, organizational precedent, or institutional priorities cannot always be cleanly modeled, regardless of methodology choice. These gaps may signal that teams should revisit the evidence base that decision-makers need and clarify which tradeoffs should remain explicit.
• Deployment: Deployment is where the analytical solution meets the organization’s workflow and decision-making structure. A recommendation has little practical value when the intended audience lacks the authority, capacity, or incentive to act on it. Teams may need to return to the Business Problem (Question) Framing domain to clarify decision ownership and feasible actions so that the analysis fully reflects how the decision is made.
• Analytics Solution Life Cycle Management: In a dynamic business setting, the original problem framing may not always remain relevant over time. As part of life cycle management, teams should periodically review the Business Problem (Question) Framing domain to confirm that the problem statement stays current. Accordingly, teams should revisit the Analytics Problem Framing domain to refresh the objectives, assumptions, inputs, outputs, and success criteria

Problem structuring has long been recognized as a substantive part of analytics.³ In the INFORMS Analytics Framework, the Business Problem (Question) Framing and Analytics Problem Framing domains begin the lifecycle but should remain active throughout it. Each subsequent domain provides another opportunity to test whether the analysis still supports the decision at hand.

Maintaining Decision Traceability 

One practical way to activate this iterative approach is to maintain decision traceability – a clear connection between analytical choices and the business decision at hand. Decision traceability carries the concerns established in problem framing into the later domains. This reflects a core principle of applied analytics: analytics creates value when it improves the target decision.⁴

Teams can maintain decision traceability by using each INFORMS Analytics Framework domain as a checkpoint:

• Business Problem (Question) Framing: Is the problem consequential and actionable? Does it have a clear decision owner?
• Analytics Problem Framing: Does the formulation reflect the objective, assumptions, constraints, and tradeoffs?
• Data: Does the evidence support the required precision, granularity, and scope?
• Methodology (Approach) Framing: Is the method appropriate for the decision window, required level of certainty, and practical constraints?
• Analytics/Model Development: Are the outputs interpretable and usable by the decision-maker?
• Deployment: Is the solution embedded in real decision processes?
• Analytics Solution Life Cycle Management: Does the solution still support the same decision and continue to create value?

When later domains expose new limitations, teams can return to the first two. For example, data gaps may require narrowing the question, while modeling tradeoffs may require revisiting the objective or role of judgment. Decision traceability is the practical discipline for using the framework iteratively and preserving alignment between an evolving analytical solution and its target decision.

What Decision Traceability Looks Like in Practice

Let’s return to the marketing example. The original request was to identify which channels generated the highest return on advertising spend. However, as the team moves through the IAF, each domain reveals new information about the decision.

In the Data domain, the team finds that historical attribution data cannot consistently distinguish the customers influenced by advertising from organic conversions. During methodology selection, the team determines that a single ranking of historical channel performance cannot capture how marginal returns change as spending increases. Before deployment, business leaders identify contractual commitments, capacity limits, and brand objectives that the solution must also reflect.

Decision traceability helps the team incorporate these inputs by revisiting the first two domains:

• Business Problem (Question) Framing: The team confirms with business leaders that the target decision is how to allocate a fixed quarterly budget – not merely rank historical channel performance. It also documents the strategic brand priorities and contractual commitments that must be considered in the analysis.
• Analytics Problem Framing: Accordingly, the team reformulates the analytics question as: “How should we allocate our available budget next quarter across channels to maximize expected incremental value, while respecting spending commitments, channel capacity, and strategic brand priorities?”

Based on this updated problem framing, the team refines its analytical approach. It supplements historical attribution with projections on channel performance elasticity at different spending levels. It also incorporates contractual commitments, capacity limits, and strategic priorities as explicit constraints. Instead of producing a simple ranking of channels, the analysis now compares feasible budget allocations and shows the expected tradeoffs across scenarios.

Using the IAF, the team revisits problem framing as new information emerges and keeps the analysis tied to the target decision.

Implications for Analytics Professionals

For analytics professionals, decision traceability should become a core design consideration. While technical accuracy remains critical, effective analytics also requires practitioners to become active stewards of the analytics problem statement: clarifying the target decision, aligning stakeholders, and reassessing whether the solution remains relevant and creates value.

The IAF clarifies this broader scope by treating analytics as an end-to-end lifecycle rather than a purely technical exercise. It equips practitioners with a structure to translate business needs into analytical questions, connect technical choices to organizational priorities, and proactively steer analytics projects through change and ambiguity.

Problem framing should not end when data collection or model development begins. Analytics teams must adopt a dynamic mindset to own the analytics problem statement as new insights and learnings emerge. The IAF serves as an effective guide for teams to achieve this across the full life cycle. Teams that prioritize decision traceability will be better equipped to adapt to change and ensure that analytical precision translates into better business decisions.

References

1. INFORMS, “INFORMS Analytics Framework,” https://www.informs.org/Professional-Development/Professional-Development-Classes/INFORMS-Analytics-Framework.
2. Lustig, I., Bos-Beijer, J., 2025, “The INFORMS Analytics Framework: A Road Map for Success with Analytics,” OR/MS Today, https://doi.org/10.1287/orms.2025.04.07.
3. Rosenhead, J., 1996, “What’s the Problem? An Introduction to Problem Structuring Methods,” Interfaces, Vol. 26, No. 6, pp. 117–131, https://doi.org/10.1287/inte.26.6.117.
4. Howard, R. A., 1988, “Decision Analysis: Practice and Promise,” Management Science, Vol. 34, No. 6, pp. 679–695. https://doi.org/10.1287/mnsc.34.6.679.