A Software Launch Date Is Not a Plan

A date is a wish until the work has an order. I have sat in rooms where the go-live was chosen because a quarter ended, a conference was booked, or someone said “we just need a stake in the ground.” Then engineering inherited a Friday. The Friday had no first increment.

Planning is what comes first, what is blocked, and what the first release will actually include. A calendar square is none of those. I have funded beautiful dates. I have rarely seen them survive the first missing training hour.

Stop publishing the Friday before the sequence exists

If no one can name the first-release result in the requestor’s language, you do not have a plan. You have a countdown. Countdowns create overtime, then blame. I learned that before 1998 had a name for agile.

Write the week. Attach the unknowns. Record the yes. Then sequence. software project planning is that step—not a new dialect, and not a slide with a flag on a month.

Constraints belong next to the problem

Busy season, legal review, the clerk who is the only trainer: those are the plan. They belong on the same thread as the request. A phase invented so leadership has a picture belongs in the drawer with the other pictures.

Use requirements gathering software so the constraints attach instead of migrating into a deck. When the date moves, the reason should still be readable by the person who reported the pain.

The release check is a changed week

I have signed off on launches that hit the date and missed the week. The ticket closed. The workaround stayed. That is not delivery. That is filing.

The full thread is in How to move software projects in real English. If the requestor cannot read the page at release, the date was a costume. Ask whether their Friday changed. That sentence is the plan’s only honest ending.