Don’t Make Reporting Just An Afterthought
April 10, 2008
When your faced with all the planning, designing and development involved with building a new application, reporting can just become an afterthought on the project schedule. I’ve been on many client projects where reporting is just a week slapped on the end of the project schedule. “We just need to create a few reports and we are done.” This is not true if your building a system of any size or complexity. Ask yourself why the system is being built. All that work to store data and build an interface to input the data, what is it all for? It is to create reports for the business to analyze how the company is doing. A company runs and survives on the quality (and quantity in some cases) of it’s reporting. CEO’s and business leaders rely on these reports to validate the health of the company and steer it’s direction. Do you think they want to hear that everything they rely on was just and afterthought!
Reporting systems can get really complex when you are dealing with business people who like to ‘slice and dice’ the data. It seems like they want 20 reports to slice the data every way possible. Executives don’t want all the detail, but want everything summarized, categorized and broken out by time. Once the business hears about a new system in development, requests for specialized reports above the “10 standard report” you planned can drive development into overtime. The work loads increase, but the amount of time does not. Add on top of that the need for securing the reports based on roles, teams or other categorization. Extending your application security model to include reporting can add time to your already crunched project schedule.
You might think that just starting work on the reporting system earlier will give you plenty of time to address the issues above. That is true, but starting reporting to early in the project schedule can cause other issues. If you start development earlier you will need to plan for reporting to take more time. SAY WHAT! If the main application and database is still in development, things are going to change. Fields are changed, flags are added, data is incomplete. All these thing effect the ability to create a correct report the first time through. As the design of the application changes, reports will need to be changed also. This takes more time and extends the reporting schedule.
There is a positive to starting reporting early. The reports that are created can be used to help validate the system in development. I worked on one project where the business leaders kept coming to me and telling me that the reports were validating were wrong. As I analyzed the data, I found problems with the interface and/or database. Once the issues were corrected, the report was correct. Having reports to validate the system during development can be very useful, especially if you are migrating records from an old legacy system to a new system. Making sure you have all the data and you can match numbers from the old system is critical.
The point of this post is to get you thinking about issues around reporting that may cause delays in your project schedule. I’ve brought up a number of problems, but what can be done about them? Here are some suggestions.
- Don’t make reporting an afterthought. The reporting system can be as critical and complex as the application.
- Allow enough time in your schedule for proper requirements from business leaders. Make sure you are meeting their needs.
- Allow time to do proper architecture and design of the reporting system. Factor it into your security model design.
- Design reports that meet the business needs. A report no one reads is a waste of time.
- Combine reports where you can. Create a single report with more parameters to allow the business to ‘slice’ the data without you needing to maintain 10 copies of a report for different users.
- Write efficient code. If your using sql, spend the time to make sure it if quick and efficient. Speed counts.
- If you are replacing a legacy reporting system, make sure you analyze how the old reports where put together. You may need to match those numbers with the new system.
- Work with business leaders and executives to make sure you are providing the information they need in a format they can use. If they can read a report or two and get everything they need to know, they’ll love you for it and it will help validate the cost of your reporting effort.
- Know you data. I tell anyone who writes reports for me that they can’t write quality report if they do not know and understand the data. SQL is a language that makes it very easy to get the wrong answers.
- Validate your data. You can’t get a correct report with wrong data. Test and development systems need to have real data and lots of it.
- Set expectation with leadership. They need to understand why extra time (and money) is need to create a proper system.
Proper reporting can be the lifeblood of a company. Don’t make it just an afterthought.
Jeff
Comments
2 Responses to “Don’t Make Reporting Just An Afterthought”
Got something to say?
Great post! I have always been an advocate of reporting and have always found that the best projects are those that get the user involved in the report design early. The data is what it is all about. Without meaningful data out of my system, I can’t make the decisions needed to run the business.
I have found that reporting efforts help drive the conceptual model development which leads to pure canonical models for the business. Having an accurate understanding at this level, gives the application much flexibility to support the reports that people are actually looking for. One of the problems with many off the shelf systems are the plethora of reports available. It is more important to have one really really good report than a hundred that contain portions of the information people are looking for. Report development is never a reporting problem, rather it points to a need for data architecture or should I say data re-architecture!
Start with the end in mind…