Your report is only as good as your requirements

Written by belle
Posted November 6, 2010 at 1:04 am

Your report is only as good as your requirements.

When I first worked with reports and reporting services, I was excited and giddy. Beside my plain old text and T-SQL, I now get to work with some shapes and colors! And look ma, no hands, err, it’s drag and drop!

But the fascination with colors, drilldowns, drillthroughs, what-have-yous fade away as quickly as that drag and drop. You realize fast that – although managers typically like the pie charts, the drill downs, the colored legends – if any number, or any minor thing for that matter, is not “right”, the whole report is not right, and all your work really goes down the drain.

Sometimes, it’s not because the report is “completely wrong”.

Sometimes, the sorting is “wrong” so the report is “wrong”. Sometimes there are missing filters so the report is “wrong”.

Sometimes it’s because the terminology – is “not quite right”. What do I mean, you ask? Isn’t a “sale” always a “sale”, ie, what was sold? Isn’t a “Project Cost” always a “Project Cost”? Isn’t an “Overbudget” always the “amount over the project budget”?

That’s the tricky thing. It’s not.

I realize that what’s hard about writing reports is not writing reports itself. Sometimes, writing the report is the easiest part. Sometimes I am tempted to tell clients, yup, I can make your reports sing and dance. The problem is, if it sings and dances to the wrong song, I’m outta luck.

What makes any report writing position challenging is the gathering, clarifying, and testing the requirements. You almost have to be a BA (Business Analyst) and try to bridge the terminology gaps. Getting users to tell you what “sales”, or “margin”, or “variance” means is a whole different ball game. You also need to keep in mind who the report is for, because sometimes the same terminology is used for multiple different things for different functional groups or departments.

Software Development Connection

Report development reminds me of software development. And whenever I am reminded of requirements gathering in software development, this is the picture that comes to mind. It looks comical, but it’s reality.
Source:http://www.jacobsen.no/anders/blog/archives/images/project.html

So what will make writing reports successful? Here are my general tips:

1. Keep track of report requests.

2. Talk to the report users. Understand exactly what they need. Clarify every terminology. Do not take any terminology for granted. Remember, what something means to you is not necessarily what it means to another person or department.

3. Identify who will be responsible for validating reports. If you are coming in as a report designer/developer, and you do not have the domain knowledge for your client’s business, it’s of utmost importance that you get commitment from someone in the organization to validate the report.

4. Request for report samples, with definitions and legends if possible. They can draw this by hand, or mock it up using Word or Excel or PowerPoint.

5. Try to keep report progress visible. Regularly check with your report users if the report in progress is aligned to what they were looking for.

6. Put legends in your report. It helps avoid the confusion when users use the report. Define your fields/columns (for example: Quantity On Hand is the physical inventory count at the time of report generation).

7. Version your reports, and document the versions. It can’t be helped that as you move along, some requirements will change, or some requirements will be “clarified”. Versioning your reports, and documenting what has changed in each version, allows you to go back and see how and why the report has changed from the initial requirement.

Rating: 9.0/10 (8 votes cast)

Rating: +1 (from 1 vote)

Your report is only as good as your requirements, 9.0 out of 10 based on 8 ratings

Be Sociable, Share!