Don't Stick a Plaster Over Poor User Data: Why Transparent Reporting Matters
- Jim Walker
- 1 day ago
- 5 min read
In the world of Business Intelligence (BI), it can be tempting to tidy up, or hide bad data so that it "looks right". When you're building dashboards or reports that will be seen by leadership teams or operational managers, you might feel the pressure to make things neat, consistent, and complete - it massively reduces trust if they're not. But here's the truth: sticking a plaster over poor user data doesn't fix the wound underneath. If you're reporting on unreliable or incomplete information, your job isn't to hide that reality—it's to reveal it. This post is aimed at systems managers, insight professionals, and BI developers, and it comes with a simple but vital message: don't clean up someone else's mess. Your role is not to correct, but to reflect.
We see the impact when reports are built to mask data quality issues. From gas compliance records to asbestos checks, from rent arrears to damp and mould reporting—when the data's wrong, hiding it can lead to reputational, financial, and legal risk, worse - health and safety!. It breaks trust in the reporting process and leads to a culture where issues are managed in the reports instead of being addressed at the source.
You're Not BAU
One of the most important distinctions a BI or Insight Manager needs to hold onto is the line between reporting and Business As Usual (BAU) operations. If you're reporting on the number of completed gas safety checks, and you notice that dozens of records are missing a completion date or have been duplicated, your job isn't to fix it. It's to report it, clearly and honestly.
By manipulating or filtering out poor-quality records, you may be giving the impression that everything is fine, when in fact there may be serious operational or safety issues.
Let's take gas compliance as an example. Imagine you produce a dashboard that shows 100% compliance, but in order to achieve that figure, you've excluded records where the check date is blank or the status is unclear. On the surface, the report looks good. But underneath, there's a risk that properties have been missed. The compliance manager doesn't realise there's a gap, and the business continues under the illusion of safety. In the event of an audit or an incident, it won't be the dashboard that gets scrutinised—it will be the actions (or inactions) of the organisation.
Examples with Consequences
Asbestos Records: We worked with a client who discovered that hundreds of properties were marked as "no asbestos information available". A junior developer had decided to label these properties as "no asbestos" in the report to make it easier to visualise. The issue went unnoticed for months until a property was due for refurbishment and no proper asbestos survey had been carried out. A contractor was put at risk.
Damp and Mould: It's easy to exclude records with vague classifications like "other" or "pending" when you're trying to produce clean visuals. But by doing so, you're obscuring the real scale of the issue. If 30% of damp and mould reports fall into an unclassified category, that tells you something important: the process for logging these cases is broken. That, in turn, should trigger action from service managers. But only if the data is shown transparently.
Gas Compliance: In one housing association, properties marked as "exempt" from gas servicing were not being reviewed regularly. In the BI reports, these were hidden under a custom status field. They weren't counted in the denominator, and the report showed 100% compliance. When a resident complaint led to a review, it was discovered that dozens of properties had been exempt for over three years—a policy failure disguised by a report built to please.
What Goes Wrong When You Change the Data
Accountability Is Misplaced – You take responsibility for data that isn't yours. If something is incorrect, your change makes you accountable for the outcome.
Operational Failures Go Unnoticed – If your report shows no gaps, managers will assume everything is fine. They won't chase their teams or correct broken processes.
The Data Never Gets Better – One of the most powerful forces for improving data quality is transparency. When people see their mistakes in reports, they get fixed. If you cover them up, you're removing the incentive to improve.
Risk Exposure – Regulatory compliance often relies on accurate reporting. If you hide issues, you may be introducing legal or audit risks.
Trust Breaks Down – Eventually, someone will discover the inconsistencies. When they do, it reflects badly on the whole reporting process and on you as a professional.
So What Should You Do?
Flag Issues Clearly: Use visuals, alerts, and colour coding to highlight missing or invalid data.
Segment Data Quality: Show separate counts for records with complete vs incomplete data. For example, "85% of assets have a valid asbestos record".
Raise It Up the Chain: Work with your BAU colleagues to raise the issue through the correct governance channels. Create a paper trail.
Push for Ownership: Every data point in your report should have an owner. Whether it's Repairs, Compliance, or Customer Services, make it clear where action needs to happen.
Use Comments, Not Code Fixes: If you're using Power Query or DAX to filter out bad data, document that in a comment. Better yet, avoid it altogether unless the business has signed off on the rule.
Data Cleansing vs Reporting
In almost every project I work on, someone will say how the data quality is poor in a given area or areas. This always surprises me. Tenants are in properties, repairs are getting done, people are being charged, payments are coming in. Is it really that bad? In some cases, no, definitely not. If you are missing a 'primary' phone number for a former tenant is it really the end of the world and will there be any follow on consequences, financial or reputational....I suspect not. In other cases, there will very likely be problems, financial, reputational, or worse - health and safety. That therefore dictates there is a priority against these things.
Reporting is such a powerful tool for data quality but you need to be clear of your intended audience and purpose of a report in doing this. For example, if you are wanting to report on your Tenant Satisfaction Measures for Complaints...then you should create a report that gives you the total numbers, nicely presented, and with sufficient drill down for users to 'self-validate' the report. If you are not happy that all complaints have a stage 1 or 2 where it should be, that's a separate report with detail that needs to go to a business lead for rectification.
By all means (and I recommend this), include on your TSM report a card for 'There are 95 known quality errors with the data in this report'. This is so easily done, and I guarantee that you will get some traction to fix the problem if senior leaders are presented with not only their stats, but also a metric of the known problems (and therefore 'confidence factor' they can place in that report.
In parallel with reporting for operational, management, legislative and regulatory purposes, you need a pro-active data quality monitoring solution. We've implemented solutions to do this, get in touch if you need any help.
Final Thought
We believe that Business Intelligence isn't just about visualising performance—it's about raising the bar (or dragging up in some cases) for how the business understands itself. That means telling the truth, even when it's messy. Reporting on poor data doesn't make you a bad analyst. It makes you a responsible one. If the data is messy in the source, you 100% report on that fact.
Because when your reports reflect reality, not a fantasy version of it, you help the organisation grow stronger, safer, and smarter.
So next time you're tempted to tidy something up in Power BI "just to make it look better", stop and think. Are you fixing a problem, or hiding it?
Let the data speak. Even if it doesn't say what someone wants to hear.
תגובות