ML Development Isn’t Slow Because of Models. It’s Slow Because of Stakeholders

TL;DR: Most stalled ML projects aren’t stuck on modeling. They’re stuck on undefined success criteria, unclear ownership, and slow data access. Fix those first and timelines shrink.

A model that works in a notebook feels like the finish line. In reality it’s often where the real delay kicks in. The baseline beats the old heuristic, the metrics are all looking good and then the project just sits for weeks with no decision in sight whatsoever.

We tend to blame the technical side of things (messy data, GPU costs, the latest architecture etc). Those are very real problems and they’re the ones that are visible. The problems that are actually slowing you down are the ones that are less obvious, they're in the meeting invites, the vague requirements and the lack of clear ownership.

The Timeline Nobody Draws

Project plans are all neat little phases: data collection, training, evaluation, deployment. The real world timelines have a fifth phase which is absolutely there and which is just sitting there waiting.

Waiting for access to a database that's owned by another team. Waiting for legal to confirm that customer data can be used for training. Waiting for a product manager to confirm that 92% precision is good enough. None of that uses any computers. All of it uses calendar time.

This is also where outside help gets misjudged. Companies that bring in ML development services often expect the vendor to compress the modeling phase, and a good team can. But no vendor can approve your data access request or decide what “good” means for your business. If those decisions aren’t made internally, an external team waits longer, with a bigger invoice.

Modeling time is fairly predictable. Decision time isn’t, and it’s the part that quietly doubles a schedule.

“Just Make It More Accurate”

The most expensive sentence in ML is “just make it more accurate.”

Accuracy is a metric, not a target. There's no such thing as an accuracy 'target' without first agreeing on a threshold. Without a threshold you've got no finish line and every review therefore leads to a new request. Take a fraud detection model as an example. The data team will be optimising for recall as missing fraud is the expensive scenario. Support will be complaining about false positives as angry customers will be calling them. Finance will be watching chargeback losses. All three are absolutely correct and no-one has actually written down which of the trade-offs is the winner.

The model gets retrained again and again, each time chasing some other person’s definition of 'better'. The metrics don't budge at all as the disagreement isn’t a mathematical one.

The fix is pretty boring and pretty effective actually: a one page success definition prior to any training commencing. It needs to contain the metric, the threshold and the business cost of each type of error. “Catch at least 85% of fraud with false positives under 2%” is a good example of something a team can work towards. Get one named person to sign off on it, and then any subsequent changes are just scope changes with a proper discussion around time and cost.

Everyone Has a Stake, Nobody Has the Call

ML touches everyone. Data engineering own the pipelines, product own the feature, security own the compliance, ops own the deployment, and a VP owns the budget. Everyone has a stake in it, and that stake quietly becomes a veto for everyone.

A decision that ought to take a day gets passed through eight people over three weeks. No one is being difficult; everyone is just protecting something real. The problem is that without one person having the authority to say “we’re going with this", every open question remains open.

Name a single decision owner. All the others are consulted (they can raise issues and be heard), but they don’t co-decide. A quick test is to ask the team, “If we disagree tomorrow, who breaks the tie?” If you get three different answers, you’ve identified your bottleneck.

The Demo Trap

A good demo can actually do you harm. A walkthrough with ten perfectly chosen, clean examples will get you applause and will set the bar very high indeed, a bar the production system may never be able to meet.

Stakeholders see ten correct predictions and assume that’s the norm. Then the model comes up against real input (spelling mistakes, missing fields, all sorts of formats that no one ever thought of). Accuracy appears to fall, trust falls with it, and the team ends up spending weeks defending a model that hasn’t in any way actually deteriorated. The expectations were built on a very biased sample.

Demo on a random sample instead and include the failures. Show us five cases where the model gets it wrong and explain in plain English why. It's a bit of a risk to be upfront about the model's weaknesses but the people in the room who have actually seen the failure modes will go on to ask better questions and will be far less panicked when things go a bit wrong in production.

Data Access Is a Political Problem

On paper, getting the data is a technical exercise. In reality, the data resides in systems owned by teams who have their own agendas, and your request is just one item on their to-do list. Throw in privacy reviews and the occasional “who even owns this table?” and a two-day task can easily become a six-week one.

This is probably the most underrated delay in ML projects, as it doesn’t appear to be any kind of work at all. There’s no coding to do, no debugging to perform, just a ticket sitting in the backlog as the momentum dies away.

Treat data access as the critical path and get on with it from day one in parallel with scoping. Get a small approved sample first so the engineers can build whilst the full request is going through review. Treat it as a feature with an owner and a due date.

Habits That Shorten Timelines

Beyond fixing individual problems, a few habits help more than any tooling change:

Replace status meetings with decision reviews: A weekly 30-minute session with one agenda item, “what’s blocked and who decides?”, beats an hour of updates.
Keep a decision log: One shared document with the date, the decision, and the owner. It stops old debates from resurfacing and makes onboarding easier.
Time-box feedback: Give stakeholders a clear window, say three business days. No objection means the default proceeds.
Get an outside view early: Some teams run a short round of AI consulting before kickoff to pressure-test scope, data readiness, and ownership. A strong internal lead can do the same, but an outsider often surfaces unspoken assumptions faster than another internal meeting.

A Pre-Kickoff Checklist

Before the next project starts, see whether you can answer these in one sitting:

Can we describe success in one sentence, with a number?
Who is the single decision owner?
Has data access been requested, and by whom?
Who approves the production release?
When the model is wrong, who is accountable?
How will we measure business impact after launch, not just accuracy?

If more than two get a shrug, the biggest risk isn’t technical. Spend the first week fixing that.

The Model Is the Easy Part

A model can be retrained overnight. A misaligned org takes months. That's why the projects always seem to be moving so slowly even when the engineering is actually progressing.

The technical bits we're already comfortable with (version control, experiments, benchmarks, etc.) are the easy part. The human side of things needs the same level of discipline: written definitions, named owners, clear-cut deadlines. Prior to your next kickoff, just take 10 minutes to write down what “done” means and who gets to call it done. It's a very small amount of effort and could save you a quarter.

What’s the longest you’ve ever waited on a non-technical blocker? Let me know in the comments.

Frequently Asked Questions (FAQs)

1. Why do ML projects take longer than anticipated?

Mainly due to non-technical delays: murky success criteria, slow data access approvals and just too many people in the decision-making process. Training is generally the smallest part of the time.

2. How long does a typical ML project take?

It varies enormously depending on the data readiness and the scope. A focused Poc can be done in a matter of weeks. A full-blown production system with all the compliance reviews and integrations will take many months. The biggest swing is in the speed of decision-making.

3. What should a success definition for an ML project contain?

The metric, the target threshold, and the business cost of each error type all on one page and signed off by one owner. It needs to be specific enough to tell you when you've got enough.

4. Who should own the decisions in an ML project?

One named decision owner (typically a product or program lead), with the other stakeholders being consulted rather than co-deciding. Security, legal and data teams all provide input, but it's one person who ultimately breaks the tie.