Analytics Adoption is Decided Before the Build

A project that did everything right

An operator running distributed sites, each with a local manager controlling shift patterns. The leadership team believed that the overtime costs were creeping up and that the shifts could be better optimised to cover part of that extra work, which would reduce overtime and improve the operating margin.

The solution to verify this assumption was to define a list of metrics that could be tracked in a dashboard, and in the same process overhaul the data platform with a solution that would allow them to leverage better analytics and AI.

A business owner was named and was responsible for working with the local managers to identify and define the correct metrics, and with IT and my team in building the analytics layer. The project went through a POC, then design and implementation of an MVP with iterations with the local managers to validate the KPIs.

The project was delivered and the platform was set up, with data flowing through the medallion layers and landing in a dashboard that was shared with the local managers.

The assumption was verified, but the local managers were not using the dashboard as the business was expecting and the adoption was low.

The finding and what followed it

The business followed the textbook in their approach to the problem: the numbers showed the overtime costs as high, so they identified a business owner and allocated them a budget to verify the assumption and fix the overtime costs.

On paper the approach looked correct. A business owner owned the problem and the project from the business perspective and acted like it: they involved the local managers in defining the KPIs, and iterated over mockups and draft dashboards to agree on what to show, as well as involving the data team and IT for the design, finalisation of the requirements and the build. Finally, when the dashboard was ready, they released it to the local managers with training.

After going through the graphs and numbers, the assumption held. The overtime cost was indeed high and the analysis showed why: the shifts were not fully utilised, and optimising them would reduce the overtime paid.

When the dashboard was released, the business found out that no actions were taken to rework the shifts and reduce the overtime. The data told them where to look; nobody looked.

The reality is that the local managers had no objective to reduce the overtime costs or improve the operating margin, so the dashboard and the data it held were an additional task on their shoulders that they were not incentivised to carry.

Where adoption followed

In an organisation operating under external regulatory pressure, the board had committed to two service-performance measures that the whole business was held to. Any new project had to fall under one or both metrics and improve on them. At the same time, the work was commissioned against the metrics that the board had committed to.

An MVP gave the business a more up-to-date view of their main activity in a real-time dashboard and helped them identify where delays happened and how to rectify them, which improved the first metric. The second use case tackled the assignment of the business activities to the workers handling them in an automated way to land on the final assignment, which improved the second metric.

Adoption was high as the targets already existed and someone was already accountable for them before the analytics discussion even started. The business watched delays surface and intervened while there was still time to recover them.

In another use case, we worked with a finance team and an operations team to create an analytics solution that allowed them to have one place where they could see their revenue, all the charges by category (employees, costs of goods, fixed costs) and their margin, alongside their financial budgets and forecasts across the business. The novelty in this project was that the metrics were not just historical, but forward facing and forecasted for every KPI and every line of business.

This mattered as the CFO and the finance team had committed numbers to forecast against and compare with. The same view without a budget behind it would have been a description of the future rather than a prompt to act.

They had a full year view until December with all their actual and predicted figures for every metric alongside their budget and forecasts, which showed where they would land. Based on that, the dashboard helped them take clear and targeted actions either on the costs to reduce or ways to drive more revenue, which allowed them to meet their financial forecasts and budgets and sometimes overdeliver.

In both use cases, the analytics were not seen as a burden, but a catalyst for their activities to meet the targets set by the leadership team, with clear actions derived from the metrics. In the case that failed, the analytics were commissioned to test an assumption, while in the cases where it succeeded the projects were commissioned against measures that were already in place and committed to. Across the work I’ve done, I have not seen an analytics project succeed where no business target existed and no one in the business was accountable for it.

What has to be true before the build

Two things separated those projects from the one that failed, and neither of them was in the build.

The first is that the outcomes of these analytics projects fall under measures and targets that are already set by the leadership team. These measures are either financial or operational, such as revenue increase, reduction of costs or an improvement in performance.

The second is that business actors who are measured and accountable for those metrics need to carry the targets. The business actor who owns the measures and acts on them is fundamentally different from the business owner that is named by the business to advance the project. In the failed case, a business owner was named, they were senior and engaged, but the local managers who would have to change the shifts had no targets of their own, and nothing happened.

These prerequisites should form a business gate for analytics projects that are planned to be released to business users. This gate has to be owned by the C-level that wants the project commissioned and by extension owns the budget assigned to it. There is an obvious weakness to this gate: the decision-maker is the person who wants the project built, but this is more a discipline than a control. Its force is that the same person owns the cost: a project that does not meet these prerequisites will not be used, and the budget spent on it is lost.

When these prerequisites are met, the C-level member can authorise the project and it moves into delivery. From there, the business actor will work with the data and analytics team to identify the right metrics, define them clearly, and clarify the actions that should be taken based on how the numbers move in the dashboards. Together, they can identify the right data technique dictated by the actions required.

A C-level sponsor can always help with business, budget and project prioritisation and logistics, but the right business actor is indispensable to the success of analytics projects.

When there is nothing to build

Without a target already set and a business actor carrying it, the analytics project will not be used and the money and effort will be wasted. So if the gate is not passed, the project should not be built: not deferred, not rescoped, not started while someone goes looking for a target. From a business point of view, there is nothing that needs to be built.

The work to do first is setting the targets and putting them with the people who need to act on them. That is not analytics work, which is why it gets skipped: no data team can do it on the business’s behalf.

Where the prerequisites are met, adoption stops being the problem you have to solve. It follows from the work rather than having to be engineered on top of it.