The email goes out on a Thursday. The go-live date has moved to March.
Almost everyone on the distribution list already knew.
That is the part worth attention. A go-live date does not slip on the day it is announced. It slips over months, in a series of small accommodations that each looked reasonable at the time. The announcement is the moment the programme runs out of room to absorb them.
Which means the question most boards ask next is the wrong one.
The date is a lagging indicator
Scope, timeline, and budget are what a status report measures. They are also the slowest things to move. By the time a date changes, whatever caused it has been in the programme for a long time.
The leading indicators sit upstream, and they are less comfortable to look at.
How deep the design workbooks go, as opposed to how complete they are marked. Whether test scripts cover the scenarios that will break or the scenarios that were easy to write. Whether the people signing off on requirements understand what they are signing. Whether the parallel run balances, and if it does not, whether anyone has quantified the gap rather than describing it as close.
None of those appear on a status report. Every one of them moved before the date did.
None of it is platform-specific either. The pattern is the same on SAP, Workday, Dayforce, Oracle, and Humanforce programmes, because what slipped was the work rather than the software.
This is why a revised plan, produced quickly and with confidence, should not reassure anyone. It is built on the same information that produced the plan before it.
Three questions worth asking
The instinctive response to a moved date is to ask for a recovery plan and more frequent reporting. That produces more paper. It does not produce more information.
Three questions get further.
What changed in the six months before the date moved? Not what changed last week. A programme that slips has a history, and the history is where the pattern lives. If nobody can construct that timeline, that is the finding.
What are we no longer going to do? An extension is often absorbed quietly, by trimming scope, deferring a workstream, or moving something into a phase two that has no funding and no date. That is a decision. It belongs at the board table, not in an appendix discovered later.
What would have to be true for the new date to hold? Not whether it will hold. What would have to be true. The answer is a list of assumptions, and assumptions can be tested. Confidence cannot.
The problem with asking the people closest to it
All three questions are usually put to the programme. That is the natural thing to do, and it is why the answers settle so little.
The delivery lead owns the plan that slipped. The system integrator owns the estimate underneath it. The sponsor owns the business case the date was promised against. Each is being asked to assess their own work, in a room where the assessment has consequences for them.
None of that requires anyone to be dishonest. Optimism is not deception. But a programme cannot mark its own homework and produce a reading a board can rely on, and individual integrity does not change that.
It is a structural problem. Only structure resolves it.
The four-party model
Every implementation has four parties. The client, who owns the outcome and funds it. The platform vendor. The system integrator who deploys. And an independent adviser positioned with the client.
Two of those four hold a commercial stake of their own in the platform. The client's stake is the outcome. Ours is the client's.
That is what makes scrutiny possible in every direction. We will test the vendor's roadmap and the integrator's estimate. We will also test the client's own assumptions, capacity, and drift, because the organising commitment is the outcome rather than the party. A filtered view protects nobody.
Is the picture you're seeing the full picture?
What to do in the first fortnight
Four things are worth doing before commissioning anything at all.
Write down the assumptions the new date depends on, and circulate them. Most programmes have never made this list. Producing it costs nothing and it surfaces disagreement immediately.
Separate the decisions from the plan. A revised plan usually contains several decisions that were never formally taken, most of them about scope. Pull them out and take them properly.
Ask for the reconciliation, not the status. Where there is a data migration or a parallel payroll run in scope, ask for the numbers rather than the confidence level.
Decide who is going to answer the question honestly. That can be someone inside the organisation with enough distance and enough standing to be believed. Where it is not, it needs to be someone with no position in the programme at all.
Where an independent read fits. The right time for a health check is before you need one. Most organisations do not commission one then, and a moved date is the moment the question becomes unavoidable.
A Project Health Check is a five-lens diagnostic: Governance, Delivery, Risk and Issues, Stakeholder, and Benefits. It is delivered as a peer review rather than an audit. An audit tests compliance against a standard. A board that has just lost a date needs something different, which is a direct read of what is happening and what to do about it while there is still time to act.
The output is not a rating. It is a short list of the things that will determine whether the new date holds, each with a named owner and a date of its own.
Rydel Group is an independent PMO advisory firm. We hold no licence with the platform vendor and no implementation contract with the system integrator, and we take no commission from either. No stake in the systems we implement. Always on the client side.
A slipped date is information arriving late. What matters is whether the next one is built on better information than the last.