范围蔓延：

未经过项目变更控制流程图而接受的项目变更，属于项目蔓延。项目范围蔓延可能会导致的后果有：
1、项目失控
2、成本无法预算
3、增加项目风险
4、验收与预期不一致
镀金是范围蔓延的另一种形式，是有项目团队，主动加功能加需求，从而导致项目范围增加，项目失控

很多人会不解，包括我在在内，为什么不允许项目镀金，员工积极主动地优化系统，不是一件好事，应该值得肯定和鼓励吗？后来自己负责了项目后才明白，镀金，私自修改需求，没有提前跟相关人沟通，等功能开发出来做验收时，发现和原本的需求文档不一样。而产品经理是产品的主要负责人，这时候，肯定是产品背锅，严重的还会影响项目进度，增加未知风险。所以不是不鼓励员工积极工作，而是需要有规范的流程制度。

如何规避项目范围蔓延镀金

1、确定基准，项目范围说明书：做且只做
2、已确定的基准，需要变更必须走变更控制流程
3、记得将变更结果更新记录文档，并且通知受影响的所有人

变更控制

在基准确定之前，变更无需正式受控于实施整体变更控制过程；一旦确定了基准，就必须通过施整体变更控制过程来处理变更；涉及基准CCB审批。没有涉及基准项目经理审批
变更管理计划为管理变更控制过程提供指导，并记录变更控制委员会的角色和职责。
在整个项目生命周期的任何时间，任何相关方都可以提出变更控制请求。
可以口头也可以书面提出，但是所有变更请求都必须以书面形式记录记录，并记纳入变更管理和（或）配置管理系统中

**

变更请求：

• 预防措施：针对工作未来绩效可能出现的偏差。为确保项目工作的未来绩效符合项目管理计划而进行的有目的的活动
• 纠正措施：针对工作绩效已经发生的偏差。为使项目工作绩效重新与项目管理计划一致而进行的有目的的活动
• 缺陷补救：针对产品或产品组件已经出现的质量问题。修正不一致的产品而进行的有目的的活动
• 更新：对正式受控的项目文件或计划等进行的变更。以反映修改或增加的意见或内容

变更控制工具

• 识别配置项：识别与选择配置项，从而为定义与核实产品配置、标记产品和文件、管理变更和明确责任提供基础
• 记录并报告配置项状态：关于各个配置项的信息记录和报告
• 进行配置项核实与审计：通过配置核实与审计，确保项目的配置项组成的正确性，以及相应的变更都被登记、评估、批准、跟踪与实施，从而确保配置文件所规定的功能要求都已实现

项目范围说明书用于明确项目的边界，为评审工作是否超出边界提供基准

• -记录整个范围，包括项目和产品范围
• -详细描述了项目的可交付成果
• -代表项目相关方之间就项目范围所达成的共识
• -明确指出哪些工作不属于项目范围
• -为评价变更请求或额外工作是否超过项目边界提供基准

需求跟踪矩阵：是一份连接需求和需求源，需求与相应可交付成果的文件
产品需求文件是衡量产品范围完成的情况的依据
项目管理计划是衡量项目范围完成情况的依据
项目管理计划里没有计划，只是定义规划如何管理，具体的项目进度计划在项目进度计划里，属于项目文件
项目范围基准用来衡量项目范围的完成情况
变更管理计划：为管理变更控制过程提供指导，记录变更控制委员会的情况，记录变更并更新项目管理计划，这是变更和配置管理过程的一项工作
变更控制系统：描述了如何管理和控制针对项目可交付成果和文档的修