PMP认证笔记 - 项目范围管理

本章重点

• 收集范围/定义范围的相关工具
• 范围管理计划与范围说明书之间的区别
• 范围基准包括哪些内容
• 确认范围(正式验收)的概念理解

1 概述

1.1 项目范围管理包含的过程(规划过程组和监控过程组)

• 确保项目做且只做所需的全部工作
• 定义和控制哪些工作应该包括在项目内，哪些不应该包括在项目内
  项目范围管理过程包括：
  • 规范范围管理：为记录如何定义、确认和控制项目范围及产品范围，而创建范围管理计划的过程
  • 收集需求：为实现项目目标而确定、记录并管理相关方的需要和需求的过程
  • 定义范围：制定项目和产品详细描述的过程
  • 创建WBS：将项目可交付成果和项目工作分解为较小的、更易于管理的组件的过程
  • 确认范围：正式验收已完成的项目可交付成果的过程
  • 控制范围：监督项目和产品的范围状态，管理范围基准变更的过程

1.2 项目范围管理和核心概念

• 范围管理强调：不镀金，预防范围蔓延
• 产品范围、项目范围的概念和区别：
  • 产品范围：某项产品、服务或成果所具有的特征和功能，产品需求衡量产品范围是否完成
  • 项目范围：为交付具有规定特性与功能的产品、服务或成果而必须完成的工作。根据项目管理计划来衡量项目范围是否完成

1.3 项目范围管理的发展趋势与新兴实践

• 需求管理过程始于需要评估，而需要评估又可能始于项目组合规划、项目集规划或单个项目
• 注重与商业分析专业人士的合作，以便确定问题并识别商业需要
• 需求管理过程结束于需求关闭，即把产品、服务或成果移交给接收方，以便长期测量、监控、 实现和维持效益
• 项目经理与商业分析师之间应该是伙伴式合作关系

1.4 裁剪时需要考虑的因素

• 每个项目都是独特的，所以项目经理需要裁剪项目范围管理过程，裁剪时应考虑的因素包 括(但不限于)
  • 知识和需求管理：组织是否拥有正式或非正式的知识和需求管理体系?为了在未来项目中重复 使用需求，项目经理应建立哪些指南?
  • 确认和控制：组织是否拥有正式或非正式的与确认和控制相关的政策、程序和指南?
  • 开发方法：组织是否采用敏捷方法管理项目?开发方法属于迭代型还是增量型?是否采用预测
    型方法?混合型方法是否有效?
  • 需求的稳定性：项目中是否存在需求不稳定的领域?是否有必要采用精益、敏捷或其他适应型 技术来处理不稳定的需求，直至需求稳定且定义明确?
  • 治理：组织是否拥有正式或非正式的审计和治理政策、程序和指南?

卡诺模型

2. 规划范围管理

• 定义：记录如何定义、确认和控制项目范围及产品范围，而创建范围管理计划(及需求管理计划)的过程
• 作用：在整个项目期间对如何管理范围提供指南和方向
• 时间：仅开展一次或仅在项目的预定义点开展

规划范围管理:输入、工具与技术和输出

2.1 范围管理计划

• 描述将如何定义、制定、监督、控制和确认项目范围
• 范围管理计划有助于降低项目范围蔓延的风险
• 定义如何完成以下过程：
  • 制定详细项目范围说明书
  • 根据详细范围说明书创建WBS
  • 确定如何审批和维护范围基准
  • 正式验收已完成的项目可交付成果

2.2 需求管理计划

• 记录如何分析、记录和管理项目和产品需求
• 有些组织称之为“商业分析计划”
• 定义如何完成以下过程：
  • 如何规划、跟踪和报告各种需求活动
  • 配置管理活动的要求
  • 需求优先级排序
  • 产品测量指标
  • 列入跟踪矩阵的项

3 收集需求

