确定项目集范围，起点是一个可描述的共同收益目标，再据此筛选必须放在一起协调的项目与工作包，划出纳入、暂缓和排除三类边界，并写清依赖关系、治理职责与变更触发条件。本文给出一套五步操作流程、角色分工表和完成检查清单，帮助你把一份庞杂的项目清单收敛成可交付、可治理的范围基线。
要点总览（TL;DR）
- 项目集范围的判断起点是共同收益：先写清收益对象、预期结果和时间窗口，再用它反向检验每个候选项目是否必须放在一起协调。
- 范围确定分五步：收集候选工作、按收益贡献与依赖强度分组、划定纳入/暂缓/排除三类边界、识别跨项目依赖与接口、形成范围基线并明确变更触发条件。
- 项目集经理组织分析与起草，发起人确认收益目标并审批基线，项目经理提供项目边界信息，架构与业务代表校验接口可行性。
- 范围说明书必须同时写全纳入、暂缓、排除三栏，暂缓项注明重启条件，排除项注明理由与责任人，否则边界缺乏约束力。
- 范围基线按可观察的触发条件定期复审，在治理例会上核对依赖状态与暂缓项重启条件，让范围持续支撑共同收益。
先定共同收益：项目集范围的判断起点
项目集范围回答的问题是“哪些工作必须放在一起协调，才能拿到单独做拿不到的结果”。判断依据是共同收益，项目清单只是候选材料。先写清收益，再用收益反向检验每个候选项目是否必须纳入，范围才有稳定的取舍标准。
一份可用的共同收益陈述，至少包含三个要素：收益对象（谁得到什么改善）、预期结果（可观察的业务或能力变化）、时间窗口（在什么周期内实现）。例如“在18个月内，让三个区域订单履约团队共用一套库存可见性规则，将跨区调拨的确认时长从两天缩短到半天”，比“提升供应链协同能力”更能支撑范围判断，因为它指明了受益对象、结果口径和时间边界。
用收益检验项目关联性，可以问四个问题：
- 如果这个项目单独实施、不与项目集中其他工作协同，共同收益是否仍然能够实现？
- 该项目产出的数据、接口、流程或组织调整，是否被其他项目依赖，或依赖其他项目？
- 去掉该项目，收益的实现时间、覆盖范围或质量会受多大影响？
- 该项目与共同收益之间是直接贡献，还是仅存在资源或人员上的间接关联？
前两个问题回答“是否必须协同”，后两个问题回答“协同的紧密程度”。仅共享预算、共享人员或同属一个部门，不构成纳入项目集的充分理由。
需要区分项目组合管理与项目集范围。项目组合管理解决“在有限投资下选哪些项目、如何排序”，关注投资回报与资源分配；项目集范围解决“已决定要拿到的共同收益，需要哪些工作放在一起协调”。投资选择与优先级排序属于项目组合层面，本文不展开。范围确定时可以直接采用组合层面已批准的项目作为候选输入，不再重新论证投资价值。
范围确定五步：从候选工作到边界清单
五步流程把共同收益转化为范围基线。每一步都有明确输入、动作、输出和完成标志，完成标志用于判断该步是否可以结束、进入下一步。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 收集候选项目与工作包 | 组合层已批准项目清单、业务部门提出的需求、现有系统与流程改造计划 | 汇总所有可能支撑共同收益的项目、工作包和持续性运营工作，标注来源、负责人、预估周期 | 候选工作清单（含来源与初步描述） | 候选清单覆盖所有已知来源，每项有提出人和一句话说明 |
| 2. 按收益贡献与依赖强度分组 | 候选工作清单、共同收益陈述 | 逐项判断对共同收益的直接贡献程度，以及与其他候选项的依赖强度，分为核心组、支撑组、弱关联组 | 分组结果与判断理由 | 每项候选工作都有分组结论和至少一条理由 |
| 3. 划定纳入、暂缓、排除三类边界 | 分组结果、资源与时间约束 | 核心组纳入；支撑组按依赖必要性和时间窗口决定纳入或暂缓；弱关联组排除，并写明排除理由 | 三类边界清单 | 每个暂缓项有重启条件，每个排除项有理由和责任人 |
| 4. 识别跨项目依赖与接口 | 纳入项清单 | 逐对识别交付物依赖、数据接口、共享资源、流程衔接点，标注提供方、接收方和交接时点 | 依赖与接口清单 | 每个依赖落到具体交付物或交接点，有双方确认人 |
| 5. 形成范围基线并明确变更触发条件 | 三类边界清单、依赖与接口清单 | 汇总为范围说明书，明确基线版本、审批人，列出触发范围复审的条件 | 范围基线（含版本与审批记录） | 基线经发起人审批，变更触发条件可观察、可判断 |
第二步的分组判断需要克制。收益贡献按“缺了它共同收益是否无法实现或明显延迟”来定，依赖强度按“是否必须与其他项目同步设计或同步上线”来定。两项都强的进入核心组；只有依赖强、贡献间接的进入支撑组；两者都弱的进入弱关联组，通常应排除。
第三步的三类边界要同时写全。只写纳入项的范围说明书，在后续讨论中容易被不断追加，因为没有任何书面依据说明某项工作为何不在范围内。暂缓项要写清重启条件，例如“待主数据治理项目完成编码统一后重新评估”；排除项要写清理由和提出人，便于日后回溯。
第五步的变更触发条件应当是可观察的事件，例如共同收益目标调整、关键依赖项目取消或延期超过一个季度、监管要求变化、预算规模变动超过约定比例。触发条件写成“情况发生重大变化”无法执行，写成具体事件才能在治理例会上被识别。
角色与交付物：谁定范围、谁签字、谁维护
范围确定是集体判断加明确授权的过程。项目集经理组织分析与起草，发起人对基线签字，项目经理提供各自项目的边界信息，架构与业务代表校验依赖和接口的可行性。
| 角色 | 主要职责 | 关键交付物 |
|---|---|---|
| 项目集发起人 | 确认共同收益目标，审批范围基线，裁决纳入与排除的争议 | 收益目标确认、范围基线审批记录 |
| 项目集经理 | 组织候选收集、分组分析、边界划定与依赖识别，起草范围说明书，维护基线版本 | 候选工作清单、三类边界清单、依赖与接口清单、范围说明书 |
| 项目经理 | 提供本项目的工作包构成、交付时间与对外依赖，确认纳入后的资源与进度影响 | 项目级工作包说明、依赖确认 |
| 架构/业务代表 | 校验跨项目接口的技术与流程可行性，指出共享组件和标准不一致风险 | 接口与依赖的技术确认意见 |
范围说明书建议包含以下字段：项目集名称与版本号、共同收益陈述、收益对象与时间窗口、纳入项清单（含负责人与预期交付）、暂缓项清单（含重启条件）、排除项清单（含理由与提出人）、跨项目依赖与接口、治理与决策机制、变更触发条件、审批人与审批日期。字段不必多，但纳入、暂缓、排除三栏必须齐全，否则基线不完整。
范围基线的审批权在发起人，项目集经理负责日常维护。变更请求由提出人说明对收益、依赖和进度的影响，项目集经理评估后提交发起人决策，批准后更新版本号并通知所有项目经理。范围基线的状态管理可以借助协作工具承载：在ONES中，纳入项可作为工作项关联到项目集，范围说明书作为文档保留版本与审批记录，变更请求走统一的工作项状态流转，使基线版本与变更历史可追溯。工具承载的是记录与流转，判断标准仍来自前述收益与依赖分析。
示例：一次范围收敛的实际推演
以下为演示情景。某制造企业计划在一年内实现“跨工厂订单统一承诺交期”，共同收益陈述为：让三个工厂的销售与计划团队基于同一套产能与库存规则回复客户交期，将承诺准确率提升到约定水平，时间窗口为12个月。
初始候选清单包含八项工作：产能数据平台建设、库存可见性改造、交期承诺规则设计、三个工厂各自的排产系统升级、客户门户改版、销售培训体系重构、工厂网络带宽扩容、历史订单数据清洗。
| 候选工作 | 边界结论 | 判断理由 |
|---|---|---|
| 产能数据平台建设 | 纳入 | 三个工厂共用产能规则的前提，缺此无法形成统一承诺 |
| 库存可见性改造 | 纳入 | 交期承诺依赖实时库存，与产能平台存在数据接口 |
| 交期承诺规则设计 | 纳入 | 共同收益的核心交付物，需与两个平台同步设计 |
| 三个工厂排产系统升级 | 纳入（分两批） | 向产能平台提供排产数据，按工厂分批上线以控制风险 |
| 客户门户改版 | 暂缓 | 交期展示可在现有门户以接口方式实现；待承诺规则稳定后重启改版 |
| 销售培训体系重构 | 暂缓 | 首期采用专项培训即可支撑上线；体系化重构待规则运行一个季度后评估 |
| 工厂网络带宽扩容 | 排除 | 属于基础设施日常运维，由IT运维计划单独安排，不构成项目集协同需求 |
| 历史订单数据清洗 | 排除 | 仅用于报表分析，不影响交期承诺规则的计算口径；由数据团队另行立项 |
依赖与接口的标注方式示例：产能数据平台向交期承诺规则提供“工厂-产线-周产能”接口，提供方为平台项目组，接收方为规则设计组，交接时点为规则设计完成前两周；库存可见性改造向规则提供实时库存查询接口，双方需在第二批工厂上线前完成联调。每个接口都写明提供方、接收方、交接物和时点，避免停留在“两个项目要配合”的描述。
最终范围基线以三栏清单加依赖表呈现，附版本号与审批记录。暂缓项注明重启条件，例如客户门户改版在承诺规则稳定运行一个季度后评估；排除项注明责任团队，便于后续追踪。基线发布后，任何新增工作需按变更触发条件评估是否进入范围。
完成检查：范围是否可交付、可治理
范围确定工作结束时，用以下清单逐项核对。全部通过，范围才具备进入执行与治理的条件。
- 共同收益陈述包含收益对象、预期结果和时间窗口，且发起人已确认。
- 每个纳入项都能说明其对共同收益的直接贡献，或说明其被依赖的必要性。
- 纳入、暂缓、排除三类边界齐全；暂缓项有重启条件，排除项有理由和责任人。
- 跨项目依赖与接口已落到具体交付物、提供方、接收方和交接时点，双方确认人明确。
- 范围说明书字段完整，版本号与审批记录可查。
- 变更触发条件是可观察的具体事件，能在治理例会上被识别和判断。
- 范围基线的维护责任人和变更审批路径已书面明确。
两个常见误区值得单独检查。其一，把相关项目全量纳入：凡是同部门、同预算或同系统的项目都放进项目集，结果是协调成本上升、收益目标被稀释。检查方法是逐项追问“缺了协同是否拿不到共同收益”，答不上来的应移出或暂缓。其二，范围只写纳入不写排除：没有排除项和暂缓项，边界就没有约束力，后续追加缺乏拒绝依据。检查方法是确认三类边界都有内容，且排除项写明了理由。
范围基线不是一次定稿后不再变动的文件。按约定的触发条件定期复审，在治理例会上核对依赖状态与暂缓项的重启条件，才能让范围持续支撑共同收益的实现。
常见问题
共同收益目标写不出来，范围还能先定吗？
不建议先定范围再补收益。收益陈述是范围取舍的唯一稳定标准，缺了它，纳入与排除的判断只能依赖部门归属或资源关系，后续讨论容易被不断追加。如果一时写不出完整收益，可以先写出收益对象和预期结果的初稿，明确时间窗口待定，再据此做第一轮分组；但范围基线审批前，收益陈述需要由发起人确认。收益目标本身发生变化时，范围基线应随之复审。
暂缓项和排除项在实际操作中有什么区别？
暂缓项是当前不纳入范围、但存在明确重启条件的工作，例如“待主数据编码统一后重新评估”；排除项是判断为不属于本项项目集协同需求的工作，需要写明理由和提出人。区别在于后续处理方式：暂缓项要在治理例会上跟踪重启条件是否满足，排除项一般不主动重提，除非提出人按变更流程重新申请。两类都要写进范围说明书，只写纳入项会让边界失去约束力。
范围基线定下来后，什么情况下需要重新走审批？
按基线中约定的变更触发条件判断，常见触发事件包括共同收益目标调整、关键依赖项目取消或延期超过约定周期、监管要求变化、预算规模变动超过约定比例。触发后由提出人说明对收益、依赖和进度的影响，项目集经理评估，发起人决策，批准后更新版本号并通知所有项目经理。触发条件要写成可观察的具体事件，写成“情况发生重大变化”在例会上无法判断是否触发。
项目集经理和项目经理在范围确定中的分工怎么划？
项目集经理负责组织候选收集、分组分析、边界划定和依赖识别，起草范围说明书并维护基线版本；项目经理提供本项目的工作包构成、交付时间与对外依赖，确认纳入后对资源和进度的影响。范围基线的审批权在发起人，争议由发起人裁决。架构或业务代表负责校验跨项目接口的技术与流程可行性。分工写清楚，范围收敛过程才不会变成项目集经理单方面拼清单。
范围确定完成后，怎么在工具里保持基线可追溯？
关键是让纳入项、范围说明书和变更请求三者保持关联。在ONES中，纳入项可以作为工作项关联到项目集，范围说明书以文档形式保留版本与审批记录，变更请求通过统一的工作项状态流转，基线版本与变更历史可以追溯。工具承载记录与流转，判断标准仍来自收益与依赖分析，两者不能互相替代。
