Critical requirements not signed off
The business unit has not formally confirmed central points — regardless of whether delivery has been reported as technically complete. Verbal agreement is not a sign-off.
Deployment & go-live
Go-live readiness: when a start is defensible — and when it is not.
Go-live readiness is a decision, not a state. It rests on everyone involved knowing what is still open and what happens if it materialises.
TopicImplementation and go-live
Reading timeapprox. 5 minutes
For whomProgram leadership, PMO, business unit
Last updatedJuly 2026
In brief
"Done" is the wrong question.
No start is ever preceded by a state in which nothing is open. The answerable question is therefore not "are we done?", but: can we go into production with what is still open — and do we know what we will do if one of these points materialises?
That turns a gut feeling into a risk assessment a steering committee can actually make. Open points are not hidden for this, they are assessed. A known defect with a defined way of handling it is less harmful than an unknown one.
What I look at first.
My first look goes to the sign-off status of the business requirements — not to the defect list. The reason is simple: open defects are visible and get discussed anyway. A requirement that is technically delivered but not signed off by the business often goes unnoticed before the start, and is noticed by the business unit immediately afterwards.
Then comes the question of whether operations can take over. This is the check that most often happens too late. If monitoring, on-call cover and the first support route are only settled in the week of the start, the problem is merely deferred by a few days.
The timing of the check matters as much as its content: it has to be early enough that a negative result still leaves room to act — usually one to two weeks before the planned start, with a short confirmation immediately beforehand. A check on the day before is a formality, because by then nobody calls it off honestly.
When I postpone a start.
Four reasons. If one of them applies, I recommend postponing — even when the date has been set politically.
Testing incomplete
Acceptance tests have not been run through, or their results are not documented. A test without a recorded result cannot be used for the decision.
Business unit or operations not ready
Training is missing, the new processes are unclear, or the first support route is not staffed. A technically flawless start that nobody can operate is not a start.
No tested rollback plan
There is no rehearsed way back. This is the reason that draws the most objection — and the one I negotiate least.
The rollback decision belongs before the start.
Talking about aborting while everyone is working towards the start feels destructive. That is exactly why it is left out — and exactly why it is discussed later under time pressure, with incomplete information and in a group that is not authorised to do so. Every hour that discussion lasts makes rolling back more expensive, because productive data is being created in the meantime.
A rollback criterion is therefore formulated in advance and kept as mechanically verifiable as possible: not "if there are major problems", but for example if the cutover exceeds its planned duration by more than a defined margin, if a defect of the highest severity level is not resolved within a defined deadline, or if a process designated as business-critical cannot be executed.
This includes a person named individually who is authorised to decide during the cutover — including the authority to abort. Committees are too slow for that.
And afterwards: the implementation does not end on the day of the start.
The implementation is only complete once operations work without project support. This period needs a plan of its own: increased on-call cover, a defined route for defect reports, a short daily picture of anomalies — and a fixed criterion for when stabilisation counts as finished.
Without that end point the project stays informally responsible, often for months. One sentence prevents it: stabilisation ends when no defect above a defined severity occurs over a defined period and operations confirm the handover in writing.
Do you have a start coming up?
Describe your system landscape, implementation window and project phase. You will receive an assessment of whether the date holds — and what is still missing for it.
Discuss your project