A platform team your program depends on has just told you their deliverable will land three weeks late, and it is on your critical path. How do you handle telling the VP the launch date has moved?

Short answer

Establish the real new date before you talk to anyone, by re-running the critical path with the slip in it rather than adding three weeks to the end. Then present one recommended date with the two rejected options and what each would have cost.

Do not add three weeks to the end date

The instinct is to take the program date, add three weeks, and go communicate it. That answer is almost always wrong in one direction or the other, and being wrong here is expensive because the number you give a VP becomes the number they give their own leadership. A three-week slip on the critical path moves the program date by three weeks only in the case where nothing downstream can absorb any of it and nothing else was close to becoming critical. Both of those conditions need checking rather than assuming.

Two things can shrink the impact. Downstream work may have float that was built in deliberately, so a task that was going to sit idle for a week waiting on integration can now start late without moving anything. Or downstream work can be resequenced, because part of it never truly needed the delayed deliverable and was only sequenced after it for convenience. Both are worth an hour of investigation before you commit to a number, and both are questions to put to the engineering leads rather than to answer from the plan document.

One thing can make the impact worse, and it is the one most candidates miss: the slip may consume the float on a parallel path and make that path critical too. If your data-migration workstream had two weeks of slack, three weeks of delay elsewhere does not make the migration comfortable, it makes it the new binding constraint with its own risks that nobody has been watching closely. You now have two critical paths, and your reporting has to change to reflect that.

flowchart TD
    A[Platform API slips 3 weeks] --> B[Re-run critical path<br/>with slip inserted]
    B --> C{Downstream float<br/>or resequencing}
    C -- Absorbs part --> D[Program moves<br/>less than 3 weeks]
    C -- Absorbs nothing --> E[Program moves<br/>full 3 weeks]
    B --> F[Parallel path float<br/>now consumed]
    F --> G[Second critical path<br/>needs its own tracking]

The branch on the right is the one to watch: the recalculation can leave the date unchanged and still leave the program materially riskier, because a path with no slack left behaves differently from a path with two weeks of it.

Arrive with a recommendation, not a problem

There is a real difference between a TPM who says "the platform team slipped, so we are three weeks late, what would you like to do" and one who says "the date moves to the eleventh of November; here are the two ways we could hold the original date and why I am not recommending either". The first hands the decision back up along with all the work of framing it. The second is the job.

The framing that works is one recommendation with the rejected alternatives visible and costed in the currency the executive actually cares about. Compressing scope, adding people, and moving the date are the three levers, and an exec wants to see that you considered all three rather than reaching straight for the date.

Naming which decision belongs to whom matters as much as the options themselves. The scope cut is a product and sales decision, the resourcing trade is an engineering-leadership decision, and the date recommendation is yours to make and theirs to accept. A TPM who blurs those lines either overreaches or under-delivers.

The one thing a VP will actually test you on

The question that follows this news, every time, is some form of "is this the last time the date moves?" What is being tested is not your optimism but whether you can say what has changed about the plan's assumptions rather than only about its arithmetic. If the answer is that the platform team's estimate was always thin and nobody had checked it, then the same failure is still live everywhere else in the plan, and a new date derived the same way deserves no more confidence than the old one.

So the credible version of the new date comes with the change that makes it more reliable: you now have a weekly checkpoint with the platform team against a named intermediate deliverable, or you have moved the integration test earlier so the next slip surfaces in week two rather than week nine. Without that, you are asking for trust in a number produced by the same process that just failed.

Keep the schedule conversation separate from the accountability one

Delivering the new date and litigating why the platform team slipped are two different conversations, and merging them damages both. The date conversation needs to end in a decision; the accountability one needs the platform team's leadership present and is not yours to run alone. Candidates who use the schedule update to build a case against another team read as political rather than as program owners, and they lose the working relationship they need for the recovery plan they just proposed.

The number a VP repeats upward becomes yours, so earn it by recalculating the path rather than adding the slip to the end.

© 2026 Preptima. Originally published at preptima.com.