The Client Asked for Real-Time Data. Nobody Asked What Decision Needs It.

In fifteen years of BI work, the phrase I have seen accepted most easily is "real-time data." It enters the brief in the first meeting. Nobody writes down the decision it serves.

This is rarely carelessness. The phrase sounds modern and responsible, and questioning it feels like arguing against progress. So it moves from the meeting into the specification, and from the specification into the model.

If you build Power BI reports, you know what comes next. Real time usually means DirectQuery, and DirectQuery changes how the whole report behaves. Microsoft's own guidance tells you to start with import, and to move beyond it only when a specific constraint demands it.

The trade is concrete. Every visual sends at least one query to the source when the page opens. Every slicer click sends them again.

Report speed now depends on the source system and the network. Microsoft warns that usability degrades once a visual takes more than 30 seconds.

You accept all of that so the numbers stay fresh. Then you look at the source. If the ERP extract loads overnight, DirectQuery shows you last night's data, only more slowly.

Scheduled refresh goes further than most briefs assume. Import models on Pro schedule up to 8 refreshes a day. Premium and PPU go up to 48, about one every 30 minutes.

Here is what the brief misses. "Real time" describes how fresh a number is. It says nothing about who acts on that number, or how soon.

A decision has a rhythm. A shift supervisor facing a stopped line acts within minutes. A finance director reviewing margin acts at the monthly close.

Data needs to arrive a little ahead of the decision it serves, and anything fresher is capacity the organisation funds and nobody uses.

Some decisions do need it. When a stopped line or a safety reading demands action now, build for that, on those tables. Keep the rest of the model in import.

The sponsor who asked is not wrong either. A product walkthrough shows numbers moving on screen, and that looks like control.

The wish underneath is sound: nobody wants to learn about a shortfall too late. That wish is the objective worth writing down.

We have all built something because the brief said so. Most requirement processes record what people ask for, and few have a step that asks what each request is for. So the line survives the meeting where everyone nods, then the build specification, and the developer who questions it in week six looks difficult.

That is a gap in the process, and the people in the room did not create it.

Eugene Meidinger wrote in March 2026 that a great consultant is worth it for "all of the solutions they didn't provide or recommend." I read that as a job description. Talking someone out of a requirement they do not need is work, and it is some of the most useful work in a BI project.

So when a brief says real time, put one question to whoever wrote it: what do you do differently when this number changes? Then ask how often they make that decision, and check how often the source updates. If the decision is weekly and the source loads nightly, a daily import serves it.

If you fund BI projects, ask for one thing in the specification. Every requirement carries the decision it serves, beside it, in plain words. A requirement with no decision beside it goes back for a conversation before anyone builds it.

Every real-time request that goes unchallenged takes performance, complexity and infrastructure investment for a capability the organisation uses once a week. The question is whether any decision in the business requires data fresher than the refresh cycle you already have. One structured session surfaces every requirement in your current brief that was accepted without evidence. The ones that survive that session are worth building. The rest are draining you before the first row loads. → Challenge the brief before you build