- 5-项目范围管理
-- 引言
--- 产品范围 vs. 项目范围
--- 项目范围管理的过程
-- 5.1-规划范围管理
-- 5.2-收集需求
-- 5.3-定义范围
-- 5.4-创建 WBS
-- 5.5-确认范围
-- 5.6-控制范围

5-项目范围管理

引言

引言

为什么第 2 个知识域是范围管理而不是其他?
范围管理的核心目标是什么?

项目范围管理,就是确保项目做且只做所需的全部工作

产品范围 vs. 项目范围

|-|-|
|-|-|
| 产品范围 | 某项产品、服务或成果所具有的特性和功能 |
| 项目范围 | 未较丰富具有规定性与功能的产品、服务或成果而必须完成的工作
项目范围有时也包括产品范围 |

项目范围管理的过程

|-|-|-|
|-|-|-|
| 5.1 | 规划范围管理 | 规划 |
| 5.2 | 收集需求 | - |
| 5.3 | 定义范围 | - |
| 5.4 | 创建 WBS | - |
| 5.5 | 确认范围 | 监控 |
| 5.6 | 控制范围 | - |

5.1-规划范围管理

怎么管

|-|-|
|-|-|
| 定义 | 创建范围管理计划,书面描述将如何定义、确认和控制项目范围 |
| 作用 | 在整个项目中对如何管理范围提供指南和方向 |

输入与输出

| 输入 | 工具与技术 | 输出 |
|-|-|-|
| 1.项目管理计划
2.项目章程
3.事业环境因素
4.组织过程资产 | 1.专家判断
2.会议 | 1.范围管理计划
2.需求管理计划 |

范围管理计划

  • 描述将如何定义、制定、监督、控制和确认项目范围
  • 对下列工作的管理过程做出规定:

    • 制定详细项目范围说明书
    • 根据详细项目范围说明书创建WBS
    • 维护和批准工作分解结构(WBS)
    • 正式验收已完成的项目可交付成果
    • 处理对详细项目范围说明书或 WBS 的变更

需求管理计划

  • 描述如何分析、记录和管理需求
  • 主要内容至少包括:

    • 如何规划、跟踪和报告各种需求活动
    • 配置管理活动,例如,如何启动产品变更,如何分析,如何进行追溯、跟踪和报告,以及变更审批权限
    • 需求优先级排序过程
    • 产品测量指标及使用这些指标的理由
    • 用来反映哪些需求属性将被列入跟踪矩阵的跟踪结构

5.2-收集需求

你要啥

|-|-|
|-|-|
| 定义 | 为实现项目目标而确定、记录并管理干系人的需要和需求 |
| 作用 | 为定义和管理项目范围(包括产品范围)奠定基础 |

输入与输出

| 输入 | 工具与技术 | 输出 |
|-|-|-|
| 1.范围管理计划
2.需求管理计划
3.干系人管理计划
4.项目章程 | 1.访谈
2.焦点小组
3.引导式研讨会
4.群体创新技术
5.群体决策技术
6.问卷调查
7.观察
8.原型法
9.标杆对照
10.系统交互图
11.文件分析 | 1.需求文件
2.需求跟踪矩阵 |

依据

  • 项目章程 =》 项目产品、服务或成果的高层级描述
  • 干系人管理计划 =》 干系人的沟通需求和参与程序
  • 干系人登记册中 =》哪些干系人能够提供需求方面的信息、干系人对项目的主要需求和期望

访谈

  • 与干系人直接交谈获取信息
  • 一对一、多对多
  • 有经验的项目参与者、发起人、其他高管、主题专家

焦点小组

  • 召集预定的干系人和主题专家,了解他们对所讨论的产品、服务或成果的期望和态度
  • 由一位受过训练的主持人引导大家进行互动式讨论

引导式研讨会

  • 把主要干系人召集在一起,集中讨论来定义产品需求
  • 快速定义跨职能需求、协调干系人差异
  • 有助于参与者之间建立信任、改进关系、改善沟通、达成一致意见
  • 联合应用设计/开发(JAD)、质量功能展开(QFD)
  • 用户故事

    • 作为一个<角色>,我想要<活动>,以便于<商业价值>
    • 作为一个“网站管理员”,我想要“统计每天有多少人访问了我的网站”,以便于“我的赞助商了解我的网站会给我们带来什么收益。”

