'We want a data dashboard' — and the room usually starts discussing color schemes, maps, and whether to go 3D. We usually interject: first, tell us where the data comes from.
Three questions, then we talk visuals.
One: where does the data come from? Already in a system, or does it have to be gathered from elsewhere?
Two: how often does it update? Real-time, daily, or monthly?
Three: who owns the numbers? When two figures disagree, who makes the call?
One conversation stalled right at question two. The client said data comes in monthly from four departments, each sending an Excel in a different format; consolidating, checking, and aligning definitions takes five days on a good run. Which means even if the dashboard got built, it would be empty five days a month and show last month's data for the rest.
So what exactly would we be dashboarding?
In the end we delivered two things: a script that auto-consolidates — four Excel files dropped into a fixed directory, one run produces a wide table with conflicts listed for human review — and a one-page definitions document stating how each metric is computed. Numbers are ready by Friday afternoon, three days faster than before.
The client later wired that wide table into Power BI themselves, made a few charts, and put them on the office TV. They don't call it a dashboard; they call it 'the Friday sheet.'
We're not against dashboards. We've seen a project where the screen looked great, but the central number hung there as a hand-entered constant because the upstream API never delivered. It hung for six months.
Check the rice before picking the pot. It's a folksy way to put it, but it beats a set of mockups.
