HDBook
项目范围管理
Max Zhang Lv4
  2024-01-25 20:00:00   2024-02-19 22:53:48    

项目范围管理

管理哪些事情该做，哪些事情不该做，就是项目范围。较靠前完成的知识领域的东西。

重点：5.3，5.6，5.7，5.8

5.1 项目范围管理基础

5.1.1 产品范围与项目范围

What： 产品范围：产品、服务或成果所具有的特征

客户需要的东西

How： 项目范围：为交付具有规定特性与功能的产品服务或成果而必须完成的工作

为了产品必须完成的工作

项目范围进一步进行拆分就得到了工作结构分解，一个项目中做的事情的拆解。

做完这些就会获得可交付成果，得到客户需要的东西

5.2 项目范围管理过程

  1. 规划范围管理
  2. 收集需求
  3. 定义范围
  4. 创建工作分解结构
  5. 确认范围
  6. 控制范围

5.3 规划范围管理

5.3.1 规划范围管理的定义及作用

定义：为了记录如何定义、确认和控制项目范围及产品范围，而创建范围管理计划的过程

目标是创建范围管理计划

作用：在整个项目期间对如何管理范围提供指南和方向。

仅开展一次，或仅在项目的预定义点开展

输入：

  1. 项目管理计划
  2. 项目章程
  3. 事业环境因素
  4. 组织过程资产

项目管理工作是一个滚动进行的一项工作，不断迭代

工具与技术：

  1. 专家判断
  2. 数据分析
  3. 会议

输出：

  1. 范围管理计划
  2. 需求管理计划

5.3.1.1 范围管理计划

规划范围管理的输出

描述了将如何定义、制定、监督、控制和确认的相关工作。

范围管理计划用于指导以下工程和相关工作

主要是指导作用

  1. 制定项目范围说明书
  2. 根据详细项目范围说明书创建 WBS
  3. 确定如何审批和维护范围基准
  4. 正式验收已完成的项目可交付成果

根据项目的需要，范围管理计划可以是正式或者非正式的。也可以是非常详细的或者高度概括的。

5.3.1.2 需求管理计划

规划范围管理的输出

描述如何分析、记录和管理需求。

主要内容：

  1. 如何规划、跟踪和报告各种需求活动。
  2. 配置管理活动（如何启动变更，如何分析其影响，如何追溯、跟踪和报告，以及变更审批权限）
  3. 需求优先级排序过程
  4. 测量指标及使用这些指标的理由
  5. 反映哪些需求属性将被列入跟踪矩阵等

可交付成果就是根据需求做出的东西，不能一味的满足需求，需要制定需求管理计划，来明确需求如何变更，如何跟踪，如何优先级排序等。

5.4 收集需求

了解收集需求的定义和作用，以及收集需求的输入、工具与技术、输出。

5.4.1 收集需求的定义及作用

定义：是为实现项目目标而确定、记录并管理干系人的需要和需求的过程。

作用：为定义和管理项目范围（包括产品范围）奠定基础。

项目范围和产品范围是不同的，但是在这里笼统的讲是互相包含的。仅开展一次，或仅在项目的预定义点开展

输入：

  1. 项目章程（最早期原始的项目需求，可行性研究，最原始最本质的）
  2. 项目管理计划
  3. 项目文件
  4. 立项管理文件
  5. 协议
  6. 事业环境因素
  7. 组织过程资产

工具和技术：

  1. 专家判断
  2. 数据收集
  3. 数据分析
  4. 决策
  5. 数据表现
  6. 人际关系和团队技能
  7. 系统交互法
  8. 原型法

输出：

  1. 需求文件
  2. 需求跟踪矩阵

5.4.2 需求文件

需求文件描述各种单一需求如何满足项目相关的业务需求。只要明确的（可测量和可测试的）、可跟踪的、完整的、相互协调的且主要干系人认可的需求才能作为基准。

得可以量化，不能只是定性的需求。所有的项目管理首先都是要做出基准。
不能是缺失遗漏的，要完整的。
基准就是根据干系人的需求，做出需求规格说明书（SRS）。
评审共识的规格说明书，才能作为基准，也叫基线。

