Search This Blog


1 March 2008

On Business Intelligence projects

What is business intelligence?

Business intelligence is, frankly, a buzzword. It looks to me as if it simply follows on as the phase 2 or 3 from a series of semi complete data warehouse projects run a few years ago.

Maybe that view is a bit sceptical.

Let’s take a look at the definition of BI from some experts. The CSIRO is the Australian government’s leading scientific research organisation. It has a neat definition of BI on its website.

“Business Intelligence is a process for increasing the competitive advantage of a business by intelligent use of available data in decision making. This process is pictured below.

The five key stages of Business Intelligence are: Data Sourcing, Data Analysis, Situation Awareness, Risk Assessment and Decision Support.”

Breaking down these categories further (and also care of the CSIRO);

  • Data Sourcing
    Extracting electronic information from text documents, databases, images, media files and web pages.
  • Data Analysis
    Synthesising useful knowledge from collected data using data mining, text understanding and image analysis techniques.
  • Situation Awareness
    Linking the useful facts and inferences and filtering out irrelevant information.
  • Risk Assessment
    Identifying reasonable decisions or courses of action based on the expectation of risk and reward.
  • Decision support
    Employing semi-interactive software to identify good decisions and strategies.

As you can see each of these dimensions can sit on a spectrum of fully automated to fully manual.

I see BI as the processes that use the data stored in those warehouses that were otherwise sitting there idly except for DM (let’s be honest: junk mail) campaigns.

How do I plan for a Business Intelligence project?

So, with BI flavour of the month, there is a reasonable chance that one or two of you out there are going to work on one this year. What sort of things should you know about BI projects to make sure you can do a good job?

I think there are a few key issues that, if managed, will make your BI project a standout.

Make sure that you don’t just focus on technology.

Enterprise projects often promise fully automated bells and whistles prior to business case, but once the project has been given the go ahead non-essential features start getting cut.

So, face facts: when you get rolling there are going to be substantial manual processes to pull data together, analyse it, apply context and then do something about it.

That’s right; people will be doing the machine’s work. So make sure you get them on board and engaged with your project.

The key question for you to ask your people who will be doing the work is WIIFM? (What’s in it for me?) Why should they take on extra or different work from what they are doing today? You need to explain the advantages of your new system to them and the enterprise.

It’s the same old human change management work that dogs all sorts of projects. It just seems that BI projects are even more likely to forget this aspect than usual.

What do business requirements look like in a Business Intelligence project?

Recently I posted something about a three level hierarchy of requirements.
1. Business Requirements
2. User Requirements
3. System Requirements

Take time on the first and second levels to understand them.

Too often on BI projects people jump straight into the data and relationships. Instead, ask yourself why this BI matters to the organisation? How will it be used and by whom? That’s the business set.

Then ask yourself how the information is going to be produced, who will be doing the actual report production, who will be using it to make presentations and how and when will they access it? What sorts of reports are they going to start off with? Where will they be in 18 months time and what will they be looking for then? That’s the user requirements.

This is a great opportunity to use prototyping in a creative way. Use your own domain knowledge to pick out a problem area and develop a report around the problem, highlighting how it’s impacting the business and why. Use a couple of these to show your stakeholders what can be done with your BI systems and get them excited.

Boiling the ocean and eating an elephant before breakfast

Be wary though of trying to solve all of the organisation’s problems in one shot. Plan your project so that it delivers capability and that it sets up a platform for further enhancements. Deliver incrementally and make sure that each delivery is useable and adds value to the organisation. Stop when the effort begins to outweigh the rewards, and on the way give the business stakeholders the time to adjust to and adopt the new systems and tools you have delivered.

(If you want to read more on this topic I have just found an article by Steve Williams about problems with requirements on BI projects.)