Part 2: Measure What Matters
Measure what matters

Written by: Phil Husbands

My core interests and specialist expertise are in enterprise data strategy, data capability development and data-driven organisational change. My work focuses on building the operational and people-focused capabilities, which are essential for ensuring that data enables businesses to work more effectively, make better decisions and achieve their goals.

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. Generate truly beneficial outcomes for your business and measure what matters.

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. They 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 on what they mean. Also 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 occurs 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? 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. This 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. 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. 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)

If you found this interesting, it would be great to discuss your thoughts! Click here to contact us!

Alternatively, you can book some time with me here!

I look forward to speaking to you!


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

You may also like…

Know What? So What? Now What?

Know What? So What? Now What?

Know What? So What? Now What? "Why do we have so many dashboards that so few people actually use? Why is it so hard to...

0 Comments

Submit a Comment

Your email address will not be published.