1. 项目范围管理的过程

    [做项目范围内的事情、明确项目边界、对项目执行工作进行监控、防止范围发生蔓延]

     2. 产品范围、项目范围

    [管辖的是工作]

     3. 规划范围管理

    应该怎么做基准、怎么做范围控制、怎么验收范围、验收流程

l     输入

    项目管理计划[正式或非正式的]、 项目章程[前 3 个指导你做范围 ]、组织过程资产、事业环境因素

l     工具和技术

    会议、专家

l     输出

    范围管理计划、需求管理计划

     4. 范围管理计划的内容

(1) 如何制定项目范围说明书

(2) 如何根据范围说明书创建WBS

(3) 如何维护和批准WBS

(4) 如何确认和正式验收已完成的项目可交付成果

(5) 如何处理项目范围书的变更，该工作与实施整体变更控制过程直接相联

     5. 需求管理计划主要内容

(1) 如何规划、跟踪和报告各种需求活动

(2) 需求管理需要使用的资源[所有规划过程组都可以写使用资源]

(3) 培训计划[聘请外部资源进行培训]

(4) 项目干系人参与需求管理的策略

(5) 判断项目范围与需求不一致的准则和纠正规程[合同与需求的对比确认]

(6) 需求跟踪结构，即哪些需求属性将列入跟踪矩阵

(7) 配置管理活动[需求在不断变化，需求文件版本问题]

     6. 收集需求

    [记录干系人]

l     输入

范围管理计划、需求管理计划、干系人管理计划、项目章程、干系人登记册

l     工具和技术

访谈……

l     输出

需求文件、需求跟踪矩阵

     7. 需求分类

业务需求[粗略]

干系人需求[隐性的（给我的是不想要的、不合理的）、明确的、沟通的需求]

解决方案需求[明码标价可以写出来的]

过渡需求[相当于中转。。装修租房]

项目需求[满足的行动、过程或其他条件]

质量需求[做的功能达到什么样的标准]

     8. 工具-访谈

一对一

     9. 工具-焦点小组

不出结论，收集、了解别人的期望以及态度

     10. 工具-引导式研讨会

    [ 达成共识]

联合应用设计/开发 JAD 、 跨职能干系人

     11. 工具-群体创新技术

(1) 头脑风暴[智力激励法、自由思考法、集思广益法]

(2) 名义小组技术[投票、优先排序，促进头脑风暴的生化应用]

(3) 德尔菲技术[专家匿名，背靠背，看专家的意见是否相互影响，多轮次]

(4) 概念/思维导图 [ 心智图]

(5) 亲和图[KJ图法，同类的放在一起]

(6) 多标准决策分析[多个维度去评价一件事]

(7) 群体决策技术

一致同意：100%同意

大多数原则：超过50%同意

相对多数原则：候选超过2个时使用

独裁：一言堂

(8) 观察[跟踪]

(9) 问卷调查[设计书面问题，适用场景]

(10) 标杆对照[与其他组织进行比较，寻找最佳实践]

(11) 原型法

(12) 系统交互图[对产品范围的可视化描述]

(13) 文件分析[把别人的文件拿过来分析一下]

     12. 需求文件

客户应该看得懂，在这里有什么东西。在收集的需求未必包含在项目中

     13. 收集需求-需求跟踪

        [ 能够反向跟踪]

做好需求跟踪、每个需求都有配置项（评审）、下游工作产品（设计、测试）

满足：

业务需求、机会、目的和目标

项目目标

项目范围（WBS）

     14. 定义范围

明确所收集的需求哪些在项目范围内，哪些将排除在项目范围内

l     输入

项目管理计划、项目章程、需求文件

l     工具和技术

产品分析、备选方案生成、引导式研讨会、专家判断

l     输出

项目范围说明书

     15. 产品分析

产品分解、系统分析、需求分析、系统工程、价值工程、价值分析

     16. 备选方案生成

我有好多种方案，做好优略势的分析，让他做选择题。

     17. 项目范围说明书

作用：明确范围、用来做沟通、规划和控制依据、变更基础、规划基础

内容：

(1) 产品范围描述[最后要交付的东西 1.2.3...]

