信息系统项目管理师之项目范围管理

项目范围管理

范围管理六个过程

1. 规划范围管理，编制范围管理计划，书面描述将如何定义、确认和控制项目范围的过程。
2. 收集需求，为实现项目目标而确定、记录并管理干系人的需要和需求的过程。
3. 定义范围，制定项目和产品详细描述的过程。
4. 创建工作分解结构（WBS）,将项目可交付成果和项目工作分解为较小的、易于管理的组件的过程
5. 确认范围，正式验收已完成的项目可交付成果的过程。
6. 控制范围，监督项目和产品的范围状态，管理范围基准变更的过程

启动过程组	计划过程组	执行过程组	监控过程组	收尾过程组
	1、规划范围管理 2、收集需求 3、定义范围 4、创建工作分解结构（WBS）		5、确认范围 6、范围控制

4W1H

4W1H	规划范围管理	收集需求	定义范围	创建WBS	确认范围	监控范围
what	创建范围管理计划和需求管理计划，书面将如何定义、确认和控制范围。 作用：在整个项目中对如何管理范围提供指南	定义干系人的需求 作用：为定义和管理项目范围奠定基础	制定一份范围说明书，详细描述项目和产品，具体定义、描述项目范围 作用：明确收集的需求哪些包含在项目范围内，哪些不再项目范围内，明确项目、服务或成果边界	创建一份WBS，把项目可交付成果和项目工作分解为较小的，易于管理的组成部分 作用：对所要交付的内容提供一个结构化视图	正式验收已经完成的可交付成果，与客户或发起人一起审查结果，确保可交付成果已经圆满完成。 作用：使验收过程具有客观性。通过每个可交付成果的验收，提高最终产品、服务或成果的验收可能性	监督项目和产品范围，管理范围基准变更 作用：在整个项目期间保持对项目范围基准的维护
why	指导范围管理知识领域其他过程如何开展	收集需求旨在定义和管理客户期望，掌握项目需求和产品需求对促进项目成功有重要作用 需求是WBS的基础	编制详细的项目范围说明书，对项目成功至关重要	WBS代表着项目范围说明书所规定的工作，可以针对WBS的工作包安排进度，估算成本和实施监控	获得客户或发起人正式验收	防止范围失控。变更实际发生时，管理变更。如果变更不可避免，必须实施项目整体变更控制。杜绝范围蔓延和范围镀金
who	项目管理团队/项目团队	项目管理团队/项目团队	项目经理带领项目管理团队/项目团队	项目管理团队/项目团队	项目经理与客户或发起人一起	项目管理团队/项目团队
when	制定项目章程后，范围管理其他过程之前	项目章程制定后，干系人初步识别后，规划范围管理后	收到需求以后	制定项目管理范围说明书后	已经产出可交付成果，并且可交付成果已经通过实施质量控制进行了检验，得到了组织中质量部门的确认后，实施质量控制和核实范围也可同步进行	项目或阶段末，项目结束前
how	会议和专家谈判	访谈/焦点小组会议/引导式研讨会/群体创新技术/群体决策技术/问卷调查/观察/原型法/系统交互图/文件分析	采用产品分析、备选方案和引导式研讨会，采用专家判断	分解/专家判断	检查/群体决策	采用净值计算，进行偏差分析

范围管理简述

• 明确项目边界
• 对项目执行工作进行监控
• 防止项目范围发生蔓延
  • 范围蔓延，客户提出新需求，超出了范围基准。（客户不断提出要求，不断去改，最终交付物不满足要求）
  • 范围镀金，客户没有提出新需求，项目实施人员自己做了额外客户不需要的工作。（实施人员往往原因尝试新技术为项目加上的）

产品范围和项目范围

• 产品范围，产品或者服务应该包含的功能
• 项目范围，为了能够交付产品，所必须要做的工作
• 产品范围使项目范围的基础，产品范围的定义是产品要求的描述；项目范围的定义是产生项目管理计划的基础
• 产品的范围基准是经过批准的项目范围说明书、WBS和WBS词典。判断项目范围是否完成要以范围基准来衡量。而产品范围是否完成，则根据产品是否满足了产品描述来判断
• 产品范围描述是项目范围说明书的重要组成部分。产品范围变更后，首先受到影响的是项目范围
• 项目范围，强调过程；产品范围，强调结果

