BI Masters Degree at Dundee University

Although I am a huge fan of Microsoft BI (which is  why I work for Microsoft not because I work for Microsoft) I realise that many of the factors behind a successful BI project are nothing to do with the technology. Of course the technology decisions can make a BI project more effective, more affordable and more agile, but that’s another story.

So when Mark Whitehorn asked me to do a session to his MSc BI course at Dundee University, we agreed on a title “Business Intelligence – it’s not about the technology”.  My talk (whihc I gave today) was based on my own experiences using solutions from Business Objects, Cognos, Informatica etc. and of course Microsoft, but what I wanted to draw out was what to watch out for in the real world irrespective of the stack used.

After thinking about this for a while I eventually realised that the core of my talk would essentially prove the validity of Ralph Kimball’s readiness test for business intelligence. So for each of these tests I simply put in evidence of where there was a positive and negative example:

Strong Business Sponsorship from the senior partner in a major UK law firm got buy in from all parts of the business and meant that the project was completed on time (two days before I joined Microsoft) and on cost.

..however at one company I worked at the IT guys could see the need to update a reporting solution, but didn’t have the senior sponsorship needed, so a very tactical solution was all that was achieved, while some decisions seemed to have been made by the board during a round of golf.  I wonder if that still happens there now?

Urgent Business Need. One successful project I remember was nothing more than a mainframe replacement. This did add extra ad hoc functionality, but a straight goal of like for like replacement and a very real need for a fixed go live date when the mainframe kept the scope and deadline fixed.

I have worked on a couple of white elephants especially when I first started and was too inexperienced and too junior to push back, the most obvious examples were often a board members pet project , so resources were made available but the project didn’t align with the business strategy (one one occasion there wasn’t one). Perhaps white elephants are rarer in these uncertain times.

Good collaboration between IT and the business has meant that I was able to train and lead a new BI team in a utility company. As a consultant this might be like eating your own children, but I wouldn’t be able to scale and do all their projects or handle the day changes and support that a good BI system needs if it is to keep up with the business. However they could always come back to me to assist in the bigger projects and to help them pitch ideas to their management.

On the other hand I was brought in  by the business users in an attempt are made to go around what is seen by the (not me) as institutional inertia in s the IT departments.  All went well until it was time to go into production where regular access was needed to data and production servers so the project hit the skids (to use a technical term).

Culture of Analysis. I have written several post before on flying on instruments and I worked in women’s fashion for a while where the merchandisers would make decisions to discount a line to ensure a balance between discounting too early and aggressively which reduces profit and too late where you have a warehouse full of unsold stock.  Complex spreadsheets were used for this which were then replaced with a suite of exception reports. 

Despite my best efforts to produce actionable insight at a brewery I worked at (tough work but somebody had to do it), the salesmen were all for using their experience to make decisions rather than believing what the reports were telling them. later the brewery were acquired and I guess the sales guys are know working elsewhere.

Feasibility Issues. I have come across which can block a project have included not being able to get at the data, and especially poor data quality around customer demographics.  One other particular was in an insurance system where it impossible to resolve the data on screen to what was in the database because of the complexity of the application.  This can happen in systems where the customer can design and alter the application to the extent that the schema changes.

This all sounds like doom and gloom, but I thoroughly enjoyed most of the projects I worked on. Of course the issues I have highlighted were frustrating but being aware of them before they became an issue meat this was kept to a minimum. 

Having given my talk, Mark thanked me for pretty much summarising what he has been telling the students , and that’s interesting when there often seems to be so little consensus in IT these days, hence the post.

I just wish this course was around when I was starting out, so I didn’t have to learn it the hard way!!

Technorati Tags: Mark Whitehorn,BI,Business Intelligence,Dundee University