The date passed and the answer was "another two weeks". That answer has now been given twice. The instinct is to escalate, add people or demand a recovery plan, and all three usually make it worse. The first week should be spent establishing what is actually true, because the gap between reported progress and working software is the real problem and nobody has measured it yet. Sorting that out is often the first thing our delivery advisory team is asked to do.
01Ask for a demo, not a status report
A status report is a claim. A running system is evidence. Ask to see the feature working end to end, in an environment you can reach, driven by someone other than the developer who built it. The difference between "90% complete" and a working demo is where late projects hide.
If the demo cannot happen this week, that is the finding. It usually means the parts exist but have never been assembled, which is a substantially different position from the one the status report describes and it changes every estimate that follows.
02Separate the three reasons projects run late
Scope growth, estimation error and execution problems look identical from the outside and need opposite responses. Treating an estimation error as an execution problem - by adding pressure - reliably produces worse software and the same date.
Work out which one you have before deciding anything. The evidence is in the change history: compare what was agreed at the start with what is being built now, and count how much of the difference was requested by your own side.
| Cause | What you will see | What actually helps |
|---|---|---|
| Scope growth | Requests accepted without date changes | Freeze scope, re-baseline the date |
| Estimation error | Every task takes 2-3x its estimate | Re-estimate from measured velocity |
| Execution problems | Work completes then fails in test | Fix quality practices before adding scope |
| Dependency stalls | Blocked on your team's decisions | Clear the decisions, they are yours |
| Team churn | New names on the calls each month | Ask who is actually assigned, and for how long |
03Adding people makes it later, with one exception
New engineers need context before they produce anything, and the people providing that context are the ones currently delivering. On a project already behind, this trade is usually negative for the first month or more.
The exception is a genuinely parallel workstream with a clean boundary - a separate service, a distinct integration - that a new person can own without needing the history. If the work cannot be described that way, adding people is a cost with no matching benefit.
04Get the code and the credentials now
Whatever happens next, you need to be able to walk. That means source control you own, deployment credentials you hold, and a documented path to build and run the system without the vendor present. Ask for it as routine practice rather than as a threat, and note the response carefully.
A vendor who is delivering hands this over without friction because it costs them nothing. Resistance here is the single strongest predictor that the relationship needs to end, and it is much cheaper to discover now than during a dispute.
- Confirm you are the owner of the repository, not a collaborator on theirs.
- Hold the cloud accounts yourself and grant access, rather than the reverse.
- Get a build from a clean machine documented and tested by someone on your side.
- Check that the domains, certificates and DNS are registered to you.
05Decide what you are optimising for
Rescue, replace and renegotiate are different objectives with different costs, and trying to keep all three open is how organisations spend another quarter deciding. Pick one within two weeks of the missed date.
Replacement is more expensive than it looks when the codebase is undocumented, and cheaper than it looks when the code is small and the vendor relationship has stopped working. The deciding factor is usually how much of the system a new team would need to understand before shipping anything, and that is a question you can answer in a few days of review.
Topics
Aarav Patel
Principal Engineer · SyncTrix
Writes about the engineering decisions behind production systems - architecture, delivery and the trade-offs that only show up at scale.
Building something like this?
SyncTrix engineers AI, SaaS, platform and cloud systems for enterprises and high-growth teams. Tell us what you're shipping and we'll scope it with you.