需求的类别：

  1. 业务需求
  2. 干系人需求
  3. 解决方案需求
  4. 过渡和就绪需求
  5. 项目需求
  6. 质量需求

5.4.3 需求跟踪矩阵

有很多种方法来获取需求，如果获取的需求有可能被遗漏，所以需要一种机制来确保原始需求追溯，不能多做也不能遗漏。
确保所有的需求都被满足，不遗漏。

组成

  1. 项目名称
  2. 成本中心
  3. 项目描述

标识 关联标识 需求描述 业务需要、机会、目的和目标 项目目标 WBS 可交付成果 产品设计 产品开发 测试案例

5.4.4 工具技术

头脑风暴

用于收集对项目需求和产品需求的多种创意技术

将所有涉及的工作人员聚集在一起，进行头脑风暴，畅所欲言，不论是否实现或是否可行，不加批判的提出各种各样的想法。（不追究提出人的责任）
侧重于收集需求，不是解决问题。

名义小组

逐条讨论 各自投票 评分或者排序

头脑风暴所收集的都是没有体系，杂乱的创意。将其进行整理，逐条讨论，逐条分析，逐条评审，逐条确认。就可以判断出哪些需求是重要的，哪些是可以做的。
有组织的投票评分，排序

焦点小组

聚焦，观察

开放式讨论，主持人已经有了较大的影响力

封闭式的问题来提问确认观点

确保所有人参与

总结信息

有主持人，进行主题聚焦观察大家反应

5.5 定义范围

5.5.1 定义范围的定义及作用

定义：是制定制定项目和产品详细描述的过程。

作用：描述产品、服务或成果的边界和验收标准。

本过程需要在整个项目期间多次反复开展

输入：

  1. 项目管理计划
  2. 项目章程
  3. 项目文件
  4. 事业环境因素
  5. 组织过程资产

工具与技术：

  1. 专家判断
  2. 数据分析
  3. 决策
  4. 人际关系和团队技能

输出：

  1. 项目范围说明书

5.5.2 项目范围说明书的内容

就是规定项目做的包括什么，不包括什么，做到什么程度，验收标准是什么。

范围说明书的内容

  1. 产品范围描述
  2. 验收标准
  3. 可交付成果
  4. 项目的除外责任（哪些不属于项目范围）
  5. 制约因素 （比如强制性日期）
  6. 假设条件

范围说明书的作用

  1. 确定范围
  2. 沟通基础（共识）
  3. 规划和控制依据
  4. 变更基础（判断是否超界）
  5. 规划基础（成本、进度等计划的基础）

5.6 创建工作分解结构

在范围说明书的基础上，将项目的范围进一步分解，分解成小颗粒的工作，会便于管理。

5.6.1 创建工作分解结构的定义及作用

定义：是把项目可交付成果和项目工作分解为更小、更易管理的部分的过程。

作用：为交付项目可交付成果而必须完成的工作提供框架。

仅开展一次，或仅在项目的预定义点开展

输入：

  1. 项目管理计划
  2. 项目范围说明书

工具与技术：

  1. 分解

输出：

  1. 范围基准

5.6.2 范围基准

定义

概念名称 含义
里程碑 标注着某个可交付成果或者阶段的正式完成
工作包 工作包是位于 WBS 每条分支最底层的可交付成果或项目工作组成部分，应该非常具体以便承担者明白自己的任务是什么。
控制账户 一种管理控制点。在该控制点上，把范围、预算、实际成本和进度加以整合，并与挣值进行比较，以测量绩效。
规划包 工作内容已知但详细进度活动未知的，低于控制账户的工作分解结构组件。
WBS 字典 针对每个工作分解结构组件，详细描述可交付成果、活动和进度信息的文件。

一般要带有项目管理项

工具与技术

  1. 分解
  • 识别和分解可交付成果以及相关工作
  • 确定 WBS 的结构和编排方法（树形，列表形）
  • 自伤而下逐层细化分解
  • 为 WBS 组成部分制定和分配标志编码
  • 核实工作分解的程度是恰当的
类别 说明 适应范围
树形 WBS 层次清晰、直观、结构性很强 中小型应用项目
列表 WBS 能反应所有工作要素，直观性较差 大型应用项目

