上线那天晚上，项目群里烟花刷了满屏。几个月后，PMO 在例会上问了一句：这个项目什么时候能关？
会议室安静了几秒。没人接话。
大家都以为它已经结束了。打开台账，它还挂在“进行中”。人早就散到新项目去了，预算还在按月摊，遗留问题在群里被@来@去。谁都能说一句“在跟”，没人说“我来关”。
很多项目不是死在交付，是卡在收尾。上线只说明成果开始被使用，离关闭还差一段路。交付有没有确认，验收有没有签字，遗留问题有没有人接，资料和权限有没有交出去，旧成员能不能退出来。小红书哔哩哔哩
这几件事单看都不难，合在一起就很难。因为它们都指向同一个动作：有人要签字认账。
验收单一签，后面再出问题，责任就换了个方向。业务方怕接了烫手，交付方怕签了背锅。于是“再观察一个版本”和“等你们先确认”来回拉扯，“有条件通过”慢慢变成“永远有条件”，项目状态就一直停在“进行中”。
到了收尾才发现，双方对“完成”的理解根本不一样。团队觉得能用了，业务方觉得场景没覆盖。小红书
拖着的代价不会立刻出现。它散在每个月的人力成本里，散在新项目借不到人的时候，散在下次出问题时又要去翻以前的聊天记录。项目看着还在，实际上已经没人对它负责。
所以结项不能当成一张行政表。它更像一道闸门，过闸之前，得把几件事说清楚。
回到最初的目标，逐项核对承诺的东西有没有交付。没交付的部分，要有处理方案。
验收要有明确的验收人和书面结论，口头一句“没问题”不算数。正式验收还得记录通过、有条件通过或不通过，并由有权限的验收人确认。小红书
遗留问题可以留，但要写清影响、责任人、截止时间和关闭标准。项目可以遗留问题，不能遗留责任。小红书小红书
资料、账号、监控、合同和后续联系人，要真正交到接手的人手里。不是发一个文件夹就算完，最好让对方复述一遍：资料找得到，系统会操作，异常知道找谁。
最后，人员、预算、设备、权限正式释放，项目状态改成“已关闭”。一张收尾清单，事项、标准、责任人、截止时间、状态、关闭确认，六列都关掉，才算结项。少一项，项目就会以某种方式继续活着。小红书
PMO 在这里的角色，不是催着大家填结项表，而是把“什么算结束”定义清楚，并且守住这道门。一个关不掉的项目，会一直占着下一个项目的资源，也一直占着团队里某个人的注意力。
庆功宴可以提前吃。项目，得有人正式说结束。
