Project Management for Website Launches

A launch is not a sprint with a scarier name

Most of what a project tool assumes is a rhythm: sprints repeat, capacity is measured over multiple cycles, a slipping date this week gets absorbed into planning for next week. A launch breaks that assumption on purpose. There's one date, it was probably announced to people outside the company, and there's no "next cycle" to push the leftover work into. Everything either lands before the date or it's a visible miss.

The other thing that makes a launch different is who's involved. A sprint usually belongs to one team. A launch is content, design, engineering, marketing, sometimes legal and support, all converging on the same deadline from different directions, each with their own idea of what "done" means and their own tools for tracking it, until launch week, when everyone discovers they were tracking different things.

ShipSprint doesn't add a countdown clock to solve that. It gives the whole convergence one board, real limits on how much any team can have in flight at once, and a forecast that reacts to a fixed date instead of an open-ended cadence. Concretely: content, engineering and marketing keep their own templates and vocabulary, but everyone converging on the date is looking at the same numbers.

What changes when the date doesn't move

In ongoing work, a forecast tells you roughly when something will be ready. For a launch, the question flips: given the date is fixed, will the team actually make it, and by how much are they behind or ahead right now. ShipSprint's forecasts are built the same way either way, from the team's measured velocity as work completes, but pointed at a fixed date, that same math tells you whether you're on pace weeks before launch week arrives, not during it.

WIP limits matter more here, not less. The instinct in the final week of a launch is to open everything at once: start the content review, the load test, and the press-kit copy simultaneously because they're all "urgent" now. That's exactly when a column overflowing is most expensive, because there's no next sprint to catch what didn't get finished. A WIP limit that holds through the last week is what keeps that instinct from turning into everyone working on six things badly instead of two things well.

Six weeks out, three weeks out, launch week

At six weeks, the board mostly holds intent: a rough list of workstreams, not yet enough real throughput to forecast anything meaningfully. This is the point to set WIP limits deliberately, before pressure makes everyone want to raise them, and to make sure content, design, and engineering are all working off the same launch board rather than three separate lists that get reconciled in a status meeting nobody enjoys.

By three weeks out, there's enough completed work for the forecast to say something real, and this is usually the first moment a genuine risk becomes visible: a workstream running behind its own pace, not because anyone said so out loud, but because the numbers show it. That's the useful moment to act: there's still time to add capacity, cut scope, or quietly renegotiate the date with whoever announced it, none of which is available the week before.

Launch week itself is mostly about holding the line already set. The WIP limits stay where they were, the runbook in the wiki gets read rather than rewritten from scratch, and blockers get flagged the moment they happen rather than saved for a standup that isn't happening this week anyway.

Keeping people outside the project honestly informed

A launch almost always has an audience that isn't doing the work: a founder who announced the date publicly, a client waiting on their agency, a leadership team that wants to know if the press release timing is still safe. The default way that audience gets informed is someone on the team pausing actual launch work to write a status update, which is exactly the wrong time to be pulling attention away from the thing with a fixed deadline.

The owner command center exists for that audience specifically: a live answer to "where are we" across the launch, without requiring anyone to stop and assemble it. Paired with the wiki holding the launch plan and any decisions made along the way, someone outside the day-to-day work can get an honest picture of progress without a meeting, and without the team spending launch week narrating itself instead of finishing it.

What happens after the date passes

A launch doesn't end cleanly at the deadline. There's usually a hypercare week after, watching for issues that only show up under real traffic. That work looks more like the ongoing cadence ShipSprint is built for day to day: items land in triage as they're found, get worked against a WIP limit, and the forecast goes back to describing an open-ended queue instead of a countdown. The same board that ran the countdown keeps running afterward; it just stops being pointed at a single date.

Before you can call it launch-ready

• Every workstream feeding the launch (content, dev, marketing) is visible on the same board, not tracked separately and reconciled by hand
• The forecast against the launch date reflects this week's actual pace, not the pace assumed when the date was first set
• No column is over its WIP limit in the final week, however tempting it is to open six things at once
• The rollback plan exists somewhere other than one person's memory, and is written down before it's needed
• Whoever is asking "are we on track" can see the answer without pulling someone off launch work to produce a status update