7 Signs You Have a Resolution Problem, Not a Data Problem

The question sounds simple: What is our qualified pipeline for the quarter? Sales has a number. Finance has another. RevOps opens the CRM, an analyst checks the warehouse, and the meeting turns into a discussion about filters. Forty minutes later, the business decision is still waiting.

Most leaders call this a data problem. That diagnosis feels reasonable because the disagreement appears in a chart. It is often wrong. The data may already exist, be current, and be accessible. What is missing is a reliable path from evidence to an answer the room accepts.

I have seen this pattern from inside operations, supply chain, planning, and analytics organisations. The technology changed. The pattern did not. Teams kept buying faster ways to retrieve data while leaving definition, authority, interpretation, and closure unresolved. The stack was rarely the constraint. The resolution path was.

Why do teams have data but still cannot make decisions?

Teams can have abundant data and still fail to decide because access does not create agreement. The delay usually sits in competing metric definitions, unclear source authority, hidden manual context, unresolved ownership, and no explicit point of closure. When the answer exists but nobody will defend or act on it, the problem is resolution.

That distinction matters because the remedies are different. A genuine data problem needs capture, quality, lineage, or modelling work. A resolution problem needs an operating agreement: what the question means, which evidence is admissible, who owns the definition, who may resolve disagreement, and where the answer becomes closed.

The time consumed across that path is decision latency. It starts when a consequential question is asked and ends when a trusted answer is acted on. Query runtime is one small part of it. Interpretation queues, reconciliation, approval, and meeting cadence usually consume more.

Data problem or resolution problem: three tests

Before approving another dashboard, warehouse project, or AI pilot, test the question in three stages. The first asks whether the evidence exists. The second asks whether the organisation agrees on how to turn that evidence into a number. The third asks whether someone can close the question and act.

1. The existence test

Can the required event, entity, or amount be observed at the necessary grain and freshness? If shipments are never scanned at dispatch, you cannot calculate real dispatch delay. If churn reasons are not captured, no semantic model can recover them. That is a data problem.

2. The agreement test

Can two competent people apply the same definition to the same evidence and reach the same answer? If one team includes partner pipeline and another excludes it, the records may be flawless while the metric remains contested. That is a resolution problem.

3. The closure test

Is there a named person who can accept the answer, explain its limits, and decide what happens next? A number can be technically correct and still remain operationally useless because nobody has the authority to close the argument. That is also a resolution problem.

Many enterprise questions pass the existence test and fail the next two. The seven signs below make that failure visible.

Seven signs the constraint is resolution, not data

1. A simple question launches a cross-functional investigation

A leader asks for one number and a temporary project team appears. An analyst translates the request, a business operator explains an exception, finance checks the close, and someone searches an old Slack thread for the definition used last quarter. None of this is analysis yet. It is organisational archaeology.

The tell is not that the question is complex. The tell is that a recurring question still requires rediscovery. If the same pipeline, margin, service-level, or inventory question repeatedly needs a fresh expedition, the organisation has never turned its answer into an operating asset.

2. Two teams produce different numbers, and both can defend them

A bad extract is easy to fix. Two defensible answers are harder. Sales may count opportunities according to selling motion while finance counts them according to recognition policy. Operations may define an on-time order at dispatch while customer success defines it at receipt. Each number is internally coherent. The enterprise has not decided which meaning governs which decision.

This is why conflicting metrics between teams are not primarily a dashboard defect. The dashboards expose an unsigned contract. Fixing the visual does not decide the owner, source, scope, exclusions, or change process. Those clauses have to be made explicit.

3. The same answer is rebuilt every week or month

Watch what happens before a recurring leadership meeting. If an analyst copies last month’s workbook, replaces extracts, repairs formulas, messages three people for adjustments, and rebuilds the commentary, the organisation is not producing an answer. It is staging a performance.

Repetition without reuse creates two risks. First, the logic drifts quietly. Second, the people who understand the repairs become part of the system without appearing in its architecture. A recurring question should have a durable definition, source path, owner, and close condition. The commentary can change. The route to the answer should not.

4. Data arrives quickly, but trust arrives late

A dashboard can refresh in minutes while the decision takes eleven days. That is not a contradiction. Freshness measures when records became available. Decision latency measures when a person with authority was willing to use the answer.

In one pipeline workflow I observed, the question took eleven days to reach an accepted answer even though the underlying systems were available throughout. Once the competing definitions and ownership path were resolved, the same class of question closed in four hours. No database became roughly sixty times faster. The waiting moved out of the human path.

If your operational metrics celebrate refresh speed while executives still ask, “Can I trust this?”, you are measuring the supply of data and ignoring the acceptance of answers.

5. One person carries the context required to make the number usable

Every organisation has people who know which account to exclude, which late file to wait for, why the regional target changed, and which apparent anomaly is normal. Their judgment is valuable. The problem begins when that judgment is undocumented and unavoidable.

This person becomes a human API. Questions queue behind their calendar, holidays pause the process, and new analysts repeat old mistakes. Leaders may describe the dependency as expertise. Operationally, it is an unmodelled resolution step.

