Every late project I have worked on was already late on day one. Not because the team was slow, but because nobody had written down what “done” meant in a form that could be argued with. Scope was a paragraph in a slide. Everything after that was negotiation disguised as engineering.
The useful move is boring: before estimating anything, write the list of things the system will refuse to do. Not features — refusals. A payments service that will not handle refunds in the first release. A dashboard that will not support custom date ranges. A migration that will not preserve deleted records. Each refusal is a decision someone senior has to disagree with now rather than in week nine.
Estimates are a claim about uncertainty
When someone asks how long a piece of work will take, they are usually asking a different question: when can I promise this to somebody else? Answering with a single number hides the part that matters. I answer with the shape instead — the two or three unknowns that could double the number, and what it would cost to resolve each one this week.
In practice that looks like: three weeks if the vendor’s sandbox behaves like their docs; five if we have to reverse-engineer the settlement file. A day of spiking the sandbox turns that range into a number. Nobody has ever refused me that day once the trade was stated plainly.
A schedule is not a prediction. It is a set of bets, and your job is to make the bets legible to the person who has to underwrite them.
The three questions I ask before kickoff
First: who can say no to this and be listened to? If the answer is more than two people, the project has no owner and the schedule is decorative. Second: what does the first real user do on the first day it exists? If nobody can describe that in one sentence, the requirements are a wishlist. Third: what happens if we ship half of it? A project that is useless at 50 percent is a project with no early feedback, and it will be late in a way you cannot see until the end.
None of this requires a methodology. It requires writing things down where other people can read them, and being willing to be wrong in public early, which is cheaper than being wrong in private for a quarter.
The teams I have seen deliver consistently were not faster engineers. They were better at closing questions. Every week, a few more things stopped being negotiable. That is what progress actually feels like from the inside — not velocity, but a shrinking list of things still up for debate.