规划范围管理

项目范围管理计划可能在项目管理计划之中，也可能作为单独的一项。根据不同的项目，可以是详细的或者概括的，可以是正式的或者非正式的

规划范围管理计划内容

1. 如何制定项目范围说明书
2. 如何根据项目范围说明书创建WBS
3. 如何维护和批准WBS
4. 如何确认和正式验收已完成的项目可交付成果
5. 如何处理项目范围说明书的变更，该工作与实施整体变更控制过程直接相连

收集需求

收集需求的工具与技术

• 访谈，正式或非正式，一对一访谈或一对多会谈，比较直接
• 焦点小组，将预先选定的干系人和主题专家集中在一起，了解他们对所提议产品、服务或成果的期望和态度。
• 引导式研讨会，通过邀请主要的跨职能干系人一起参加会议
• 群体创新技术，头脑风暴法、名义小组技术、德尔菲技术、概念/思维导图、亲和图、多标准决策分析
  • 头脑风暴，各抒己见，集思广益，不一定会有结论产生
  • 名义小组技术，通过投票来排列，头脑风暴法的深化应用
  • 德尔菲技术，采用匿名或背靠背方式、预测过程几轮反馈，使专家的意见逐渐趋同、有助于减轻数据的偏倚，防止任何个人对结果产生不恰当的影响，会有结论产生
  • 亲和图，又称为KJ法，针对某一问题，充分利用各种经验、知识、想法和意见等，通过图解的方式汇总，使问题明确起来，求得统一认识，以利于解决的一种方法。核心是头脑风暴，根据结果去找原因
  • 多标准决策分析，借助决策矩阵，多个方面进行分析
• 群体决策技术，为了达成某种期望结果而对多个未来行动方案进行评估。
  • 一致同意
  • 大多数原则，群体中50%以上的人支持
  • 相对多数原则，相对多数人支持但不足50%
  • 独裁
• 问卷调查
• 观察
• 原型法
• 标杆对照，将实际做法和类似组织的做法进行比较，进行改进
• 系统交互图，产品范围的可视化模型
• 文件分析，通过分析文档，识别与需求相关的信息来挖掘需求

需求文件和需求跟着矩阵

需求文件，既可以是一份按干系人和优先级分类列出全部需求的简单文件，也可以是一份包括内容提要、细节描述和附件等的详细文件。（可以包括全部需求，也可以只包括部分需求）

需求跟踪

• 可跟踪性是项目需求的一个重要特征
• 可验证性是项目需求的最基本特征

• 左半部分表明，用户原始需求可以向前追溯到需求文件，同样，从需求文件回溯到相应的用户原始需求，确认每个需求的出处
• 追溯到需求（用户需求—需求）
• 从需求追溯（需求—下游工作产品）
• 回溯到需求（下游工作产品—需求）
• 从需求回溯（需求—用户需求）

需求跟踪矩阵

需求和其他产品元素之间的联系链的最普遍方式是需求跟踪矩阵

需求跟踪矩阵中记录的典型属性包括唯一标识、需求的文字描述、收录该需求的理由、所有者、来源、优先级别、版本、当前状态（进行中、已取消、已推迟、新增加、已批准、已分配、已完成）和状态日期

定义范围

定义范围是制定项目和产品详细描述的过程，主要作用是明确所收集的需求哪些将包含项目范围内，从而明确产品、服务或成果的边界

定义范围的工具与技术

• 专家判断
• 产品分析，针对产品提问并回答，形成对将要开发产品的用途、特征和其他方面的描述
• 备选方案生成，用于识别执行项目工作的不同方法
• 引导式研讨会

项目范围说明书内容–背诵

1. 产品范围描述
2. 验收标准
3. 可交付成果
4. 项目的除外责任
5. 制约因素
6. 假设条件