• 定义：为实现目标而确定、记录并管理相关方的需要和需求的过程
• 作用：为定义产品范围和项目范围奠定基础
• 时间：且仅开展一次或仅在项目的预定义点开展
• (☆)让相关方积极参与需求的探索和分解工作(分解成项目和产品需求)，并仔细确定、记录和管理对产品、服务或成果的需求
• 需求包括发起人、客户和其他相关方的已量化且书面记录的需要和期望
• 收集需求从项目一开始就开始进行(分析项目章程/相关方登记册/相关方管理计划中的信息)
• 需求是工作分解结构，成本/进度/质量规划的基础
  
  

  需求分类

收集需求:输入、工具与技术和输出

3.1 收集需求：工具与技术

3.1.1 头脑风暴

• 自由发言，面对面交流
• 速度快，但容器受影响
• 本身不包含投票，排序，分类等过程。常与其他群体创新技术共同使用
• 常用技巧：
  • 不批评、不表扬
  • 以量求质
  • 尽量扩散
  • 最后总结

3.1.2 访谈

• 通常一对一，面对面交谈，也可以包括多个访谈者和/或多个被访者
• 可能获取机密信息
• 访谈技巧：
  • 开场问题：2-3个(问答题，选择题，判断题)
  • 按计划分门别类提问
  • 引导客户，选择题
  • 机会探讨(新技术等，为了下次合作)
  • 约束条件(人财物等)
  • 感谢信
  • 规划下次访谈
  • 评审

3.1.3 焦点小组

• 一定要有一个受过专业训练的主持人
• 引导、讨论
• 强调碰撞，比访谈更激烈
• 可分为不同小组和主题

3.1.4 问卷调查

• 设计书面问题，向众多受访者快速收集信息
• 适用于：受众多样化，快速完成，地理位置分散，开展统计分析

3.1.5 标杆对照

• 概念：实际项目实践与可比项目实践对比(两个项目)
• 使用范围：组织内部或外部，同一或不同领域
• 两个目的：识别最佳实践，为绩效考核提供基础
• 规划质量管理过程也用到了标杆对照

3.1.6 数据分析 - 文件分析

• 分析文件，挖掘需求
• 分析文件技巧：焦点小组会议+头脑风暴
• 可用于分析的文件包括：
  • 商业计划
  • 市场文献
  • 协议
  • 建议邀请书
  • 程序和法规文件
  • 用例

3.1.7 决策

-包括：

• 投票
  • 一致同意
  • 大多数同意(超过50%，投票者为奇数)
  • 相对多数同意
• 独裁
• 多标准决策分析

3.1.8 数据表现

亲和图

• 1.准备
• 2.头脑风暴会议
• 3.制作卡片
• 4.分成小组
• 5.并成中组
• 6.归成大组
• 7.编排卡片
• 8.确定方案

思维导图

