DEV Community

Cover image for Telling Clients the Truth About AI Timelines
Sonal Jain
Sonal Jain

Posted on

Telling Clients the Truth About AI Timelines

The most valuable thing a project manager does on an AI build isn't planning the work. It's telling the client the truth about it early, especially when the truth is "this will take longer than the demo suggested." Clients don't leave over honest bad news delivered on time. They leave over surprises delivered too late to act on.

I've delivered enough AI projects to know the technical risks are manageable. The relationship risk is the one that sinks engagements, and it's almost always a communication failure, not a code failure. Here's how I handle it.

Why AI makes expectation-setting harder

AI raises expectations before the first meeting. The client has seen a viral demo, maybe built something impressive in an afternoon with a chatbot, and walks in believing the hard version is nearly as fast. It isn't. A polished pilot can take weeks while the production system behind it takes months. If I let that gap sit unspoken, every honest update later sounds like an excuse.

So I set the frame at the start, in plain language: the demo proves the idea can work; getting it to work reliably, on your real data, inside your systems, every time, is the actual project. We put the same point sharply in The AI demo works. That's the problem. Saying it on day one isn't lowering ambition. It's the difference between a client who trusts my updates and one who reads them as backpedaling.

Deliver bad news on a schedule, not when cornered

The instinct under pressure is to wait, to hope the slip recovers before anyone asks. It almost never does, and waiting converts a manageable conversation into a crisis. My rule is simple: the client hears about a risk while there's still time to do something about it.

What that looks like in practice:

  • Flag risk early and specifically. Not "things are a bit tight." Instead: "The CRM integration is messier than scoped. That puts the date at risk by roughly a week. Here are two options."
  • Always bring options, not just problems. Cut scope, move the date, add a person, ship a smaller first version. A problem with choices attached is a decision. A problem alone is just anxiety I've handed the client.
  • Separate facts from forecasts. "This is what we know" and "this is what we expect" are different statements. Blurring them is how confidence quietly erodes.
  • Make the trade-offs theirs. It's their budget and their business. My job is to lay out the real choices clearly, not to make them in the dark and present a result.

This is also why I'm careful with accuracy and reliability targets. "More accurate" sounds like a quick promise and can be an open-ended one. I commit to a number against a test set, and I explain why I won't promise perfection: these systems are probabilistic, and a confident "100%" is a lie I'd have to walk back.

The honesty compounds

Here's the part that took me years to fully trust. Every time I deliver hard news early and well, the relationship gets stronger, not weaker. The client learns that when I say the date holds, it holds, because I'm the same person who told them when it didn't. That credibility is the most valuable asset on a project, and it's built entirely out of small, uncomfortable, on-time truths.

The opposite compounds too. One buried problem that surfaces at the deadline can cost you a client who would have happily accepted the same news three weeks earlier. The information was the same. The timing was everything.

Key takeaways

  • The biggest risk on an AI project is usually the relationship, and it fails through poor communication, not poor code.
  • Set the demo-versus-production frame on day one so honest updates later don't read as excuses.
  • Deliver bad news while the client can still act on it. Late truth becomes a crisis; early truth stays a decision.
  • Always bring options, separate facts from forecasts, and let the client own the trade-offs.
  • Commit to accuracy as a number against a test set, and refuse to promise perfection from a probabilistic system.

FAQ

When should I tell a client a project is slipping? The moment you're confident the risk is real and there's still time to respond. Early enough to choose a path beats waiting for certainty that arrives too late to matter.

How do I deliver bad news without losing the client? Pair it with options and a clear recommendation. Clients handle hard news well when you hand them choices and the information to decide. They handle it badly when it's a surprise with no way out.

Should I promise a specific accuracy figure for an AI feature? Promise a number tied to an agreed test set, never perfection. Explaining why 100% isn't realistic builds more trust than a confident figure you'll later have to retract.


If you've been burned by an AI project where the bad news always arrived too late, that's a delivery and communication problem worth fixing before the next one. The team at Shanti Infosoft builds software on honest timelines, and we're glad to talk through how we'd de-risk yours.

Top comments (0)