Been a  little quiet on here lately. The current project has been in that stage of delving into business-specifics, which obviously I'm not going to share on here. Now, starting to come up for air again. I did put together these four principles for starting a BI/MI project, which I thought were a quite reasonable set to begin with.

·         Baseline the current reporting set

Creating an initial baseline refers not only to an inventory of data sources, but of an overarching view of the current state and perception of MI and BI. In a legacy environment, much of the process of enrichment which transforms data into information resides within the heads of individuals and the manual processes that are often deeply embedded. This cannot be easily captured in a simple matrix. 

·         Capture current problems

All legacy reporting processes have issues with data integrity, manual steps, workarounds, poor performance, etc… If not addressed, these will be populated through into the new solution. On the other hand, if they are addressed, this issue resolution encourages buy-in of the key user group.

·         Anticipate changes

The introduction of a new MI/BI platform will open the user group up to new possibilities in terms of reporting, which inevitably bring new requirements. The confluence of introducing such a platform in a rapidly changing organisational environment, greatly increases the likelihood of new requirements. These may be of such scope as to entail structural change in the solution. Anticipating these changes in the design stage is up-front work which will pay back manyfold on implementation.

·         Understand duration

Time is the most complex data source in a reporting platform but it is the most often overlooked.  Time plays a role within periodic reporting, within the organisational calendar (which is often distinct from the calendar everyone else uses), in scheduling, alerting, and in the way it impacts when changes in sources or requirements affect the database.