A delivery date is the most expensive sentence a project manager says. Everything downstream is planned against it: the client’s launch, the finance team’s cash flow, the next project waiting for the same developers. So I do not say it on the first call, and I do not let a developer say it on my behalf. Before a date leaves my mouth it has to survive three questions.
What has to be true for this date to hold?
This is the honest version of a plan. Not the Gantt chart, but the list of assumptions the chart is quietly resting on. The bank’s sandbox credentials arrive by week six. The client signs off the data model in one round rather than three. The senior backend developer stays on this project and is not pulled onto the support queue. Nobody goes on leave in the last fortnight.
I write those down in plain language and I put them in front of the client. The point is not to cover myself. It is that half of those assumptions are theirs to keep, and most people are far more careful with a commitment once they can see it written next to the date it protects.
The list also tells me how much I trust the estimate. A date with three assumptions behind it is a date. A date with fifteen is a hope with a calendar attached, and it should be presented as a range until the list gets shorter.
Which of those things do we not control?
Every assumption gets sorted into two piles: things my team can make true, and things somebody else has to. Sandbox access, content, sign-off, third-party APIs, procurement, the other supplier’s deliverable. The second pile is where projects actually slip, and it is the pile a developer’s estimate never includes, because a developer is estimating the work and not the waiting.
For each item in the second pile I want a name, a date, and a fallback. Who provides it, when we need it by, and what we build in the meantime if it is late. On a recent payments integration the fallback was a stubbed gateway that let the rest of the build and the testing continue while the real credentials were three weeks late. The date held because the plan had already assumed the bank would be slow.
If an item has no fallback, it goes on the risk register on day one with the slip it would cause, and the client hears about it in the kickoff rather than in week nine.
What gets cut first if one of them slips?
Scope is the only lever that moves a date without moving the budget, so I agree the order of the cuts before there is anything to cut. The exercise is simple: rank every feature by what happens on launch day if it is missing. Some things stop the launch. Some things embarrass the client. Some things nobody would notice until the second month.
That ranking becomes the release plan. The build order follows it, so whatever is unfinished when time runs out is by construction the least important thing. It also removes the worst conversation in project management, the one where a slip has already happened and everybody is arguing under pressure about what matters.
Clients occasionally resist this on the grounds that everything is essential. The answer is that everything will still be built. The question is only what ships in the first release and what ships in the second, and they would rather choose that now than have it chosen for them by a calendar.
Then the date
Once the three lists exist, the date is not a guess any more. It is the developers’ estimate plus the waiting time on the things we do not control, with a fallback for each, and a scope that flexes in an agreed order. That is a date I will put my name to, and it is the date I report against every week, with the assumptions that still hold and the ones that have moved.
The habit came from writing code before managing it. A developer learns early that an estimate is only as good as the unknowns it accounts for. Project management is the same discipline applied to a room full of people rather than a codebase.