Every reporting platform we've been asked to rescue failed the same way. Not at launch — at launch it was fine. It failed three months later, when a source system changed a column, and the report kept producing numbers. They were just wrong, and nobody knew.
The demo is not the hard part
Building a report against a fixed dataset is straightforward. The hard part is the second year: new sources, renamed fields, a definition someone changed in a meeting you weren't in. The schema will change. Designing as though it won't is the single most common mistake we see.
We build for the day the schema changes, not the demo.
Make the change loud
Our answer is unglamorous. A semantic model sits between the raw data and every report — one agreed definition of each metric, in version control. Around it are tests that check the model against the source on every refresh. When a source changes, a test fails. The report doesn't drift; it stops, visibly, and tells you why.
A failed test on a Tuesday morning is a good outcome. It is far better than a number that has been quietly wrong since the spring and informed two quarters of decisions.
Governance that actually happens
Governance that needs a committee tends not to happen. So we keep it light: definitions in version control, changes reviewed like code, drift caught by tests. It isn't a programme. It's a habit, and habits survive staff turnover in a way that programmes don't.