Last Safe Start Date

A vendor publishes an end-of-maintenance date three years out. The architect presents it. Everyone agrees it is important, and no money moves. The following year the architect presents it again, now two years out, with the same result.

A deadline more than a budget cycle away loses every prioritisation contest to something with a date this year. The fix is arithmetic: subtract the programme's duration and its contingency from the deadline and negotiate against that date instead.

Why it matters

The external date creates the obligation; the last safe start creates the urgency. They are different instruments and only one of them fits inside a planning horizon. The last safe start is also a number the architect owns, derived from an estimate they can defend, rather than a claim borrowed from a vendor page — which matters because the vendor's date invites the response "they will extend it" and an arithmetic date does not.

It also reframes the conversation from a warning into a decision with a deadline attached, which is the form funding requests take.

Implementation patterns

• Estimate duration from the critical path, not the work. The binding constraint is usually a single scarce team, a freeze window or a regulatory approval.
• Add contingency as a stated percentage, 20% being a defensible default for a multi-year programme, and show it separately so it can be argued about on its own.
• Subtract downstream fixed windows: year-end freezes, audit periods, peak trading. A 36-month programme that cannot cut over in November loses months of apparent slack.
• Express the output as two funded decisions with dates, not as a risk: approve the cost by date X, start by date Y.
• Re-compute it every planning cycle and publish the movement. A last safe start that has passed is the strongest possible evidence, and it must be stated rather than quietly dropped.
• Name what happens after it passes: scope cut, a bought extension, or accepting a reduced support posture for a ring-fenced system. A date with no consequence is not a deadline.

Industry example

SAP has published that mainstream maintenance for the SAP Business Suite 7 core applications runs to the end of 2027, with optional extended maintenance from the start of 2028 to the end of 2030 at a premium of two percentage points on the existing maintenance base, and customer-specific maintenance after that; it has separately published an innovation commitment for SAP S/4HANA to 2040.

Run the arithmetic for a conversion estimated at 30 months. With 20% contingency that is 36 months, so a finish inside mainstream maintenance required a start by the end of 2024. For an organisation that has not started, the mainstream date is already unreachable and arguing for it is arguing for a plan that cannot succeed. The binding date becomes the end of 2030, the last safe start the end of 2027, and the extension premium a budget line for 2027 rather than an option. On a maintenance bill of $4M a year, two points is roughly $80k a year for three years — priced correctly, it is a put option on schedule risk, compared against the cost and failure probability of compressing 36 months into 30.

Failure scenarios

• The duration is the optimistic estimate, so the last safe start is later than the truth and the programme starts too late while appearing on schedule.
• Contingency is buried inside the estimate, so the first challenge strips it invisibly.
• The date passes and is not restated, which teaches the organisation that the architect's dates are advisory.
• It is computed once and never re-derived as scope grows.
• It is presented as the only option, which reads as a threat; three costed options read as a decision.

Trade-offs

Publishing a last safe start commits the architect to an estimate, in public, years before the evidence exists. That is genuine exposure: a programme that turns out to take 24 months rather than 36 makes the architect look alarmist, and one that takes 48 makes them look wrong in the other direction. The exposure is the price of urgency, and the mitigation is showing the contingency separately and re-deriving the number each cycle rather than defending the original.

It also concentrates attention on schedule at the expense of scope. The strongest version of the argument carries both: this date, or this smaller scope.

When not to use it

Where the deadline is soft, do not manufacture a hard date from it. A roadmap slide from a small vendor, a competitor's announcement or an internal aspiration cannot carry this arithmetic, and using it there spends the credibility you will need when a real date arrives. It is also wrong for work whose value does not depend on a deadline at all: a platform improvement should be argued on its returns, and dressing it in a manufactured deadline invites the discovery that the deadline was invented.

Interview question

Q: A vendor's support for a system you depend on ends in three years. You have presented this twice and received no funding. What do you take into the next conversation, and how do you make the number credible?

What a strong answer covers: the distant deadline losing to this quarter; the last-safe-start derivation including contingency and fixed freeze windows; converting it into dated funding decisions; pricing any available extension as an option rather than a reprieve; presenting three costed paths rather than one; and the honesty of restating the date when it has already passed.

Quick check

Quiz: Why does a vendor's end-of-maintenance date fail as a funding argument? It sits outside the planning horizon, so it loses to anything with a date this year, and it invites the reply that the vendor will extend it.

Flashcard: How do you compute a last safe start date? External deadline minus critical-path duration minus stated contingency minus downstream fixed windows, then published as two dated decisions: approve the cost by X, start by Y.