项目终止是一套有输入、有动作、有产出的收尾流程：先依据明确条件做出正式决策并留痕，再冻结范围与资源、完成合同与财务清算、移交可交付物与知识资产、安置人员、归档证据，最后复盘并沉淀经验。本文覆盖项目整体终止与提前终止，帮助项目经理和PMO把“停止”变成一次可检查、可追溯的特殊收尾。
要点总览（TL;DR）
- 项目终止先判断类型：整体终止、提前终止、暂停与恢复、正常收尾四类情形对应不同后续动作，暂停保留恢复预期，终止进入清算与关闭。
- 终止决策要留痕，记录终止类型、生效日期、决策人、影响范围与依据材料，作为执行与审计的基础。
- 执行按七步走：正式决策与通知、范围冻结与任务清理、合同与财务清算、可交付物与知识资产移交、人员安置、归档与系统关闭、复盘沉淀。
- 用角色—交付物对照表固定发起人、项目经理、财务法务、职能经理与接收方的责任，避免清算与移交悬空。
- 关闭前逐项核对检查清单，未结清合同、未取得移交确认、关键资料缺失属于阻断项，应标记为终止执行中而非正式关闭。
项目终止前要判断什么：终止类型与决策依据
启动终止流程之前，先要判断眼前的情况属于哪一类。把暂停、阶段结束和整体终止混为一谈，往往会导致该清算的没有清算、该保留的团队被提前解散，或者一个已经失去目标的项目被反复“续命”。判断的核心是问一句：这个项目未来还会以当前目标继续推进吗？
四类情形的区分
| 情形 | 特征 | 后续动作 |
|---|---|---|
| 整体终止 | 项目目标不再需要实现，生命周期结束 | 进入完整清算、移交、归档与复盘流程 |
| 提前终止 | 原定目标仍存在，但因条件变化在计划完成前停止 | 同样走终止流程，需额外说明目标承接方或替代方案 |
| 暂停与恢复 | 资源或优先级临时让渡，目标保留 | 冻结状态、记录恢复条件，恢复时重新评估目标、资源与授权 |
| 正常收尾 | 目标已达成，进入验收与交付 | 按验收收尾流程处理，不适用本文的清算重点 |
暂停与终止的关键差别在于是否保留恢复预期。暂停需要写明恢复的触发条件和责任观察人；终止则意味着不再以当前形态继续，必须完成清算与关闭。
触发终止的常见依据
终止决策应当建立在可核查的事实上，常见依据包括：项目目标所依赖的业务前提已经失效；预算削减或关键资源无法持续投入；出现无法在可接受成本内化解的技术风险或合规风险；组织业务方向调整，项目产出不再被需要。判断时要把“依据”和“情绪”分开——一次延期、一次人员变动通常不构成终止理由，需要评估其对目标达成的影响程度。
决策所需的输入材料
做出终止决定前，决策层至少应看到三类材料：项目状态报告（进度、范围完成度、主要风险与问题）、合同条款（付款节点、违约与终止条款、质保责任）、财务与资源现状（已发生成本、待付款项、在岗人员与外部供应商合同）。材料不完整时，可以先形成“有条件终止”的判断，把待补材料列为决策生效的前置条件。
决策记录应包含的字段
终止决策必须留痕，建议使用统一模板，至少包含以下字段：
- 终止类型（整体终止/提前终止）与终止原因分类；
- 决策人、决策会议或审批记录、决策日期；
- 生效日期，以及生效前仍需完成的最小工作；
- 影响范围：涉及的业务方、合同、人员、系统与数据；
- 依据材料清单与存放位置；
- 后续处置方案的责任人与时间要求。
这份记录既是执行依据，也是后续审计和复盘的基础。字段缺失的记录在清算阶段很容易引发争议。
项目终止的核心操作步骤
终止流程可以拆成七个步骤，每一步都应有明确的输入、动作、输出和完成标志。步骤之间存在依赖：决策未正式生效，不宜对外发布通知；范围未冻结，清算口径就无法确定。
第一步：正式决策与终止通知
输入是终止决策记录与授权文件。动作包括：由有权决策人签署终止决定，确定生效时点；起草对内对外通知，说明终止范围、生效时间、对接人和后续安排；按合同或组织规定提前通知相关方。输出是签署后的决策记录和已发出的终止通知。完成标志是所有关键相关方确认收到通知，且通知内容与决策记录一致。
第二步：范围冻结与任务清理
输入是当前工作项清单、需求池和里程碑计划。动作是冻结项目范围，停止新增需求和新任务派发；对每一项未完成工作逐项处置——关闭、转出至承接项目、转为待办需求或明确放弃，并指定处置责任人。输出是更新后的工作项状态和一份未完成事项处置表。完成标志是清单中不再存在“无人负责且未标注处置方式”的任务。
第三步：合同、采购与财务清算
输入是合同文本、采购订单、付款记录与成本台账。动作包括：对照合同条款确认已付款项、待付款项、退款安排、违约与质保责任；与供应商确认已交付物和未履行部分；形成书面清算说明并经财务、法务确认。输出是清算说明和付款/退款计划。完成标志是每笔合同与采购都有明确的结清或处置结论，不存在悬而未决的款项。
第四步：可交付物与知识资产移交
输入是交付物清单、文档库、代码或数据资产目录。动作是整理已完成和部分完成的交付物，明确接收方、移交内容、验收方式和确认人；对设计文档、调研结论、客户关系等知识资产同步移交，避免随人员离开而流失。输出是移交清单与接收确认单。完成标志是接收方书面确认收到并认可移交内容。
第五步：人员安置与外部供应商沟通
输入是项目人员名单、岗位安排和供应商合同状态。动作是由职能经理与项目经理共同确定人员去向——回到原部门、转入其他项目或进入待分配状态，并完成沟通；对外部供应商说明终止安排与结算方式。输出是人员安置记录和供应商沟通记录。完成标志是每位成员和每家供应商都已知晓安排并有对接人。
第六步：资料归档与系统状态关闭
输入是项目全过程文档、决策记录、清算与移交材料。动作是按组织归档规范整理资料，标注保存期限与访问权限；在项目管理系统中关闭项目状态，停止相关通知与权限。输出是归档清单和系统状态变更记录。完成标志是归档清单经核对完整，系统状态显示为已关闭。
第七步：复盘与经验沉淀
输入是终止全过程记录。动作是组织复盘，围绕终止原因、决策时机、清算与移交中的问题形成结论，提炼可复用的经验条目。输出是复盘报告和经验条目。完成标志是报告归档并进入组织知识库，供后续项目参考。
这七步涉及大量工作项状态变更、文档归集和审批留痕。在ONES中，项目与工作项的状态流转、文档的集中存放和归档，可以把“关闭了哪些任务、移交了哪些资料、谁做了确认”记录在同一处，减少终止后期靠邮件和表格拼凑证据的情况。具体操作路径以组织实际配置为准。
角色分工与各阶段交付物
终止流程最容易出问题的地方是责任悬空：决策层以为项目经理会处理合同，项目经理以为法务会跟进，结果清算拖了几个月。用一张对照表把职责和交付物固定下来，可以显著降低这种风险。
| 角色 | 主要职责 | 关键交付物 |
|---|---|---|
| 项目发起人/决策层 | 批准终止、确定生效时点、承担对外沟通授权 | 终止决策记录、对外沟通授权 |
| 项目经理 | 组织执行终止流程、维护终止清单与整体状态、协调各方 | 终止通知、未完成事项处置表、终止清单 |
| 财务与法务 | 合同清算、付款与退款处理、违约与风险条款处置 | 清算说明、付款/退款计划 |
| 职能经理 | 人员安置、资源释放与回撤 | 人员安置记录 |
| 接收方/业务方 | 接收可交付物与知识资产、完成验收确认 | 移交确认单 |
除上表外，完整的终止交付物清单还应包括：终止决策记录、终止通知、清算说明、移交确认单、归档清单和复盘报告。建议在终止启动时就把这份清单发给所有相关角色，每完成一项由责任人更新状态，项目经理定期核对。
示例：一个提前终止项目的收尾过程
以下为演示情景，用于说明流程如何落地，不对应具体组织。
某内部系统改造项目原计划分三期上线，第一期完成后，公司业务方向调整，原定第二、三期覆盖的业务场景被合并到另一条产品线。项目发起人评估后决定提前终止，保留已上线部分，未完成部分移交新产品线团队。
决策与通知
发起人召集决策会，依据项目状态报告、合同条款和成本台账形成终止决策记录，明确终止类型为提前终止、生效日期为两周后，影响范围包括一个外部供应商合同和五名项目成员。项目经理据此发出对内通知，并向供应商发出书面终止通知，援引合同中的终止条款。
范围冻结与任务清理
项目经理冻结需求池，把未完成工作项分为三类：已开发未上线的功能转交新产品线团队；仅完成调研的内容整理为需求文档移交；与合并场景无关的任务直接关闭。每项都标注处置方式和责任人，处置表经发起人确认。
合同与财务清算
财务与法务对照供应商合同，确认已完成阶段的付款、未履行部分的结算方式以及质保责任归属，形成清算说明。供应商确认后签署结算确认，付款按计划执行。
移交、人员安置与归档
项目经理整理已上线系统的运维文档、设计资料和调研结论，移交新产品线团队并取得接收确认。五名成员中三人转入新产品线，两人回到原部门，由职能经理逐一沟通确认。全部决策、清算与移交材料归入项目文档库，系统内项目状态关闭。
复盘输出
复盘形成两条经验：一是业务方向变化应在季度规划评审中提前识别，减少中途终止的清算成本；二是外部供应商合同应约定分阶段结算条款，便于提前终止时快速清算。两条经验进入组织知识库。
完成检查：项目终止是否真正关闭
终止流程是否完成，不能凭感觉判断。建议用一份检查清单逐项核对，并为关键项设置阻断条件：阻断项未通过时，不应对外宣布项目关闭。
| 检查项 | 通过标准 | 是否阻断 |
|---|---|---|
| 决策与通知 | 决策记录已签署，通知已送达关键相关方，授权清晰 | 是 |
| 合同与财务 | 每笔合同与采购已结清，或有书面处置方案和责任人 | 是 |
| 可交付物与知识资产 | 移交完成并取得接收方书面确认 | 是 |
| 人员与供应商 | 成员安置完成，外部供应商已沟通并有记录 | 否 |
| 系统与文档状态 | 项目状态已关闭，归档清单完整，关键资料无缺失 | 是（关键资料缺失时） |
| 复盘 | 复盘报告完成并进入组织知识库 | 否 |
三个典型阻断情形需要特别注意：合同未结清就宣布关闭，后续付款和违约争议会失去项目上下文；移交未取得确认，资料责任在人员离开后难以追溯；关键资料缺失，归档清单不完整，复盘和审计都缺少依据。遇到阻断项时，应记录未完成原因、责任人和预计完成时间，把项目标记为“终止执行中”，待阻断项消除后再正式关闭。
把终止当作一次特殊的项目收尾来管理，用决策记录、操作步骤和检查清单保证每一步可验证，组织才能真正从一次终止中获得清算的确定性和可复用的经验。
常见问题
项目暂停后决定不再恢复，需要补做哪些终止动作？
暂停转终止时，前期已完成的冻结状态可以复用，但需要补齐三类动作：一是把暂停记录升级为正式终止决策记录，明确终止类型、生效日期与决策人；二是对暂停期间搁置的合同、付款和人员安排重新核对现状，形成清算说明；三是完成可交付物与知识资产的移交确认和归档。暂停时写明的恢复条件与责任观察人，也应在终止记录中注明不再触发。
终止时部分交付物只完成了一半，移交应该怎么处理？
按完成度分类移交，避免把半成品当作完整交付物交接。已完成且可独立使用的部分，按正常移交流程确认接收；部分完成的内容，整理为需求文档、设计说明或调研结论等知识资产移交，并注明完成度与后续承接方；与终止原因直接相关、没有承接价值的部分，在处置表中标注放弃并说明理由。接收方确认的范围应与其实际接收的内容一致。
合同清算谈不下来，项目还能宣布关闭吗？
合同未结清属于阻断项，不宜对外宣布项目关闭。可行的做法是把项目标记为“终止执行中”，在检查清单中记录未结清事项、争议焦点、责任人和预计完成时间，同时保留项目上下文与相关资料的可访问性。待清算结论形成、付款或退款安排明确后，再完成系统状态关闭与归档。提前关闭会让后续争议失去项目背景，增加追溯成本。
终止复盘和正常收尾的复盘有什么不同？
正常收尾的复盘围绕目标达成情况、交付质量与协作过程展开；终止复盘的重点在决策链条：终止依据是否充分、决策时机是否偏晚、清算与移交中暴露了哪些合同或流程问题。输出上，终止复盘更应产出可复用的规则类经验，例如合同分阶段结算条款、业务方向变化的早期识别机制，而不只是单个项目的得失总结。
小团队没有专职法务和财务，终止流程怎么简化？
可以合并角色，但不能省略动作。由项目经理牵头，把合同条款核对、付款与退款确认、违约与质保责任判断集中到一份清算说明中，请有审批权限的负责人签字确认；移交确认单由接收方负责人签署即可。检查清单中的阻断项保持不变，简化的是参与人数和文档数量，清算结论与移交确认仍需书面留痕。
