That report carries the most useful date in the building: the last day on which the programme told the truth about itself. A rescue starts there, with everything reported since treated as unproven. It does not start with a new plan.
Late is ordinary; misreported is what sinks a programme
BCG's 2024 Build for the Future study, a survey of more than 1,000 C-suite executives, found that more than two-thirds of large-scale technology programmes are not expected to be delivered on time, within budget or within their planned scope. A late programme is in the majority, and lateness alone is recoverable.
What is rarely recoverable is a go-live decision taken on reporting nobody tested. Grant Thornton, external auditor to Birmingham City Council, concluded of the council's Oracle programme that reporting was overly optimistic, with risks and issues poorly articulated, and that the level of risk was not understood when the system went live in April 2022.
My career has been spent on JD Edwards implementations, upgrades, cloud rollouts and data migrations. The pattern that audit describes is not unusual. Programmes drift into reporting activity because activity is always available to report.
Days 1 to 10: find the last honest date
A CEO or CFO can tell activity from readiness without any technical knowledge. Activity is counted in effort: test scripts executed, data loads run, people trained, percentage complete. Readiness is counted in evidence: a month-end closed in the new system by the finance team, opening balances reconciled to the old ledger and signed by the controller, a clerk posting an invoice with nobody at her shoulder.
Four signs tell me a pack reports activity. The plan has been re-baselined and the status has stayed green. Defects are counted but not aged. Risks have no named owner outside the project office. Nobody can produce the exit criteria for the phase just completed.
For ten days I rebuild the record from evidence alone, and I interview the people who do the work before the people who report on it.
Days 11 to 20: what stops, and what is protected
A rescue is mostly subtraction. I stop new change requests. I stop any testing cycle that is running against a configuration still being altered, because its results will be worthless. I stop percentage-complete reporting entirely, and I halve the meetings.
Two things are protected, whatever else is cut. The first is the handful of people who understand both the business and the system. The second is the legacy system and its support contract. A programme with no way back will go live when it should not.
Many SAP programmes are running against the end of mainstream maintenance for Business Suite 7 in 2027. In the UAE, businesses with revenue above AED 50 million must be on the Ministry of Finance's e-invoicing system by 1 January 2027. A date that cannot move is an argument for cutting scope. It is never an argument for compressing testing.
A mock close that had never been run
Picture a manufacturing group replacing finance and supply chain systems across several countries, weeks from go-live, every workstream green. Reading backwards, the last report anyone could believe is the one before integration testing was declared complete. It was declared complete because the scripts had been executed, with the defects carried forward.
No mock month-end close has ever been run from start to finish. Data migration is reported by loads completed, and nobody in finance has reconciled a balance. Three change requests from one country are absorbing the two best consultants.
The rescue stops the change requests, keeps the legacy contract alive and runs one mock close with the real finance team. It fails, usefully, in places no status report had mentioned.
Day 30: the sponsor's single decision
By day 30 the sponsor owes the programme one decision, and it has three possible answers: continue, re-scope or stop. Continue means the original scope and a new date the evidence supports. Re-scope means a smaller first release and a named owner for what is deferred. Stop means preserving what is reusable and ending the spend.
Each answer is respectable. The failure is the fourth one, taken by default: carry on, and review again next quarter.
What the steering committee reads on day 31
The pack on day 31 is four pages, and it contains no percentages. Page one lists what was proven this month, each line carrying the name of the business owner who signed for it. Page two lists what was attempted and failed.
Page three shows the decisions the committee must take today and what each week of delay costs. Page four gives the conditions for go-live, each marked met or not met.
Before the next steering committee
This quarter, ask your programme director one thing: show me the last deliverable the business signed as working, and the date it was signed. If the answer takes more than a day to arrive, you have found your last honest date.
If you would rather have that work led from inside the programme, NectarGlobal can place a fractional programme owner or rescue lead alongside your team, usually within two to four weeks of agreement.