The launch was supposed to be this Friday. On Wednesday you get a message: "We need two more weeks." Then, two weeks later, another message.
Late software is so common that researchers have measured how late. In a study of 1,471 IT projects published in Harvard Business Review, Bent Flyvbjerg and Alexander Budzier found that one in six was a "black swan," with a cost overrun of 200% on average and a schedule overrun of almost 70% (Flyvbjerg and Budzier, Harvard Business Review, 2011). Your project being late does not make it one of those. It does mean you should act this week rather than wait.
Key Takeaways
- A first slip is common. A second slip without a new plan is a warning sign.
- Ask for what is done, what is left, and what is blocking, in writing.
- Test what exists. Working software you can click is the only reliable progress report.
- Your levers are cutting scope, adding time, or changing the team, in that order.
Step One: Get the Facts in Writing
Ask your builder for three lists:
1. Done and testable. Features you can try today.
2. Left to do. Everything remaining, with a rough effort for each.
3. Blocked. Anything waiting on a decision, an account, or a third party.
The third list often surprises owners. A good share of delays come from the owner's side: an unanswered question, a missing login for the payment provider, content that was never sent. If you are the blocker, fix that first. It is the cheapest fix available.
Step Two: Test What Exists
Do not accept "it is almost done" as progress. Ask for a link and click through the finished parts yourself. If very little works after most of the time has passed, the project is in worse shape than the message suggested. If a lot works and the remainder is clear, you are probably looking at an ordinary delay.
Step Three: Find the Real Cause
| Cause | What it looks like | What helps |
|---|---|---|
| Underestimated a hard part | One feature taking far longer than planned | Cut or simplify that feature |
| Scope grew | Many small additions since the start | Freeze scope, move extras to a later list |
| Waiting on you | Unanswered questions, missing accounts | Clear the blockers this week |
| Team too thin or distracted | Slow replies, little progress between updates | Ask who is working on it, and how many hours |
| Wrong approach | Repeated rework of the same thing | Get an outside review before paying more |
The last two are the dangerous ones. The first three are normal and fixable.
Step Four: Pull the Right Lever
Cut scope. Launch with fewer features on the original date. This is usually the best option, because it gets real users on the app sooner. Our post on what to leave out of the first version of your app helps pick what goes.
Add time. Agree a new date, with weekly working demos until then. A new date without demos is a hope.
Change the team. Only if the cause is thin staffing or the wrong approach, and after an outside review. See how to switch software development companies mid-project.
Adding more developers to a late project rarely speeds it up in the short run, because new people need time to learn the code. Our post on Brooks's law explains why.
What Payment Structure Changes
If you pay per accepted milestone, a delay costs the builder as well as you, because nothing is billed until a milestone passes your review. That is how our software factory bills, and it is the strongest protection against a project that slips quietly. If you prepaid most of the project, you have less bargaining power, and getting working code into your own account matters even more.
A Concrete Version
A contractor-scheduling app is due in eight weeks. At week eight, the builder asks for two more. The owner asks for the three lists.
- Done: login, job list, assigning jobs to crews.
- Left: text message reminders, the customer sign-off screen, and an accounting export.
- Blocked: the text message provider needs a verified business account in the owner's name, which the owner never finished.
The owner finishes the verification that day. Testing shows the finished parts work well. The accounting export turns out to be the hard part, estimated at six more days alone.
Decision: launch in one week with reminders and sign-off, and export to a spreadsheet by hand for the first month. The accounting export ships two weeks after launch as its own milestone. The app is live one week late instead of two, and the hardest feature no longer holds up the launch.
The Honest Counterpoint
Sometimes the original date was never realistic, and the builder agreed to it to win the job. In that case, "late" is really "the estimate was wrong," and the fix is a new, honest plan rather than pressure. Pushing a team to hit an impossible date usually trades a delay for bugs. Our post on the planning fallacy covers why estimates run short so reliably.
Frequently Asked Questions
How late is too late?
A single slip with a clear cause and a new plan is normal. Two slips in a row without working software to show for them means the project needs a harder look.
Should I withhold payment?
Pay only for what the contract says you owe, usually accepted milestones. Withholding money you owe damages trust and can breach your contract. See fixed-price software contract: what to include.
Can I get compensation for the delay?
Only if the contract says so. Most small projects do not include delay penalties. Future contracts can tie payments to accepted work instead.
When is it time to rescue rather than wait?
When testing shows little works, or the same parts keep being redone. Read how to rescue a failing software project.
The Bottom Line
Get the three lists, test what exists, find the cause, and cut scope before you add time. If you are planning a new project and want the scope honest from the start, the honest read names the hard parts before anyone sets a date.
Roberto Espinoza is CEO of Ruzora, which builds custom software for business owners at a fixed price and places pre-vetted senior LATAM engineers with US teams. Get a free honest read on your idea.
