项目范围管理1

项目变更管理

范围缺陷 ：产品功能不全

质量缺陷：不符合技术要求

变更产生的原因

1. 项目计划中的缺陷

2. 项目外界的变化

3. 项目执行的低效

如果变更太多、太大就可能需要修改章程，甚至必须终止现行项目，而另外启动一个新项目

变更管理程序

1. 从源头上变更

2. 提出变更请求

   在计划被批准之后重复开展启动和规划过程，可能提出变更请求

3. 评审变更请求

   记录变更一般是指把变更请求写入变更日志

   变更无论大小，都必须经过综合评审，确认从总体上有利于项目，才能加以批准

4. 实施和跟踪批准变更

5. 总结经验教训

变更审批的权限

不影响极准的变更，有项目经理审批。

会影响极准的变更，项目经理无权审批，除非是紧急情况

配置管理

1. 识别和记录项目产品的重要功能以及为实现这些功能所需的技术参数

2. 跟踪这些参数，控制对这些参数的变更，并记录参数变更情况

3. 按既定的参数（包括变更后的参数）执行项目，并记录与报告参数实现情况

4. 审计项目产品，以确保所有参数度以实现，项目产品能发挥既定功能

配置管理的重点是，确定哪些是核心技术参数，并以特别严格的程序来控制对这些技术参数的变更，确保配置变更可控、在控、可追踪

项目范围管理

范围蔓延 scope creep

未经控制的项目范围逐渐扩大

镀金

项目蔓延的结果，即做了额外的工作

输入输出关系

项目范围管理

收集需求

旨在使需求明确化、具体化和书面化。需求必须是可测量的、文档化的

定义范围

把必须高层管理人员或职能经理搞定的事情，列为假设条件保护自己。

创建WBS

工作分解结构中，应专列一条项目管理分支，使项目管理城管委必须完成的工作之一

WBS的工作都是必须做的，多余需要经过变更控制程序把他去掉。

WBS之外的都是必须不做的，如果做必须经过变更控制程序加进去。

逐层向下分解是为了提高时间和成本估算的准确性，更有效地开展项目规划、执行与控制

规划包不能直接辅助执行，必须先分解成工作包

1. WBS、WBS字典和基准范围

2. 控制账户、规划包和工作包（每一个工作包只能属于一个控制账户）

3. 工作分解结构的作用（给项目相关方看的）

确认范围

控制范围