群体创新技术

  • 头脑风暴法:庭外判决、自由鸣放、追求数量
  • 名义小组技术:分组、多轮询问、评审排序
  • 概念/思维导图:将创意用一张简单的图联系起
  • 亲和图:对大量创意进行分组
  • 多标准决策分析:借助决策矩阵,对众多方案进行评估和排序
  • 德尔菲技术:组织专家就某一主题达成一致意见的信息收集技术
  • 特点;

    • 吸收专家参与预测,充分利用专家的经验和学识
    • 采用匿名或背靠背的方式,能使每一位专家独立自由地做出自己的判断
    • 预测过程几轮反馈,使专家的意见逐渐趋同
    • 减轻数据偏倚,防止任何人对结果产生不恰当的影响

群体决策技术

  • 一致同意 / 大多数原则 / 相对多数原则 / 独裁

问卷调查

  • 设计一系列书面问题,向众多受访者快速收集信息
  • 适用于:受众多样化,需要快速完成调查,受访者地理位置分散,并且适合开展统计分析

观察

  • 直接察看个人在各自的环境中如何执行工作和实施流程
  • 当产品使用者难以或不愿清晰说明他们的需求时,就特别需要通过观察来了解他们的工作细节
  • 体验该流程或程序是如何实施的,一边挖掘隐藏的需求

原型法

  • 先造出该产品的实用模型,据此征求对需求的早期反馈
  • 故事板是一种原型技术,通过一系列的图像或图示来展示顺序或导航路径

标杆对照

  • 将实际或计划的做法与其他可比的做法进行比较,以便识别最佳实践,形成改进意见,并为绩效考核提供依据
  • 所采用的可比做法可以是内部的,也可以是外部的

系统交互图

  • 是对产品范围的可视化描绘
  • 显示业务系统与人和其他系统之间的交互方式

-pic-5-系统交互图

文件分析

  • 分析现有文档,识别与需求相关的信息,来挖掘需求
  • 如:商业计划、营销文献、协议、建议邀请书、现行流程、逻辑数据模型、业务规则库、应用软件文档、业务流程或接口文档、用例、其他需求文档、问题日志、政策、程序和法规文件(如法律、准则、法令等)

需求文件

|-|-|
|-|-|
| 业务需求 | 整个组织的高层级需要 |
| 干系人需求 | 干系人或干系人群体的需求 |
| 解决方案需求 | 功能需求 / 非功能需求 |
| 项目需求 | 项目需要满足的行动、过程或其他条件 |
| 过渡需求 | 从“当前状态”过渡到“将来状态”所需的临时能力 |
| 质量需求 | 用于确认项目可交付成果的成功完成或其他项目需求的实现的任何条件或标准 |

需求跟踪矩阵

  • 把产品需求从其来源连接到能满足需求的可交付成果的一种表格
  • 提供了在整个项目生命周期中跟踪需求的一种方法
  • 为管理产品范围变更提供了框架

-pic-5-需求跟踪矩阵-1
-pic-5-需求跟踪矩阵-2

5.3-定义范围

我干啥

|-|-|
|-|-|
| 定义 | 制定项目和产品详细描述 |
| 作用 | 明确所收集的需求哪些将包含在项目范围内,哪些将排除在项目范围外,从而明确项目、服务或成果的边界 |

输入与输出

| 输入 | 工具与技术 | 输出 |
|-|-|-|
| 1.范围管理计划
2.项目章程 3.需求文件 4.组织过程资产 | 1.专家判断
2.产品分析
3.备选方案生成
4.引导式研讨会 | 1.项目范围说明书
2.项目文件更新 |

产品分析

  • 对于以产品可交付成果的项目非常有效
  • 包括:产品分解、系统分析、需求分析、系统工程、价值工程和价值分析等

备选方案生成

  • 制定尽可能多的潜在可选方案
  • 识别执行项目工作的不同方法
  • 生成备选方案的技术有:头脑风暴、横向思维、备选方案分析

项目范围说明书

  • 对项目范围、主要可交付成果、假设条件和制约因素的描述
  • 记录了整个范围,包括项目和产品范围
  • 包括:项目目标;产品范围描述;项目需求;项目边界;项目的可交付成果;项目的制约因素;假设条件‘

项目范围说明书 vs. 项目章程

-pic-5-项目范围说明书 vs. 项目章程

5.4-创建 WBS

细一点

