I am currently involved in the planning stages for a Business Intelligence (BI) project in our company.

We are attempting to understand many facets of the business, and as such the technical side of the project appears relatively unimportant compared with the business aspects of the project.

Should this project be spearheaded by a technical team, or by a business team?

Is it more important to have technical teams drive the requirements, or should the business drive the requirements?

What should I expect, as a DBA, to be held responsible for in a project of this kind of scope?

  • 4
    Your questions are still pretty non-specific and hard to answer meaningfully. Fortunately I think it's possible to meaningfully answer this question by looking into the origins and dynamics of this particular trope. However, I'm not going to write a whole essay in answer to every vaguely worded question I see on dba.se, so you will need to start being a lot more specific if you want to get meaningful answers. – ConcernedOfTunbridgeWells Apr 2 '12 at 11:14
  • 1
    This post is highly subjective and can not be objectively answered without more details. Closing. – jcolebrand Apr 3 '12 at 15:19

Is B.I. a business or technical project?

There are too many variables to answer this categorically; I'm tempted to VTC the question as it doesn't really have a single correct answer. However, on second thoughts I can say a few reasonably meaningful words on the subject.

Customer Intimacy

Business Intelligence (or more prosaically reporting) is very requirements heavy in comparison to the amount of implementation work involved in the delivery. Getting the requirements right requires nuanced analysis but may not require technically sophisticated solutions - in some cases a spreadsheet is sufficient.

I.T. departments may not have a sufficiently close working relationship with individual consumers within the business to effectively gather the requirements for a B.I. solution, or may simply not be responsive enough. In many cases desktop tools such as Excel and Access are sufficient for the job, so reporting teams are often run directly within the individual business units.

I have seen a number of sites where B.I., reporting or analysis teams were run within the business precisely because of the issues with responsiveness and working relationship. In many cases they even had their own server hardware, ETL processes and development staff.

Strong business sponsorship vs. responsibility without authority

On a larger scale, data warehouse or business intelligence projects are middle men. They do not produce data, but aggregate and present it in a form that is easy to report on. This means they are integration projects and have to interact with many little empires within the business - sometimes called 'gatekeepers' in the literature.

This interaction - and the attendant real or perceived shifts in power - tend to politicise data warehouse projects and make them heavily dependent on the cooperation of many third parties. These third parties will have responsibilities and agendas of their own and no responsibility for the project success, so they can seriously affect the progress of a project and even derail it without necessarily being held responsible.

Building a non-trivial data warehouse system involves putting fingers in a lot of pies, including ones where they may not be particularly welcome. Without a business sponsor who has the political will and the political clout to bang heads together on behalf of the project, this generates a significant risk of failure or limitations on delivery that can't be worked around. Weak business sponsorship is the #1 cause of B.I. project failure.

Getting it right

The flip side of this is that a larger scale project is much more challenging technically and from a 'software engineering' perspective - keeping the code base well organised. This requires technical skills that may or may not be present in a B.A.U. reporting team. Most reports or other dependent feeds from a data warehouse will be tightly coupled to the data model unless care is exercised in interface and data mart design - and even then a database has a limited range of options for supporting abstractions efficiently. This means that getting the model wrong can be very expensive or even infeasible to fix.

Failure to build the system properly can also allow a large class of leaky abstraction problems where the underlying data exposed through the system is too dirty or inconsistent to use through an ad-hoc reporting tool. A project where the brief has aspirations to a self-service facility must be built so that the data presented is clean, consistent and presented in a form that works well with the ad-hoc reporting tools.

Leaky abstractions place non-obvious elephant traps in the data and make it easy to report incorrect data from the system. Even if the problem could (in theory) be corrected with user training this can significantly erode end-user confidence in the system. Getting conformed data (where it may behave significantly differently across multiple sources) is a critical success factor for any self-service reporting project and may well be a non-trivial undertaking.

In many cases technology is a non-issue, although I have seen projects switch platforms due to technical limitations of the original choice. In some cases data volumes may require the use of certain technologies; in others a ROLAP tool may lack sophistication necessitating the use of dedicated OLAP software. A server consolidation environment may not be the best choice of platform for a TB range data warehouse system (don't laugh - I've seen this attempted on more than one occasion).

Platform choice can be politicised and can also have a significant bearing on project success or implementation costs or time scales.


A large B.I. project will need strong sponsorship, priority treatment from the business and good technical leadership to work effectively. In most cases the actual technology used is less of an issue, but an unsuitable platform can impede the delivery of an effective system.

  • Weak sponsorship allows gatekeepers to impede access to necessary data or domain knowledge, or the project can be constrained from delivering an effective solution by petty office politics.

  • Lack of business priority also impedes access to necessary subject matter expertise, or allows the delivery to be dumbed down to sub-optimal as-is practices.

  • Weak technical leadership can result in a platform that lacks flexibility and becomes too expensive to change.

  • Ineffectively cleaned and conformed data generates leaky abstractions in the reporting layer that can erode user conficence in the system.

  • In some cases the project can be crippled by poor choice of technology.

Stating that a B.I. project is a 'Business' initiative is something of a truism. Technically it is correct in that a project of this sort is likely to fail without effective business sponsorship. However, there are also a variety of technical critical success factors whose absence can seriously unseat a project.

In practice, I suggest answering queries about a business intelligence project with something like:

We can, but the price will be your firstborn child and the head of your CFO1 mounted on a plaque on the wall of the project office.

If the business sponsor just briefly considers that - even for a moment - then they have about the right level of motivation and commitment to the project's objectives. If they have the clout to take out a contract on the CFO then they have about the right level of political influence to back a project of this sort to success.2 Anything less than that means your project is at significant risk from weak sponsorship.

1 Obviously if the CFO is the sponsor than you will have to nominate another sacrifical victim of equivalent status.

2 Also, we don't necessarily recommend you hold your sponsor to this price. In practice, it is normally sufficient to demonstrate an appropriate level of commitment to the project.

| improve this answer | |

Like all IT projects it is both. You cannot succeed without a strong business need and support nor can you succeed without people with the techincial skills to put the project together.

| improve this answer | |

I would consider BI a business project, because the outputs are metrics that business is required to use. This is despite the fact that about 80% of the input is technical.

In my experience, if the focus of the project is technical, then alot of time will be spent analyzing the implementation technology, yet if the focus is business them more time will be spent deciding which metrics are to be delivered, how often, how fast etc, and the technology will be selected based on the constraints. Infact most BI project start with database based reporting before outgrowing to full blown BI.

Bottom line, for success focus on business, and bring in tech to deliver "goods" within budget and time constraints.

| improve this answer | |
  • BI could be considered an example of how the very concept of "an IT project" is becoming obsolete: more and more, IT (say, a BI database) is simply a tool which is used for business goals. IT is no longer a separate world; at least, less so than it used to be. – Jon of All Trades Apr 2 '12 at 15:45

Not the answer you're looking for? Browse other questions tagged or ask your own question.