可采用的形式

  • 以项目生命周期的各阶段作为分解的第二层，把产品和项目可交付成果放在第三层。
  • 以主要可交付成果作为分解的第二层。

5.6.3 WBS 工作分解注意事项

  1. WBS 是一个可交付成果导向的层次分解
  2. 必须符合项目范围，避免遗漏
  3. 低层工作应该支持计划和控制，具有可比性，可管理，可定量检查的（最短不小于 8 小时，最多不超过 80 小时）
  4. 工作单元分开不同的责任人，有且只有一个责任人
  5. 一个工作单元只能从属于一个上层单元，避免交叉
  6. 包括项目管理工作，也包括分包出去的工作
  7. WBS 的编制需要项目干系人的参与
  8. WBS 并非一成不变，需要不断更新

5.7 确认范围

了解确认范围的定义和作用，以及确认范围的输入、工具与技术、输出。

5.7.1 确认范围的定义及作用

定义：是正式验收已完成的项目可交付成果的过程。

作用：使验收过程具有客观性；同时通过验收每个可交付成果，提高最终产品、服务或成果获得验收的可能性。

确认范围过程应根据需要在整个项目期间多次定期开展

确认范围关注的是可交付成果，质量控制关注的是用户的需求。先控制质量，再确认范围。

输入：

  1. 项目管理计划
  2. 项目文件
  3. 需求跟踪矩阵

5.8 控制范围

了解控制范围的定义和作用，以及控制范围的输入、工具与技术、输出。

5.8.1 控制范围的定义及作用

定义：是监督项目和产品的范围状态，管理范围基准的变更的过程。

作用：在整个项目期间保持对范围基准的维护。

控制范围过程需要在整个项目期间开展

变更原因：

  • 项目外部环境的发生变化
  • 项目范围的计划编制不周密详细，有一定的错误或者遗漏
  • 市场上出现了或者设计人员提出了新的技术、先手段或者新方案
  • 项目实施组织本身发生变化
  • 客户对项目、项目产品或服务的要求发生变化

工具与技术：

数据分析

  1. 趋势分析

    真实工作与基线的比较，看偏差的趋势

  2. 偏差分析

    实际与基准的比较，看偏差的大小

 评论
评论插件加载失败
正在加载评论插件
  1. 项目范围管理
    1. 5.1 项目范围管理基础
      1. 5.1.1 产品范围与项目范围
    2. 5.2 项目范围管理过程
    3. 5.3 规划范围管理
      1. 5.3.1 规划范围管理的定义及作用
        1. 5.3.1.1 范围管理计划
        2. 5.3.1.2 需求管理计划
    4. 5.4 收集需求
      1. 5.4.1 收集需求的定义及作用
    5. 5.5 定义范围
      1. 5.5.1 定义范围的定义及作用
      2. 5.5.2 项目范围说明书的内容
    6. 5.6 创建工作分解结构
      1. 5.6.1 创建工作分解结构的定义及作用
      2. 5.6.2 范围基准
      3. 5.6.3 WBS 工作分解注意事项
    7. 5.7 确认范围
      1. 5.7.1 确认范围的定义及作用
    8. 5.8 控制范围
      1. 5.8.1 控制范围的定义及作用
  1. 项目范围管理
    1. 5.1 项目范围管理基础
      1. 5.1.1 产品范围与项目范围
    2. 5.2 项目范围管理过程
    3. 5.3 规划范围管理
      1. 5.3.1 规划范围管理的定义及作用
        1. 5.3.1.1 范围管理计划
        2. 5.3.1.2 需求管理计划
    4. 5.4 收集需求
      1. 5.4.1 收集需求的定义及作用
    5. 5.5 定义范围
      1. 5.5.1 定义范围的定义及作用
      2. 5.5.2 项目范围说明书的内容
    6. 5.6 创建工作分解结构
      1. 5.6.1 创建工作分解结构的定义及作用
      2. 5.6.2 范围基准
      3. 5.6.3 WBS 工作分解注意事项
    7. 5.7 确认范围
      1. 5.7.1 确认范围的定义及作用
    8. 5.8 控制范围
      1. 5.8.1 控制范围的定义及作用