项目集目标从跨项目的共同收益出发确定，把各项目目标简单相加并不能形成项目集目标。本文围绕目标确定阶段，说明如何判断项目集边界、按六步流程形成可度量目标、用目标卡写清字段、落实角色分工，并用检查清单判断目标是否可评审、可跟踪。
要点总览（TL;DR）
- 项目集目标从跨项目共同收益出发确定，先判断项目之间是否存在关联性、依赖关系和共同收益，三项均不成立时按独立项目或项目组合处理。
- 目标确定按六步推进：收集战略与业务输入、识别共同收益假设、转成可度量目标、划定范围与排除项、明确责任人与验收口径、治理层评审确认并建立变更机制。
- 目标卡需写清目标陈述、收益类型、度量指标、基线值、目标值、时间窗口、关联项目与依赖、责任人和验收标准，并区分结果型目标与过程型目标。
- 发起人提供战略输入并确认目标，项目集经理组织收益识别与目标编写，项目经理提供可行性与依赖信息，治理机构评审确认目标与变更。
- 完成检查重点看目标与收益的对应关系、指标四要素是否齐全、范围与排除项是否明确、验收口径能否复核，未通过项在治理评审前补齐。
先判断这是不是项目集：目标确定的前提
项目集的存在理由是协调一组关联工作，获得单个项目无法独立实现的共同收益。目标确定的第一步，是确认手头这批项目是否构成项目集。如果只是若干互不相关的项目放在一张清单上，各自目标独立成立，那么需要的是分别设定项目目标，再在项目组合层面做投资取舍，这属于项目组合管理的范围，不在本文展开。
判断可以围绕三项标准展开，三项中至少前两项成立，才有必要按项目集方式确定共同目标。
| 判断项 | 要回答的问题 | 成立时的表现 | 不成立时的处理 |
|---|---|---|---|
| 关联性 | 这些项目是否服务于同一业务变化或同一战略主题 | 项目之间存在共享的交付物、流程或用户群体 | 按独立项目分别设定目标 |
| 依赖关系 | 项目之间是否存在前后置、接口、共享资源或共同上线要求 | 一个项目的延期或变更会直接影响另一个项目的收益 | 梳理依赖后再判断是否需要协调管理 |
| 共同收益 | 是否存在只有协同推进才能实现的收益 | 收益来自多个项目成果的组合，单独交付无法兑现 | 收益可拆分归属时，回到单项目目标 |
三项标准都不成立时，不要急于编写项目集目标。更稳妥的做法是先拆清范围：把共享依赖单独列为协调事项，把可独立交付的部分还原为项目，再判断剩余工作是否需要组成项目集。边界不清就定目标，常见后果是目标写得很大，却找不到对应的责任项目和验收依据。
核心答案与操作步骤：六步确定项目集目标
项目集目标的确定可以按六个步骤推进。每一步都有明确输入、动作、输出和完成标志，前一步的输出构成后一步的输入。流程的目标是形成一组经治理层确认、可度量、可跟踪的目标条目，而非一份方向性描述。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 第一步：收集战略与业务输入 | 组织战略主题、业务部门诉求、上一周期收益回顾、外部约束 | 梳理目标来源，区分战略驱动、业务驱动与合规驱动，记录每项输入的提出方 | 目标来源清单 | 每项目标来源都能追溯到具体战略主题或业务诉求，并注明提出方 |
| 第二步：识别共同收益假设 | 目标来源清单、项目集边界判断结果 | 组织发起人、项目集经理、项目经理共同识别跨项目收益，写成收益陈述，标注假设条件 | 收益假设清单 | 每条收益说明受益对象、收益内容和实现前提，且明确需要哪些项目成果组合才能兑现 |
| 第三步：把收益转成可度量目标 | 收益假设清单 | 为每条收益选择度量指标，确定基线值、目标值和时间窗口，检查指标能否被现有数据支撑 | 可度量目标草案 | 每条收益至少对应一个指标，指标具备基线、目标值和时限三要素 |
| 第四步：划定项目范围与排除项 | 可度量目标草案、项目清单 | 明确哪些项目支撑哪些目标，写出本期不纳入的项目、场景和收益 | 目标—项目映射表与排除项说明 | 每个目标都有支撑项目，每个纳入项目都能说明支撑哪个目标，排除项有书面记录 |
| 第五步：明确责任人与验收口径 | 目标—项目映射表 | 为每个目标指定目标责任人，约定验收数据来源、验收时点和判定方式 | 目标责任矩阵与验收口径说明 | 每个目标有唯一责任人，验收口径可被第三方按同一方式复核 |
| 第六步：治理层评审确认并建立变更机制 | 目标卡、责任矩阵、验收口径 | 提交治理机构评审，记录评审意见与确认结论，约定变更触发条件和复审节奏 | 经确认的目标基线、变更规则 | 治理机构形成确认结论，变更触发条件与复审周期写入项目集管理文件 |
六步中最容易被跳过的是第二步和第四步。收益假设不写清楚，后面的指标就会变成对现有项目指标的重新包装；范围与排除项不写，目标就会在執行中不断被追加内容，最终无法验收。建议把这两步的产出作为评审的必查项。
目标卡怎么写：字段与填写要求
目标卡是承载单条项目集目标的最小单元，作用是把收益假设落成可评审、可跟踪的条目。字段不必多，但每个字段都要能回答评审时的追问。
| 字段 | 填写要求 | 常见问题 |
|---|---|---|
| 目标陈述 | 用一句话说明通过项目集协同要达成的结果，包含受益对象和变化方向 | 写成“提升协同效率”这类方向性口号，无法判断是否达成 |
| 收益类型 | 标注财务收益、效率收益、风险合规收益或能力建设收益 | 所有目标都标为效率收益，掩盖收益性质的差异 |
| 度量指标 | 写明指标名称、计算方式和数据来源 | 指标名称含糊，不同人算出不同结果 |
| 基线值 | 填写目标确定时的实际水平，注明统计口径和时间 | 基线缺失，目标值无法判断改进幅度 |
| 目标值 | 给出目标期结束时要求达到的数值或状态 | 只写“显著改善”，没有可比较的数值 |
| 时间窗口 | 写明起算时间、目标达成时点和关键检查点 | 只写项目集结束时间，缺少中间检查节点 |
| 关联项目与依赖 | 列出支撑该目标的项目，标注项目间关键依赖 | 目标与项目脱节，找不到交付来源 |
| 责任人 | 填写对目标达成负责的单一责任人及其角色 | 写成多个部门共同负责，实际无人推动 |
| 验收标准 | 说明验收数据、验收时点、判定规则和未达成的处理方式 | 验收时临时商量口径，结论难以服众 |
填写时还要区分结果型目标与过程型目标。结果型目标描述业务或组织状态的变化，例如某类业务处理周期缩短到约定水平；过程型目标描述项目集自身要建立的能力或交付物，例如完成统一数据标准的制定并被各项目采用。两类目标都需要，但目标卡中应标明类型，避免用过程型目标的完成代替结果型目标的达成。评审时优先看结果型目标，过程型目标作为支撑条件管理。
角色及交付物：谁定目标、谁确认、谁跟踪
项目集目标不宜由项目集经理单方拟定。目标涉及战略意图、项目可行性和资源约束，需要多方输入并经过治理确认。角色分工的核心是让每个环节都有明确的输入提供者和结论确认者。
| 角色 | 主要职责 | 交付物 | 交接节点 |
|---|---|---|---|
| 项目集发起人 | 提供战略与业务输入，对目标方向和收益优先级做出判断，确认最终目标 | 目标来源说明、目标确认意见 | 第一步提供输入，第六步确认目标基线 |
| 项目集经理 | 组织收益识别、目标编写和目标卡维护，协调各项目提供信息 | 收益假设清单、目标卡、目标—项目映射表 | 第二至第五步主导产出，第六步提交评审 |
| 项目经理 | 提供项目层交付可行性、依赖关系和资源约束信息，确认本项目对目标的支撑关系 | 项目可行性说明、依赖清单 | 第二步和第四步提供输入，执行期反馈目标进展 |
| 治理机构 | 评审目标的合理性、可度量性和范围边界，确认目标基线，审批目标变更 | 评审结论、变更审批记录 | 第六步确认目标，后续按复审节奏跟踪 |
跟踪环节通常由项目集经理组织，按约定的复审节奏收集目标进展数据，向治理机构报告偏差。目标责任人对自己负责的目标提供进展说明和风险判断。治理机构在偏差超出约定阈值时决定是否调整目标、范围或资源。角色之间通过目标卡和评审记录交接，减少口头约定带来的理解偏差。
当目标条目、支撑项目和验收记录需要在同一处维护时，可以借助项目集管理工具承载。ONES Plan 提供项目集管理能力，支持多项目总览和自定义项目属性管理不同类型项目，并通过里程碑与甘特图查看多时间跨度的进度；其甘特图可与 ONES Project 中的项目和迭代关联，查看工作量和进度。目标卡字段的具体承载方式需按实际版本功能确认，可以在工具中建立目标条目并与支撑项目关联，使目标责任人和验收口径有据可查。
示例：一个跨系统改造项目集的目标确定过程
以下为演示情景，用于说明方法如何落地，不代表真实客户案例。
某企业启动一个跨系统改造项目集，包含三个项目：客户主数据统一、订单流程重构、报表平台升级。三个项目共享客户与订单数据，订单流程重构依赖主数据统一后的编码规则，报表平台升级需要前两个项目提供的新数据接口。三项判断均成立，可以按项目集方式确定目标。
第二步识别出的共同收益假设包括：客户与订单数据在各系统间保持一致，减少人工核对；订单处理环节减少重复录入；管理层能按统一口径查看订单与客户数据。每条假设都标注了实现前提，例如编码规则需在订单流程重构上线前确定。
第三步把收益转成可度量目标。以“减少人工核对”为例，指标设为每月人工核对工单数量，基线值为改造前三个月的月均值，目标值为下降至约定水平，时间窗口为报表平台升级上线后三个月。目标卡填写如下：
| 字段 | 示例内容 |
|---|---|
| 目标陈述 | 客户与订单数据在核心系统间保持一致，业务人员日常核对工作量降至约定水平 |
| 收益类型 | 效率收益 |
| 度量指标 | 每月人工数据核对工单数量，数据来源为运维工单系统 |
| 基线值 | 改造前三个月月均工单数，统计口径为数据不一致类工单 |
| 目标值 | 降至基线值的约定比例以下 |
| 时间窗口 | 报表平台升级上线后三个月内达成，上线后第一个月设中间检查点 |
| 关联项目与依赖 | 客户主数据统一、订单流程重构、报表平台升级；依赖编码规则先行确定 |
| 责任人 | 项目集经理指定一名数据治理负责人 |
| 验收标准 | 以工单系统连续三个月数据为准，由治理机构复核；未达成时分析原因并决定是否调整目标或补充措施 |
第四步划定范围时，项目集明确本期不纳入供应商主数据统一，也不承诺财务系统改造，相关诉求记录为排除项，留待后续评估。这一取舍使目标覆盖的项目范围与可交付成果匹配，避免目标在执行中被不断追加。第五步为每个目标指定责任人并约定验收数据来源，第六步由治理机构评审确认，同时约定每季度复审一次，当关键依赖项目发生范围变更或目标值连续两个检查点未达预期时触发目标复审。
完成检查：目标是否可评审、可跟踪
目标确定工作是否完成，可以用一份检查清单逐项核对。清单未通过的项目应作为阻断项处理，在治理评审前补齐，避免带着缺口进入执行阶段。
| 检查项 | 通过标准 | 未通过时的处理 |
|---|---|---|
| 目标与共同收益的对应关系 | 每条目标都能追溯到收益假设，每条收益至少有一个目标承接 | 补充收益陈述或调整目标，消除无来源目标 |
| 指标要素齐全性 | 指标、基线、目标值、时限四项齐全，计算方式和数据来源明确 | 退回目标卡补充，暂不提交评审 |
| 范围与排除项 | 目标覆盖的项目范围清晰，排除项有书面记录 | 与发起人确认边界后补写排除项 |
| 责任人与验收口径 | 每个目标有单一责任人，验收数据、时点和判定规则可复核 | 指定责任人并约定验收方式后再评审 |
| 变更触发条件与复审节奏 | 写明何种情况触发目标复审，复审周期已确定 | 由治理机构补充变更规则 |
清单全部通过后，目标基线进入跟踪阶段。跟踪时按复审节奏核对目标进展，偏差达到变更触发条件时提交治理机构审议。目标变更应保留原目标、变更原因和新目标的记录，使后续复盘能够还原决策过程。目标确定阶段的产出，包括收益假设清单、目标卡、目标—项目映射表和评审结论，构成项目集执行期跟踪与验收的依据。
常见问题
项目集目标和各项目目标是什么关系？
项目集目标描述多个项目协同才能实现的共同收益，项目目标描述单个项目自身要交付的成果。确定项目集目标时，先识别跨项目的收益假设，再把它转成可度量目标，然后检查每个纳入项目支撑哪个目标。项目目标在项目集目标框架下细化，项目层提供交付可行性和依赖信息，两者通过目标—项目映射表对应起来，避免目标与交付来源脱节。
收益暂时无法量化时，目标还能定吗？
可以先把收益写成带假设条件的收益陈述，说明受益对象、收益内容和实现前提，再选择可观察的替代指标，例如工单数量、处理时长、数据不一致次数等。目标卡中标注指标的数据来源和统计口径，并在时间窗口内设置中间检查点。随着数据积累再调整指标，比用方向性口号代替目标更便于后续评审和验收。
目标确定后，执行中发现范围需要调整怎么办？
按第六步约定的变更触发条件处理。当关键依赖项目发生范围变更、目标值连续多个检查点未达预期，或外部约束发生实质变化时，由项目集经理提交治理机构审议。变更记录应保留原目标、变更原因和新目标，使后续复盘能够还原决策过程。未达到触发条件的偏差，优先通过补充措施和资源协调解决，保持目标基线稳定。
目标卡在协作工具中如何承载？
可以在项目集管理工具中建立目标条目，记录目标陈述、指标、基线、目标值、责任人和验收口径，并与支撑项目关联，使目标进展和验收记录有据可查。ONES Plan 提供项目集管理能力，支持多项目总览、自定义项目属性管理不同类型项目，并通过里程碑与甘特图查看多时间跨度进度，其甘特图可与 ONES Project 中的项目和迭代关联查看工作量和进度。目标卡字段的具体承载方式需按实际版本功能确认。
目标确定阶段需要哪些人参与评审？
通常由项目集发起人和治理机构参与确认，项目集经理提交目标卡、目标—项目映射表和验收口径说明，项目经理提供项目层可行性与依赖信息。评审重点看每条目标能否追溯到收益假设、指标四要素是否齐全、范围与排除项是否书面记录、责任人是否唯一。评审结论和变更规则写入项目集管理文件，作为执行期跟踪的依据。
