Very often a project or program will need a reporting portal.
It may start as a small folder for reports and grows with the project. Even “Big Data” projects can have multiple small reporting portals separate from the main reporting portal. In this article, I will share with you some best practices to make a small reporting portal that helps users get to the information they need, with minimal support overhead, that can grow as the project grows. Here’s the first of the nine best practices:
1. Create brief, descriptive names for key reports and put them in a top level folder
Identify the report or reports that most end users will need and put these at the top level folder so the user can download them easily with few clicks. Do not change the names as people will link to them consistently. Be descriptive of what’s in the report so the user will be able to understand what’s in them, but not too specific — only what is essential to describe the contents. . Be consistent in naming — consider having a fixed format — be brief as possible in description (makes easier to link to)/ If something is understood to be everything (eg a national or worldwide report), consider not adding a description:
Online Page Views
Marketing_Online Campaign Analysis_Eastern
Online System Registrations _Worldwide_All Regions
Sales Reports_March_30_2012_Central Regional Headquarters
Eastern Region Marketing Campaigns_1_1_2012_2_28_12
How do your users keep track of reporting dates, updates, data sources if not in the report title? I’ll cover that in my next post on using metadata to facilitate reporting. If done correctly, it simplifies use and reduces technical support issues.