(2) 验收标准[保证可以验收的]

(3) 可交付成果[做各种各样的文件、报告...]

(4) 项目的除外责任[哪些是不用做的]

(5) 制约因素[1.合同中规定的东西 2. 有限的时间]

(6) 假设条件[天然本来应该是的，后来忽略的]

     18. 创建工作分解结构WBS

范围基准： 已批准的项目范围说明书、WBS、 WBS 字典

l     输入

范围管理计划、项目范围说明书、需求文件

l     工具和技术

分解[2个有，进度]

l     输出

范围基准[一定要评审]

WBS被成为工作包 [ 名词属性，完成属性 ] ，可交互成果。 [ 在此过程中会有很多工序]。

WBS是向下分解的

     19. WBS

分级的树级结构

表格

     20. WBS分解的原则

功能或者技术原则

组织结构

系统或者子系统

     21. WBS分解方法

外包的也必须编制相应的WBS

     22. WBS分解活动和作用

(1) 识别可交互成果和相关工作

(2) 确定编排方式（按生命周期）

(3) 分解（自上而下）

(4) 编码（标识）

(5) 核实可交付成果是否恰当

作用：

说明范围的、确定了边界、单位分派人员、确定了时间、成本和资源、工作和内容顺序、防止需求蔓延

     23. WBS注意事项

(1) 可面向可交付成果

(2) 100%规则

(3) WBS有且只有一个负责人

(4) WBS指导而不是原则

(5) 一个工作单元只属于某个上层单元

(6) WBS包括项目管理工作

(7) WBS是所有项目干系人参与

     24. 相关名词

里程碑（标识着可交付成果的完成、时间为0）、

控制账户（管理控制点、对范围、进度、预算加以整合，测量绩效）

规划包（工作内容已知，但尚缺详细进度、粗颗粒的放在那里）

WBS字典（对工作包的描述，编码、假设条件、制约因素、负责人、里程碑进度）

     25. 确认范围[验收工作]

确认范围应该贯穿项目的始终，趁热打铁，赶紧验收

l     输入

项目管理计划、需求跟踪矩阵、需求文件、确认的可交付成果、工作绩效数据

l     工具和技术

检查、群体决策技术

l     输出

工作绩效信息、验收的可交付成果、变更请求

     26. 确认范围工作要点

制定并执行确认程序、步骤

(1) 确定需要进行确认范围的时间

(2) 识别确认范围正式接收的标准和要素

(3) 确定确认范围会议的组织和步骤

(4) 组织确认会议

项目干系人对项目范围确认的正式承认，检查6个方面

(1) 可交付成果是确定的

(2) 有明确的里程碑

(3) 明确的质量标准

(4) 审核或承诺是否有清晰的表达

(5) 项目范围是否覆盖了需求完成的产品或服务

(6) 项目范围的风险是否太高，管理层是否能降低可预见的风险性。

     27. 确认范围与质量控制的关系

(1) 确认范围强调可交付成果获得客户或发起人的接受，输出的是验收的交付成果。

(2) 质量控制强调可交付成果的正确性，并符合其制定的具体质量标准。

(3) 质量控制一般在确认范围之前，也可同时进行。确认范围一般在阶段末进行，而质量控制并一定在阶段末进行。

(4) 质量控制属于内部检查，确认范围则是由外部检查。

     28. 检查

一定要满足书面内容、

确认范围、质量控制、控制采购可以用到

29. 控制范围

拿基准做比较

寻找根本原因

走变更流程

是否都更改

l     输入

项目管理计划、需求跟踪矩阵、需求文件、工作绩效数据

l     工具和技术

偏差分析

l     输出

变更请求、工作绩效信息、

     30. 控制范围

范围变更的原因

(1) 政府政策

(2) 项目范围计划编制不周密

(3) 新的技术手段

(4) 项目执行组织发生变化[项目领导发生变化]

(5) 客户对项目提出新需求

范围变更控制的工作

影响导致范围变更的因素，往有利的方向发展。

判断范围变更是否已经发生

范围变更发生时管理实际的变更，确保所有的请求变更按照项目整体变更控制过程处理。