The sunset clause, written on day one

Extraction is the stage everyone plans last, and therefore the stage everyone plans badly. The fix is a sunset clause written at kickoff: not an exit clause for breach, but a definition of what a finished deployment is. It sits on the first page of the project charter and deliberately not in the contract, because a termination clause reads as a threat while a project definition reads as an agreement.

The five fields

Field	What it must contain
Trigger date	A fixed number of months after acceptance, between six and twelve. A project of three months or less takes six, three to six months takes nine, longer than six months takes twelve.
Review output	Three lists produced by the sunset review: features that are alive, work still to be handed over, and people still to be withdrawn. Missing any one of the three means extraction is not complete.
Continuation condition	A further period granted only on written customer consent. Verbal agreement does not count, and neither does an unsigned chat screenshot or unsigned meeting minutes.
Compression exception	Personal safety or major public interest only, and the exception must leave a record. Nothing else accelerates the clause.
Post-extraction role	The FDE moves from part of the workflow to emergency contact: a first response within four hours and disposition advice within twenty-four during working hours, twelve and forty-eight outside them. The role ends on written notice that it is no longer needed, or after a set number of months following the sunset review with no emergency request.

The second field is the one that gets softened in practice. "Review output" sounds like a meeting; it is actually a deliverable list, and an extraction that produces two of the three lists has not finished.

Why the clause belongs in the charter

The clause is a shared expectation, not an enforcement mechanism. Placed in the contract, it announces that the relationship has an end, which is true but reads as leverage. Placed on page one of the project charter, it announces what done looks like, which is the same fact without the threat.

The continuation condition only works if it was agreed before anyone needed it. A customer who first hears about the sunset review in month five will experience it as a surprise bill; a customer who read it at kickoff will experience it as the schedule they signed up for.

The order of extraction

Four steps, in this order: handover, weaning, the four-week rule, then the sunset trigger.

Handover comes first because everything else depends on it, and the handover manual is written by the successor rather than dictated by the FDE. That rule looks inefficient and is the whole point: a manual the FDE writes tests nothing, because the FDE is the thing being removed. If the successor cannot write the manual, the organisation has not learned the system, and the honest reading is that the deployment is not finished.

Weaning runs from low risk to high risk, so that each removal is observed before the next one. The four-week rule must already have passed, which is why the observation window in the delivery stage cannot be shortened to make the exit date. Only then does the sunset review happen, producing the three lists.

One recorded contract shows what the other end looks like. The customer's key contact disappeared, three contractual tasks went overdue on the same day, and the fallback was written into a todo list with no completion record. That is the fifth of the six standard death causes: the only person pushing the project left. A sunset clause does not prevent a person from leaving. A named continuation condition and a review-output list do make the disappearance visible on a schedule rather than at the end.

What stays and what comes back

What stays with the customer is the running system, the successor's manual, the workflow it now supports and the data behind it. The customer should be able to operate, extend and explain the thing without calling.

What comes back to the product organisation is the other half of the job. The six-section anatomy, with a concrete death cause rather than the word "none". At least one method-library entry carrying the trigger scenario, the failure mode, the identification signal, the action to avoid and the boundary condition. The anonymisation check at entity, number and time level, since an entry that fails any of the three is not usable. And, over time, reusable components and a smaller customisation surface.

That last item is the test of whether the model is working at all. The marker of a functioning deployment practice is that each subsequent customer requires less customisation. If that number does not fall, what is happening is day-rate outsourcing with better vocabulary.

Success looks like no longer being needed

The role's own criterion runs backwards from the usual one: the day the customer no longer needs you is the day the job succeeded. The after-the-fact version of the test is whether the system is still used once the team has left the building. If it is not, what took place was accompaniment, not activation.

Which is why the sunset clause is not a termination clause. It is the part of the agreement that gives "done" a date, a reviewer and an archive. Fill the five fields at kickoff, name the reviewer, and put the trigger date where the customer will see it before they need it — then check the four-week rule before the review, keep the annex honest about what was promised, and hand over within the method's fixed order.