项目收尾指南：如何漂亮地落地而非悄然死亡

Everyone loves the start of a project. There’s the kickoff, the fresh energy of newness, and the blank canvas of a new feature to build. There’s a particular optimism that comes with beginnings, when the team is aligned, the scope feels manageable, and the possibilities stretch out ahead of you. Starting is the fun part, which is probably why so many of us have a pile of musical instruments and unfinished side projects.

But the end is a different story. The final 10% of a project, where the work gets fiddly, the energy dips, and the finish line keeps moving, is where most projects quietly fall apart.

If starting a project is like takeoff, finishing it is like landing, demanding a completely different kind of skill and attention, and it’s where most of the risk accrues. After all, the hardest part of flying a plane is landing it.

This article is about why endings are so hard, what goes wrong when you don’t manage them deliberately, and how to land your projects well. Here’s what we’re going to cover:

• Why the final stretch of a project is psychologically and structurally harder than the beginning.
• The anti-patterns that cause projects to die quietly instead of finishing cleanly.
• Why scope creep accelerates at the worst possible moment, and how to protect against it.
• A practical playbook for landing well.

If you find this topic interesting, here are some complementary articles from the archive:

• One bottleneck at a time argues that when everything feels urgent, the counterintuitive move is to focus on the single thing that’s actually blocking progress, which is also the discipline the final stretch demands.
• The beauty of constraints makes the case that saying “not now” to good ideas is a skill rather than a compromise, and one that pays off most when scope pressure is highest.
• One list to rule them all is about the power of a single prioritised backlog, which becomes essential when you’re deciding what makes the cut and what doesn’t.
• Invert, always invert walks through the habit of asking “how could this go wrong?” before it does, a question worth asking explicitly as any project approaches the finish line.

So, let’s dig in.

Why the end is the hardest part

So why does the final stretch of a project feel so different from the beginning? Part of it is structural, since the work that remains is often the hardest of the whole project: getting it out there to customers. But a surprising amount of the difficulty is psychological, and understanding the psychology helps you manage it.

There’s a well-known adage in programming, the ninety-ninety rule, credited to Tom Cargill of Bell Labs: the first 90% of the work takes 90% of the time, and the remaining 10% takes the other 90%. Jeff Atwood wrote about living in that state in his classic post on being perpetually 90% done. I’m sure you can associate with this.

That’s because the last 10% is where you hit the edge cases, the integration problems, and the thousand small decisions that weren’t apparent when the architecture was being sketched on a whiteboard, or the initial lines of code were being written.

This certainly feels familiar to me, so I’m sure it feels familiar to you too.

The psychological side is just as powerful. Novelty is easier to desire than completion, because starting something new promises reward! And possibility! Finishing, by contrast, is structural and unglamorous, and there’s none of that novel pull in writing migration scripts or fixing the remaining glut of accessibility bugs.

Seth Godin calls this the Dip in his book of the same name: that long, unrewarding stretch between the initial excitement and the satisfaction of completion. Most people quit in the Dip not because the work is impossible, but because the emotional fuel runs out. I’m glad you can’t see my private GitHub projects.

Then there’s the planning fallacy, coined by Kahneman and Tversky and popularised in Thinking, Fast and Slow: we systematically underestimate how long tasks will take, especially tasks we haven’t done before. This then hits hardest at the end of projects, because the remaining work is precisely the kind that’s challenging to estimate (“what iterations will customers need to make this great?”)

Additionally, integrations, testing, deployment, and documentation are the tasks that expand to fill whatever time you thought you had, and then some…

Research by Diwas KC, Bradley Staats, Maryam Kouchaki and Francesca Gino found that when workload rises, people gravitate towards easier tasks to maintain a sense of progress. This is completion bias, and it maps directly to the final stretch: when pressure builds, your team will instinctively reach for minor UI tweaks and documentation fixes rather than tackling the hardest parts of the work that stand between them and shipping.

You might expect the “goal gradient” effect to help here. Research by Kivetz, Urminsky, and Zheng shows that effort naturally accelerates as you approach a goal. But, however, the goal gradient only works when the finish line is visible and stable. In software, the finish line keeps moving and moving, and that’s the problem!

The quiet death

Let’s invert the question to garner more insight. Instead of asking what a good ending looks like, consider what happens when a project never officially ends at all.

You’ll have all experienced the project that was “almost done” three months ago, where the team mentally moved on but nobody formally closed the book. Telltale signs: the Linear board still has tickets in it, nobody’s looked at them in weeks, and there was no retrospective, no celebration, no learning captured, and rather than failing spectacularly, it just faded away into the oubliette.

This is the quiet death, and it’s far more common than outright failure. Think about the project your team spent months on that got to about 90% before, say, a reorg shifted priorities and you didn’t touch it again.

Nobody makes an explicit decision to stop a project, after all: people get absorbed into other work, the remaining tickets sit untouched, and a few months later someone quietly archives the board. All that effort, all those decisions and trade-offs, and nothing shipped, and the worst part is that often nobody even notices!

The reason quiet deaths are so insidious is that “95% done” is the most expensive state a project can be in: you’ve made the maximum investment but delivered zero value.

Or worse, something partially shipped, enough to create maintenance burden but not enough to deliver the promised outcome.

The organisational cost compounds over time. When projects routinely fade instead of finishing, trust erodes between engineers and leadership. The next time you kick off something ambitious, your team starts with scepticism rather than excitement.

Interestingly, the Zeigarnik effect describes how unfinished tasks occupy mental bandwidth: your brain keeps returning to incomplete work, creating a low-grade cognitive load, which gives yet another reason to finish stuff: it helps you concentrate better on the next thing.

What makes the lack of landing projects worse is that when “almost done” drags on long enough, the tension for getting it done dissipates. The project becomes background noise, neither finished nor actively worked on, consuming mental space without the urgency that might push it across the line.

The one more thing trap

If the quiet death is what happens when nobody’s paying attention, the “one more thing” trap is what happens when everyone starts paying attention at exactly the wrong moment.

For months, stakeholders were vaguely aware your team was building something. They attended the occasional update meeting, nodded along, and went back to their own priorities. But now the project is visible, there’s a working demo, and suddenly everyone has opinions.