Part 2: Measure What Matters

Written by: Phil Husbands

I show organisations of all shapes and sizes how real business intelligence isn't just about technology. As the Data and Analytics Director at Acrotrend, I help businesses to turn their data into truly valuable reports and information, by aligning BI and data technology with their goals, people and processes.

This is the second article in a four-part series about how to ensure that your BI efforts don’t just create reports and dashboards, but generate truly beneficial outcomes for your business.

Part 2: Measure What Matters

In part 1, ‘Results Before Reports’, I highlighted four key qualities that BI solutions must possess, to ensure that they deliver true business value. In this article I’m going to focus on the first of those aspects; relevancy.

To achieve high-value business intelligence, the content of BI solutions must be wholly relevant to the business’s goals, processes and people. It’s impossible to do anything worthwhile with irrelevant information. People either know it is irrelevant and so decline to use it, or worse still, people don’t realise it is irrelevant, and end up wasting time and creating risks by taking action on bad information. Sure, all this sounds obvious. But it’s commonly overlooked. It happens when businesses set KPIs without fully agreeing what they mean. It happens when BI projects accept the shortcut of ‘industry standard template’ reports. It happens when spreadsheets are replaced with new tools that deliver the same information in a different format. It happens when BI solutions don’t evolve in response to changing business needs. You get the picture.

Discovering What Matters

Thankfully, ensuring that BI solutions are relevant is easy, if you focus BI requirements analysis on discovering what really matters to the business, through the tried and tested method of user stories. Most people are familiar with how user stories work. Even so, it’s worth sharing a quick reminder, because there’s some subtleties which are very important for BI user stories.

User stories are just a simple way of recording requirements in plain language. They work like this – each requirement is captured in three distinct parts:

‘As a…’
‘I need…’
’So that…’

So an example of a BI user story might be ‘As a Product Manager, I need to compare product features with customer complaints, so that I can shape future product specifications to maximise customer satisfaction’.

I know what you’re thinking. Most BI projects already use user stories, right? But the thing is, many BI projects fail to embrace what makes user stories so effective at ensuring that BI solutions are relevant. The key lies in meticulously controlling the ‘I need’ and ’so what’.

In order that your BI solutions are always wholly relevant and measure what matters to your business, user stories are your secret weapon. But you need to understand those subtleties which make them to effective for BI.

Here’s an example of the kind of substandard BI user story that I see far too often. ‘As a Product Manager, I need a spreadsheet of complaints by product feature, so that I can manage product specifications’. So what’s wrong with this BI user story?

Firstly, the ‘I need’ part is defining a solution rather than a need. Who’s to say that a spreadsheet is the best way of delivering the right information? Contrast this user story with my first example, where the need was ‘to compare product features with customer complaints’. In that example, the best way to deliver the need is left open for solution designs and prototypes to figure out the best method, which may be some kind of data visualisation rather than a table.

Secondly, the ‘so that’ part refers to a non-specific activity rather than an action with a measurable outcome. Compare the second example ‘so that I can manage product specifications’, with the first example ‘so that I can shape future product specifications to maximise customer satisfaction’. By being clear about the required outcome – maximising customer satisfaction, we have something specific and relevant to target and measure benefits against.

In many cases, user stories have become such a commonplace stable of requirements analysis, that they have become just about filling in the columns. The true value in user stories, is that they should prompt the right questions to be asked, in order to capture how relevant a requirement is to the achievement of the business’s goals. In BI projects, strong user stories are a highly effective method of avoiding silos of irrelevant information which do not clearly identify purpose.

A final thought – sometimes, a good BI user story may seemingly contradict the importance of relevance, when the objective is justifiably about open-ended data discovery. So for example, ‘As a Retail Merchandiser, I need to compare weather data with product sales data, so that I can analyse how changes in the weather may be affecting product sales. In the words of Edgar Allan Poe, “Experience has shown, and a true philosophy will always show, that a vast, perhaps the larger, portion of truth arises from the seemingly irrelevant.” (From: The Mystery of Marie Rogêt)

To stay up to date with articles like this, sign up for our monthly newsletter!

You may also like…

Part 1: Results Before Reports

This is the first in a series of four articles about how to ensure that your BI efforts don’t just create reports and...


Submit a Comment

Your email address will not be published. Required fields are marked *