Why are Business Intelligence Projects So Different?
Posted by Rob Risetto on November 10, 2015
Have you ever wondered why BI projects are so different to the traditional IT development projects?
I found this article 8 Ways that Business Intelligence Projects are Different (here) by Analytics8 that succinctly outlines the differences and what to watch out for when taking on a BI project.
In summary, some of the core differences of BI Projects gleamed from the article are listed below and tend to be reasonably accurate based on the BI projects that I have been involved in.
- A BI project should be considered a Business project and not an IT focused project. Business needs to take the lead role both in defining their information requirements and in ensuring that the BI solution built by IT meets these requirements.
- There is a significantly greater contribution of business analyst time during the development and testing phases then traditional IT projects. This mainly due to the iteratively refinement of requirements/design as the project progresses.
- New ideas arise well into the development and even testing phase of the project, presenting a major challenge to the project manager to balance the evolving business requirements with the need to manage scope. The new ideas represent one of the major benefits of developing a data warehouse, as these new insights are often where the greatest potential value of the project lies.
- BI development efforts tend to fit better into an iterative methodology, where work is done in cyclical stages. I.e. rapid release cycles of small components of the overall solution.
- One of the major areas that is frequently under-estimated in data warehousing projects is the amount of time required for testing and dealing with data fixes. Most organizations assume that a report or dashboard is finished once the development process is completed. However, once a report is available for testing, the testing process will often identify errors not in the report itself but with the underlying data sources.
- It is therefore critical to define a change management strategy for the BI effort. This should take into account user training needs as well as gaps in reporting capabilities, and should address any concerns about flexibility to manipulate data manually for ad hoc reporting or analysis.
- Although it is tempting for users and developers to agree to reproduce an existing set of reports, this is not the best approach as it does not take advantage of the additional capabilities provided by the new data warehouse, and may also reproduce existing errors in the new system. A far better approach is to work with the users and business analysts to define the reporting requirements based on discussions and workshops, rather than seeking to replicate existing reports.
- It is better to structure the BI effort as a series of projects, each with its own limited budget and schedule. The data warehouse is thus built in stages, where each project delivery consists of a component of the overall set of requirements defined by the business.