Big Data & Data Visualisation

When talking to people about data related projects I have started noticing that it doesn’t take long to get on to the topic of Big Data. It’s a subject that is getting a lot of press at the moment so that’s not too surprising.

The thing that I am finding surprising is that few of those I have been talking to make the connection between Big Data and Data Visualisation. To them the talk is all about the “Three V’s” (Velocity, Variety and Volume) that define big data. My question, once we have covered the ground of how do we cater for and handle the three V’s, is what about the fourth V, Visualisation?

From where I stand it’s all well and good being able to stuff data into a cleverly designed warehouse at an ever increasing rate. But what is the point in that if all you do is pull it out in static, flat one dimensional reports? To make the data really useful and come alive you really need to make it tell a story in a dynamic and visually appealing way. The message you are trying to convey should jump off the screen at the user and at the same time lead them to zero in on the the good AND the bad news.

These days there are an increasing number of tools that allow you to this with varying degrees of flexibility, complexity, functionality and naturally cost. All you have to do is think about how to make it easy for people to get at the information they need through the overwhelming volumes of data (to them) that is available.

The Trouble with Metrics

Over the years I have worked on a number of back office system projects. Typically they projects are aimed at delivering either cost savings or performance improvements (or optimistically both). Naturally management are eager to monitor and calculate how much of each is achieved. To that end they look to set up a number of measurements that will show the level of uptake, throughput, cost per unit etc.

When the system is designed to make it easier for someone to do their job you would expect that their productivity would increase… Makes sense right? But it’s not alway the case. For example implementing a system that makes it easier for a sales rep to capture the client details, record conversations and track follow up actions will only increase the productivity of the rep if their job doesn’t require them to meet the client face to face. It would be pointless therefore trying to measure the benefit of the new system and the performance of the rep on the basis of the number of phone calls the rep makes each day. If you do then the result of that will be to encourage sales reps to sit at a desk and make phone calls. Not a good result when what you really want from them is to be generating new sales and building relationships with clients so that they become repeat customers.

Therein likes the problem with metrics… Get them right and they will be able to tell you a story of how your business is performing, identify areas for improvement and highlight those activities that are contributing to good performance. Get them wrong and they have the unintended consequence of influencing peoples behaviour toward irrelevant tasks that should not be their focus.

A classic example of this is the UK government target that no patient should wait more than 2 days to see a doctor. The result… When you ring up to make an appointment many doctors won’t allow you to make an appointment that is more than 2 days in the future as it will distort their statistics. Additionally if there are no appointments available you have to ring back the next day in order to make an appointment for 2 days in the future (rinse and repeat until you get in early enough to beat the rush). They do this as the government is not interested in how many people are unable to make an appointment on their first, second, third (or more) attempt. But I’m almost certain this was not the behaviour that the government was trying to encourage. It’s just the unintended consequence of a poorly thought out and defined metric.

So when determining what metrics should be used to measure performance, you must determine (either for yourself or your client/customer):

  1. is the metric relevant (to the job and/or system)
  2. what behaviour is use of the metric likely to encourage (and is that what you want to happen)
  3. is the information the metric conveys actionable
  4. what are you going to do with the information

If the answer to any of the above is negative then it’s probably not the right metric to be using. On the bright side though, being able to identify this will make you look good and help avoid some of the post implementation pitfalls that beset many projects.