In many of the data and analytics engagements I’ve been part of, a familiar pattern shows up early and quietly shapes everything that follows.

The conversations are led by IT.

Not supported by IT. Not enabled by IT. Led by IT.

At first glance, this seems efficient. After all, IT teams understand the systems, the data structures, the pipelines and the constraints. They can articulate what’s feasible. What’s available. What can be built.

But beneath this efficiency lies a deeper structural issue. One that rarely gets acknowledged.

The people closest to the systems are speaking on behalf of the people closest to the decisions.

And that changes everything.

The Proxy Problem

When IT becomes the primary interface in a data project, they unintentionally step into the role of a proxy for the business.

Business problems are no longer expressed directly. They are translated.

And in that translation, something critical is lost.

A business leader might be thinking:

• Why is our margin declining in certain segments?
• Which customers are becoming unprofitable over time?
• Where should we intervene to improve outcomes?

But what reaches the data team often sounds like:

• We need a margin report
• We need customer-level data
• We need a dashboard with filters

These are not the same problems.

They are system-compatible versions of decision problems.

And once the problem is reframed this way, the trajectory of the entire project shifts from decision-making to data retrieval.

If IT frames the question, business lives with the consequence

The Loss in Translation

Every data project starts with a question. But the nature of that question determines the value of everything that follows.

When the business is directly involved, the questions are ambiguous, contextual and decision-oriented. They are uncomfortable, but meaningful.

When filtered through IT, those questions become structured, sanitized and system-aligned.

It’s not a flaw. It’s a natural outcome of perspective.

IT teams are trained to think in terms of:

• Data availability
• System constraints
• Integration feasibility
• Performance optimization

Business teams, on the other hand, operate in:

• Uncertainty
• Trade-offs
• Market dynamics
• Strategic intent

When one speaks for the other, the complexity of decision-making gets compressed into the simplicity of data fields.

And that is where most data projects quietly lose their edge.

Data projects loosing the context

Why Organizations Allow This

This dynamic doesn’t happen by accident. It persists because it is convenient for everyone involved.

For business teams, engaging deeply in data discussions requires time, clarity and ownership. It forces them to articulate decisions, define success and confront ambiguity. Delegating this to IT feels efficient.

For IT teams, working with structured requirements is more manageable than navigating evolving business questions. It reduces uncertainty and keeps projects within defined boundaries.

For leadership, dashboards provide a sense of visibility without demanding immediate accountability. They create the perception of control.

So the system stabilizes around a comfortable equilibrium:

1. IT defines
2. Data teams build
3. Business reviews

But no one truly owns the decision.

The Dashboard Outcome

This is why so many data projects converge toward the same output: dashboards.

Dashboards are safe.

They present information without forcing action. They create alignment without demanding commitment. They answer “what is happening” without addressing “what should we do.”

When IT leads the conversation, dashboards become the default outcome. Not because they are always needed, but because they are the most neutral deliverable.

But neutrality is not value.

A dashboard is only useful if it sits within a decision-making context. Without that, it becomes a reporting layer which is polished, interactive and ultimately underutilized.

In many organizations, the problem is not that dashboards are poorly designed. It’s that they are the product of conversations that never reached the decision layer.

The vicious Visibility Loop

The Hidden Cost

The impact of this misalignment is subtle but significant.

It rarely shows up as outright project failure. Instead, it manifests as:

• Slower decision cycles
• Superficial insights
• Repeated reviews without resolution
• A growing gap between data availability and business impact

Perhaps the most dangerous outcome is false confidence.

Organizations begin to believe they have visibility because they have dashboards. They assume they are data-driven because they have reports. But when decisions remain unchanged, the illusion becomes clear.

This is not a data problem. It is a decision velocity problem.

Same Data, Different Outcomes

Consider two scenarios.

In the first, the engagement is driven through IT.

The requirement is to build a sales performance dashboard. The output shows region-wise trends, product-level breakdowns and time-based comparisons. Review meetings are scheduled. Numbers are discussed. Variances are explained.

In the second, the conversation starts with the business.

The question is: “Where are we losing profitable customers, and why?”

The analysis leads to identifying patterns of customer attrition, linking them to pricing, service levels and engagement gaps. The output is not just a view. It is a set of targeted interventions.

Both scenarios use the same underlying data.

But only one changes outcomes.

The difference is not technical capability. It is who defined the problem.

Two different perspectives

Reframing the Role of IT

This is not an argument against IT involvement. In fact, strong IT capabilities are essential for any meaningful data initiative.

But the role needs to be clearly understood.

IT should:

• Enable access to reliable, well-structured data
• Ensure scalability, security and governance
• Support the technical execution of analytical solutions

What IT should not do is define the business problem.

That responsibility lies with those who are accountable for decisions and outcomes.

When IT begins to shape the problem itself, the focus shifts from “what should change” to “what can be built.”

And those are fundamentally different directions.

Organizational ownership gap

Moving to a Decision-Centric Model

If organizations want their data efforts to drive real impact, the starting point needs to change.

Not tools. Not dashboards. Not data pipelines.

The starting point is the decision.

A more effective approach looks like this:

1. Begin by identifying the decision that needs to improve
2. Clarify who owns that decision
3. Understand the variables that influence it
4. Map the data required to support those variables
5. Design outputs that guide action, not just observation

This approach is harder. It requires deeper engagement from business stakeholders. It introduces ambiguity early in the process.

But it aligns the entire effort around outcomes, not outputs.

Structured framework for effective data intiatives

A Simple Diagnostic

If you want to assess whether your data projects are falling into this pattern, a few questions can help:

• Who defined the problem—business or IT?
• Can we clearly state the decision this analysis supports?
• Are we producing insights, or just visibility?
• Who will act differently because of this output?

If these questions don’t have clear answers, the issue is not technical.

It is structural.

When the wrong people define the problem, the right data won’t save you

Closing Thought

Most organizations invest heavily in data infrastructure, tools and reporting capabilities. But far fewer invest in clarifying how decisions are made, who owns them and how data feeds into that process.

As a result, conversations default to those who understand systems best, not those who understand decisions best.

And that is where the disconnect begins.

If your data conversations are led by the people closest to systems instead of the people closest to decisions, don’t expect transformation. Expect reporting.