Business intelligence mistakes that can derail your plans

The mistakes below are not made by data teams. They are made around them, by the executives who fund the work, the managers who consume it, and the committees that decide what counts as official. A capable team can be rendered useless by every one of them.

Each entry describes a move that is reasonable on its face, what it actually costs, and the smaller thing to do instead.

What to take away

• Most damage to an intelligence function is done by its sponsors, not its staff.
• Almost every one of these is a large project standing in for a small decision nobody wants to make.
• The cheap fix is nearly always to settle one contested number rather than to reorganize, re-platform, or re-scope.

1. Commissioning a single source of truth

It sounds like the right ambition and it funds well. In practice it becomes a multi quarter program to inventory everything, which produces a catalog rather than an agreement.

The cost is time. A year in, the same two numbers still disagree in the same meeting, because nobody was ever asked to give up their version. Truth is not a technical property; it is a decision about whose calculation wins.

The fix is to take the single number that causes the most arguments, name an owner, write the definition, and switch everything to it. Then do the next one. Ten of those beats one program.

2. Attaching a metric to pay before it has been stress tested

Once a number affects compensation, it stops being a measurement and becomes a target that intelligent people will move. Campbell's law states the general form: the more an indicator is used to make decisions, the more it will be distorted and the more it will distort what it was measuring.

You will not notice immediately, because the number improves. What degrades is the thing the number was standing in for: a response time falls because tickets get closed and reopened, a pipeline figure rises because opportunities get created earlier.

The fix is to run any candidate metric for at least a few review cycles unattached, watch how people behave around it, and name the guardrail measure that would show it being gamed.

3. Re-platforming to solve a definitions problem

New tooling is visible, budgetable, and satisfying. Definitional disagreement is none of those.

But a migration carries every ambiguity across intact, adds a year of rebuilding, and produces a period during which two systems disagree for reasons nobody can untangle. Teams emerge from it with the same arguments and less credibility.

The fix is to settle the definitions on the system you already have. If the platform is genuinely the constraint, that becomes obvious once the definitions are clean, and the migration is then a small technical project rather than an act of faith.

4. Letting the reporting tool hold the definitions

Every modern reporting tool can define calculations inside itself. It is convenient, so the definition of a core business concept ends up living in a visualization layer.

Two things follow. Anything that does not read through that tool, a notebook, a data science model, an operational system, cannot see the definition and reimplements it. And when the tool is eventually replaced, the definitions are hostages.

The fix is to define governed concepts upstream, in the modeled data, and let every tool read the same one. A shared semantic layer is the usual name for the place those definitions live.

One set of books, kept in one place, with a rule about who may write in it: the idea long predates any of the tooling, and it is still what the first and fourth mistakes are both about.

5. Refreshing faster than anyone decides

Someone asks for real time, nobody wants to say no, and a nightly pipeline becomes an hourly one.

The cost is not only compute. Frequent refresh makes numbers move under readers, which means every conversation starts with reconciling two screenshots taken at different times. It also makes failure louder and more frequent without making anything more actionable.

The fix is to set refresh from the decision cadence, and to write the last updated time on the page so nobody has to guess. If a decision genuinely happens in minutes, the right answer is an alert, not a faster dashboard.

6. Keeping a separate number for leadership

A leadership deck gets its own calculation, usually because someone wanted it adjusted, simplified, or shown net of something.

From then on, the operating teams and the board are steering by different instruments. The divergence is discovered at the worst possible moment, in a room where the cost of being wrong is highest.

The fix is one calculation, with the adjustments shown as visible lines rather than baked in. If leadership needs a different view, give them a different presentation of the same number.

7. Treating access as a substitute for modeling

Granting people access to raw tables feels like enabling self service and costs nothing to approve.

What follows is a set of private, mutually inconsistent answers built by people who did not know about the exclusions, the late arriving rows, or the two tables that look interchangeable and are not. The data team then spends its time adjudicating rather than building.

The fix is to widen access to modeled, documented data and to keep raw tables narrow. Access to something curated is genuine self service; access to everything is an unfunded mandate.

8. Never changing a definition, or changing it silently

Both failures come from the same avoidance. A definition that can never change slowly stops describing the business. A definition that changes without announcement makes every historical comparison quietly wrong.

The fix is a stated rule: definitions can change, changes are announced before they land, the charts are annotated on the date, and someone decides explicitly whether history is restated or the change applies forward only.

9. Measuring the team by throughput

Tickets closed and dashboards delivered are easy to count, so they become the score.

A team measured this way will produce many small artifacts, because that is what the score rewards, and will never take on the work that removes whole categories of request. The queue stays exactly as long as it was.

The fix is to count what stopped: requests that no longer arrive, spreadsheets retired, meetings that now start from the same screen. Those are observable, and they point the team at work that compounds.

Which of these to fix first

Take the two that are currently costing you meetings. In most companies that is the contested number from the first entry and the private leadership figure from the sixth, because both surface publicly and repeatedly. The rest can be sequenced behind them.

Related reading on this site

The economics of the function these mistakes damage are covered in business intelligence. For the guardrail pairing that makes the second mistake survivable, see metric shapes and their traps. For the equivalent errors made while a data function is being set up rather than run, see the setup phase mistakes. Ownership and change control for definitions are the subject of data governance, and the skeptical reading that keeps the third mistake from being funded is in how to read a platform case study.

Common questions

Our leadership genuinely wants a single source of truth. How do we redirect that?

Agree with the goal and change the unit of delivery. Offer to settle three named numbers this quarter, with owners and written definitions. It is the same ambition, sized so it finishes.

Is a metric in a bonus plan always wrong?

No, but it should be one you have watched behave for a while, paired with a guardrail, and reviewed on a schedule. The mistake is speed, not the idea.

We already re-platformed and still have the same arguments. Now what?

Then the platform was not the constraint, which you now know for certain. Start settling definitions, and use the migration as the evidence that tooling was never the issue.

How do we say no to a real time request?

Ask what decision gets made within the hour, and who is on the hook to make it. If there is a real answer, build an alert for that specific case. If there is not, the question answers itself in the requester's own words.