2-项目范围管理

软考系统集成项目管理工程师--项目范围管理

项目范围管理

• 确保项目做且只做所需的全部工作，以完成项目的各个过程
• 1. 编制范围管理计划
  • 描述如何定义、制定、监督、控制和确认项目范围。
  • 1.1. 输入
    • 1.1.1. 项目管理计划
      • 项目管理计划和各子计划互为输入
    • 1.1.2. 项目章程
    • 1.1.3. 组织过程资产
    • 1.1.4. 事业环境因素
  • 1.2. 工具
    • 1.2.1. 会议
    • 1.2.2. 专家判断
  • 1.3. 输出
    • 1.3.1. 范围管理计划
    • 1.3.2. 需求管理计划
      • 如何分析、记录、管理需求，以及阶段与阶段间的关系对管理需求的影响。
• 2. 收集需求
  • 实现项目目标而确定、记录并管理干系人的需要和需求的过程。
  • 2.1. 输入
    • 2.1.1. 范围管理计划
    • 2.1.2. 需求管理计划
    • 2.1.3. 干系人管理计划
    • 2.1.4. 项目章程
    • 2.1.5. 干系人登记册
  • 2.2. 工具
    • 2.2.1. 访谈
      • 一对一谈话
    • 2.2.2. 焦点小组
      • 召集预定干系人和主题专家，了解他们对所讨论的产品、服务或成果的期望和态度
    • 2.2.3. 引导式研讨会
      • 研讨会是快读定义跨职能和协调干系人差异的重要技术。
    • 2.2.4. 群体创新技术
      • 1、头脑风暴 2、名义小组 3、思维导图 4、亲和图 5、多标准决策分析
    • 2.2.5. 群体决策技术
      • 1、一致同意 2、大多数原则 3、相对多数原则 4、独裁
    • 2.2.6. 问卷调查
    • 2.2.7. 观察
    • 2.2.8. 原型法
      • DEMO
    • 2.2.9. 标杆对照
    • 2.2.10. 系统交互图
    • 2.2.11. 文件分析
  • 2.3. 输出
    • 2.3.1. 需求文件
      • 主要包括： 1、业务需求 2、干系人需求 3、解决方案需求 4、项目需求 5、过度需求
    • 2.3.2. 需求跟踪矩阵
• 3. 定义范围
  • 明确所收集的需求哪些将包含在项目范围内，哪些将排除在项目范围外，从而明确项目、服务或输出的边界
  • 3.1. 输入
    • 3.1.1. 范围管理计划
    • 3.1.2. 项目章程
    • 3.1.3. 需求文件
    • 3.1.4. 组织过程资产
  • 3.2. 工具
    • 3.2.1. 产品分析
      • 弄清产品范围，并把对产品的要求转化成项目要求。
    • 3.2.2. 专家判断
    • 3.2.3. 备选方案生成
    • 3.2.4. 引导式研讨会
  • 3.3. 输出
    • 3.3.1. 项目范围说明书
      • 定义： 对项目范围、主要可交付成果、假设条件和制约因素的描述。项目范围说明书记录了整个范围，包括项目和产品范围。 内容： 1、项目目标 2、产品范围描述 3、项目需求 4、项目边界 5、项目的可交付成果 6、项目的制约因素 7、假设条件
    • 3.3.2. 项目文件更新
      • 可能需要更新：干系人登记册、需求文件、需求跟踪矩阵等
