The 60:40 rule: Why analytics projects succeed or fail on adoption

Most analytics projects are judged by the same yardstick as any other piece of work: was it finished, on time and on budget? The dashboard is live, the tracking is fixed, the data flows. Project complete.

And yet many businesses have dashboards nobody opens, reports nobody reads, and data that marketing teams quietly work around rather than rely on. So what did they actually get for the investment?

The problem is rarely that the technical work was done badly. It's that the technical work is only part of the job, and the smaller part at that.

The 60:40 split: delivery is the smaller part of the job

Much of our work has been spent consulting on growth - helping businesses grow faster, more efficiently and more effectively. One lesson stands out from that experience.

You can produce excellent recommendations and well-engineered solutions, but unless they are taken up and implemented, you haven't been very effective. The job is to effect change as much as it is to come up with the answer. And effecting change is the harder part, needing a different set of skills and a different approach.

That is the idea behind what we call the 60:40 split:

• 40% is the technical delivery - the data collection, processing, infrastructure, dashboards and fixes.
• 60% is the people work - the engagement, change and adoption that determine whether the output is trusted and used.

The numbers are a rule of thumb, not a formula. Nobody should be timesheeting against them. The point is the weighting: the work that makes an analytics project succeed is mostly not technical.

In other words:

An analytics project isn't finished when the data is right. It's finished when the data is used.

Why on time and on budget is not the same as success

There is nothing wrong with judging a project on its deliverables. Completing the agreed scope, on time and on budget, matters. It is a fair test of whether the work was managed well.

But it is not a test of whether the work was worthwhile.

The objective of analytics is not to produce data. It is to enable better decisions. That only happens when people use the data to generate meaningful insight. The causal chain looks something like this:

Delivery → Adoption → Insight → Better decisions

Most project reporting stops at the first step. The value sits at the last.

So the real measure of an analytics project is a change in behaviour. When the 60% is done well, the business either:

• Starts using data it previously ignored or didn't have.
• Uses it more, making it part of everyday decisions rather than occasional reporting.
• Uses it better, asking sharper questions and acting on what it finds.

If none of those things happen, the project may have been delivered. It has not succeeded.

Why data projects struggle to gain traction

If adoption matters this much, why is it so often neglected? In our experience, data and analytics projects face three structural barriers that most other projects don't.

• Nobody owns it. It is unusual for a business to have a budget specifically for data and analytics, so projects often lack an internal sponsor. Everyone wants the outcome of better data, but it isn't their problem, or their expertise, to own and fix.
• It is largely invisible. Where data already exists but is inaccurate or unreliable, most of the work to fix it happens out of sight. Few people outside the project have any idea what was involved, which makes it hard to build momentum or recognition.
• It is complex and technical. There are hundreds of marketing platforms, so almost every business runs a unique combination. The underlying challenges are similar, but there is no off-the-shelf solution. Each one means understanding the specific circumstances and choosing from the options available. That complexity is unavoidable, and it is off-putting to large parts of the business.

None of these barriers is solved by better engineering. Each one is a people problem: ownership, visibility and understanding. That is why the 60% has to be planned for, not left to chance.

Start the people work before the technical work

The instinct on many data projects is to get the technical foundations right first and bring people in once there is something to show. We think that gets the order wrong. Engagement needs to start at the beginning, for two reasons.

The first is ownership. We consistently find that people who are involved early are more engaged with the outcome. There is probably some simple psychology at work: when people feel they have contributed, they feel a degree of ownership over the result. A dashboard someone helped shape is one they are far more likely to open.

The second is better decisions within the project itself. It is very easy to make all of the data available to end users - every metric, every segment, every dimension. It feels thorough. In practice, it usually produces something overwhelming and underused.

Slimming the data down to what is genuinely useful and relevant delivers a better outcome. One that is more usable, and therefore more likely to be used.

That can only be done well if you understand what people across the business actually need. Involving them early lets you:

• Cut what nobody will use, making the project more efficient.
• Build what is needed, rather than your assumption of what is needed.
• Surface the questions people are already trying to answer, so the output fits how they work.

A practical roadmap for driving and maintaining engagement

The short answer to keeping people engaged is simple: share information and keep people actively involved. In practice, we build five touchpoints into every analytics project.

1. Discovery workshop - Find out what matters to people and teams.
• How are they using data today?
• What data do they wish they had but don't?
• What are they regularly reporting on?
• How are they, and their department, measured - what counts as marketing success?
2. Sharing the plan - Feed back what we have understood.
• Share the plan and what the project will deliver.
• Crucially, explain why it is being undertaken, not just what.
3. First draft and QA testing - Where relevant, put an early version in front of a small group of future users.
• Ask them to use it for real-world scenarios.
• Use their feedback to refine it before wider launch.
4. Launch and socialising - Share the final output with the wider team, whether that is a dashboard, new data sets or the results of an audit.
• Explain what is new and how it affects their day-to-day.
• Be specific: what does this give them that they didn't have before, and how should they use it in their role?
5. Follow-up - Check in with end users after launch. Our rule of thumb is four weeks.
• Gather feedback once people have lived with the output for a while.
• Evaluate actual uptake, because the project only succeeds if what we delivered is being used.

The last step is the one most often skipped, and arguably the most important. It is the point at which you stop assuming adoption and start measuring it.

Fixing the data is not the same as restoring trust

A current project illustrates the point well.

We are working with a client who has a data quality problem. Several known issues mean their marketing data isn't trusted. Because it isn't trusted, it isn't fully used to make marketing decisions.

At a basic level, our job is to fix those issues and return the data to accuracy. That is the 40%, and it has to be done properly.

But if that is all we do, very little changes. Correct data does nothing on its own to restore confidence in it. In our experience, without rebuilding that trust, the business would carry on as before - marketing still not using the data, or using it only marginally more.

So success on this project is defined by more than the technical fixes to data collection and processing. It is defined by a change in how the data is used. The technical fixes are our first task, not the only one.

This is the 60:40 split in practice. The technical work is necessary, but it is not sufficient. It earns you the right to change behaviour; it doesn't change behaviour by itself.

Conclusion: measure analytics by what it changes

Getting the technical side of an analytics project right is essential. But it is the 40%. The value of the work is decided by the 60% - whether people understand it, trust it and use it.

That means treating engagement as part of the project, not an afterthought. It starts at discovery, continues through testing and launch, and is checked weeks after delivery, when the real test of adoption begins.

When you plan for the 60% from day one, three things happen:

• The output becomes more focused, because it is built around what people actually need.
• Adoption becomes something you plan for and measure, rather than something you hope for.
• And the business gets what it really invested in: not just better data, but better decisions.

That is what a successful analytics project should deliver.