The answer is not to remove human interpretation. It is to separate judgment that belongs in the current decision from recurring rules that belong in the contract. Humans should interpret exceptions, not repeatedly reconstruct the definition.

6. Everyone contributes, but nobody can close the question

Resolution often fails through distributed participation without explicit authority. Data engineering owns the pipeline. Analytics owns the model. Finance owns the report. Sales owns the target. The executive owns the meeting. Each can comment, but no one has been named to decide when the answer is sufficient.

The result is a long approval loop disguised as collaboration. Every additional reviewer can reopen scope, request another cut, or introduce a new source. Because closure has no owner, the safe choice is to keep analysing.

A useful ownership rule is simple: the metric belongs to the person who must defend its use in the decision, not to the team that stores or visualises it. Technical teams can own reliability. They should not be forced to settle business meaning by default.

7. The answer arrives after the decision window

An answer can be correct and still be worthless. A staffing recommendation delivered after schedules are published, a risk signal delivered after inventory is committed, or a forecast delivered after the board pack is frozen cannot change the decision it was meant to support.

Late answers create two quiet behaviours. Leaders decide on instinct, then use the analysis as retrospective justification. Or the question disappears, only to return next cycle with the same unresolved definitions. Both create answer debt: a backlog of important questions the organisation never properly closed.

I saw a planning cycle move from eighteen days to six after the organisation established one close number, one owner, and one window in which the number could change. The gain did not come from a larger planning model. It came from stopping the renegotiation of the past before discussing the future.

Why another dashboard usually makes the problem worse

When trust is low, the instinct is to create a better view. The new dashboard may be clearer, faster, and more complete. It also becomes another place the number can come from. Unless the underlying definition and ownership are settled, the organisation has added a new claimant rather than a source of truth.

This is the central risk of self-service analytics. Access increases faster than agreement. Each team can build a valid-looking answer from its local assumptions, so the cost of finding the enterprise answer rises. More dashboards can generate more analytical entropy even when every dashboard works as designed.

Natural-language interfaces and analytics agents intensify the same dynamic. They reduce the effort required to produce an answer, but they do not decide which definition has authority. Put an agent on contested semantics and it can produce the wrong organisational answer with excellent syntax and impressive speed.

A practical diagnostic: follow five real questions

Do not assess this through a maturity survey. Choose five consequential questions that leaders asked recently and reconstruct what actually happened. Use questions from different functions if possible, but keep them concrete: “What is at-risk revenue this quarter?” is useful; “How data-driven are we?” is not.

• Record when the question was first asked and when an answer was acted on.
• List every source, definition, handoff, approval, and meeting the question crossed.
• Mark where people waited, disagreed, rebuilt work, or reopened the answer.
• Name the person who had authority to close the question. If nobody did, record that explicitly.
• Classify each delay as foundation, semantic contract, resolution workflow, or human interpretation.

This is the compact version of a decision latency audit. It produces evidence you can act on: not a generic score, but a map of where the organisation turns a question into a queue.

Then establish one outcome measure and a small set of diagnostics. The outcome is end-to-end time from question to acted-on answer. Useful diagnostics include time to first response, clarification time, reconciliation time, approval wait, reopen rate, and decision-window miss rate. Do not collapse them into one average that hides the bottleneck.

Fix the first broken layer, not the most visible symptom

The resolution path has four layers. The governed foundation supplies owned, quality-controlled evidence. The semantic contract states what the metric means and who owns that meaning. The resolution workflow takes a question to a sourced answer in the place work happens. Human interpretation frames the choice and accepts accountability.

Repair them in that order, but only where the audit shows a failure. If source records are missing, fix capture. If sources exist but definitions conflict, write the metric contract. If the contract exists but requests disappear into tickets and meetings, redesign the answer path. If the answer arrives but nobody acts, clarify decision rights and closure.

A focused thirty-day repair can be modest. Pick one recurring executive question. Write its definition and exclusions. Name its business owner and permitted source. Set the response and closure points. Deliver the answer in the meeting or channel where the decision occurs. Measure the old and new cycle. One repaired path teaches more than a company-wide data transformation slide.

When it really is a data problem

The resolution framing should not become a reflex. Sometimes the evidence is absent, corrupt, too coarse, or too late for the decision. A retailer cannot resolve store-level stockouts from monthly regional totals. A service team cannot explain cancellations if reasons were never captured. A finance team cannot reconcile entities whose identifiers do not join.

In those cases, operational agreements alone will not help. Improve capture, identity, lineage, quality, or freshness first. The useful discipline is to identify the earliest failed test. Do not buy a resolution tool for missing evidence, and do not rebuild the warehouse because two leaders have never agreed what “qualified” means.

The question to ask before funding the next data initiative

Ask: “What decision will become faster, more trusted, or more likely to close?” Then name the current delay. If the answer is missing records or unreliable pipelines, fund the data work. If the answer is conflicting definitions, waiting for context, ownerless approval, or a missed decision window, treat it as resolution work.

Enterprises rarely suffer from a simple shortage of data. They suffer from an excess of possible answers and no designed path for choosing one. The organisations that move faster do not eliminate debate. They make the terms of debate explicit, assign authority, preserve context, and know when the question is closed.