Problem 1: Unfamiliar Territory for Users

This creates a problem that might be unique to the BI field. The problem is that the end-users or consumers of a BI solution are not familiar with those terminology, tools, and technologies. This situation does not exist in other fields. For example the consumers of a customer relationship management (CRM) system are familiar with the concepts of leads, opportunities, customers, and accounts that the CRM system manages.

The problem surfaces right at the start of a BI project. How do you discuss the requirements of the system when the consumers don't understand the terminology? The answer is that you cannot effectively present and evolve the requirements in document form: you need to show them, and ideally let them use, a prototype or pilot of the system.

The consumers of a BI system have to be actively involved in the definition of the system and can only do so effectively if they have a something that works and is based on real data. If more users have access to the pilot system better feedback on the requirements can be gathered. This introduces a second problem.

Problem 2: Cost of Prototypes

In order to alleviate the first problem many BI practitioners recommend using 5-10% of the project's budget (or proposed budget) to create a prototype or pilot.

These prototypes or pilot need to be created very early on during the project: in many cases before the project has been given budget approval. This is because the benefits of a BI solution are often hard to quantify. A particular solution might help managers make more informed, and therefore supposedly better, decisions. How much money will those better decisions save the organization in the first year? It is frequently hard to estimate.

Prototypes are often built during feasibility or return-on-investment (ROI) studies to help alleviate this situation. However if the estimated cost of estimating the ROI is too high the feasibility study might not ever be undertaken. The problem is that to get good feedback on the expected ROI you need to gather feedback from as many users as possible, however if there is a per-user license cost to do this the cost of gathering the feedback can become prohibitive. If it costs $20,000 to do the prototype the project budget needs to at least be in the $100,000-200,000 range.

The good news is that open source BI tools let you do this with no license fee for the BI functionality. In conjunction with open source operating systems, databases, and application servers a pilot using open source BI tools can be executed without any software license fees.

Problem 3: Expensive Infrastructure

A third problem with BI implementations is that the infrastructure of a BI solution is expensive. This means that there can be a high cost, in both software (unless open source is used) and effort, in creating even a simple BI solution. What is worst in most cases the users get no value from the system until the end of the project. You can compare it to building a house: it takes a lot of resources and time to construct the house but none of the value can be realized before the end. If the house design has 10 rooms and you are half way through the construction of the house do you have 5 usable rooms? No, you have no usable rooms, and you continue to have no usable rooms until the last day of the project.

Problem 4: Rigid Project Methodologies

The final problem with traditional BI projects is that the methodology used can compound the problems above and make them worse. Traditional development methodologies have phases with rigid transitions between them. In addition there are different people working on the different phases with 'hand-offs' between them. This makes adapting to change difficult and the later in the process that the change surfaces the harder it is to handle. This causes problems for the development of all software systems. BI's unique 'unfamiliar user' problem makes it hard to concretely define the requirements. Combining a requirements definition that cannot be reliably confirmed with a process that does not handle change well is a recipe for problems.

Is there an alternative? Why yes. The alternative is to use an agile approach.