项目集综合进度表把多个关联项目的计划、里程碑、依赖和整体状态汇总到一张表里，让项目集经理能在一个视图中判断整体推进情况。本文提供一份可直接复制填写的空白表格，逐字段说明填写口径，区分必填与选填，并给出完整示例和长期维护方法。在工具承载上，ONES 可用于项目集层面的计划与里程碑统筹，本文的表格结构也可作为系统内视图设计的参照。
要点总览（TL;DR）
- 模板分五个区块：项目集基本信息、项目清单、里程碑、跨项目依赖、整体状态，复制到表格工具即可填写。
- 必填字段集中在定位与判断类信息：项目编号、负责人、计划起止、里程碑编号与计划日期、依赖影响里程碑、偏差说明与下一步动作。
- 填写示例演示三个关联项目如何通过依赖编号把延期影响传导到下游里程碑，便于项目集经理判断连锁影响。
- 维护上按汇报周期更新，各项目负责人更新本项目行，项目集负责人汇总依赖与整体状态，计划日期变更单独记录。
- 项目数量少可精简进度百分比与依赖状态，项目多或跨部门协作多时可增加优先级与依赖风险等级字段。
可复制空白模板：项目集综合进度表
模板分为五个区块：项目集基本信息、项目清单、里程碑、跨项目依赖、整体状态。复制到表格工具后，按区块逐行填写即可。区块之间通过项目名称和里程碑编号关联，填写时保持编号一致。
区块一：项目集基本信息
| 字段 | 填写内容 |
|---|---|
| 项目集名称 | |
| 项目集负责人 | |
| 表格版本 | |
| 更新日期 | |
| 本期汇报周期 |
区块二：项目清单
| 项目编号 | 项目名称 | 项目负责人 | 计划开始 | 计划结束 | 当前阶段 | 进度百分比 |
|---|---|---|---|---|---|---|
区块三：里程碑
| 里程碑编号 | 里程碑名称 | 所属项目 | 计划日期 | 实际/预测日期 | 状态 | 负责人 |
|---|---|---|---|---|---|---|
区块四：跨项目依赖
| 依赖编号 | 依赖来源项目 | 依赖对象 | 接收方项目 | 影响里程碑 | 约定交付日期 | 依赖状态 |
|---|---|---|---|---|---|---|
区块五：整体状态
| 项目编号 | 整体状态 | 偏差说明 | 下一步动作 | 动作负责人 | 计划完成日期 |
|---|---|---|---|---|---|
字段说明：每个字段填什么、怎么填
同一张表由不同项目负责人填报时，最容易出现口径不一致：日期有的填计划、有的填预测，状态有的写“正常”、有的写“顺利”。下面按字段类别统一口径，让各项目的填报可以直接横向比较。
标识类字段的命名规则
项目编号建议采用“项目集缩写-两位序号”的格式，例如“CRM-01”“CRM-02”，编号一经分配不再复用。里程碑编号在项目编号后追加“-M”加序号，例如“CRM-01-M1”，这样从编号就能看出里程碑归属哪个项目。依赖编号用“项目编号-D序号”，例如“CRM-01-D1”，表示该项目对外的一条依赖。编号的作用是让里程碑表和依赖表能准确引用项目清单中的行，避免用项目名称做关联时因改名而断链。
时间类字段的口径区别
计划日期是立项或计划评审时确认的基准日期，除非走变更流程，否则不修改。实际日期是已经发生的事实，里程碑完成当天填写。预测日期用于尚未完成的里程碑，由负责人根据当前进展给出最新估计，每次更新时覆盖旧值。三者的关系是：里程碑未完成时看计划日期与预测日期的差距，完成后看计划日期与实际日期的差距。表格中“实际/预测日期”合并为一列，填写规则是已完成填实际日期，未完成填预测日期，并在状态列区分。
状态类字段的取值集合与判定标准
里程碑状态建议固定为四个取值：未开始、进行中、已完成、已延期。判定标准是：计划日期未到且无工作启动为未开始；已启动但未达成为进行中；达成并确认交付物为已完成；预测日期晚于计划日期为已延期。项目整体状态建议用三个取值：正常、关注、风险。正常指关键里程碑按计划推进；关注指存在偏差但已有明确的追赶动作；风险指偏差影响项目集关键节点且暂无可行方案。取值集合固定后，汇总统计才能按状态计数。
依赖字段的记录方式
一条依赖记录一行，写明来源项目、依赖对象（具体交付物或决策）、接收方项目和受影响的里程碑编号。依赖对象要写到可验收的粒度，例如“用户中心接口联调完成”比“接口支持”更便于判断是否兑现。约定交付日期是双方确认的日期，与来源项目自己的计划日期可能不同，以约定日期作为依赖状态的判断依据。
偏差说明与下一步动作的写法
偏差说明写“事实加影响”，例如“支付模块联调比计划晚 5 个工作日，影响 CRM-01-M2 验收”。下一步动作写“动作加负责人加日期”，例如“由张伟协调测试资源，6 月 20 日前完成联调”。两栏配合使用，读者不需要再追问就能知道问题是什么、谁来处理、什么时候有结果。避免只写“进度滞后，正在跟进”这类无法核验的表述。
必填与选填：哪些字段不能空
必填字段的作用是保证表格能被汇总和追责，选填字段用于补充背景。判断标准很简单：缺少该字段会导致无法定位责任人或无法判断进度，就设为必填。
必填字段清单及理由
- 项目集名称、项目集负责人、更新日期：确定表格的归属和时效，缺少更新日期的表格无法判断信息是否可用。
- 项目编号、项目名称、项目负责人、计划开始、计划结束：项目清单的基础定位信息，用于关联里程碑和依赖。
- 里程碑编号、里程碑名称、所属项目、计划日期、状态：里程碑是项目集进度的判断依据，这五项缺一不可。
- 依赖编号、依赖来源项目、依赖对象、影响里程碑：依赖不写清影响哪个里程碑，就无法评估连锁影响。
- 整体状态、偏差说明、下一步动作：状态为“关注”或“风险”时，偏差说明和下一步动作必须填写。
选填字段清单及适用场景
- 本期汇报周期：适用于按固定周期（如双周、月度）向管理层汇报的项目集。
- 进度百分比：适用于需要粗粒度量化对比的项目，若团队以里程碑达成率衡量进度，可省略。
- 实际/预测日期：里程碑未开始时可以留空，进入进行中后应填写预测日期。
- 依赖的约定交付日期、依赖状态：依赖刚识别、双方尚未确认日期时可暂缓。
- 动作负责人、计划完成日期：整体状态为“正常”且无偏差时可留空。
可暂缓填写的字段与补录时点
项目启动阶段，里程碑的实际/预测日期、依赖的约定交付日期可以暂缓，补录时点分别是里程碑进入进行中、依赖双方完成确认。进度百分比在项目首次周报后补录。暂缓填写的字段在表格中用“待补”标注，并在下一次更新时检查是否已补齐，避免“待补”长期滞留。
字段留空时的标注方式
统一用“—”表示该字段不适用（例如尚未开始的里程碑没有实际日期），用“待补”表示应当填写但暂未取得信息。两种标注含义不同：前者说明字段与当前情况无关，后者说明存在待办。汇总时统计“待补”数量，可以作为表格完整度的一个检查指标。
填写示例：一个项目集的完整填法
以下示例为演示情景，用于说明各区块如何配合填写，不代表真实项目数据。假设某项目集包含三个关联项目，处于第二个汇报周期。
示例项目集的基本信息
| 字段 | 填写内容 |
|---|---|
| 项目集名称 | 客户服务平台升级项目集 |
| 项目集负责人 | 李敏 |
| 表格版本 | V1.2 |
| 更新日期 | 2025-06-13 |
| 本期汇报周期 | 2025-06-02 至 2025-06-13 |
示例项目清单
| 项目编号 | 项目名称 | 项目负责人 | 计划开始 | 计划结束 | 当前阶段 | 进度百分比 |
|---|---|---|---|---|---|---|
| CS-01 | 用户中心重构 | 张伟 | 2025-04-01 | 2025-08-29 | 开发联调 | 55% |
| CS-02 | 工单系统迁移 | 王芳 | 2025-04-15 | 2025-09-30 | 开发 | 40% |
| CS-03 | 数据看板建设 | 陈磊 | 2025-05-06 | 2025-10-31 | 需求确认 | 15% |
示例里程碑与依赖
| 里程碑编号 | 里程碑名称 | 所属项目 | 计划日期 | 实际/预测日期 | 状态 | 负责人 |
|---|---|---|---|---|---|---|
| CS-01-M1 | 用户中心接口设计评审通过 | CS-01 | 2025-05-09 | 2025-05-09 | 已完成 | 张伟 |
| CS-01-M2 | 用户中心接口联调完成 | CS-01 | 2025-06-20 | 2025-06-27 | 已延期 | 张伟 |
| CS-02-M1 | 工单数据迁移方案确认 | CS-02 | 2025-06-06 | 2025-06-06 | 已完成 | 王芳 |
| CS-03-M1 | 看板指标口径确认 | CS-03 | 2025-06-30 | 2025-06-30 | 进行中 | 陈磊 |
| 依赖编号 | 依赖来源项目 | 依赖对象 | 接收方项目 | 影响里程碑 | 约定交付日期 | 依赖状态 |
|---|---|---|---|---|---|---|
| CS-01-D1 | CS-01 | 用户中心接口联调完成 | CS-02 | CS-02-M2 | 2025-06-27 | 进行中 |
| CS-02-D1 | CS-02 | 工单历史数据清洗结果 | CS-03 | CS-03-M2 | 2025-07-11 | 未开始 |
示例整体状态与偏差说明
| 项目编号 | 整体状态 | 偏差说明 | 下一步动作 | 动作负责人 | 计划完成日期 |
|---|---|---|---|---|---|
| CS-01 | 关注 | 接口联调比计划晚 5 个工作日，影响 CS-01-M2 验收，并推迟 CS-02 的接口对接 | 协调测试环境与联调资源，压缩回归测试周期 | 张伟 | 2025-06-27 |
| CS-02 | 正常 | — | 按计划推进迁移脚本开发，等待 CS-01 接口就绪 | 王芳 | 2025-06-27 |
| CS-03 | 正常 | — | 6 月 20 日前完成指标口径评审 | 陈磊 | 2025-06-20 |
从示例可以看到，CS-01 的延期通过依赖编号 CS-01-D1 传导到 CS-02 的里程碑，项目集负责人据此判断是否需要调整 CS-02 的计划，而不必逐个询问项目负责人。这正是综合进度表相对于单项目进度表的价值：把跨项目的连锁影响显性化。
调整与维护方法：按团队情况改表并持续更新
模板是起点，项目集规模、治理要求和汇报节奏不同，字段和行数需要相应调整。维护的重点是让表格在每次更新后仍然可信、可比较。
按项目集规模增减字段与行
项目数量在五个以内、依赖关系简单的项目集，可以省略进度百分比和依赖状态，用里程碑状态加偏差说明就足以判断整体情况。项目数量超过十个或跨部门协作较多时，建议增加“项目优先级”和“依赖风险等级”两个字段，便于在汇总时排序和聚焦。里程碑行数按每个项目的关键节点控制，通常每个项目保留三到六个对项目集有影响的里程碑，项目内部的细粒度节点留在单项目计划中。
更新频率与更新责任人
建议按汇报周期更新，例如双周一次，与项目集例会节奏对齐。分工上，各项目负责人更新本项目行和里程碑的预测日期与状态，项目集负责人汇总依赖和整体状态，并在更新日期栏记录本次更新时间。遇到里程碑延期或依赖变更时，不等下一个周期，当天更新并在例会中说明。
版本与变更记录方式
每次发布在表格版本栏递增，例如 V1.2 到 V1.3，同时在表格下方或单独的变更记录区写明变更内容、变更人和日期。计划日期的调整属于基准变更，需要记录变更原因和批准人；预测日期的更新属于例行维护，只需保留最新值。版本记录让读者能追溯某次状态变化是数据更新还是计划调整。
与项目进度表、依赖清单的衔接
综合进度表不替代单项目进度表，两者的关系是汇总与明细：项目清单中的计划起止和当前阶段来自各项目进度表的汇总，里程碑行选取对项目集有影响的关键节点，依赖区与项目间的依赖清单保持编号一致。更新时先更新单项目进度表，再同步到综合进度表，避免两处数据各自维护产生冲突。在工具层面，ONES Plan 支持借助项目集管理总览多项目信息，并提供里程碑与甘特图、多时间跨度查看进度，可将本文的字段结构对应为系统内的项目属性与视图；ONES 瀑布项目管理方案支持设置项目计划和里程碑基线，实时对比计划与执行的偏差，适合需要把“计划日期与实际/预测日期”的对比固定下来的项目集。表格中的状态取值、更新频率等规则属于建议做法，团队可结合自身治理要求调整。
常见问题
项目集综合进度表和单项目进度表是什么关系，两张表都要维护吗？
两张表承担不同职责。单项目进度表记录项目内部的详细任务、资源和排期，是明细；项目集综合进度表从各项目进度表中提取计划起止、当前阶段和关键里程碑，做汇总与横向比较。实际操作中先更新单项目进度表，再同步到综合进度表，避免两处各自维护产生数据冲突。项目内部的细粒度节点留在单项目计划里，综合进度表每个项目通常只保留三到六个对项目集有影响的里程碑。
里程碑的计划日期需要调整时，表格里怎么处理才不混乱？
计划日期属于基准，调整要走变更流程并留下记录：在变更记录区写明原日期、新日期、变更原因和批准人，表格版本号递增。预测日期则不同，它随进展更新，每次覆盖旧值即可，不需要逐次留痕。这样读者能区分某次日期变化是计划基准调整还是例行进展更新。若团队使用 ONES 瀑布项目管理方案，可设置项目计划和里程碑基线，实时对比计划与执行的偏差。
依赖双方还没谈定交付日期，这一行先空着还是先不填？
依赖一旦识别就应登记，来源项目、依赖对象、接收方项目和影响里程碑四项先填上，约定交付日期和依赖状态用“待补”标注。补录时点是双方完成确认之后。登记的价值在于让项目集经理提前看到影响哪个里程碑，即使日期未定也能评估连锁风险。若长期停留在“待补”，应在例会上推动双方确认，避免依赖在临近交付时才暴露。
项目集规模变大后，模板需要增加哪些字段？
项目数量超过十个或跨部门协作较多时，可增加“项目优先级”和“依赖风险等级”两个字段，便于汇总时排序和聚焦高风险项。里程碑行数仍按关键节点控制，不随项目数量线性膨胀。反过来，项目在五个以内、依赖简单的项目集，可以省略进度百分比和依赖状态，用里程碑状态加偏差说明判断整体情况。字段增减以能否支撑汇总判断为标准，不追求字段齐全。
表格里的状态取值可以按团队习惯改吗？
可以，但取值集合一旦确定就应固定，并在表格说明中写明判定标准，否则汇总统计无法按状态计数。里程碑状态建议保持未开始、进行中、已完成、已延期四类，项目整体状态保持正常、关注、风险三类。团队可以调整措辞，但需保证每个取值有明确、可核验的判定条件，例如“关注”对应存在偏差且已有追赶动作。状态取值、更新频率这类规则属于建议做法，可结合项目集治理要求调整。
