Lt. Col. Timothy Tendall, 48th Fighter Wing chief of flight safety, leads a discussion between three business leaders and U.S. Air Force officers during a leadership panel at Royal Air Force Lakenheath, England, in the Strike Eagle Complex auditorium March 1. The event’s topics included how the pane. Business intelligence mistakes: most happen around the team, not in it
Photo by U.S. Air Force photo by Senior Airman Malcolm Mayfield on Wikimedia Commons, Public domain

Guides

Part of 8 things about business intelligence worth your time

Business intelligence mistakes: most happen around the team, not in it

Business intelligence mistakes made around a data team rather than by it: truth programs, metrics tied to pay, and re-platforming instead of deciding.

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.

Truth program vs one number at a time

Multi-quarter program

Time to value
A year or more
Output
Catalog
Same numbers still disagree
Yes
Requires giving up a version
Never asked
Scale
One big program

One number at a time

Time to value
Immediate
Output
Agreement
Same numbers still disagree
No
Requires giving up a version
Explicit decision
Scale
Ten small fixes

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.

Stress test a metric before pay

  1. Pick candidate metric
  2. Run unattached for a few review cycles
  3. Watch how people behave around it
  4. Name the guardrail measure
  5. Only then attach to pay

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.

Re-platform vs settle definitions first

Re-platform now

Visibility
High
Budgetable
Yes
Ambiguity carried over
Intact
Rebuild time
A year
Two systems disagree
Yes
Credibility
Less

Settle definitions first

Visibility
Low
Budgetable
No
Ambiguity carried over
Resolved
Rebuild time
None
Two systems disagree
No
Credibility
Intact

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.

Set refresh from decision cadence

Does the decision happen in minutes?

Yes

send an alert, not a faster dashboard

No

set refresh to the decision cadence and show last updated time

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.

One calculation vs separate leadership number

Separate leadership number

Instruments
Different
Adjustments
Baked in
Divergence found
Worst moment
Board vs teams
Different numbers

One calculation

Instruments
Same
Adjustments
Visible lines
Divergence found
Before it matters
Board vs teams
Same number

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.

Raw tables vs modeled data access

Access to raw tables

Cost to approve
Nothing
Answers produced
Private, inconsistent
Exclusions known
No
Data team time
Adjudicating
Self service
Unfunded mandate

Access to modeled data

Cost to approve
Some curation
Answers produced
Shared, documented
Exclusions known
Yes
Data team time
Building
Self service
Genuine

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.

More in Guides

Latest from Policy Desk