The building blocks of all quantitative KPIs and performance measures are data items. Define them well enough so your KPIs are not rendered useless.

The data management body of knowledge is very complex and conceptual, to much so for me to fully get my head around. It’s a world best navigated by Data Management Professionals. But that doesn’t mean we, as performance measurement practitioners, should bury our heads in the sand and hope someone else sorts out our KPI (or performance measure) data requirements.

If we don’t clearly articulate the data items our KPIs need, we will end up with the wrong KPI being implemented. Someone else will make assumptions about what the KPI means, what data is available, and
consequently how it will be calculated. We own the KPI; we own the responsibility of it being implemented as intended.

Despite the complexity of the data management world, we can easily get to a point of articulating the data we need, in a way that our data professionals can translate into technical requirements. To get to this point, we need a good understanding of four simple concepts:

1. Performance measures only get their values from quantitative calculations.
2. Performance measure calculations are statistical summaries of raw data.
3. A performance measure’s raw data is described using data items.
4. Performance measure data items have definitions too.

Let’s get into it…

Performance measures only get their values from quantitative calculations.

Performance measures are quantifications of the direct evidence of a performance result we want to monitor, at regular time periods. To be quantitative, a performance measure needs a mathematical, or statistical, formula.

The formula of a KPI describes how raw data will be summarised into values for each time period. Raw data is what we collect in our business processes. For example, raw data could be:

• a customer’s satisfaction rating from the latest survey
• the revenue received from a particular sale
• the cost of last month’s electricity bill
• the start date and end date of an employee’s tenure

Each performance measure needs raw data for three parts of it’s calculation:

1. the formula to compute the values, such as customer satisfaction ratings
2. a time period within which the values are computed, such as monthly
3. a scope factor to segment or filter the population to which the measure relates, such as active customers

Sometimes a performance measure’s values are calculated from one or more other measures (like how EBIT is calculated from revenue, cost of goods sold, and operating expenditure). But at it’s foundation, each performance measure value is calculated by summarising one or more different items of raw data.

Performance measure calculations are statistical summaries of raw data.

We quantitatively summarise raw data using statistical processes such as a count, sum, percentage, or average. Every performance measure has a calculation frequency, meaning its values will be calculated in specific time periods, like monthly or weekly.

The statistical processes, therefore, will apply only to the raw data collected during each specific time period. To calculate a monthly performance measure of rework, only the raw data on how much rework was done in the month is used for that month’s calculation.

Of course, which statistic we choose depends on our measure’s design, the one that best answers the question the measure should answer. If we want, for example, to track how much engagement our employees have, a percentage won’t be anywhere near as useful as an average. The percentage tells us how much of our workforce has some level of engagement. But the average tells us how much engagement there is.

A performance measure’s raw data is described using data items.

The raw data we summarise for our performance measures comes from repositories where the data is stored. No doubt, your organisation has some kind of database where it stores raw data about expenses, such as payment dates, amounts paid, expense types, supplier names, and so on.

Each type of raw data is a field in a table in that database. In PuMP, we call these fields ‘data items’. For example:

• in a Customer Satisfaction table, there is a data field called ‘Overall Satisfaction Rating’
• in a Sales table, there is a data field called ‘Amount Received’
• in an Expenses table, there is a data field called ‘Amount Paid’, a data field called ‘Expense Type’, and so on
• in an Employee Tenure table, there is a data field called ‘Employment Start Date’ and a field called ‘Employment End Date’

When we define the data requirements for a performance measure, we need to find out the correct field name and table name. For a performance measure called Electricity Spend, calculated monthly, the calculation might be written like this:

Sum of (Amount Paid), by (Payment Date) formatted as ‘mm/yyyy’, where (Expense Type) = ‘Electricity’

There will be more than one way to write any measure’s formula. That’s not a problem, so long as we write it clearly enough that anyone can understand what we’re trying to achieve.

But it doesn’t end there. It’s also important, as we begin to implement our measures, that we understand a little bit more about the specifics of how our data items are, or should be, defined. This matters in two situations:

1. when we need to find the best data for a measure
2. when we need to create new data for a measure

Performance measure data items have definitions too.

Imagine if we discovered our measure of Delivery Cycle Time was computed from dates based on days, but we wanted to pick up changes in the measure as little as a few hours. Or our measure of Customer Lifetime Spend was calculated from data where lots of customers have several different customer identification codes, that get counted as though they were separate customers.

These problems stem from the data items not being set up to match the requirements of our measures. For this reason, it helps to be aware of five specific parts of a data item’s definition:

1. Name – so our measure definition refers to the correct data item.
2. Description – to be sure that the data item is about what we think it’s about. For example, ‘Amount Paid’ might be different to the ‘Invoice Amount’, because it’s the invoice amount less any credit that might have existed.
3. Format – to make sure the units of the data match the intended units for our measure. For example, we might need ‘Amount Paid’ to be in Australian dollars, ‘Employment Start Date’ to be a date-time value like yyyy-mm-dd, and ‘Overall Satisfaction Rating’ to be an integer.
4. Valid value ranges – to make it easier to identify data errors and fix them before our measure values are calculated. For example, ‘Overall Satisfaction Rating’ may only take the values from 0 to 10 and ‘Employment End Date’ may not be a value in the future.
5. Standardisation – so it is possible to link data between datasets or tables or databases, where our measure is computed from several data items collected in different places.

It’s these five things we need to have conversations about, with our data management professionals. It’s only through these conversations – merging our business requirements and their technical requirements – that we can be confident the right measures are being implemented in the right ways.

Data items are the building blocks of KPIs. If we fail to clearly define them, the KPIs fall apart.
[tweet this]