So, you've made a sophisticated data pipeline. Now your data automatically flows from various databases, is seamlessly combined and transformed, quality is guaranteed, all processes are documented, versions are controlled and the rich, structured data is presented in a beautiful visualisation interface.

It's a great achievement and something to be rightfully proud of.

The only issue you have is that nobody is using it…

Data with a purpose

In order for data to be used, there needs to be a business issue that it can help solve. This can be finding a solution to a performance problem, a question on how to improve, or a need to better understand how something works.

These issues don’t originate from the data management process – they come from managers, typically in /review meetings/ – where people come together to discuss problems or search for opportunities.

Bad review meetings

But how many review meetings have you been in that have just felt like a complete waste of time?

An issue has been identified, but people spend time debating what the issue is:

“actually, I think the cause is…” “Is this really an issue?”

If supporting data is available, people argue over the definition

“I have a different number!”

or the veracity

“I don’t trust these numbers!”

and conclusions are not reached

“Given the time, let’s offline this topic”

These meetings are often attended by multiple senior managers, meaning they can easily cost an organisation thens of thousands of euros in employee time – not to mention the stress and exasperation generated for the people attending the debate that gets nothing done.

However, it is possible to get results from these meetings while making them efficient, productive and enjoyable for the people attending – by using data.

Better reviews with data

First, review meetings need structure – they should happen at regular intervals with the same group of people and the same agenda.

On the agenda should be time to review performance metrics. Which metrics? Start with a small selection of a few metrics that are commonly tracked (don’t start with a long shopping list of numbers – it will lead to confusion).

The important thing is that the performance metrics must come from your high-quality data system. They should be documented, quality controlled and versioned. There should be appropriate comparison data (targets, historicals) and they should be presented in a way that is easy for everyone to read.

In the review, look at the performance metrics and identify where performance needs to be improved. Perhaps a number is below a planned target, or worse than historical performance, or just subjectively low compared to what you would expect to see.

If the data is high quality and the definition is clearly documented for people in the meeting to see (including source, transformations applied, scope, units, accuracy etc.), then there is no need to argue about definition or veracity, and we can get down to planning actions.

Actions

An action in a review meeting should take one of two forms:

1. The data is understood and a potential cause is known – here the action can be to do something that should cause the metric to change value (i.e. out a business action in place)
2. The data is not fully understood or the cause is unknown – the action should be to task for an analyst with further investigate the data and report back to the next meeting.

In the second case, the meeting must not be allowed to spend time debating and theorising the cause and the form of the underlying data. This is not a time to break out the self-service BI tools and start analysing data in a meeting!

Instead, an analyst (i.e., someone who is proficient in data management, understands the underlying data as well as the business context) will be able to quickly and efficiently elucidate what is going on.

Review the actions!

However, the most important thing about actions is that they are reviewed in the next meeting – this requires strong meeting agenda control by the facilitator (chair, secretary, lead etc.).

Each due action needs to be looked at – where business actions have been completed, metrics should be reviewed to see if they have had the desired effect and if not, different actions should be taken.

For analyst actions, the metrics should be reviewed again in light of the new information and decisions made on taking further (business) actions. Analyst actions may show that reviewing a different metric would be better. This way, the metrics the meeting look at can be iterated, which is typically more successful than creating a large and confusing “shopping list” of metrics for a scorecard up front (see above)

If actions have not been completed, the reasons need to be addressed (resource, time, prioritisation etc.) to ensure they can be completed in a timely manner.

Iterate and Archive

The key to review meeting success is consistency – running the meeting in a structured way, many times, consistently taking and reviewing actions and iterating the metrics being used.

As meetings evolve, there will be metrics that are regularly not looked at because they are either no longer relevant or others have superseded them. These metrics should be archived or hidden into separate views to keep the meeting efficient.

If you have built a structured data pipeline system, you could apply automated analytics to highlight significant deviations in archived/hidden metrics, so that can be re-surfaced for action if a situation changes.