What a three-month delay actually costs

When a project pauses for three months, the usual way to describe the cost is a date. Go-live was March, now it's June. The plan shifts to the right, the remaining work moves with it, and the conversation is about whether June is realistic.

That framing leaves out the most expensive part. A delay doesn't just move the work that hasn't happened yet. It quietly undoes some of the work that already has.

Finished work doesn't stay finished

Think about what "done" meant at the moment the project paused.

The data migration was validated in September. It was genuinely complete: extracts run, records reconciled, exceptions resolved, signed off. By February it's stale. The source system has kept running for five months. New customers, new suppliers, changed prices, closed accounts. The validation was true of a dataset that no longer exists.

Training was delivered in August, and it went well. But by the time the system is live, some of the people who sat in that room have moved roles, some have left, and the ones who remain have had six months to forget a system they never got to use. Training that isn't followed by use doesn't keep.

User acceptance testing was signed off on a particular version. Since then the vendor has released two patches, a couple of configuration changes were made to fix something else, and an integration was rebuilt. The sign-off is real, and it covers a version that is no longer the one going live.

None of this is anyone's failure. Each piece of work was done properly. It simply had a shelf life, and the project ran past it.

Every plan assumes done is forever

Here's the structural problem. Planning tools treat completed as a permanent state. A task marked 100% stays at 100% whether the project goes live next week or next year. There's no mechanism for a finished task to become unfinished because time passed.

So when a project restarts after a long pause, the replan does the natural thing. It takes the completed work as complete, schedules what's left, and produces a date. That date is wrong before anyone starts, because it's built on a foundation that's partly expired. The migration will need re-running. The training will need repeating. Testing will need to be redone on the current version. None of it is in the plan, so all of it arrives as a surprise — usually in the last month, when there's the least room to absorb it.

This is also where the client side tends to get blamed, and unfairly. Re-validating data, re-attending training and re-testing land disproportionately on the client's people. If the replan doesn't include that work, it looks like the client is slow to "finish" things they had already finished once. What we're really doing is asking them to repeat work, in the gaps of their day jobs, that the plan pretended didn't need repeating. Putting it in the plan is what makes it a reasonable request rather than an unreasonable surprise.

Re-running isn't always a redo

The answer isn't to assume everything expires. That would be just as wrong in the other direction, and it would make every pause look catastrophic.

How much has to be re-run depends on the work and on the length of the gap. A data migration paused for three weeks might need a delta load — just the records that changed. Paused for five months, it might need a full re-extract and re-validation, because the volume of change makes a delta riskier than starting again. Training after a short pause might need a refresher session; after a long one, the full course for a partly new audience. Testing might need a targeted regression on what changed, or a full cycle if the changes touched too much.

So for each piece of finished work, the useful question isn't "is this still done?" It's "has this expired, and if so, does it need doing again in full or in part?" That's a judgement call, and it should be made explicitly, task by task, rather than defaulted to either extreme.

Most of it survives — and that matters

This is the part that tends to get lost once you start looking for expired work: most finished work does survive.

The design decisions still stand. The configuration that was built and tested hasn't changed. The chart of accounts is still the chart of accounts. The integrations that weren't touched still work. The documentation is still accurate. On most paused projects, the expired work is a meaningful minority, not the bulk.

Saying that out loud is half of the case you take to a steering committee. A sponsor hearing "three months of delay" imagines three months of wasted effort and wonders whether to stop. A sponsor hearing "these four pieces need re-running, two in full and two in part, and everything else holds" can make a decision. The honest account cuts both ways. It adds work the optimistic plan left out, and it removes the fear the pessimistic one creates.

The real cost of the delay

So what does a three-month delay cost? The extra months, obviously. The people kept on the project, the licences paid for longer, the benefits that arrive later.

But also the expired work: the re-validation, the repeat training, the re-testing. That cost is real, predictable and almost never counted, because the plan has no way of expressing it. It's the cost that turns a restart into a second failure when nobody accounts for it, and into an ordinary piece of planning when somebody does.

The fix is unglamorous. When you replan after a pause, walk the finished work and ask, for each piece, whether time has spent it.

---

ProjectPlanOS lets you mark which completed tasks have expired when you plan a restart, choose a full or partial re-run for each, and see the effect on schedule and cost before committing to a date.

If you're replanning after a long pause, the list of what's expired, and of what hasn't, is the place to start, with or without us.