3 Avoidable Pitfalls in Report Development and Maintenance

No enterprise can be complete without numerous reports for internal and external visibility, but how do all these reports come to be? In large organizations, there may be a whole department dedicated to reporting and business metrics, while in other organizations the entire process may be outsourced or left to one single individual.

In any case, the process of building and maintaining reports has common obstacles, which can quickly eliminate the value of the reports as well as any trust in company data. Because reports can be invaluable, organizations should take the time to avoid costly mistakes.

Here are some of the top pitfalls we often see and how to avoid them:

Pitfall #1: Expecting a Quick Turnaround

In our wonderful age of powerful technology, some problems can be resolved almost instantaneously, but the world of reporting development/maintenance can (and often should) take a little longer. When planning a reporting project, one must understand what will be required to make the appropriate changes.

For a full-scale enterprise data warehouse (EDW) implementation or construction of a new data mart, plan for several months to put everything together. Reports are only as good as the data contained within, and to ensure clean, performant data requires intensive planning, building, and testing before publishing. If there are new reports to be created, expect at least one to two weeks. The requirements and metrics need to be completely fleshed out to ensure the accuracy of reports. If the data necessary for a new report doesn’t exist in a usable form in the current data model, not only will the model need adjusting, the process to fill the model will have to be changed.

Reporting is like icebergs: the little bit that is exposed to most people only accounts for 10% of the underlying processes. It is essential not to be dismayed by longer turnaround times to fully understand and implement the best reports possible. This goes not only for the developers tasked with creating reports, it is key for those asking for the reports as well, which leads to the next pitfall.

Pitfall #2: Losing the Involvement of Stakeholders

Because reporting projects can have an extended timeline, it is crucial to keep stakeholders involved in the creation process. Every report has an impetus for its creation, someone who needs the report to be created to fulfill a business need; this person (or department or group) must be continually involved to ensure the report truly is solving the business problem in question.

All too often, stakeholders in the report will cease to be involved in the development process, will not be available to answer questions about requirements, and the development team will be left to make assumptions about the metrics and reports to complete work by the assigned deadlines. When this happens, the development team will either make all the right assumptions through sheer dumb luck or there will be harsher consequences. Either the report will be wrong, lowering overall confidence in data and reporting, or (even worse) the report will be published in its incorrect form, leaving consumers to make incorrect insights without a doubt in their minds. No matter the changes, stakeholders and consumers need to be available to help guide the process successfully, particularly for requirement gathering and testing.

Pitfall #3: Not Using Source Control

When writing new reports and working with existing reports, using source control is always the right choice. Whether working as a one-person report shop or as part of large development team, it is very important to keep all reports and report code in source control. This may seem obvious to some, but all too often report code comes from many different silos in an enterprise.

When discussing data, one will often hear the phrase “one source of truth” or “a single source of truth,” but this applies not only to data, also to the reports built on that data. Imagine changes in business rules and business logic without some form of source/version control. If new rules and logic are implemented in certain reports but not others, or implemented by one developer who then leaves the company without checking in the code, the rules of the business become very convoluted and the reports become confusing if not downright conflicting.

Keeping reports in source control is incredibly important for keeping all of the enterprise on the same page.

A Better Process

Given the insights and decisions that can be made with reports, they serve a key function in any company. The projects can be long, the work can be hard, but if these pitfalls are kept in mind, the process can be much smoother. If these become default enterprise practices, organizations can move into new levels of analytics, driving insights competitors have not even imagined yet while maintaining internal and external integrity.

Be sure to follow us on Twitter or LinkedIn for more useful tips.  If you have a question or comment related to this post, you can use the comments section below to join the conversation.

–

Transform your business operations with our Microsoft solutions

Explore Our Microsoft Consulting Services  →

–

• Information Overload
• SharePoint 2013 Information Architecture
• Publishing Portals