How to Forecast a Go-Live Date That Does Not Lie to Your CEO

The go-live date in most rollout decks is a wish. Someone wrote it in kickoff, the customer nodded, and it stayed there until it became impossible. The projection you actually need is derived from the plan, not typed into it. Here is how to build one.

What is a dependency-based go-live projection?

A dependency-based go-live projection models the onboarding plan as a graph. Every task has a duration and a set of upstream dependencies. The projected go-live date is the earliest date the last go-live task can complete, given the current state of every task and dependency in the graph.

That definition matters because it is a function, not an assertion. Nobody updates the date. It updates itself when the state of any task changes.

Three properties fall out of this design.

• The date moves when work moves. Not when someone remembers to update it.
• The critical path is knowable. You can see which specific chain of tasks is driving the date, and which chains have slack.
• The date reflects reality, not optimism. It cannot say Sep 12 when the math says Sep 20. There is no field to lie in.

Every complaint about status-column dates comes down to the fact that they can lie. Derived projections cannot.

Why does the status-column date always lie?

Because updating it is somebody's job that always loses to more urgent work. The mechanism has three failure modes.

1. Nobody remembers to update. IM is running eight accounts, a task slipped Monday, nobody moved the date field until Friday. Four days of hidden slip.
2. Updating requires re-planning. Moving the go-live date implies renegotiating downstream commitments. The friction of that conversation delays the update, sometimes indefinitely.
3. The update is directional. Dates slip forward eagerly but backward reluctantly. When a task completes early, the date does not usually get pulled in. Slack accumulates in one direction.

None of these are individual failures. They are consequences of a design that requires humans to keep a number honest.

How do you actually build the graph?

Three inputs, one output.

• Tasks with durations. Every task has a "days to complete" estimate. Not "Q3." Not "when data is ready." A number.
• Dependencies. Every task lists its upstream dependencies. Explicitly. "Field mapping review depends on data audit complete."
• State. Every task has a status: not started, in progress with a start date, or complete with a completion date.

From those three, the projection is a topological sort of the graph followed by a longest-path calculation. If you had to explain the algorithm to a data engineer, that is the whole thing.

The output is one date, plus the critical path that produced it, plus per-task slack.

What does the critical path tell you?

The critical path is the sequence of tasks with zero slack. Any slip on any of them slips go-live one-for-one.

The point of naming the critical path is prioritization. If Task A is on the critical path and Task B has three days of slack, the IM knows where to spend their Monday morning.

Most rollouts have a critical path of 5 to 8 tasks, in a graph of 30 to 60 total. Focus follows the path.

How do you handle uncertain durations?

Not every task has a knowable duration. Legal review takes an unknown number of days. Procurement approval is a black box. Customer IT tickets sit in queues.

Three practices handle this without pretending to certainty.

• Default estimates by task type. Legal review defaults to 10 business days. Procurement to 15. IT tickets to 7. Override with actual when known.
• Confidence bands. The projection shows the primary date and a 90% confidence range around it. Customer sees Sep 12 (Sep 8 to Sep 20). Do not hide uncertainty.
• Update the moment the black box opens. Legal comes back in 4 days instead of 10, that goes into the graph immediately. The projection pulls in.

Confidence bands are the missing feature in most Gantt charts. A single date implies precision the plan does not have.

Who should see the projection?

Different roles need different views of the same underlying number.

• Customer sponsor. Projected date, confidence range, top three current risks. Not the whole graph.
• Customer-side lead. Projected date, their overdue tasks, upcoming tasks with dates.
• Implementation manager. Full graph, critical path, slack per task, portfolio version across all their accounts.
• VP CS. Portfolio: every active rollout, projected go-live vs baseline, aggregate slip, cohorted by segment and template.
• CEO or board. Aggregate: percentage of rollouts on-track, aggregate slip, first-90-day churn correlation.

Every view is a derivative of the same graph. When one moves, all move. Do not maintain five copies of the projection.

How do you talk to a customer when the projection slips?

The conversation goes better when both sides can see the math.

• Show the chain. "The projection moved from Sep 12 to Sep 20 because the SSO configuration task went 8 days over." Not "we are running behind."
• Own your side, name theirs. If the slip is on the customer side, name it plainly and offer options. Do not pretend it is a shared responsibility when it is a customer IT queue.
• Offer scoping options. If the slip is unacceptable, the answer is scope, not effort. What can move to phase two.
• Do not silently rebaseline. Keep both the committed date and the projection visible. Rebaseline explicitly, with agreement, or the projection has no anchor.

The rollouts that end well handle slip openly early. The ones that end badly hide slip until the customer notices, then negotiate under pressure.

What does the CEO see, exactly?

One number and one trend.

• Number. Percentage of active rollouts on-track (within 5 days of baseline).
• Trend. That number, week over week, for the last quarter.

If the CEO or board wants more, offer aggregate slip in days and first-90-day churn correlation. Everything else is IM-level detail that does not belong in a board deck.

The mistake CS leaders make in board reporting is showing per-account status. That is where the CEO starts second-guessing individual rollouts and pulling on threads that do not belong at the CEO layer. Aggregate up, keep detail available on request.

The mistake to avoid

The mistake is treating the go-live date as an opinion instead of a calculation. Opinions can be optimistic. Calculations cannot lie in the same way. A go-live projection that recalculates from a dependency graph is not clever technology, it is the minimum baseline for a rollout that hits its committed date. When the CEO asks "is the Meridian rollout on track," the answer is not a CSM's read of the room. It is a number that the plan produces, updated the moment any task moved. That is what makes a projection actually usable.