The Elevator Go-Live Date: How Rushed Kickoffs Destroy Technical Estimates

I have inherited go-live dates in elevators. The doors opened, somebody said “end of quarter,” and by the time engineering saw the request, the date had acquired a sponsor, a slide, and the emotional stability of a legal obligation.

Nothing had been estimated. Nobody had written what the software needed to change. The deadline was still called aggressive, which is corporate language for a guess wearing dress shoes.

Why rushed kickoffs produce fictional estimates

A kickoff held before intake does not discover a plan. It performs one. Leadership announces the date, the project manager opens a parking lot, and engineering is asked whether the work is feasible while still learning which system owns the customer record.

I once watched a team estimate six weeks during a kickoff because silence had become socially expensive. Two days later they found three integrations, a data migration, and an approval dependency owned by a person who was not invited. The estimate did not fail. The question arrived before the evidence.

Put the request into software project intake before the calendar invitation. Write what happens today, who is stuck, what better looks like, and what event makes the timing matter. “The CEO said Q3” is sponsorship. It is not a timing event.

Separate the business estimate from the technical estimate

An unrealistic software delivery deadline usually hides two different estimates.

The business side estimates how quickly the organization can answer questions, approve scope, prepare users, clean data, and make a decision when a tradeoff appears. The technical side estimates analysis, build, integration, testing, release, and the uncertainty currently sitting between those nouns.

Do not add the two numbers in a hallway and call the result alignment. Record them separately. The business and technical estimates guide shows why this matters: a six-week build attached to four weeks of unanswered decisions is not a six-week project.

I prefer ranges before precision. Engineering can say, “With the current evidence, this is eight to twelve weeks after scope approval.” The business can say, “We can supply the policy decisions in ten days.” Now the date has owners. Before that, it had typography.

Protect capacity with a scope firewall

If leadership needs a fixed date, the first-release boundary must move. Keep the outcome. Reduce the surface area.

Use software project planning to name what the first release must prove, what can wait, and which assumption would change the estimate. Then place the work beside existing commitments. Capacity does not become available because the new request has a better executive.

The broader deadline failure is covered in why project managers get blamed for missed deadlines. Pay particular attention to the moment before that blame begins: the rushed kickoff where a date is accepted before either side has estimated its work.

Replace the kickoff promise with a decision

At the end of review, leadership gets three honest choices:

1. Keep the outcome and move the date. 2. Keep the date and reduce the first release. 3. Fund additional capacity where additional capacity can actually help.

The fourth choice—keep everything and ask the team to be agile—is not a choice. It is minutes from the future post-mortem.

How to push back on an unrealistic project deadline

Do not say, “Engineering says no.” That turns evidence into a departmental mood. Put the outcome, date, scope boundary, two estimates, and current capacity on one page. Then use sentences that return the decision to the person who owns it:

> “We can hold the date if the first release proves this one outcome and the other two capabilities move.”

> “The technical range is eight to twelve weeks after scope approval. The business side still owns ten days of policy and training decisions.”

> “To start this now, name the approved work that should move. The team has no unassigned capacity hiding behind the roadmap.”

> “If the date cannot move and scope cannot shrink, we need a named risk acceptance—not a kickoff promise.”

That is how to push back a project deadline without performing a small rebellion in a status meeting. Give leadership choices with consequences. Do not offer a heroic yes and quietly invoice the team later.

Do not reject an arbitrary deadline with a larger arbitrary deadline. Show the two estimates, the capacity collision, and the smallest release that can survive the date. I have seen executives accept difficult tradeoffs when the tradeoffs were written plainly. I have rarely seen them accept a lecture about velocity.

The elevator may still produce dates. Elevators do strange things to senior leadership. Your intake process does not have to promote them into plans.