项目终止是一套有决策、有交接、有证据的收尾机制：先由有权决策的角色依据终止条件作出正式决定并留档，再冻结范围与预算、盘点合同与资产、完成人员与知识交接、结清财务与法务事项，最后归档证据并复盘。本文按决策、执行、分工、示例和完成检查五个环节展开，适用于项目整体结束或转换的场景。
要点总览（TL;DR）
- 终止决定由业务发起人、业务负责人或决策委员会在授权范围内作出，项目负责人提供现状与建议；决议需写明理由、决策人、生效日期和影响范围并留档。
- 执行按冻结、盘点、结算、交接、归档关闭五步推进，前一步的输出作为后一步的输入，避免未盘点就结算造成遗漏。
- 项目负责人、业务发起人、财务、法务与采购、人力负责人、归档责任人各有明确交付物，三处关键交接点需书面或系统内确认。
- 收尾是否完成以证据判断：决议留档、合同与资产处置完毕、财务结清、人员再分配、知识归档、系统关闭、遗留事项有人跟踪。
- 暂停、缩减范围、转阶段与终止口径不同，决定作出时就应明确属于哪一种，避免预算、人员和合同继续被占用。
终止决定怎么作出并留下依据
终止决定的价值在于“可追溯”：谁在什么时间、基于什么事实、按什么权限作出决定，以及这个决定覆盖哪些范围。把这一步做实，后续的盘点、结算和交接才有统一依据，也才能在审计、复盘或对外沟通时给出完整说明。
常见终止触发条件
终止通常由一类或多类条件叠加触发，判断时应写明具体事实，避免只写“情况变化”这类模糊表述：
- 目标失效：原定业务目标已被取消、被其他方案替代，或市场需求不再成立。
- 预算或资源不可持续：资金缺口无法弥补，关键人员长期无法到位，继续投入会挤占更优先的事项。
- 技术路线不可行：关键技术验证未通过，或继续研发的成本与周期超出可接受范围。
- 外部条件变化：合规要求调整、供应商或合作方退出、政策与市场环境发生实质变化。
- 计划合并或转换：项目被上级计划吸收、拆分为新项目，或转为运维、产品化等其它形态。
决策角色与权限边界
终止决定应由对项目目标和资源负有最终责任的角色作出，项目负责人负责提供事实和建议，但不单独决定终止。常见分工如下：
- 业务发起人：确认业务目标是否仍然成立，对终止的业务影响负责。
- 项目负责人：提交项目现状说明，包括进度、成本、风险与可交付成果，提出终止建议。
- 业务负责人或决策委员会：在授权范围内作出正式决定，确定生效日期。
- 财务：提供已发生成本、未结款项与预算占用情况，作为决策输入。
- 法务与采购：提示合同解除、违约风险与供应商约束条件。
审批路径应与组织授权制度一致：金额或影响范围超过一定阈值的终止，需要上升一级审批；涉及对外合同的，法务意见应作为决策材料的一部分。
决策输出物与留档要求
一次完整的终止决策至少形成以下记录，并存入项目档案：
| 输出物 | 关键内容 | 留档要求 |
|---|---|---|
| 终止决议 | 决定事项、决策人、决策日期、生效日期 | 正式文件或系统审批记录，可追溯到决策人 |
| 终止理由说明 | 触发条件、支撑事实、已评估的替代方案 | 与决议一并归档，作为复盘依据 |
| 影响范围初判 | 受影响的合同、人员、资产、外部关系 | 作为后续盘点清单的起点 |
与暂停、缩减范围、转阶段的区分
终止意味着项目生命周期结束，资源按关闭流程释放；暂停是临时停摆，保留恢复可能，需要写明恢复条件与复查时间；缩减范围是继续推进但调整交付内容，项目编号与目标仍然有效；转阶段是项目进入下一生命周期阶段，管理动作延续。把四者混用，最容易出现“以为停了、其实没关”的情况：预算仍被占用、人员仍在待命、合同仍在计费。因此，决定作出时就应明确本次属于哪一种，并在记录中使用统一口径。
在协作工具中，这类决议可以通过审批记录、项目状态变更和说明文档留存，使决策人与生效时间可查。ONES 支持通过模板、权限和流程配置管理项目制场景（F2），可作为决议留档与后续任务关闭的承载方式之一；具体审批表单需按组织实际配置。
终止执行的操作步骤与阶段产物
决策生效后，执行阶段按“冻结—盘点—结算—交接—归档关闭”的顺序推进。前一步的输出是后一步的输入，顺序颠倒容易造成遗漏，例如未盘点就结算，会漏掉未登记的采购订单。
第一步：冻结
输入：终止决议与生效日期。动作：通知全体相关人员，停止新增需求、停止新的采购与外包承诺，锁定当前范围、进度与预算基线，记录冻结时点的项目状态。输出：冻结通知、基线快照。完成标志：所有相关方确认收到通知，系统中不再产生新的需求与采购条目。
第二步：盘点
输入：冻结时的基线、合同台账、资产台账。动作：逐项清点合同、采购订单、外包协议、软硬件资产、账号与数据资产，标注每项的处置方向（继续履行、解除、转让、报废）。输出：盘点清单，含责任人与处置结论。完成标志：清单覆盖全部合同与资产，无“待确认”项悬空。
第三步：结算
输入：盘点清单、财务账目。动作：核对应付应收、处理违约金与退款、完成资产处置、释放未使用预算。输出：结算说明与财务确认记录。完成标志：财务确认无未结事项，预算释放已入账。
第四步：交接
输入：在研成果清单、文档与代码、外部关系清单。动作：明确每项成果的接收对象与验收方式，完成文档、代码或资料的移交，将供应商与客户关系转交承接方。输出：交接清单与接收确认。完成标志：接收方书面确认，遗留事项有明确承接人。
第五步：归档与关闭
输入：前四步的全部记录。动作：变更系统状态、归档文档与数据、关闭项目编号、登记遗留事项跟踪人。输出：归档记录、关闭确认。完成标志：项目在系统中处于关闭状态，档案可检索，遗留事项有人跟踪。
| 步骤 | 输入 | 关键动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 冻结 | 终止决议、生效日期 | 停止新增需求与采购，锁定基线 | 冻结通知、基线快照 | 相关方确认，无新增条目 |
| 盘点 | 基线、合同与资产台账 | 清点合同、订单、资产、账号与数据 | 盘点清单 | 全部条目有处置结论 |
| 结算 | 盘点清单、财务账目 | 核对款项、处理违约与退款、释放预算 | 结算说明 | 财务确认无未结事项 |
| 交接 | 成果清单、外部关系清单 | 移交文档、代码、资料与关系 | 交接清单 | 接收方确认，遗留事项有承接人 |
| 归档关闭 | 前四步记录 | 变更状态、归档、关闭编号 | 归档记录、关闭确认 | 系统状态关闭，档案可检索 |
角色分工与各环节交付物
终止过程中最常见的失控点是“都以为别人在处理”。把每个角色的职责和交付物写清楚，并在冻结通知中一并发布，可以显著减少悬空事项。下表按角色列出主要职责与对应交付物，实际执行时可按组织规模合并角色，但职责不能空缺。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 项目负责人 | 组织盘点、编写终止说明、推动交接与关闭 | 终止说明、盘点清单、交接清单、关闭确认 |
| 业务发起人 | 确认业务影响，确定后续承接方案 | 业务影响说明、承接方案 |
| 财务 | 核对已发生成本、未结款项，完成预算释放 | 结算说明、预算释放记录 |
| 法务与采购 | 处理合同解除、违约事项，与供应商沟通 | 合同处置意见、供应商沟通记录 |
| 人力与团队负责人 | 人员再分配、沟通工时与绩效口径 | 人员安置记录、工时结算口径说明 |
| 归档与知识管理责任人 | 文档、数据与经验留存，保证可检索 | 归档目录、复盘记录 |
角色之间需要明确的交接点有三处：项目负责人向财务提交盘点清单，财务据此结算；项目负责人向承接方提交交接清单，接收方确认后交接才算完成；归档责任人接收全部过程记录，确认归档完整后项目才能关闭。每个交接点都应有书面或系统内的确认记录，避免口头交接。
当终止项目数量较多或跨团队并行时，统一的任务关闭与文档归档入口能减少遗漏。ONES 提供需求—任务—测试—缺陷的全流程闭环（F3），终止时可将未完成需求与任务集中关闭并保留记录；文档与复盘材料可归入知识库统一管理，具体归档规则按组织配置执行。
一个完整示例：中途终止的研发项目如何收尾
以下为演示情景，用于说明各步骤如何衔接，不代表真实案例。某研发项目进行到中期，因公司业务方向调整，决定终止该项目并将部分能力并入新方向。
决策与留档
业务发起人提交方向调整说明，项目负责人补充项目现状：已完成两个模块，第三个模块处于开发中，另有一份外包开发合同在执行。决策会议确认终止，决议写明终止理由为业务方向调整、生效日期为会议后第三日，影响范围包括外包合同一份、在研模块一个、已采购测试设备若干。决议与理由说明一并归档，项目状态在系统中标记为待关闭。
盘点与结算
冻结通知发出后，项目停止新增需求与采购。盘点发现：外包合同剩余工作量约三分之一，测试设备已到货未入固定资产账，另有两个云服务账号仍在计费。结算阶段，法务与采购同外包供应商协商，按已完成工作量结算并解除剩余部分；测试设备转入其他项目使用并补登资产；云服务账号在数据导出后停用。财务确认无其他未结款项，释放剩余预算。
交接
已完成的两个模块文档与代码移交给新方向的承接团队，第三个模块的半成品代码连同设计说明一并移交，由承接团队评估是否复用。外包供应商关系转交采购部门统一管理。交接清单由接收方逐项确认，未完成事项标注承接人。
归档与复盘
项目全部文档、决议、盘点与结算记录归档至知识库，项目编号关闭。复盘会围绕三个问题展开：终止信号出现的时间点是否被及时识别、外包合同的剩余工作量为何在冻结时才被准确掌握、哪些设计成果可以被新方向复用。复盘结论形成记录，其中“外包合同按里程碑分段结算”的建议被纳入后续项目的合同模板。
这一情景中，决议留档、任务关闭、文档归档和遗留事项跟踪分别落在不同环节。ONES 的效能管理支持对研发过程数据做多维度分析并提供角色化仪表盘（F4、F5），可用于复盘时查看进度与投入分布；这类数据能力服务于复盘分析，不替代终止决策本身。
完成检查：终止是否真正收尾
终止是否完成，不能以“会开过了”为标准，而应逐项核对证据。以下清单可作为关闭前的最后一道检查，每项都应有对应的记录或确认人。
| 检查项 | 通过标准 |
|---|---|
| 决策与授权 | 终止决议已留档，决策人、决策日期与生效日期明确，审批路径符合授权制度 |
| 合同与采购 | 全部合同、订单与外包协议有处置结论，解除或转让已书面确认 |
| 资产处置 | 软硬件资产、账号与数据资产已处置或移交，资产台账已更新 |
| 财务结清 | 应付应收核对完毕，违约与退款处理完成，预算释放已入账 |
| 人员安排 | 团队成员完成再分配与沟通，工时与绩效口径已明确 |
| 知识归档 | 文档、数据与复盘记录已归档，可按项目或主题检索 |
| 系统关闭 | 项目状态已变更，项目编号已关闭，不再产生新的任务与费用 |
| 遗留事项 | 未完成事项有明确承接人与跟踪方式，并约定复查时间 |
检查中出现“部分完成”的项，应记录剩余动作、责任人和期限，而不是直接放行。尤其要注意两类隐性遗留：一是仍在计费但无人关注的账号或服务，二是已移交但接收方尚未确认的成果。前者造成持续支出，后者在后续出现问题时难以界定责任。
对于需要长期跟踪遗留事项的组织，可在协作工具中为每项遗留建立独立任务并指定承接人，与已关闭的项目分开管理，避免关闭动作把未完成事项一并“关掉”。ONES 支持按角色配置读写权限（F4），便于在归档后控制终止项目资料的访问范围；版本与部署方式以官网当期信息为准（F6）。完成上述检查并留存记录，项目终止才算真正闭环。
常见问题
项目终止和项目暂停在执行上有什么实质差别？
暂停保留恢复可能，需要写明恢复条件和复查时间，人员和预算通常继续预留；终止意味着项目生命周期结束，资源按关闭流程释放。执行上的差别集中在三点：终止必须完成合同处置与财务结清，暂停一般只做阶段性冻结；终止要关闭项目编号并归档，暂停保留原编号；终止需要明确遗留事项承接人，暂停则由原团队继续跟踪。如果决定时口径不清，最容易出现预算仍被占用、合同仍在计费的情况。
终止时外包合同还没执行完，应该怎么处理？
先由法务与采购依据合同条款判断可选路径：按已完成工作量结算并解除剩余部分、将合同转让给承接方继续履行，或按违约条款处理。无论哪种路径，都需要把剩余工作量、已付款项和对方诉求核对清楚，形成书面确认。实际操作中，冻结时点与合同结算时点之间可能仍有计费，建议在冻结通知发出后同步通知供应商暂停新增工作，并在结算说明中记录这一时间差。
项目终止后，团队成员的工作交接和绩效口径怎么确定？
人员安排由人力与团队负责人牵头，在冻结后尽快明确每个人的去向和交接任务。绩效口径需要在终止说明中写清楚：已完成工作的认定范围、终止原因对目标达成的影响如何计入考核、交接任务的完成标准。这些内容与人员再分配记录一并留存，可以减少后续争议。交接任务本身应设定完成期限，并纳入承接方的确认环节。
终止项目的资料要归档到什么程度才算可检索？
至少应保证三类材料可按项目名称或编号找到：决策类材料（决议、理由说明、影响范围初判）、执行类材料（盘点清单、结算说明、交接清单与接收确认）、复盘类材料（复盘记录与可复用经验）。归档时统一命名规则和存放位置，并明确访问范围。对于含敏感信息的合同与数据资产记录，可在归档后按角色控制读写权限，ONES 支持按角色配置读写权限（F4），具体规则按组织制度设置。
遗留事项在项目关闭后由谁跟踪，怎么避免被一并关掉？
遗留事项应在关闭前逐项登记承接人、跟踪方式和复查时间，并与已关闭的项目分开管理。常见做法是为每项遗留建立独立任务，归属到承接方所在的项目或团队，而不是留在原项目下。关闭检查时核对遗留清单是否全部有承接人，复查时间到期后由承接人反馈进展。这样项目编号关闭不会影响遗留事项的继续推进。
