Report Guidelines: Report Approval and Deployment

This article is day five in a week of reporting articles.

Create and follow standard procedures for report deployment. The actual procedure depends greatly on the report method. Since I often use Crystal Reports Server and SQL Reporting Services (SSRS) for my report presentation, I have a Testing folder where all finished reports go prior to manager approval. Specify who can approve such reports.

In my experience, users have the tendency to request reports as single requests for data. In other words Milton will ask you, “Can I have the last 3 years of invoiced sales for Acme Rockets that shipped to Arizona?” There will be a temptation to fulfill his request as expediently as possible as an ad hoc query. If possible, put in a little extra effort and create a stand-alone report that can be re-used, regardless of whether the user wants it. You may even ask Milton if he will ever need similar information again and he will likely say no. However, next week he will come to you, most likely holding his red stapler and ask, “Now Bill needs year to date invoiced sales for Initech.” To most users these are completely different reports. Think ahead and create more versatile, reusable reports. This will save time for both you and Milton.

Create a watermark (if possible) to differentiate which reports have been approved and which are still being tested. Watermarks are typically semi-transparent logos or large text such as “Draft” shown behind the data. Watermarks “encourage” users not to use a report ad infinitum, which has yet to be approved because their data can be hard to read. Some may balk at this, but trust me if you do not create and follow a similar procedure, reports will become disorganized and never are certified. I’ll follow up with a “How To” article to achieve this with Crystal and SSRS.

Remember, you are (or at least this is directed to) the technical person. At a previous employer, a V.P. affectionately referred to me as the “chip head.” At least I think it was affectionately. You are most likely NOT the decision maker, you write reports for them. It is very unlikely that you know their data and what it means better than they do. Therefore, they must certify that your reports are right.

It goes without saying, but use descriptive and specific report names. Reports are not helpful if the user cannot determine their purpose at a glance. To go along with that, thoroughly document every report. Inevitably, a user will come to you and ask something like, “Does this include part revisions that are….” If you do not document reports up front, you will have to edit the report to find out. When documenting, I always imagine that today may be my last day at that particular job. This is the “What happens if Dave gets hit by a bus?” kind of thinking. If someone needs to take over for you, can he/she do so easily? If not, you are not doing your job.

Report Documentation for Crystal Reports

Report Documentation for Crystal Reports

In Crystal, I document using the Document Properties Window at File – Summary Info. The Comments text is displayed next to the report title on Crystal Server and assists the user in selecting their reports.

So, this was my week of general reporting tips and guidelines. I will follow up soon with a series of videos, which will demonstrate the best ways to extract SQL from M2M reports as well as creating Crystal, and SSRS Reports based on M2M data.

2 comments to Report Guidelines: Report Approval and Deployment

Leave a Reply




You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>