Never go live on a conference date

The request is always reasonable. There is a conference, an audit, a fiscal year end, a board meeting. The new system should be live for it. Everyone agrees, and the date goes in the plan.

The problem is what the date does to every decision after it. A fixed external deadline turns every discovery into a negotiation about what to cut. And the things that get cut are always the same things: the rehearsal, the data checks, the training, the documentation. Precisely the work that makes a launch survivable.

The date is not the risk. The compression is

If a build finishes two weeks early, nobody notices. If it finishes two weeks late against an immovable event, you go live untested in front of the exact audience you were trying to impress. The downside is enormously larger than the upside, and it arrives on a day when everyone is already busy.

Worse, the people who would normally catch problems are at the event.

What I do instead

My go-live dates come from a rehearsal, not a calendar. We run the whole thing on a copy: the migration, the logins, the reports, with real people doing real tasks. What that rehearsal tells us is when the system is ready. That becomes the date.

If there is an event you care about, we plan backwards from it with real slack, and I tell you early, in writing, if it is not achievable. Early is the important word. A deadline you cannot hit is only a crisis if you find out in the final fortnight.

There is also a middle path people forget: go live quietly two or three weeks before the event, with a small group, and let the event be the moment you talk about it rather than the moment it first runs. Same announcement, none of the risk.

Payments follow the same rule

I tie payment stages to things you can see working, not to dates on a calendar. A calendar-based schedule pays for time. A milestone-based one pays for progress, and it removes the incentive to call something finished because the month ended.