The Miracle They Tried to Put in the Baseline

Filed by: D.B. Trench

Field line: Do not let survival become the estimating method.

Two months after the launch, the old miracle came back wearing a planning assumption.

It happened in a schedule review for the next release.

The new plan had the same testing window as the last one. Same compressed cutover. Same short stabilization period. Same cheerful belief that regional validation could fit inside three days if everyone stayed focused and no one became inconveniently human.

The delivery lead asked where the estimate came from.

The answer was immediate:

That is what we managed last time.

There it was.

The sentence that turns rescue into baseline.

Last time, the team worked late for nine straight days. The vendor kept an engineer online through the weekend. The business analyst rewrote scripts during UAT. The reporting view was delayed on launch morning. Support manually cleared exception cases that automation was supposed to handle.

But the launch date held.

So now the date had become proof.

This is how good teams get punished for saving the organization from its own earlier choices. They absorb the damage once, and the system mistakes absorption for capacity.

I pulled up the post-launch record.

Not the public congratulations. Not the smooth-launch note. The internal record.

Launch succeeded with manual containment. Reporting view delayed three hours. Exception-case validation required manual support. Training materials updated post-launch. Vendor engineer retained through stabilization. These conditions should not be treated as normal launch assumptions.

That last sentence had been annoying when we wrote it.

Now it was useful.

The schedule review changed after that.

Not dramatically. No one apologized to the ghosts of the previous weekend. But the old estimate lost some of its authority.

For about eleven minutes.

Then the sponsor asked whether we could still hold the same date if everyone committed early.

That is how miracles return. Not through stupidity. Through optimism with a better haircut.

We added the work the miracle had hidden: additional validation time, named regional testers, separate support window, confirmed vendor availability, automation fix before launch, training updates before UAT.

The proper plan moved the date by one week.

The preferred plan did not.

Leadership chose the preferred date with reduced scope and a larger support window. Not my favorite answer. A real answer.

The baseline note said:

Date maintained with reduced launch scope and elevated stabilization support. Prior release performance is not used as evidence of standard capacity because it required manual containment, extended vendor support, and post-launch training correction.

That sentence did not save the team from pressure.

It did not prevent every bad assumption from entering the room.

It did stop the miracle from becoming clean math.

There is a difference.

If you do not write down what a miracle cost, the next project will price it at zero. If you do write it down, the organization may still try to spend it again. But now it has to do so in daylight.

The old miracle did not stay in the file where it belonged.

It kept trying to get out.

So we kept the file open.

---

Baseline protection: Use this when last project’s overtime, manual recovery, vendor favors, or post-launch patching is being treated as proof the same timeline is normal.

What happened: Name the extraordinary conditions that made the date possible.

What it cost: Late work, manual processing, delayed checks, support load, deferred fixes, or borrowed vendor capacity.

What cannot be reused: Do not put rescue conditions into the baseline unless they are explicitly approved, resourced, and owned.

Field channel: Get The Dispatch — weekly field reports for PMs managing the work beneath the official update.