• 4. 创建工作分解结构
  • 作用： 把项目可交付成果和项目工作分解成较小的、更易于管理的组件的过程。工作分解结构（WBS）是项目管理的基础，项目的所有规划和控制工作都必须基于工作分解结构。 内容： 1、WBS最低层的工作单元被称为工作包，是我们进行进度安排、成本估算和监控的基础。 2、项目所有活动都要包含在工作分解结构当中 3、工作分解结构的编制需要所有项目干系人的参与 4、工作分解结构是逐层向下分解的 注：一般工作分解结构控制在3-6层为宜，工作分解结构中各要素应该是相对独立的，要尽量减少相互之间的交叉 形式： 1、分级的树形结构：层次清晰，直观，结构性强，但是不容易修改，适合中小型项目 2、表格形式：可列出所有工作要素，客观性差，适合大型、复杂的项目。 注： 里程碑：标志某个可交付成果或者阶段的正式完成 工作包：属于WBS最小部分，建议工作包大小最小8小时，最多80小时。 WBS编码设计：对WBS内容进行编码标题归类
  • 4.1. 输入
    • 4.1.1. 项目范围管理计划
    • 4.1.2. 项目范围说明书
    • 4.1.3. 需求文件
    • 4.1.4. 组织过程资产
    • 4.1.5. 事业环境因素
  • 4.2. 工具
    • 4.2.1. 分解
      • 原则： 1、保持完整，避免遗漏 2、一个工作单元只能从属某个上层单元，避免交叉从属 3、相同层次的工作单元应用相同性质 4、工作单元应分开不同的责任者和不同的工作内容 5、便于项目管理计划和项目控制的需要 6、最底层工作应该具有可比性，是可管理的，可定量检查的 7、应包括项目管理工作，暴恐分包出去的工作。
    • 4.2.2. 专家判断
  • 4.3. 输出
    • 4.3.1. 范围基准
      • 经过批准的范围说明书、工作分解结构和相应的WBS词典组成范围基准。 注：WBS词典是针对每个WBS组件，详细描述可交付成果、活动和进度信息的文件。
    • 4.3.2. 项目文件更新
      • 如果再创建WBS过程中提交了变更请求并获得批准，那么需要更新需求文件。
• 5. 确认范围
  • 确认范围是正式验收已完成的项目可交付成果的过程。确认范围需要审查可交付物和工作成果，以保证项目中所有的工作都能准确的、满意的完成。 确认范围应该惯出项目的始终。
  • 5.1. 输入
    • 5.1.1. 项目管理计划
    • 5.1.2. 需求跟踪矩阵
      • 需求跟踪矩阵连接了需求与需求源，用于在整个项目生命周期中对需求进行跟踪。
    • 5.1.3. 需求文件
    • 5.1.4. 核实的可交付成果
    • 5.1.5. 工作绩效数据
      • 可能包括符合需求程度、不一致数量等在某段时间的确认的次数
  • 5.2. 工具
    • 5.2.1. 检查
    • 5.2.2. 群体决策技术
  • 5.3. 输出
    • 5.3.1. 验收的可交付成果
      • 相当于验收报告 验收通过需要以书面形式正式签字批准，验收不通过也应当记录下来，并记录未通过原因。 注：可分批验收
    • 5.3.2. 变更请求
      • 可能针对验收未通过的项进行变更
    • 5.3.3. 工作绩效信息
      • 包括项目进展信息
    • 5.3.4. 项目文件更新
      • 确认范围结束后，签署验收报告，会需要对项目文件进行更新
• 6. 范围控制
  • 范围控制是监督项目和产品的范围状态，管理范围基准变更的过程
  • 6.1. 输入
    • 6.1.1. 项目管理计划
      • 包括范围基准、范围管理计划、变更管理计划、变更管理计划、需求管理计划等
    • 6.1.2. 需求跟踪矩阵
    • 6.1.3. 需求文件
    • 6.1.4. 工作绩效数据
      • 可能包括变更请求的数量、接受的变更请求数量、或者完成的可交付成果数量
    • 6.1.5. 组织过程资产
  • 6.2. 工具
    • 6.2.1. 偏差分析
      • 偏差分析是一种确定实际绩效与基准的差异程度及原因的技术。
  • 6.3. 输出
    • 6.3.1. 项目管理计划更新
    • 6.3.2. 变更请求
      • 对范围绩效的分析，可能导致对范围基准或者项目管理计划等提出变更请求
    • 6.3.3. 工作绩效信息
      • 包括收到的变更分类、识别的范围偏差和原因、偏差对进度和成本的影响等
    • 6.3.4. 项目文件更新
    • 6.3.5. 组织过程资产更新