13.12 实施整体变更控制

一句话讲明白

项目里所有的"改",都必须过这一道总闸门——分析影响、交给有权的人批,批了才动手,动完还得验证。

生活类比

装修走到一半想改水电走向。正确做法:

  1. 向装修公司书面提出"我要改"(提出变更申请);
  2. 公司算清楚要加多少钱、延几天、会不会影响瓷砖已贴好的部分(变更影响分析);
  3. 你和公司负责人双方签字确认这份变更单(CCB 审批);
  4. 师傅按新图纸施工(执行变更);
  5. 改完闭水试验、验收签字(变更验证)。

你要是跟师傅口头说一句就让他砸墙——这就是案例题里最常见的错误做法:绕过整体变更控制。

正经定义

实施整体变更控制是审查所有变更请求,批准变更,管理对可交付成果、组织过程资产、项目文件和项目管理计划的变更,并对变更处理结果进行沟通的过程。本过程审查对项目文件、可交付成果或项目管理计划的所有变更请求,并决定处理方案。主要作用是确保对项目中已记录在案的变更做综合评审;如果不考虑变更对整体项目目标或计划的影响就开展变更,往往会加剧整体项目风险。本过程需要在整个项目期间开展。

终结责任:本过程贯穿项目始终,项目经理对此承担最终责任。

拆解与流程

一、变更控制五步流程(案例大题模板)

flowchart LR A[① 提出变更申请<br/>任何干系人书面提出] --> B[② 变更影响分析<br/>评估对范围/进度/成本/质量/风险的影响] B --> C[③ CCB 审批<br/>批准 / 否决 / 推迟(搁置)] C -->|批准| D[④ 执行变更<br/>通过指导与管理项目工作实施] D --> E[⑤ 变更验证<br/>确认并纳入基准、通知干系人] C -->|否决或推迟| F[通知提出者并记入变更日志]

二、三条"铁律"

  1. 任何变更都不能跳过整体变更控制;变更可能影响项目基准,也可能不影响,但都必须由指定责任人批准、推迟或否决(通常是项目发起人或项目经理,具体操作多在 CCB)。
  2. 在基准确定之前,变更无须正式受控并实施整体变更控制过程;一旦确定了项目基准,就必须通过该过程处理(教材原题考点)。
  3. 口头提出的变更请求,也必须书面形式记录,并纳入变更管理和(或)配置管理系统。

三、变更请求的四类

类型 干什么 举例
纠正措施 为使项目工作绩效重新与计划一致而采取的有目的的活动(纠的是当前偏差) 进度落后 → 加班赶工
预防措施 为确保未来绩效符合项目管理计划而开展的活动(防的是还没发生的问题) 预测将延期 → 提前培训人员
缺陷补救 修正不一致的产品或产品组件(修的是产品瑕疵) 测试发现 Bug → 返工修复
更新 对正式受控的项目文件或计划进行修改 因法规变化更新质量政策

影响基准的变更通常要说明执行变更的成本、所需修改的计划日期、资源需求及相关风险,由 CCB(如有)和客户或发起人审批。只有经批准的变更才能纳入修改后的基准。

四、CCB(变更控制委员会)

五、配置管理与变更管理(配套但不同)

对比 配置控制 变更控制
关注点 可交付成果及各个过程的技术规范 识别、记录、批准或否决对项目文件、可交付成果或基准的变更

配置项管理三件事:① 识别配置项(为定义与核实产品配置、标记产品和文件、管理变更和明确责任提供基础);② 记录并报告配置项状态;③ 进行配置项核实与审计(确保配置项组成正确、相应变更均已登记、评估、批准、跟踪和正确实施,确保配置文件规定的功能要求都已实现)。

变更管理四件事:识别变更 → 记录变更(形成合适的变更请求)→ 做出变更决定(批准/否决/推迟)→ 跟踪变更(确认登记、评估、批准、跟踪并向干系人传达最终结果)。

六、输入 / 工具与技术 / 输出

主要输入 主要工具与技术 主要输出
项目管理计划(变更管理计划、配置管理计划、范围基准、进度基准、成本基准)、项目文件(估算依据、需求跟踪矩阵、风险报告)、工作绩效报告(资源可用情况、进度与成本数据、挣值报告、燃烧图/燃尽图)、变更请求 ① 专家判断 ② 变更控制工具 ③ 数据分析(备选方案分析、成本效益分析)④ 决策(投票、独裁型决策制定、多标准决策分析)⑤ 会议 批准的变更请求;另有项目管理计划更新(任何组件)、项目文件更新(变更日志)

考试怎么考

易混辨析

对比 纠正措施 预防措施 缺陷补救
针对 已经发生的工作绩效偏差 尚未发生但可能出现的偏差 已发现的产品或组件瑕疵
时间取向 现在(亡羊补牢) 未来(未雨绸缪) 现在(修东西)

另:变更日志(记录所有变更请求及处理结果,属于项目文件) ≠ 变更请求(单个申请)。

一秒记忆

"变更五步:申请→分析→CCB 批→执行→验证;纠正补现在、预防挡未来、缺陷修产品、更新改文件;口头说了也要白纸黑字,批准之后才进基准。"

相关