|-|-|
|-|-|
| 定义 | 把项目可交付成果和项目工作分解成较小的、更易于管理的组件 |
| 作用 | 对所要交付的内容提供一个结构化的视图 |

输入与输出

| 输入 | 工具与技术 | 输出 |
|-|-|-|
| 1.范围管理计划
2.项目范围说明书
3.需求文件
4.事业环境因素
5.组织过程资产 | 1.分解
2.专家判断 | 1.范围基准
2.项目文件更新 |

分解

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

WBS

  • 对项目团队为实现项目目标、创建所需可交付成果而需要实施的全部工作范围的层级分解
  • 工作分解结构每向下分解一层,代表着对项目工作更详细的定义
  • 是后续管理工作的主要依据,是项目时间、成本、人力等管理工作基础
  • 树形结构、列表形式

-pic-5-wbs-1
-pic-5-wbs-2

分解-按生命周期

-pic-5-wbs-分解-按生命周期-1

分解-按可交付成果

-pic-5-wbs-分解-按可交付成果-1

对比

-pic-5-wbs-对比

WBS-概念

-pic

WBS-原则

有理、有据、有人管
不缺、不重、不添乱

范围基准

  • 批准的范围说明书、工作分解结构(WBS)和相应的 WBS 词典
  • WBS 词典是针对每个 WBS 组件,详细描述可交付成果、活动和进度信息的文件
  • WBS 词典包括:账户编码标识、工作描述、假设条件和制约因素、负责的组织、进度里程碑、相关的进度互动、所需资源、成本估算、质量要求、验收标准、技术参考文献、协议信息。

WBS词典

-pic

5.5-确认范围

你验收

|-|-|
|-|-|
| 定义 | 正式验收已完成的项目可交付成果 |
| 作用 | 使验收过程具有客观性;同时通过验收每个可交付成果,提高最终产品、服务或成果获得验收的可能性 |

确认范围 vs. 控制质量

|-|-|
|-|-|
| 确认范围 | 关注可交付成果的验收 |
| 控制质量 | 关注可交付成果的正确性及是否满足质量要求 |

输入与输出

| 输入 | 工具与技术 | 输出 |
|-|-|-|
| 1.范围管理计划
2.需求文件
3.需求跟踪矩阵
4.核实的可交付成果
5.工作绩效数据 | 1.检查
2.群体决策技术 | 1.验收的可交付成果
2.变更请求
3.工作绩效信息
4.项目文件更新 |

确认范围的步骤

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

检查什么?

  1. 可交付成果是否是确定的、可确认的
  2. 每个可交付成果是否有明确的里程碑
  3. 是否有明确的质量标准
  4. 审核和承诺是否有清晰的表达
  5. 项目范围是否覆盖了完成产品或服务的所有活动
  6. 项目范围的风险是否太高,是否能够降低可预见风险对项目的冲击

干系人关注点

|-|-|
|-|-|
| 管理层 | 范围对项目的进度、资金和资源的影响 |
| 客户 | 产品范围,项目的可交付成果是否足够完成产品或服务 |
| 项目管理人员 | 可交付成果是否足够和必须完成,时间、资金和资源是否足够
| 项目团队成员 | 项目范围中自己参与的元素和负责的元素 |

验收的可交付成果

  • 由客户或发起人正式签字批准的符合验收标准的可交付成果
  • 应该客户或发起人那里获得正式文件,证明干系人对项目可交付成果的正式验收

5.6-控制范围

做且仅做

|-|-|
|-|-|
| 定义 | 监督项目和产品的范围状态,管理范围基准变更的过程 |
| 作用 | 在整个项目器间保持对范围基准的维护 |

输入与输出

| 输入 | 工具与技术 | 输出 |
|-|-|-|
| 1.范围管理计划
2.需求文件
3.需求跟踪矩阵
4.工作绩效数据
5.组织过程资产 | 1.偏差分析 | 1.工作绩效信息
2.变更请求
3.项目管理计划更新
4.项目文件更新
5.组织过程资产 |

偏差分析

  • 一种确定实际绩效与基准的差异程度及原因的技术
  • 可利用项目绩效测量结果评估偏离范围基准的程度,并决定是否需要采取纠正或预防措施

范围蔓延 vs. 镀金

|-|-|-|
|-|-|-|
| 范围蔓延 | 未经变更控制的产品或项目范围的扩大;往往由客户导致 |
| 镀金 | 团队主动增加的项目范围以外的工作 | - |

标签: none