Rationale . . .

Why Are We Doing This Project?

It's important to understand the rationale for the reports in the first place. If your organisation has a formal business case - great! Chances are, you won't, so you will need to appreciate why the sponsor (or client, or stakeholders) have forked out cash to make it happen. Here are some possible scenarios, grouped by rationale:


Cost Reduction Benefit Increase Change in Environment Political Considerations
  • Legacy system too expensive to run
  • Legacy system too slow and clunky
  • Employees waste too much time
  • Reports are flaky or old-fashioned
  • Users need new features
  • More users or reports than before
  • Incomplete or unintegrated data
  • Increase reliabilty and quality of reports
  • Mergers, acquisitions and spin-offs
  • Source systems shutting down
  • New systems employed
  • Training requirements of staff changed
  • Legal or regulatory shifts
  • Sponsor needs sexy project
  • Someone needs to keep you busy
  • Showcasing your organisation's prowess
  • Part of program to drive cultural change

Project Factors

You should be sensitive to the relative importance of the following factors, as trade-offs between these must be made continually throughout your project:

  • Time - Remember to consider both elapsed time and effort (staff-hours). Project Management methods will help you with this aspect.
  • Cost - Don't forget to include risks, opportunity costs, labour, the cost of capital and the time value of money. You should think about employing Total Cost of Ownership (TCO) methods here.
  • Quality - You need to wear different hats for understanding quality, ranging from "meeting the users' expectations", to "conformance to specifications".
  • Scope - Not all features for everyone can be delivered straight away. You might want to look at pilots, phased roll-outs and vendor trials to lower your time, cost or quality risks.

Design Levels

In addition, each of these plays out at different levels of your project:

  • Project - Development of overall reporting system. The project manager or vendor delivering the system will be most concerned about trade-offs here.
  • Report - Design and deployment of each report. This is the realm of report designers and business analysts.
  • Delivery - Regular publication and distribution of report set. The person responsible for the day-to-day publishing of reports will make these decisions.
  • Usage - Browsing and access of reports by users. Here, report users who experience the system first-hand should have primary consideration.

For example, you may decide to deliver the entire reporting system in a way that is very quick and cheap, but makes it clunky and expensive to add new reports. Or you may deliver a system that is an absolute pleasure for users to view their reports - on those occassions when it works. The inherent tension between sponsors, developers and users will be played out in the trade-offs the requirements analyst makes. Understanding what has been before - and why it is no longer - will help.

The flow of information through an organisation is extremely political. In addition to turf wars and ownership disputes, changes will be resisted and have unpredictable consequences. You should anticipate grief and hassle when it comes to defining even basic concepts such as customer, employee, sale and order as they will mean different things to different people in your organisation.