I don’t mind when a client tells me my report is wrong. This was not always how I felt. In over 10 years working in Business Intelligence (BI) and IT I have noticed that a considerable percentage of developers do not take kindly to being told their report/data extract/table is wrong. In some environments I have worked developers have been so defensive that the clients are very reluctant to engage with the developer but rather seek alternative “solutions”. These alternative solutions are usually an external consultant or a competing BI suite.
Before I delve into my reasons for not minding being told my data is wrong, lets get something out the way. This post is not referring to reports that are wrong because you fudged your SQL and ended up having:
- Double counting in your report.
- Used the wrong aggregation.
- Applied the wrong criteria in filtering your data.
This post will not help you. My only suggestion is formatting your SQL in a manner that enables you to test your data as you develop. Note that your report may be technically accurate but still be wrong. This is a much better problem to deal with and is the subject of this post. In this post I use the terms report, data and table interchangeably.
Here are my reasons why I don’t mind my report being wrong.
I get to meet my client
The fact that I get to communicate to the person who uses the report is always a positive. After introducing myself when necessary, this I use opportunity to find out how the report is used within the business. In a typical corporate setting there are good reasons why you may not know who is using a BI report:
- The report was development before your time.
- Original business report owner left the company.
- Merger, acquisition or restructure happened.
- You have over 800 reports and you don’t know if anyone still uses the 350 reports developed 5 years ago.
Now I have a report name and I can put a name to the user.
Report is relevant
All BI environments have too many unused reports. The problem is how to get rid of these reports. I am partial to turning off all reports and only restoring the ones where a user complains. This is not always practical for these reasons:
- Some reports are run once a year and by the time you find out the report is needed it may be too much trouble to restore it.
- You may not have the resources to answer all the calls from angry users looking for their report
- There is the odd chance that you may turn off a report that a VP uses to demo to potential clients. This would be a career limiting move.
- If it ain’t broke don’t fix it
The problem is you end up not knowing which reports are still relevant. Yes looking at your logs helps but you still need to know why someone is running the report. This brings me to my point, when someone bothers to tell you the report is wrong. You now know for a fact the report matters and the user is actually reading the report. In a sea of reports, this is good.
Opportunity for client engagement
Being told my report is wrong also tells me that the client has read through the report. They have applied their mind and have come to a conclusion I am wrong. All this means I have an engaged client. This is better than:
- Clients who do not read or understand the report.
- Clients who do not tell you that your report is wrong but tell everyone else in the company.
An engaged client presents an opportunity to get first hand information about how the report is used and interpreted within the business It is also a great opportunity for you to explain in none technical terms what data the report is drawing. You may find the client’s understanding of what the report is showing and the logic in the SQL are at odds. This is usually the primary cause for reports being called wrong.
Cunningham’s Law
Cunningham’s Law which states “the best way to get the right answer on the Internet is not to ask a question, it’s to post the wrong answer.” The concept is named after Ward Cunningham, father of the wiki. According to Steven McGeady, the law’s author, Wikipedia may be the most well-known demonstration of this law. Treat your reports like a continually improving Wiki. Most businesses are constantly changing making it impossible to ever a complete set of you reports. You should see your “wrong” report is an opportunity to get the “right” information.
Conclusion
I understand why developers and data analysts can be defensive over their reports. Reasons include job security and dealing with not so polite business users. You cannot control how users react but you can control how you react to them. I say you should welcome any feedback to your reports whether positive or negative, as long as your reports do not have technical defects causing them to be actually giving the wrong information. Being told your report is wrong is an opportunity to find our more about the business processes being reported upon. Reacting this way gives you a window to educate the users on how reports relate to business process. I have created some really fantastic relationships with some of my users. Those who have embraced my efforts to educate are now proactive when it comes to reporting. They inform me of changes to business processes and IT developments. They include me in meetings that have anything to do with data. This is because they have a better understanding of the impact of changes on reports. I now have a better understanding of the “business” side of BI.