项目集决策跟踪是对治理层已作出的决策进行登记、指派责任、跟进执行状态并确认关闭的持续管理动作。它要回答的核心问题是“决定后来怎么样了”，跟踪对象既包括决策事项本身，也包括执行责任、交付物、状态偏差和关闭结论。本文说明它的定义、纳入范围、台账字段与状态取值，并区分它与决策记录、项目集状态监控的关系。
要点总览（TL;DR）
- 项目集决策跟踪是对治理层已作出的决策进行登记、指派责任、跟进执行状态并确认关闭的持续管理动作，回答“决定后来怎么样了”。
- 纳入跟踪的是需要治理层授权、改变项目集范围/预算/优先级或涉及跨项目裁决的事项；日常任务分派和独立项目立项选择不进入台账。
- 台账字段分决策事项、责任、执行、关闭四组，状态统一为待启动、执行中、受阻、已完成待验证、已关闭、已撤销六类。
- 决策记录回答“决定了什么”，决策跟踪回答“执行到哪一步”，项目集状态监控回答“整体进展与风险如何”，三者通过决策编号和执行状态衔接。
- 执行受阻的决策以编号进入状态报告的风险项，长期未解决的偏差升级回治理会议重新裁决。
项目集决策跟踪的直接定义
项目集决策跟踪，是指项目集治理层作出决策之后，由指定角色把决策事项登记进台账，明确决策责任人与执行责任人，持续记录执行动作、交付物和状态变化，直到满足关闭条件并给出关闭结论的管理过程。它的输入是已经形成的治理决策，输出是一份可查询、可追溯的执行状态记录和关闭结论。没有这两个产出，决策跟踪就退化为口头询问。
执行主体通常包括项目集经理、PMO 以及治理委员会秘书等角色。项目集经理负责推动执行与状态更新，PMO 负责台账口径、字段规范与汇总，治理委员会秘书负责把会议结论准确转化为可跟踪的决策条目，并在下次会议上带回执行情况。不同组织中这些职责可能由同一人兼任，但登记、执行、验证三类动作需要分开，避免执行人自行认定关闭。
它属于项目集运行治理的持续动作，贯穿决策生效到关闭的整个周期。适用场景包括定期治理会议前后的状态核对、跨项目资源调整后的落地检查，以及重大风险处置方案的执行跟进。决策一旦作出并进入执行，就应纳入跟踪；仅在会议中讨论而未形成结论的议题，留在议题清单中，不进入决策台账。
跟踪边界：哪些算决策事项，哪些不算
决策跟踪的范围应限定在治理层有权作出、且会影响项目集目标、资源或交付节奏的决定。范围划得过宽，台账会变成任务清单，治理会议被琐事淹没；范围划得过窄，重要决定执行到哪一步无人掌握。判断一条事项是否进入台账，可以用一个简易标准：它是否需要治理层授权、是否改变项目集的范围、预算、优先级或放行条件、是否涉及多个项目之间的裁决。三项中满足其一，就应登记。
| 类别 | 典型事项 | 是否纳入决策跟踪 |
|---|---|---|
| 范围与目标调整 | 子项目交付范围缩减、项目集目标指标修订 | 纳入 |
| 预算与资源追加 | 追加开发人力、增加外包预算、调配共享专家 | 纳入 |
| 里程碑与优先级变更 | 上线时间推迟、两个子项目优先级对调 | 纳入 |
| 重大风险处置方案 | 关键技术路线切换、供应商替换的应对决定 | 纳入 |
| 跨项目依赖裁决 | 两个子项目对共享接口的交付顺序争议 | 纳入 |
| 上线与验收放行 | 准予进入生产环境、阶段验收通过与否 | 纳入 |
| 日常任务分派 | 某成员本周处理哪几个缺陷 | 不纳入，留在执行层任务管理 |
| 常规执行细节 | 代码评审安排、测试用例编写顺序 | 不纳入 |
| 独立项目立项选择 | 单个项目是否启动、是否进入组合 | 不纳入，归项目组合治理 |
组织级 PMO 的制度建设、流程规范修订属于研发治理与 PMO 机制范畴，由相应机制管理，不放进单个项目集的决策台账。这样划分的目的是让台账保持治理密度：每条记录都值得在治理会议上被问一次“执行到哪了”。
一条决策要跟踪哪些字段与执行状态
决策跟踪台账的字段可以分为四组：决策事项、责任、执行、关闭。字段设计的目标是让任何一个不参加会议的人，只看台账就能判断这条决策是否在推进、卡在哪里、由谁负责。字段不宜过多，能支撑状态判断和升级即可。
| 字段组 | 字段 | 填写要求 |
|---|---|---|
| 决策事项 | 决策编号 | 唯一编号，供状态报告和会议纪要引用 |
| 决策事项 | 议题 | 一句话说明决策针对什么问题 |
| 决策事项 | 决策结论 | 明确做什么、做到什么程度，避免模糊表述 |
| 决策事项 | 决策层级与会议来源 | 记录由哪一级治理会议作出，便于回溯授权 |
| 决策事项 | 生效范围 | 涉及哪些子项目、团队或交付物 |
| 决策事项 | 决策日期 | 结论正式生效的时间 |
| 责任 | 决策责任人 | 对决策结果负责的治理层成员 |
| 责任 | 执行责任人 | 推动落地的具体负责人，通常为项目集经理或子项目负责人 |
| 责任 | 配合方 | 需要提供资源、信息或审批的团队与角色 |
| 执行 | 执行动作 | 为落实决策需要完成的具体动作 |
| 执行 | 交付物 | 可验证的产出，如资源到岗名单、修订后的计划 |
| 执行 | 计划完成时间 | 约定的完成节点 |
| 执行 | 当前状态 | 按统一取值填写，见下文 |
| 关闭 | 关闭条件 | 满足什么条件才算执行到位 |
| 关闭 | 验证证据 | 证明执行到位的材料，如到岗记录、评审结论 |
| 关闭 | 关闭结论与关闭时间 | 由验证方给出结论并记录时间 |
状态取值建议统一为六类：待启动、执行中、受阻、已完成待验证、已关闭、已撤销。待启动表示决策已登记但执行动作尚未开始；执行中表示按计划推进；受阻表示出现资源、依赖或审批障碍，需要升级；已完成待验证表示执行责任人认为动作完成，等待验证方核对证据；已关闭表示验证通过并记录结论；已撤销表示决策因条件变化被治理层撤回，需注明撤销依据。状态取值统一后，治理会议可以直接按状态筛选，优先讨论受阻和长期停留在待验证的条目。
决策记录、决策跟踪与项目集状态监控怎么衔接
这三个概念经常被混用，实际承担不同职责。决策记录解决“决定了什么”，留存会议结论与依据；决策跟踪解决“决定执行到哪一步”，记录责任、动作与状态；项目集状态监控解决“项目集整体进展与风险如何”，关注多个项目的进度、资源和风险态势。三者通过决策编号和执行状态衔接，形成从会议结论到整体视图的链路。
| 维度 | 决策记录 | 决策跟踪 | 项目集状态监控 |
|---|---|---|---|
| 回答的问题 | 决定了什么、依据是什么 | 决定执行到哪一步 | 项目集整体进展与风险如何 |
| 主要对象 | 会议议题与结论 | 单条决策的责任、动作与状态 | 多个项目的进度、资源、风险 |
| 更新频率 | 会议结束后形成 | 随执行进展持续更新 | 按报告周期汇总 |
| 典型产出 | 会议纪要、决策清单 | 决策台账、关闭结论 | 状态报告、风险清单 |
| 衔接方式 | 提供决策编号与结论 | 提供执行状态与偏差 | 引用决策编号形成风险与偏差项 |
衔接的关键动作有两个。其一，执行受阻的决策以决策编号进入项目集状态报告的风险与偏差部分，让整体视图能反映治理决定的落地情况。其二，状态报告中反复出现或长期未解决的决策偏差，升级回治理会议，由原决策层级重新裁决或调整资源。这样，决策跟踪为状态监控提供治理视角的输入，状态监控为决策跟踪提供升级通道，两者相互支撑。
一个具体例子与常见误解
以下为演示情景。某项目集治理委员会决定为子项目 A 追加两名开发资源，以保住季度上线节点。登记时，决策编号为 D-021，议题为“子项目 A 资源缺口”，决策结论为“从共享池调配两名后端开发，投入周期六周”，决策责任人为治理委员会负责人，执行责任人为项目集经理，配合方为资源池所属部门。执行动作包括确认人选、完成交接、更新排期，交付物为到岗名单与修订后的迭代计划，关闭条件为两人到岗并完成首个迭代交付。
状态变化过程如下：登记后状态为待启动；资源部门确认人选、项目集经理更新排期后转为执行中；第二周其中一人被另一项目临时抽调，状态改为受阻，并以 D-021 进入状态报告的风险项；治理会议据此重新裁决，补充一名替代人员，状态回到执行中；六周后两人完成首个迭代交付，执行责任人提交到岗记录与迭代结果，状态转为已完成待验证；验证方核对证据后给出关闭结论，状态改为已关闭。整个过程在台账中留下完整轨迹，任何人可以回溯每个节点的判断依据。
常见误解有四条。第一，把决策跟踪当成会议纪要归档：纪要保持结论，跟踪要记录执行，只有纪要没有状态更新，治理层无法判断决定是否落地。第二，只记录决策不记录执行状态：台账停留在“已决定”，等于没有跟踪，状态字段必须随进展更新。第三，把决策关闭等同于任务完成：任务完成只说明动作做了，关闭需要验证证据支撑，例如资源是否真正到岗、交付物是否达到约定标准。第四，认为状态监控报表可以替代决策台账：状态报告按项目汇总，无法呈现单条决策的责任人与关闭条件，两者粒度不同，不能互相替代。
用工作项与文档承载决策跟踪
决策台账的字段和状态流转，需要有稳定的载体才能持续运转。一种可行做法是把每条决策登记为工作项：决策编号作为标识，议题与决策结论写入描述，决策责任人、执行责任人、配合方、计划完成时间、当前状态作为字段维护，状态取值按前述六类统一配置。这样，台账可以按状态、责任人、生效范围筛选，治理会议前直接拉出受阻和待验证条目。
决策结论、会议依据与验证证据以文档形式关联到对应工作项，形成“工作项记录状态、文档保存依据”的结构。执行责任人更新状态时附上交付物或证据链接，验证方在文档中给出关闭结论，工作项随之关闭。状态变化汇总到项目集视图，供治理会议评审整体执行情况；交接与评审过程留痕，便于日后回溯某条决策为何关闭、由谁确认。
ONES Plan 提供多项目进度管控和资源管理，支持借助项目集管理总览多项目信息，并可通过自定义项目属性、多项目数据集合多维度查看项目进度，这些能力可用于承载决策执行状态进入项目集视图后的汇总查看。决策事项本身以工作项登记、结论与证据以文档关联的做法，属于组织可自行设计的台账结构；具体字段配置与视图形式需结合所用版本确认。
常见问题
决策已经执行完成，但验证方迟迟不给结论，台账状态该怎么处理？
状态停留在“已完成待验证”本身就是需要治理层关注的信息。可以在台账中记录提交验证的时间和验证方，并在治理会议上按停留时长排序讨论。若验证方因证据不足退回，状态应回到“执行中”并注明缺口；若验证方长期无响应，由决策责任人指定替代验证人或明确验证时限。关键是让“待验证”有明确的下一步，而不是无限期挂起。
决策执行到一半，外部条件变化导致原结论不再适用，能直接关闭吗？
不能按“已关闭”处理，应改为“已撤销”并注明撤销依据，例如市场变化、上级战略调整或资源条件不再具备。撤销同样需要治理层确认，由原决策层级重新裁决，必要时生成新的决策条目替代原条目。这样台账保留完整的决策变更轨迹，后续回溯时能看清是执行到位后关闭，还是因条件变化被撤回。
项目集经理和 PMO 在决策跟踪中如何分工，避免状态更新没人负责？
一种常见分工是：PMO 负责台账口径、字段规范、状态取值统一和定期汇总，项目集经理负责推动执行责任人更新状态并核对证据，治理委员会秘书负责把会议结论转化为可跟踪的决策条目。三类动作分开，执行人不能自行认定关闭。组织规模较小时可由同一人兼任，但登记、执行、验证的角色边界仍需在流程中写明，否则容易出现状态长期不更新。
决策数量多的时候，治理会议如何高效评审执行状态？
可以按状态筛选，把会议时间优先分配给“受阻”和长期停留在“已完成待验证”的条目，“执行中”且按计划推进的条目只做批量确认。台账字段中的计划完成时间和当前状态支持这种筛选，决策编号便于与状态报告的风险项对应。评审的重点是判断是否需要重新裁决或调配资源，而不是逐条听取执行汇报。
用工作项承载决策台账时，需要注意哪些配置问题？
需要先统一状态取值，把六类状态配置为工作项状态，避免各团队自定义造成口径不一；决策编号要作为可检索的标识，便于状态报告引用；决策结论与验证证据以文档关联到工作项，保证关闭时有据可查。ONES Plan 提供多项目进度管控和资源管理，支持借助项目集管理总览多项目信息，并可通过自定义项目属性、多项目数据集合多维度查看项目进度，可用于承载决策执行状态进入项目集视图后的汇总查看；具体字段配置与视图形式需结合所用版本确认。
