Write the Ending First: Why Every Project Deserves an Expiration Date

There's a project on your board right now that should have ended eight months ago. You know the one. The status says “in progress,” the last update was three weeks back, and the owner has quietly stopped bringing it up in standups. Nobody has killed it because killing it would require admitting something, and admitting things is awkward.

So it sits there. It eats a little of everyone's week. It appears in planning sessions as a line item nobody questions. When someone new joins the team and asks what it's for, the answer involves a lot of hedging.

Call it a zombie project. Every team has at least one, and every team insists theirs is different.

Nothing Ends on Time Because Nobody Planned to End

Here's the uncomfortable pattern: we plan launches in obsessive detail and endings not at all. A kickoff gets an agenda, a doc, a deck, and a RACI chart. A shutdown gets silence, then a channel that goes dormant.

That asymmetry isn't an accident. Endings feel like failure. In a culture that celebrates shipping, proposing a deadline for your own project can sound like you don't believe in it. So we don't. We leave the end date as TBD and trust that the work will conclude naturally when it's done.

Work does not conclude naturally. It concludes when someone with authority says “we're done,” and if nobody schedules that moment, the project keeps existing at low intensity — the organizational equivalent of a browser tab you're afraid to close.

The Sunset Clause, Explained

A sunset clause is a sentence agreed at kickoff that says: this project ends on a certain date unless we explicitly decide otherwise, and here's who decides, and when.

That's it. It's not a threat. It's not a prediction that the project will fail. It's a pre-commitment that makes the ending a scheduled decision rather than an accumulating awkwardness.

The clause has four parts.

The date. A real one. Not “end of Q2,” which is a season, not a day. Put it on the calendar the way you'd put a launch date.

The review trigger. The specific moment the team sits down and asks whether to continue. A date, a milestone, or a threshold — a signup number, a weekly cost, a support volume. Pick one and write it down.

The decision-maker. One name. Not “leadership.” One person empowered to say stop, who will actually say it.

The default. This is the part teams skip, and it's the most important. What happens if nobody shows up to the review? The default must be: it ends. Otherwise the clause is decorative.

Why the Default Is Everything

If the fallback is continuation, you've built a system that rewards inattention with more budget. Skip the review, keep the project. Nobody wants to be the person who killed something, so nothing gets killed, the review gets rescheduled, and suddenly it's next quarter.

Flip it. Make silence mean sunset. Now continuing requires an affirmative act — someone has to look at the numbers, make an argument, and put their name on it. That's a healthier burden. It's easy to defend a project you believe in. It's clarifying to discover you can't be bothered.

What This Does to the Work Itself

The counterintuitive part: sunset clauses tend to make projects better, not shorter. When a team knows a real checkpoint is coming, scope conversations get honest earlier. “We could add that, but it won't be measurable by the review” is a complete sentence that ends a lot of arguments.

It also changes how you launch. A team with an ending in view builds for evidence — a clear metric, a defined audience, a way to tell whether the thing worked. A team without one builds for completion, which is a much vaguer goal and a much easier one to fake.

And when a project does get extended, the extension means something. It's a documented decision with a reason attached. Very different feeling from drift.

How to Write One Without Being a Downer

Frame it at kickoff as part of the plan, not a hedge against it. Something like: “We're committing to this for twelve weeks. On March 6 we'll look at adoption and cost and decide whether to extend, change shape, or wrap it up. If we don't meet by then, it wraps by default.”

Say it once, calmly, before anyone has sunk cost to defend. Agreeing to an ending on day one is far easier than proposing one on day ninety.

Then hold the meeting. Put it on the calendar at kickoff with the same seriousness as a launch review. Show up. Read the numbers out loud. Decide, and write down what you decided.

Endings Are Part of the Craft

Go3 Project is built around building together and launching smarter, and the smarter part includes knowing when to stop. A project with a planned ending is a project someone thought about. A project without one is a project someone started and then hoped for the best.

Write the ending first. It's the cheapest form of courage your team will ever buy.