• **`将放射性思考(头脑风暴的结果)图形化的方法
• 反映创意之间的共性和创意，激发新创意
• 以主题为中心开始，沿着不同分支进行思考
• 应用于记忆、学习、思考等的思维“地图”，利于人脑的发散思维的展开

3.1.9 人际关系与团队技能

名义小组技术

名义小组技术是一种结构化的头脑风暴形式，步骤组成：

• STEP1：向集体提出一个问题或难题，每个人沉思后写出自己的想法
• STEP2：主持人在挂图上记录所有人的想法
• STEP3：集体讨论各个想法，直到全体成员达成明确共识
• STEP4：个人私下投票决出各种想法的优先排序，可进行轮数投票，每轮投票后，都将清点选票，得票高者被选出

观察和交谈

• 难以说或不愿说
• 又被称为工作跟随
• 旁观式观察、体验式观察

引导

• 引导与主题研讨会结合使用，把主要相关方召集在一起定义产品需求
• 研讨会可用于快速定义跨职能需求并协调相关方的需求差异
• 与分别召开会议相比，研讨会能够更早发现并解决问题
• 联合应用设计或开发 (JAD)：JAD会议适用于软件开发行业。这种研讨会注重把业务主题专家和开发团队集中在一起，以收集需求和改进软件开发过程
• 质量功能展开(QFD)：制造行业则采用QFD这种引导技能来帮助确定新产品的关键特征。QFD从收集客户需要(又称“客户声音”)开始，然后客观地对这些需要进行分类和排序，并为实现这些需要而设定目标
• 用户故事：对所需功能的简短文字描述，经常产生于需求研讨会，适应于敏捷开发

3.1.10 系统交互图

• 系统交互图是范围模型的一个例子
• 它是对产品范围的可视化描绘
• 显示了业务系统的输入、输入提供者、业务系统的输出和输出接收者
• 建立了参与者与系统之间的本质关系

3.1.11 原型法

• 符合渐进明细
• 原型是有形的实物，它使得相关方可以体验最终产品的模型，而不是仅限于讨论抽象的需求描述
• 故事版：通过一系列图像或图示展示顺序或导航路径

3.2 收集需求：输出

3.2.1 需求文件

• 需求文件描述各种单一需求将如何满足与项目相关的业务需求包括
  • 可跟踪的业务目标和实施项目的原因(业务需求)
  • 相关方对沟通和报告的需求(相关方需求)
  • 功能需求；非功能性需求(解决方案需求)
  • 数据转换和培训需求等(过渡和就绪需求)
  • 验收标准(项目需求)
  • 质量需求
• 一开始概括性的需求，然后逐步细化
• 只有明确的(可测量和可测试的)、可跟踪的、完整的、相互协调的，且主要县官方愿意认可的需求，才能成为基准

3.2.2 需求跟踪矩阵(用于监控、确保每个需求都可追溯)

• 需求跟踪矩阵把每一个需求与业务目标或项目目标联系起来，有助于确保每一个需求都具有商业价值
• 为在整个项目生命周期中跟踪需求提供了一种方法
• 为管理产品范围变更提供了框架
• 包括：
  • 从需求到业务需要、机会、目的和目标
  • 从需求到项目目标
  • 从需求到项目范围/WBS中的可交付成果
  • 从需求到产品设计
  • 从需求到产品开发
  • 从需求到测试策略和测试场景/脚本
  • 从高层次需求到详细需求

4 定义范围

• 定义：制定项目和产品详细描述的过程
• 作用：描述产品、服务或成果的边界和验收标准
• 时间：且仅开展一次或仅在项目的预定义点开展
• 由于在收集需求过程中识别出的所有需求未必都包含在项目中，所以定义范围过程就要从需求文件(收集需求过程的输出)中选取最终的项目需求，制定出关于项目边界的具体描述
• 应根据项目启动过程中记载的主要可交付成果、``假设条件**和**制约因素`来编制详细的项目范围说明书

• 在迭代型生命周期的项目中，先为整个项目确定一个高层级的愿景，再一次针对一个迭代期明确详细范围(多次反复)

  
  
  

  定义范围:输入、工具与技术和输出

4.1 定义范围：工具

• 产品分析
  • 针对以产品和服务为可交付物的项目
  • 包括产品分解、需求分析、系统分析、系统工程、价值工程和价值分析(V = F / C)
• 数据分析：备选方案分析
  • 包括头脑风暴、横向思维和备选方案分析等常见方法

4.2 定义范围：输出

• 项目范围说明书是对项目范围、主要可交付成果、假设条件和制约因素的描述，包括：
  • 产品范围描述
  • 可交付成果
  • 验收标准
  • 项目除外责任
• 制定项目范围说明书时，会生成更详细的假设条件和制约因素
• 表明项目相关方之间就项目范围所达成的共识
• 描述要做和不要做的工作的详细程度，决定着项目管理团队控制整个项目范围的有效程度
• 注意项目章程与项目范围说明书内容上的差别

5. 创建WBS(工作分解结构)

