How to Turnaround a Data Project

There are many ways of finding out a customer is not only complaining but also genuinely unsatisfied with your services. The tricky part is that by the time the complaint becomes explicit, the relationship is already damaged. A good lead should be able to sense dissatisfaction earlier than that — reading customer behaviour, understanding what they actually expected, and honestly assessing how far reality has drifted from those expectations.

Start with customer experience, not the customer

The first move as a technical leader, before approaching the customer directly, is to talk to whoever owns the customer relationship on your side. Account management, customer success, sales — whoever has been in regular contact. Go in with genuine curiosity, not defensiveness.

What you want to understand:

• What the customer originally signed up for — the stated goals, the success criteria, the implicit promises made during the sales process.
• What has changed — in their business, their team, their priorities, or their understanding of the problem.
• What they have been saying — in calls, in emails, in passing. Complaints about timelines are often proxies for something deeper.

This conversation is not about building a case for yourself. It is about getting an accurate picture of the gap between what the customer expected and what they are experiencing. You cannot close a gap you have not measured.

Diagnose before you prescribe

Once you have context from the relationship side, it is time to look at the actual work. Most troubled data projects fail for one of three reasons:

1. Misaligned scope — the team built what was asked, not what was needed. The requirements were interpreted too literally, or they drifted over time without formal acknowledgement.
2. Trust deficit — deliverables have been late, incorrect, or poorly communicated. The customer no longer believes the team will deliver.
3. Invisible progress — the work is actually going well, but the customer cannot see it. This is more common than it sounds, especially in infrastructure-heavy projects.

Each of these requires a different response. Prescribing a new sprint plan will not fix a trust deficit. Improving your demos will not fix a scope problem.

The direct conversation

At some point you need to sit down with the customer and have an honest conversation. Not a status update — a real conversation about whether the engagement is working.

Come prepared with your own assessment of where things stand. Customers respect leaders who can say “here is what I think went wrong and here is what I propose we do differently” far more than those who deflect or over-promise.

A few principles for that conversation:

• Acknowledge specifically, not generically. “We know things have been difficult” is noise. “The pipeline rework we committed to in January is still not in production, and I understand why that is frustrating” is signal.
• Do not bring solutions before you understand the problem. Ask what success looks like from their side before pitching a recovery plan.
• Be realistic about what is fixable. A turnaround is possible in most cases. A full reversal of a six-month trust deficit in two weeks is not. Set honest expectations.

The recovery plan

A good turnaround plan is short, concrete, and verifiable. It should answer three questions:

1. What will be different going forward?
2. How will the customer know it is working?
3. What happens if it is not?

Avoid the temptation to pad the plan with reassurances. Customers in this state have heard enough words. What they need is evidence — small, consistent, visible proof that things are changing. Identify the smallest meaningful deliverable you can ship in the shortest honest timeline, and ship it cleanly.

Momentum matters more than ambition at this stage.

When to call it

Not every project can or should be saved. If the customer’s expectations were structurally unachievable from the start, or if the relationship has broken down beyond repair, the right move is to say so — professionally, clearly, and early enough that both sides can exit on reasonable terms.

Dragging out an engagement that cannot succeed wastes everyone’s time and, more importantly, leaves the customer worse off. That is not a trade-off worth making to preserve short-term revenue.

Turning around a data project is mostly a people problem wearing a technical costume. The code matters, but what usually needs fixing first is the conversation.