Why your BI project stalled at the data model

Most abandoned BI projects did not fail at the dashboard. They failed months earlier, in a series of meetings about what counts as a customer.

The pattern is consistent. The tool gets chosen quickly — everyone enjoys choosing tools. Then the work turns out to be modelling, and modelling turns out to be a negotiation between departments who have each been quietly using a different definition for years. Sales counts a customer at signature. Finance counts at first invoice. Support counts at onboarding. None of them are wrong, and the project is now a diplomatic exercise with a software budget attached.

The definitions were doing a job

It is tempting to treat the disagreement as sloppiness. It usually is not. Each definition was fit for the decision the department using it had to make, and each is defensible in isolation. What nobody ever needed was for them to agree, because nobody ever put them in the same table.

So the modelling phase is where a company discovers it has three businesses' worth of definitions and one budget for reconciling them. That is a genuinely hard organisational problem, and no tool solves it.

What a tool can change

What a tool can change is when the disagreement surfaces, how expensive it is to hold, and whether resolving it requires an engineer.

The conventional order is: model everything, then build. You pay the full cost of the negotiation before producing anything anyone can look at, which is exactly backwards for a disagreement that is easier to settle with a chart in front of you.

We built Dashful around the opposite order. Upload the files you already have. The agent profiles them and proposes a dataset — including, explicitly, the assumptions it had to make. Those assumptions are where the ambiguity lives, and putting them in front of a person is the point: you are looking at a concrete claim about your data rather than an abstract question about definitions.

Approve it and you have something to argue with by lunchtime. When someone in finance says the number is wrong, the conversation is about a specific stated assumption, not about first principles.

Keep the disagreements as separate datasets

The other thing that helps is not forcing a merge that the business has not actually made.

Facts at different grains stay separate datasets in Dashful — receipts, invoices, shrink. What connects them is declared, not assumed: you say that receipts.store_code is the same key as edi.store_number, and a link is refused outright if the two columns share no values. Sales can keep its definition and finance can keep its own, joined where they genuinely correspond and left apart where they do not.

That is a smaller promise than a single unified model of the business. It is also one you can deliver in an afternoon, which matters more than it sounds, because the projects that die are the ones that never showed anybody anything.