• 项目经理向项目干系人说明项目范围时，应以项目范围说明书为依据
• 项目范围说明书在“可交付物”层次上明确了要完成项目需要做的相应工作。

项目范围说明书主要作用

1. 确定范围
2. 沟通基础
3. 规划和控制依据
4. 变更基础
5. 规划基础

创建工作分解结构（WBS）*

创建WBS是将项目可交付成果和项目工作分解成较小的、更易于管理的组件的过程。

WBS不是某个项目团队成员的责任，应该由全体项目团队成员、用户和项目干系人共同完成和一致确认

• 里程碑，重要的检查点是里程碑、重要的里程碑是基线。
• 工作包，8/80规则（80小时原则），至少需要8小时完成，最大不应大于80小时
• 控制账户，是一种管理控制点，一个控制账户中包括若干个工作包，但一个工作包仅属于一个控制账户
• 规划包，控制账户之下，工作内容已知但尚缺详细进度活动的WBS组成部分

• WBS词典，描述WBS各组成部分的文件

分解工作包包含的活动

1. 识别和分析可交付成果及相关工作
2. 确定WBS的结构和编排方法
3. 自上而下逐层细化分解
4. 为WBS组件制定和分配标识编码
5. 核实可交付成果分解的程度是恰当的

分解工作划分原则

• 功能或技术原则
• 组织结构
• 系统或者子系统

分解工作划分方法

• 生命周期
• 可交付成果
• 外包

WBS表示形式

• 树形结构图，适用于小项目，层次清晰、直观性和结构性强，但不容易修改
• 表格形式，适用于大项目，直观性差，但能反映出项目所有工作要素

WBS分解注意事项*

1. WBS必须是面向可交付成果的
2. WBS必须符合项目范围
3. WBS的底层应该支持计划和控制
4. 必须有负责人，而且只由一个人负责，尽管实际上需要多个人参与
5. WBS应控制在4~6层，大项目可以超过6层
6. WBS应包括项目管理工作，也要包括分包出去的工作
7. WBS的编制需要所有（主要）项目干系人参与
8. WBS并不是一成不变的，完成后可能需要修改的

确认范围

确认范围，正式验收项目已完成的可交付成果的过程。确认范围包括**与客户或发起人一起审查可交付成果，确保可交付成果已圆满完成，并获得客户或发起人的正式验收，**阶段性的验收，贯穿于项目的整个生命周期

工具与技术

• 检查，开展测量，审查和确认等活动，来判断工作和可交付成果是否产品需求和产品验收标准
• 群体决策技术

确认范围步骤

1. 确定需要进行范围确认的时间
2. 识别范围确认需要哪些投入
3. 确定范围正式被接受的标准和要素
4. 确定范围确认会议的组织步骤
5. 组织范围确认会议

比较确认范围与质量控制

范围控制，强调有没有做；质量控制，强调做的正不正确

• 确认范围强调可交付成果获得客户或发起人的接受；质量控制强调可交付成果的正确性
• 质量控制一般在确认范围前进行，也可同时进行；确认范围一般在阶段末尾进行，而质量控制并不一定在阶段末尾进行
• 质量控制属内部检查；范围控制是外部干系人

比较确认范围与项目收尾

1. 确认范围强调核实与接受可交付成果，项目收尾强调结束项目所要做的流程性工作
2. 确认范围和项目收尾都有验收工作，确认范围强调验收可交付成果，项目收尾强调验收产品

控制范围

控制范围，监督项目和产品的范围状态、管理范围基准变更的过程。其主要作用是在整个项目期间保持对范围基准的维护。对项目范围控制，就必须确保所有请求的变更、推荐的纠正措施或预防措施都经过实施整体变更控制过程的处理。在变更实际发生时，也要采用范围控制过程来管理这些变更。

范围变更控制主要工作

• 影响导致范围变更的因素，尽量使这些因素向有利的地方发展
• 判断范围变更是否已经发生
• 范围变更发生时管理实际的变更，确保所有被请求的变更按照项目整体变更控制过程处理