项目变更影响评估清单应覆盖范围、进度、预算、资源、质量、风险、依赖关系七个核心维度，并在前后各加一个收口项：变更描述与基线确认作为评估起点，审批结论作为材料出口。这份清单用于变更申请提交后、审批会前，由变更提出人、项目经理和各领域评估人共同填写，让审批人在同一份材料上判断变更是否可控、代价是否可接受、需要哪些前置条件。
要点总览（TL;DR）
- 清单以范围、进度、预算、资源、质量、风险、依赖关系七个维度为主体，前后各设变更描述与基线确认、审批结论两个收口项。
- 每个检查项统一写成“检查内容—通过标准—证据材料—负责人—检查时点”，通过标准尽量量化，审批人才能逐项判断。
- 阻断项与普通检查项分开列示：基线未确认、关键路径影响未量化、预算缺口无来源、依赖方未回复、高风险无应对，未清零不进入表决。
- 审批完成需满足三个条件：七维度均有结论、阻断项清零或有豁免记录、审批结论已填写；结论分为批准、有条件批准、退回补充。
- 清单在申请提交时触发填写、审批会前锁定版本，并作为审批材料的固定附件留痕。
谁在什么时点使用这份清单
清单的价值取决于填写时点。如果各维度评估在审批会上才口头补充，审批人拿到的就是未完成的材料，讨论容易滑向信息澄清而非决策。建议把清单定位为审批材料的固定附件，申请提交即触发填写，审批会前完成并锁定版本。
| 角色 | 主要动作 | 填写时点 | 对清单的贡献 |
|---|---|---|---|
| 变更提出人 | 填写变更描述、原因、期望生效时间，初判变更类型 | 变更申请提交时 | 完成变更描述与基线确认部分 |
| 项目经理 | 组织各维度评估，核对基线，汇总结论 | 申请提交后1–3个工作日内启动 | 对全部维度做完整性检查，标注阻断项 |
| 各领域评估人 | 按分工填写本领域检查项、通过标准判断与证据 | 审批会前完成 | 范围、进度、预算、资源、质量、风险、依赖关系中的对应部分 |
| 审批人 | 逐项审阅结论与证据，给出批准、有条件批准或退回意见 | 审批会上 | 填写审批结论与附加条件 |
不同变更规模可以采用不同的填写深度。小额变更（例如不影响关键路径、不新增预算）可只填变更描述、范围、进度、预算四项并做简化判断；涉及里程碑调整、外部合同或高风险项的变更，七个维度全部填写，且证据材料必须附齐。深度差异应写在清单说明里，避免评估人自行缩减范围。
变更描述与基线确认：评估的起点
后续所有维度都建立在“相对什么发生变化”之上。基线不明确，进度偏移天数和成本增量就失去参照，评估结论无法复核。因此清单第一组检查项要先把变更内容和对比基线固定下来。
- 变更内容：具体调整什么，涉及哪些工作包、交付物或约束条件。
- 变更原因：业务需求、外部条件、技术约束或前期估算偏差，写清触发来源。
- 提出人与期望生效时间：明确责任人和时间要求，便于排定评估节奏。
- 当前基线：范围基线、进度基线、成本基线、质量标准的版本号或确认日期，四项分别注明。
- 变更类型判定：范围调整、进度调整、预算调整、资源调整、质量要求调整，可多选，用于决定后续评估重点。
基线未确认时的处理方式要写进清单：暂停后续维度评估，由项目经理组织基线确认或指定临时参照版本，并在清单中记录“基线待确认”状态及预计确认时间。以临时参照版本评估的结论，需在审批材料中标注其局限。
七个核心维度的检查项与通过标准
清单主体按七个维度展开，每个检查项统一写成“检查内容—通过标准—证据材料—负责人—检查时点”。通过标准尽量量化，让审批人能直接判断“通过”还是“不通过”，而不是读一段描述后自行揣测。
| 维度 | 检查项 | 通过标准示例 | 证据材料 | 负责人 |
|---|---|---|---|---|
| 范围 | 受影响的工作包、交付物、验收标准是否逐项列出 | 受影响项全部列明，验收标准变化有新旧对照 | 更新后的范围说明、验收标准对照表 | 产品/业务负责人 |
| 进度 | 关键路径是否受影响，里程碑偏移天数与缓冲消耗是否量化 | 偏移天数与缓冲消耗比例有明确数值，关键路径变化已标注 | 更新后的进度计划、关键路径分析 | 项目经理 |
| 预算 | 新增成本、已发生成本处置、资金来源是否说明 | 新增成本有测算明细，资金来源明确到预算科目或审批口径 | 成本测算表、资金审批记录 | 财务/预算负责人 |
| 资源 | 人力投入变化、关键技能缺口、外部资源合同影响是否评估 | 投入变化有人数与人天口径，技能缺口有补充方案，合同影响有对方确认 | 资源计划、技能缺口说明、合同变更记录 | 资源经理 |
| 质量 | 质量目标、测试范围、返工风险是否重新评估 | 质量目标变化有说明，测试范围已更新，返工风险有等级判断 | 测试计划、质量目标对照、返工风险评估 | 质量/测试负责人 |
| 风险 | 新增风险条目、风险等级、应对措施与责任人是否登记 | 新增风险全部入册，高等级风险均有应对措施和责任人 | 风险登记册更新记录 | 项目经理/风险负责人 |
| 依赖 | 上下游项目、外部供应商、系统接口的连带影响是否确认 | 每个依赖方有明确回复，影响范围与时间窗口已确认 | 依赖方确认记录、接口影响说明 | 接口/供应商对接人 |
通过标准的写法有三条实用规则。第一，能用数字就不用形容词，例如“里程碑偏移不超过5个工作日”“缓冲消耗不超过20%”，比“影响较小”可判断。第二，标准要对应证据，写“已确认”就必须说明确认形式是邮件、会议纪要还是系统记录。第三，标准要区分“必须满足”和“建议满足”，前者进入阻断项判断，后者作为审批附加条件。
证据材料与负责人分工
证据的作用是让审批结论可追溯：三个月后回看，能知道当时依据什么做出判断。各维度责任人按变更类型确定，默认由该领域的日常负责人承担，涉及外部合同时增加采购或法务角色。
| 证据类型 | 对应维度 | 时效与版本要求 | 确认方式 |
|---|---|---|---|
| 更新后的范围说明与验收标准对照 | 范围 | 基于当前基线版本，注明更新日期 | 责任人确认 |
| 进度计划与关键路径分析 | 进度 | 与申请提交日相差不超过约定天数 | 项目经理确认 |
| 成本测算表与资金审批记录 | 预算 | 测算口径与财务口径一致 | 财务确认 |
| 资源承诺与技能缺口说明 | 资源 | 承诺到人到时间段 | 资源经理确认 |
| 测试计划与返工风险评估 | 质量 | 覆盖变更后范围 | 质量负责人确认 |
| 风险登记册更新记录 | 风险 | 含新增条目与等级 | 风险责任人确认 |
| 依赖方确认记录 | 依赖关系 | 有明确回复时间与影响结论 | 对接人确认 |
证据的时效要求应写进清单说明：超过约定天数的测算或确认记录视为过期，需重新确认。评估人的确认方式建议统一，例如在清单对应行签字或在协作工具中留下确认记录，避免口头确认无法追溯。
阻断项与审批完成条件
阻断项与普通检查项分开列示。普通检查项不通过可以转为审批附加条件，阻断项未清零则不应进入审批表决，需要退回补充或走升级机制。
- 基线未确认，或临时参照版本未标注。
- 关键路径影响未量化，只有定性描述。
- 预算存在缺口且无资金来源说明。
- 关键依赖方未回复，影响范围无法判断。
- 高等级风险无应对措施或责任人。
阻断项的处理路径要明确：由项目经理判断是退回提出人补充，还是升级到变更决策层做例外处理。例外处理需留下豁免记录，写明豁免理由、批准人和补偿措施。
审批完成条件可以归纳为三条：七个维度均有明确结论（通过、不通过或带条件通过）；阻断项清零，或存在经批准的豁免记录；审批结论已填写。审批结论有三种去向——批准、有条件批准、退回补充。有条件批准必须把附加条件写成可核验的条目，例如“补充供应商书面确认后方可执行”，并指定跟踪责任人。
把清单落到协作工具里的管理动作
清单要真正在审批前完成，需要把填写、分派、评审和归档串成一条可追踪的流程。常见做法是将变更申请作为工作项承载，清单各维度作为该工作项下的必填字段或子项，未填写完整时无法流转到审批状态。
具体动作可以按以下顺序组织：变更提出人提交工作项并填写变更描述与基线信息；项目经理按维度分派评估人，各评估人填写检查项、通过标准判断并上传证据；项目经理核对完整性与阻断项，将工作项流转到评审状态；审批人在评审记录中给出结论，结论与附加条件随工作项留痕；变更执行后更新基线，并在后续跟踪中对照新基线检查偏差。
ONES 的项目计划支持创建工作分解结构并为任务设置前后置依赖，里程碑可标记重要时间点与决策点，这为进度维度的关键路径判断和里程碑偏移量化提供了承载。ONES 支持设置项目计划和里程碑基线，实时对比计划与执行的偏差，并可通过对比版本细节追溯变更细节，便于在变更后更新基线并保留前后对照。资源维度上，项目经理可用工时日历查看资源饱和度，结合成员工员报表与饱和度报表分析资源利用情况，为人力投入变化的评估提供数据。审批结论与评审记录的留痕形式，建议按团队实际配置的评审流程确认。
需要说明边界：本篇聚焦单项目约束调整的影响评估。需求对象本身的修改流程属于需求变更与版本管理范畴；跨研发资产的变更治理属于研发变更控制与影响分析范畴，可另行参考相邻主题。多项目组合层面的变更优先级排序不在本清单覆盖范围内。
常见问题
小额变更是否也要填满七个维度？
可以简化，但简化规则要事先写进清单说明，由评估人自行缩减容易漏项。通常不影响关键路径、不新增预算的小额变更，可只填变更描述、范围、进度、预算四项并做简化判断；涉及里程碑调整、外部合同或高等级风险的变更，七个维度全部填写且证据附齐。简化判断的依据要记录在清单里，便于审批人确认简化是否成立。
基线还在调整中，变更评估能否先做？
可以先做，但要在清单中标注“基线待确认”，并指定临时参照版本及预计确认时间。以临时参照版本得出的偏移天数和成本增量，需在审批材料中注明其局限。基线确认后应复核受影响的结论，避免审批依据停留在临时版本上。
有条件批准的附加条件怎么写才可跟踪？
把条件写成可核验的条目，包含动作、对象、完成标准和跟踪责任人。例如“补充供应商书面确认后方可执行”，比“进一步确认供应商影响”更容易判断是否完成。附加条件应随审批结论一并记录，并在变更执行跟踪中作为检查项回看。
评估证据过期或版本不一致时怎么处理？
清单说明中应约定证据时效，例如进度计划与申请提交日的间隔上限、成本测算与财务口径的一致性要求。超过约定时效的测算或确认记录视为过期，需重新确认后再提交审批。版本不一致时，以当前基线版本为准重新出具证据，并在清单中记录更换原因。
清单在协作工具中如何保证审批前填完？
常见做法是把变更申请作为工作项承载，清单各维度设为必填字段或子项，填写不完整时无法流转到审批状态；项目经理按维度分派评估人，证据随工作项上传，审批结论在评审记录中留痕。ONES 的项目计划支持创建工作分解结构并设置前后置依赖，里程碑可标记决策点，项目计划和里程碑基线可实时对比计划与执行偏差，并通过对比版本细节追溯变更，这些能力可承载进度维度的量化与变更后的基线更新。审批结论的具体留痕形式建议按团队实际配置的评审流程确认。