• 定义：把项目可交付成果和项目工作分解成较小、更易于管理的组件的过程
• 作用：为所要交付的内容提供架构
• 时间：且仅开展一次或仅在项目的预定义点开展
• WBS(Work Breakdown Structure)：是对项目团队为实现项目目标、创建所需可交付成果而需要实施的全部工作范围的层级分解
• WBS组织并定义了项目的总范围，代表着经批准的当前项目范围说明书中所规定的工作
• WBS最低层的组成部分称为工作包,可针对工作包安排进度、估算成本和实施监控
• 工作”是指作为活动结果的工作产品或可交付成果，而不是活动本身
• WBS不表示逻辑关系和历时，只表示范围
  
  

  创建 WBS:输入、工具与技术和输出
• WBS具有层次结构，由团队成员共同完成
• 账户编码COA(Code Of Account)：每个组成部分分配唯一的编码，识别所在的层次和位置
• 控制账户(Control Account)是一种管理控制点，用于挣值分析(高低决定控制粗细)
  • 每一个控制账户都可以包括一个或多个工作包，但是每一个工作包只能属于一个控制账户
• 规划包(Planning Package)：在CA之下，工作包之上。知道工作内容，但暂时不确定详细工作分解
• 工作包(Work Package)：位于工作分解结构每条分支最底层的可交付成果或项目工作组成部分

WBS对于项目的意义

• 了解项目的范围层次结构
• 进行挣值分析的基础
• 明确责任人

WBS分解原则

• 100%包含原则：WBS分支的上下包含关系，WBS整体包含了项目所需的所有工作
• MECE(Mutually Exclusive Collectively Exhausitive 互斥，完全穷尽)
• 如果采用敏捷方法，可以将长篇故事分解成用户故事
• WBS可以采用提纲式，组织结构图或能说明层级结构的其他形式
• 不同的可交付成果可以分解到不同的层次
• 分解到可控制层面即可
• 滚动式规划：远期工作或信息暂时不足的可交付成果，可以暂时不分解，等信息充分后继续分解

分解

• 目的：便于控制
• 程度: 能够可靠的估算工作费用和持续时间
• 创建WBS的常用方法包括：自上而下、使用组织特定的指南、使用WBS模板、自下而上(用于归并较低层次组件)
• 可作为分解第二层：项目生命周期各阶段，主要的可交付物，子项目
• 不能分解：很远的将来要完成的成果(WBS也是渐进明细的定义)

范围基准&WBS词典

• 范围基准是经过批准的范围说明书、WBS和相应的WBS 词典，只有通过正式的变更控制程序才能进行变更，它被用作比较的基础。范围基准是项目管理计划的组成部分，包括：
  • 项目范围说明书
  • WBS
  • 工作包
  • 规划包
  • WBS词典
• 工作分解结构词典对工作分解结构组成部分(包括工作包和控制账户)进行更详细的描述
  • 内容：账户编码标识；工作描述；假设条件制约因素；负责的组织；进度里程碑清单；相关的进度活动；所需资源；成本估算；质量要求；验收标准；技术参考文献；协议信息
• WBS词典是最详细的范围描述

6 确认范围

• 定义：正式验收已完成的项目可交付成果的过程
• 作用：使验收过程具有客观性;同时通过确认每个可交付成果，来提高最终产品、服务或成果获得验收的可能性
• 时间：需要在整个项目期间定期开展
• 由客户或发起人审查从控制质量过程输出的核实的可交付成果，确认这些可交付成果已经圆满完成并通过正式验收
• 确认范围与控制质量区别：
  • 确认范围：关注可交付成果的验收
  • 控制质量：关注可交付成果的正确性及是否满足质量要求

  • 控制质量过程通常先于确认范围过程，但二者也可同时进行

    
    
    

    确认范围:输入、工具与技术和输出

7 控制范围

• 定义：监督项目和产品的范围状态，管理范围基准变更的过程
• 作用：在整 个项目期间保持对范围基准的维护
• 时间：需要在整个项目期间开展
• 未经控制的产品或项目范围的扩大(未对时间、成本和资源做相应调整)被称为范围蔓延

• 变更不可避免，因此在每个项目上，都必须强制实施某种形式的变更控制

  
  
  

  控制范围:输入、工具与技术和输出