The problem wasn't the tool or the team that built it. The problem was the sequence in which the project was run. The team chose the technology stack first, configured it second, and then decided what to measure third. By the time the dashboard was complete, it was measuring things the business had stopped caring about six months earlier, and missing the one question the CFO asked every Monday morning.
This sequence failure is the single most common cause of reporting projects that deliver technically and fail practically.
The correct sequence
The sequence that produces reporting the business actually uses starts from the opposite end.
Start with the decision. What is the one thing the CFO needs to know to make a decision on Monday morning? Not everything she might want to know — the specific, named decision that her reporting needs to support. Get that question written down and agreed before any technology discussion happens.
Work backward from that decision to the metric that drives it. What number, if it changed, would change the decision? That is the metric the dashboard needs to surface. Everything else is secondary.
Work backward from the metric to the data source that has it. Where does that number live? In what system, at what granularity, updated at what frequency? Now you have a defined data requirement.
Work backward from the data source to the infrastructure that keeps it clean. What cleaning, normalisation, and governance does that source need to be reliable? Now you have a scoped technical project.
Why teams get the sequence wrong
The technology-first sequence is not irrational. Tools have to be evaluated and procured, and procurement has lead times. Starting with the tool feels like progress. It produces visible outputs — a configured system, a populated dashboard, something to show in a steering committee meeting.
The decision-first sequence produces outputs that are less visible in the early stages. Two-hour workshops. A one-page document defining the five questions the reporting needs to answer. A metric hierarchy that maps decisions to data sources. These don't look like progress until the dashboard built on top of them gets used.
The irony is that the decision-first sequence is usually faster overall. The scoping is tighter. The technical work is more focused. The output is smaller, simpler, and actually gets used. The three-month project becomes a six-week project, and nobody needs to rebuild it the following quarter.
What good data infrastructure actually delivers
Feature: a data infrastructure built around a defined set of business decisions — not a defined set of tools.
Advantage: every metric on every dashboard has a named decision it supports and a named owner responsible for the underlying data. When the number is wrong, there is one person to call. When the decision changes, there is one metric to update.
Benefit: the finance team closes the monthly reporting cycle in two days instead of ten, and the CFO trusts the number when she sees it. Not because the technology is better — but because the question was answered before the tool was chosen.
The single most useful question before any reporting project
Before discussing platforms, vendors, connectors, or dashboards, ask this: what is the one business decision this reporting needs to support, and who is accountable for making it?
If there isn't a clear answer, the project isn't ready to start. No technology investment will make it succeed.