What We Do When a Project Goes Wrong
Last updated:
Projects slip. The question is what happens next
Any supplier claiming they have never had a project go wrong is either new or not telling you the truth. Third-party APIs turn out to be undocumented, data migrations reveal fifteen years of inconsistency, a requirement means two different things to two departments.
What separates suppliers is not whether it happens. It is when you find out and who pays.
The rule: immediately, in writing, with options
The moment we know a date is at risk, you know. Not at the milestone, not at the next scheduled call — that day, in writing, with the cause and at least two options.
- What has happened, specifically
- What it means for the date and the price
- Two or three options, with the trade-off in each
- What we recommend and why
- What we need from you to proceed
The most damaging thing a supplier can do is hope. A fortnight of hoping the schedule recovers removes every option you had at the start of it.
Who pays
| Cause | Who absorbs it |
|---|---|
| We underestimated | Us |
| We misunderstood a requirement | Us |
| A documented assumption was wrong | Discussed — usually shared |
| Scope grew | You, priced and agreed in advance |
| A third party changed something | Discussed; we absorb small, price large |
| Client-side delay | Timeline moves, cost usually unchanged |
The first two rows are the ones that matter. A fixed price means fixed, and an estimate being wrong is our risk to carry — that is what you paid the fixed-price premium for.
The three failures we see most
- Data worse than described. The most common by a distance. We flag it in week one where we can, which is why we ask for real data early.
- A third-party system that does not do what its documentation says. Discovered on contact with reality.
- A requirement that meant two things. Two departments agreed on a sentence and disagreed on what it meant.
When it is not recoverable
Occasionally a project should stop. The business case has changed, the sponsor has left, or the technical finding makes it uneconomic.
We would rather say that than take a budget to complete something we no longer believe in. In that situation we stop, hand over everything produced so far, and invoice for work delivered rather than for the contract value. It has happened twice and both clients came back with different projects.
What we ask of you
- Tell us early if something has changed on your side — funding, priorities, people
- Escalate to us before escalating internally, so we can bring options
- Say when you are unhappy, plainly; hints get missed across a distributed team
- Hold us to the written record rather than to remembered conversations
Frequently asked questions
How often do your projects run late?
What if we lose confidence in the team?
Do you have a formal escalation process?
What if we disagree about who caused a problem?
Want a fixed price you can budget against?
Tell us what the process looks like today. Scoping is free, the specification is yours either way, and the price we quote is the price you pay.
Related services
What we build for problems like this one