What is the best way to discover, prioritize, and iteratively deploy business intelligence solutions?

Question

BACKGROUND: Have a client that has terabytes of transactional data and they would like to begin leveraging the data they have, but beyond the knowledge it's possible, and the belief that an analytic system would produce value, they do not appear to have a solid starting point and have mainly been looking at the problem in the context of what technology is able to do, instead of what their business requirements really are, and I'd like to move the analysis away from what tools are able to do, and to how discover, prioritize, and iteratively deploy business intelligence solutions.

UPDATE: As requested on meta, this update is a response to the current current answers. First, thanks, my guess is that the fitness of the questions is directly related to how clear my question is. I have reviewed all of the answers a number of times, and to my knowledge all address general business requirements gathering, not "Business Requirements Analysis for Business Intelligence", which to me is not the same thing. More to the point, the best example of a source that speaks to this is a recent book by Lawrence Corr titled Agile Data Warehouse Design. While so far, this to me seems like the best answer, I had hoped that I'd either get feedback on the question itself, or another perspective via an answer.

Answer 1

Defining business requirements for BI is a challenge because people tend to think just about data and reports or dashboards (and rapidly get overwhelmed by the near infinite potential for analysis that terabytes of data bring), losing sight of what that information can do for their business. Good BI is not about bringing complicated reports or cool dashboards to end-users: it's about understanding how well your business is going so that you can make the right decisions.

This is how I would recommend you go about defining BI requirements:

Step 1: Identify which KPIs drive the business:

• Basically what this is about is working out what tells us the business is performing well (or badly) and what we base our decisions on.
• To identify these KPIs, you can look at the WHO (who needs BI information?), WHAT (what information do they need?), and SO WHAT (what are they going to do with it?).

For example:

As a Business Unit Manager (WHO), I need to know how our products are currently selling against this year's profit targets (WHAT), so that I can take actions such as retiring a poor-performing product and concentrate resources on high-performing ones (SO WHAT) => In this example the KPI would be product profitability.

Step 2: Define how KPIs will be measured:

• This is about putting clear definitions and formulas behind the KPIs and working out which transactional data is actually required to provide the result.
• This is also the step where you define dimensions (e.g. time dimensions such as Fiscal Year, Months, Days, etc.) and units (e.g. $, %).

In the example: You could define profitability as ratio of profit on revenue. Then this number can be calculated for for year to date, month to date, variance against target, rolled-up by product lines, etc. This tells you which data you need (sales revenue and cost), how you need to calculate the KPI and the dimensions you would need to include.

Step 3: Define how results will be presented:

• This is where you look at ways for information to be accessed and presented (static or dynamic reports, dashboards, etc.) and how you can leverage a particular technology.

Finally, when it comes to prioritisation, it should based on which KPIs drive high-impact decisions. Start with a few and do them well (get the definitions, formulas and dimensions right) - in any case you can't effectively make good decisions using 50 measurements, it's better to have a few but of high quality.

Otherwise, as for other projects, I'd recommend you facilitate this exercise as part of a workshop with key business stakeholders and make sure people have ownership for driving this to successful completion.

Answer 2

I am answering this because I saw a comment on meta.

You are faced with a classic problem, a customer has a big pile of data, and has no real plan for working with the data. What you need to do is propose a several week project to do the meta analysis. During this time you will work on playing with the data, and proposing solutions.

That is the product you deliver, a plan for the future.

Answer 3

It is a question of perspective. You have to take off and fly a little bit; and take your clients with you. You have to help them have a global perspective on their business. The technical side of a project is very fun and interesting; but some seem not able to have a brother perspective. It is the same thing as a manager who does not have any tehnical backgroud and who is not able to inter the technical world. Maybe you should meet half ways. I would make them a 5-10 min speach of basic management concepts to open their mind to give them the passion they need to have a brother perspective on what they are doing business wise.

Answer 4

I agree with mhoran that this is a classic problem. But I do not agree that you should conduct a meta analysis.

We get lost with the bells and whistles of technology. Not only do you see this in business, but in personal aspects too. Watch buying behavior when Apple puts out new technology. It is a feeding frenzy and we buy. We buy whether we need it or not. We design our lives around the technology versus the technology around our lives, mostly because it is really cool. Apple does not ask us what we need, they tell us, then we evolve, or devolve, our lives to be consistent with the new need that Apple just told us we now have.

What you need is a strong facilitator, a person that can speak the business language of your client, who can check the technology at the door and focus on the direction of the business, the value props of the business, the mission, and its vision. Once your client can agree on where it is going, then it can focus on what data it needs, how it needs to be synthesized, and then what solutions you will need to synthesize it.

If you do it the other way around, then you will end up altering the business to meet the needs of the solution. Sadly, we do this all the time. You need to remember, the IT solutions exist because of the business...not the other way around.

Answer 5

May I suggest a practical solution:

Your client believes that there is value in the data, so that would be my starting point. Identify some benefits, ideally in tangible (hard cash) terms, but if these don't exist, start with intangible benefits then get your client to put some values around them. That's stage 1.

Choose the top handful of benefits, and work out which pieces of data are necessary to allow these benefits to be realised. That's stage 2.

Stage 3 is to evaluate your options for analysing your data. It could be that there is some standard tool - perhaps already used by your client's competitors or others in similar industries, or maybe already being used alongside similar transactional systems to those that your client uses. Consider these, and decide whether they meet the requirements. If so, great; if not, get out into the market and see what else is available. One word of caution: keep your wits about you, and don't buy the glitziest, flashiest tool in the marketplace unless you need it and know exactly what it will do for you, that cannot be done by low cost alternatives.

Stage 4 is to implement the tool and get some real value out for your client. Stick to the original set of benefit areas, and control the scope of your deployment to get the benefits out quickly. That way, the tool will start to pay for itself.

Stage 5 is to use the knowledge that has come from the first iteration, identify more benefit areas, and do it all again. You may need to think about using a different tool, or even better, you will be able to further exploit the tool that you have. Either way, you will have gained a lot of knowledge that will make the second and subsequent rounds slicker and easier.

Go round the loop as often as necessary, but stop when the benefits no longer outweigh the incremental costs.

Hope that helps!