I used to work with a contract database developer named Charlie who specialized in small to medium-size businesses. I sat in on client meetings and helped draft technical specs and reporting requirements. Charlie would ask the client to list the reports they were currently getting and the types of reports they wanted to receive following implementation. The client typically responded with the usual suspects, including monthly cash flow, accounts payable and receivable, customer lists, number of orders processed, status of orders, and so on.
After hearing the client’s list, Charlie would then suggest a few additional reports, which were more of a strategic nature and consisted of cross-tab reporting.
For instance, when we met with a firm that sold items used in the rehabilitation of orthopedic surgery patients, Charlie suggested reports showing all income by payee (Medicare, Medicaid, private insurance) and all income by physician. To Charlie, those reports were obvious choices to help manage the business. Those reports weren’t as obvious to the client, who was often thrilled with Charlie’s suggestions. The office manager had either done without those reports in the past, or had spent a considerable amount of time manually generating similar reports.
Charlie focused on the reporting requirements for these key reasons:
- Reports requirements drive the database design. You can’t design an accurate data model if you don’t know the client’s reporting needs. Since reports are the client’s decision-making cornerstones, bad reports equal bad data.
- Clients always think of new reports after they start using the custom application. Getting as many reports into the design specification document up front means fewer haggles about additional billable time down the road.
- Business drivers are often uncertain of what they really need from a database application. The strategic decision makers may have a grasp of some of the reporting requirements, but they often are unaware of the range of possibilities presented by a well-designed and maintained database. Getting those folks to talk about reports helps focus attention on the big picture.
A discussion about reports makes a great segue into data storage and retention requirements. Most reports are generated on the fly, while others are run once and stored for archival reference. How long you keep some data active may depend on how frequently the client may want to run reports on older data.
Prototype now, save time later
Prototypes can require a lot of money and development hours, but they’re worth it. Find out how prototypes can save you from bigger problems down the road.
Some clients will try to defer discussion of reports until they see some “progress on the application.” Don’t let them get away with it. Unlike the chicken and the egg, there’s no doubt about which should come first in database development. Define the reports first, and you’ll know which columns you need to store in your table and which columns you can calculate at report runtime.