知识领域 / 过程组启动 2规划 24执行 10监控 12收尾 1

整合

制定项目章程

制定项目管理计划

指导与管理项目工作
管理项目知识

监控项目工作
实施整体变更控制

结束项目或阶段

# 核心概念

  • 项目范围管理包括做且只做所需的全部工作。
  • “范围” = 产品范围 + 项目范围。
产品范围
某项产品、服务或成果所具有的特性和功能
项目范围
为交付具有规定特性与功能的产品、服务或成果而必须完成的工作
  • 项目管理计划衡量项目范围的完成情况,用产品需求衡量产品范围的完成情况。
产品范围项目范围
相互关系决定项目范围服务于产品范围
影响关系自身变化不一定会引起项目范围的变化自身变化不一定会引起产品范围的变化
包含关系不包含项目范围广义上有时也包括产品范围
衡量依据产品需求文件项目管理计划
  • 预测型和适应型生命周期之范围管理的对比
预测型生命周期适应型 / 敏捷型生命周期
总体模式项目开始时就对项目可交付成果进行定义,对任何范围变化都要进行渐进管理通过多次迭代来开发可交付成果,并在每次迭代开始时定义和批准详细的范围
基本特征需求稳定,技术成熟应对大量变更,相关方持续参与
何时从哪里收集需求、定义范围、创建 WBS项目开始时,从所有需求中开展这些过程,必要时通过实施整体变更控制过程进行更新。每个迭代开始时,在产品未完项中选择最优先项开展这些过程。

何时确认范围、控制范围

确认范围每个可交付成果生成时或在阶段审查点
控制范围持续性进行。

每次迭代中

最终的范围基准项目范围说明书 + WBS+WBS 词典未完项(包括产品需求和用户故事)

# 项目范围管理的 “发展趋势和新兴实践”

  • 需求一直是项目管理中的重点。
    组织开始认识到如何运用商业分析,通过定义、管理和控制需求活动来提高竞争优势。
  • 商业分析活动可在项目启动和项目经理任命之前就开始。
    要注重与商业分析专业人士的合作。
  • 需求管理过程始于需要评估,结束于需求关闭。
  • 项目经理与商业分析师之间是伙伴式合作关系。
    • 商业分析师负责需求管理相关的活动
    • 项目经理负责确保这些活动在项目管理计划有所安排,并且在预算内按时完成,同时能够创造价值

# 在敏捷和适应型环境中需要考虑的因素

  • 特意在项目早期缩短定义和协商范围的时间,并为持续探索和明确范围而延长创建相应过程的时间。

  • 有目的地构建和审查原型,并通过多次发布版本来明确需求。把需求列入未完项

# 讨论 “需求” 和 “范围” 的区别

需求
是一种需要
范围
是满足 “需求” 必须交付的可交付成果和相关工作

# 规划 规划范围管理

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

  • 本过程的作用:在整个项目中对如何管理范围提供指南和方向

过程输入工具和技术输出
规划范围管理项目章程专家判断范围管理计划

项目管理计划

  • 质量管理计划
  • 项目生命周期描述会议
  • 开发方法

数据分析

  • 备选方案分析

需求管理计划

事业环境因素
组织过程资产

# 输入

# 1️⃣ 项目章程

项目章程记录项目目的、项目概述、假设条件、制约因素,以及项目意图实现的高层级需求。

# 工具和技术

理解为主

# 输出

# 1️⃣ 范围管理计划

  • 描述如何定义、制定、监督、控制和确认项目范围。

  • 注意点:

    1. 范围管理计划无范围,范围是记录在范围基准中的;
    2. 范围管理计划可以是正式或非正式的,非常详细或高度概括的。

# 2️⃣ 需求管理计划

  • 描述将如何分析、记录和管理项目和产品需求。

  • 注意:

    1. 需求管理计划无需求,需求在需求文件中
    2. 内容包括配置管理活动、需求优先级排序过程、测量指标等。

# 规划 收集需求

  • 为实现目标而确定记录管理相关方的需要和需求的过程。
需求
根据特定协议或其他强制性规范,产品、服务或成果必须具备的条件或能力。
需求包括发起人、客户和其他相关方的已量化书面记录的需要和期望。
过程输入工具和技术输出
收集需求项目章程专家判断需求文件

项目管理计划

  • 范围管理计划
  • 需求管理计划
  • 相关方参与计划

数据收集

  • 头脑风暴
  • 访谈
  • 焦点小组
  • 问卷调查
  • 标杆对照

需求跟踪矩阵

项目文件

  • 假设日志
  • 经验教训登记册
  • 相关方登记册

数据分析

  • 文件分析

商业文件

  • 商业论证

决策

  • 投票
  • 独裁型决策
  • 多标准决策分析

协议

数据表现

  • 亲和图
  • 思维导图

事业环境因素

人际关系与团队技能

  • 名义小组
  • 观察/交谈
  • 引导
组织过程资产系统交互图
原型法

# 输入

# 1️⃣ 项目文件

相关方登记册
用于了解哪些相关方能够提供需求方面的信息,及记录相关方对项目的需求和期望。

# 2️⃣ 商业文件

  • 会影响收集需求过程的商业文件是商业论证
  • 它描述了为满足业务需要应该达到必要期望可选标准

# 3️⃣ 协议

  • 协议会包含项目和产品需求。

# 工具与技术

工具与技术类别工具与技术名称关键词
数据收集头脑风暴大量创意、各种想法、畅所欲言
访谈直接交谈、预设和即兴问题、一对一、多对多、获取机密信息
焦点小组同职能同一领域、有相似背景、主题专家 SME 、主持人引导互动式讨论
问卷调查受众多样化、需快速完成、地理位置分散、适合开展统计分析
标杆对照标杆可以是内部或外部、同行业或不同行业、识别最佳实践、形成改进意见
数据分析文件分析分析现有文件
决策投票一致同意每个人都同意、德尔菲专家、匿名、多轮趋同、消除偏见)
大多数同意超过 50%、一般把决策小组的人数定为奇数
相对多数同意相对多数,通常候选项超过两个时使用。(没有任何一个超过 50%)
独裁型决策制定一个人做决策
多标准决策分析决策矩阵、多种标准(可以加权)、评估和排序
数据表现亲和图分组、分类,以便进一步审查分析
思维导图整合、反映共性与差异、激发新创意、脑图
人际关系与团队技能名义小组(民意小组)促进头脑风暴、投票(强调投票这一过程,而非决策结果)、优先排序、5 分制、数轮
观察(工作跟随)和交谈“工作跟随”、难以或不愿清晰说明挖掘隐藏的需求
引导与主题研讨会结合使用 引导式研讨会跨职能不同部门协调相关方差异
联合应用设计或开发 JAD软件开发行业、业务主题专家和开发团队集中
质量功能展开 QFD制造行业、收集客户需要(客户声音)开始、分类和排序
用户故事需求研讨会、角色、目标、动机
系统交互图拓扑图、可视化

原型法

  • 支持渐进明细的理念。
  • 例如:故事板,能减轻返工的风险
  • 步骤(反复循环):
    1. 模型创建
    2. 用户体验
    3. 反馈收集
    4. 原型修改(可能需要走变更流程)

# 输出

# 1️⃣ 需求文件

  • 描述各种单一需求如何满足与项目相关的业务需求
    只有明确的(可测量和可测试的)、可跟踪的、完整的、相互协调的,且主要相关方愿意认可的需求,才能作为基准。

  • 需求的分类:

    • 业务需求:整个组织的高层级需要
    • 解决方案需求:为满足业务需求和相关方需求,产品、服务或成果必须具备的特性、功能和特征。分功能需求和非功能需求。
    • 项目需求:项目需要满足的行动、过程或其他条件,例如里程碑日期、合同责任、制约因素
    • 相关方需求:相关方或相关方群体的需要
    • 过渡和就绪需求:从 “当前状态” 过渡到 “将来状态” 所需的临时能力。 例如:数据转换培训需求
    • 质量需求:用于确认可交付成果的成功完成或其他项目需求的实现的任何条件或标准,例如测试、认证、确认

# 2️⃣ 需求跟踪矩阵

  • 产品需求从其来源连接到能满足需求的可交付成果的一种表格。
    把每个需求业务目标项目目标联系起来,有助于确保每个需求都具有商业价值
  • 提供了在整个项目生命周期跟踪需求的一种方法(正向跟踪和逆向跟踪)
    有助于确保需求文件中被批准的每项需求在项目结束的时候都能交付
  • 收集需求时产生的需求文件和需求跟踪矩阵并不代表项目的真实范围
    需要进一步明确哪些包含在项目范围内,哪些排除在项目范围外。(定义范围)

# 规划 定义范围

  • 制定项目和产品详细描述的过程。
本过程的作用
描述产品、服务或成果的边界验收标准

从需求文件中选取最终的项目需求,然后制定出关于项目及其产品、服务或成果的详细描述。(P151)

  • 需要多次反复开展定义范围过程:在迭代型生命周期的项目中,先为整个项目确定一个高层级的愿景,再一次针对一个迭代期明确详细范围。
过程输入工具和技术输出
定义范围项目章程专家判断项目范围说明书

项目管理计划

  • 范围管理计划

数据分析

  • 备选方案分析

项目文件更新

  • 假设日志
  • 需求文件
  • 需求跟踪矩阵
  • 相关方登记册

项目文件

  • 假设日志
  • 需求文件
  • 风险登记册

决策

  • 多标准决策分析

事业环境因素

人际关系与团队技能

  • 引导
组织过程资产产品分析

# 输入

# 1️⃣ 项目章程

项目章程中包含对项目的高层级描述产品特征审批要求

# 2️⃣ 项目文件

需求文件
识别了应纳入范围的需求。

# 工具与技术

# 1️⃣ 数据分析

可用于本过程的数据分析技术包括:备选方案分析

# 2️⃣ 决策

可用于本过程的决策技术包括:多标准决策分析

# 3️⃣ 人际关系与团队技能

在研讨会和座谈会中使用引导技能来协调具有不同期望或不同专业知识的关键相关方,使他们就项目可交付成果以及项目和产品边界达成跨职能的共识

# 4️⃣ 产品分析

  • 高层级的产品描述转变为有形的可交付成果
  • 产品分析技术包括产品分解、系统分析、需求分析、系统工程价值工程价值分析等。

# 输出

# 1️⃣ 项目范围说明书

  • 是对项目范围、主要可交付成果、假设条件和制约因素的描述。记录了整个范围,包括项目和产品范围

  • 项目范围说明书详细描述了项目的可交付成果,还代表项目相关方之间就项目范围所达成的共识

  • 为了便于管理相关方的期望,项目范围说明书可明确指出哪些工作不属于本项目范围

  • 详细的项目范围说明书包括以下内容:

包含的内容内容描述
产品范围描述逐步细化项目章程需求文件中所述的产品、服务或成果的特征

可交付成果

必须产出的任何独特并可核实的产品、成果或服务能力。
也包括辅助成果,如项目管理报告和文件

验收标准可交付成果通过验收前必须满足的一系列条件。
除外责任明确说明哪些内容不属于项目范围,有助于管理相关方的期望减少范围蔓延

补充示例:
高层级需求、需求、范围
用需求跟踪矩阵连接需求文件与范围说明书

项目章程需求文件范围说明书
  • 高层级需求:
    有荤、有素、有汤、有主食
  • 主要(高层级)可交付成果:
  • 单一需求
  • 可交付成果 / 验收标准
蔬菜蔬菜要有绿叶菜香菇菜心 / 验收标准
水果水果要拼盘不能单一水果拼盘 / 验收标准
荤菜要下饭回锅肉 / 验收标准
虾或蟹虾蟹要新鲜大闸蟹 / 验收标准
汤要素一点紫菜鸡蛋汤 / 验收标准
有人在旁边拉小提琴米饭 / 验收标准

# 规划 创建工作分解结构 WBS, Work Breakdown Structure

  • 把项目可交付成果项目工作分解成较小的、更易于管理的组件的过程。
本过程的作用
对所要交付的内容提供架构。
WBS 组织并定义了项目的总范围,代表着经批准的当前项目范围说明书中所规定的工作(项目范围说明书只定义范围,没有组织范围)
  • WBS 最低层的组成部分称为工作包,其中包括计划的工作。
  • 在 “工作分解结构” 这个词语中,“工作” 是指作为活动结果的工作产品或可交付成果,而不是活动本身
过程输入工具和技术输出

创建 WBS

项目管理计划

  • 范围管理计划

专家判断

范围基准

项目文件

  • 项目范围说明书
  • 需求文件

分解

项目文件更新

  • 假设日志
  • 需求文件
事业环境因素
组织过程资产

# 输入

# 1️⃣ 项目范围说明书

描述了需要实施的工作及不包含在项目中的工作。

# 2️⃣ 需求文件

需求文件详细描述了各种单一需求如何满足项目的业务需要。

# 工具和技术

# 1️⃣ 分解

  • 把项目范围和项目可交付成果逐步划分为更小、更便于管理的组成部分的技术。
工作包
WBS 最低层的组件,可对其成本持续时间进行估算和管理。

创建 WBS,就是要将整个项目工作分解为工作包

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

WBS 的结构可以采用如下形式

  • 项目生命周期的各阶段作为分解的第二层,产品和项目可交付成果放在第三层。
  • 主要可交付成果作为分解的第二层
  • 纳入由项目团队以外的组织开发的各种较低层次组件(如外包工作
    作为外包工作的一部分,卖方须制定相应的合同 WBS。


  • 创建 WBS 的四个注意

    1. 如果采用敏捷方法,可以将长篇故事分解成用户故事
    2. 不同的可交付成果可以分解到不同的层次。
    3. 并不是分解得越细越好。
      过细的分解会造成管理努力的无效耗费资源使用效率低下工作实施效率降低,同时造成 WBS 各层级的数据汇总困难
    4. 远期才完成的可交付成果或组件,当前可能无法分解成工作包,此时称为 规划包 ,需要滚动式规划
  • 创建 WBS 的四个主要原则

    1. 必须 100% 原则:无遗漏无多余;
    2. 必须 责任唯一:责任明确原则,有明确责任人;
    3. 建议 80 小时原则:工作包 80 小时,即不超过两周,否则颗粒度过大
    4. 建议 4~6 层原则:根据项目具体情况来,不宜过细分解。

# 输出

# 1️⃣ 范围基准

  • 经过批准范围说明书WBS 和相应的 WBS 词典

范围基准数据项目管理计划的一部分,故也是由主要相关方批准

范围说明书WBSWBS 词典
  • 产品范围描述
  • 验收标准
  • 可交付成果
  • 项目的除外责任
  • 工作包
  • 规划包
  • 控制帐户
  • 账户编码标志号
  • 工作描述
  • 负责的组织
  • 进度里程碑清单
  • 相关的进度活动
  • 所需的资源
  • 成本估算
  • 质量要求
  • 验收标准
  • 技术参考文献
  • 协议信息

哪儿找可交付成果和验收标准:首选范围说明书,次选 WBS 词典,再次选范围基准

WBS 词典
针对 WBS 中的每个组件,详细描述可交付成果、活动和进度信息的文件。
控制账户 CA
是一个管理控制点(可以与组织的财务程序链接),在该控制点上,把范围、预算、实际成本和进度加以整合,并与挣值相比较,以测量绩效

每个控制账户可能包括一个或多个工作包(或规划包),但是一个工作包只能属于一个控制账户。

绩效测量基准 PMB
范围基准、进度基准、成本基准共同构成

# 监控 确认范围 Validate scope

  • 客户” 或 “发起人 正式验收已完成的项目可交付成果的过程。
本过程的作用
  • 通过验收每个可交付成果,提高最终产品、服务或成果验收的可能性。
  • 使验收过程具有客观性。

确认范围过关注可交付成果的验收,而控制质量关注可交付成果的正确性及是否满足质量要求。
控制质量过程通常先于确认范围过程,但二者也可同时进行。

过程输入工具和技术输出

确认范围

项目管理计划

  • 范围管理计划
  • 需求管理计划
  • 范围基准

检查

验收的可交付成果

项目文件

  • 经验教训登记册
  • 质量报告
  • 需求文件
  • 需求跟踪矩阵

决策

  • 投票

工作绩效信息

核实的可交付成果变更请求

工作绩效数据

项目文件更新

  • 经验教训登记册
  • 需求文件
  • 需求跟踪矩阵

# 输入

# 1️⃣ 核实的可交付成果

已经完成,并被控制质量过程检查为正确的可交付成果。

# 工具与技术

# 1️⃣ 检查(审查、产品审查、巡检)

开展测量、审查与确认等活动,来判断工作和可交付成果是否符合 需求和产品验收标准。

# 输出

# 1️⃣ 验收的可交付成果

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

# 2️⃣ 变更请求

  • 如果未通过验收,处理步骤:
    1. 记录(了解)原因;
    2. 变更流程,进行缺陷补救

# 监控 控制范围

  • 监督项目和产品的范围状态,管理范围基准变更的过程。
本过程的作用
  • 在整个项目期间保持对范围基准的维护。
    • 确保所有变更请求、纠正措施、预防措施都通过实施整体变更控制过程进行处理。
过程输入工具和技术输出

控制范围

项目管理计划

  • 范围管理计划
  • 需求管理计划
  • 变更管理计划
  • 配置管理计划
  • 范围基准
  • 绩效测量基准

数据分析

  • 偏差分析
  • 趋势分析

工作绩效信息

项目文件

  • 经验教训登记册
  • 需求文件
  • 需求跟踪矩阵

变更请求

工作绩效数据

项目管理计划更新

  • 范围管理计划
  • 范围基准
  • 进度基准
  • 成本基准
  • 绩效测量基准

组织过程资产

项目文件更新

  • 经验教训登记册
  • 需求文件
  • 需求跟踪矩阵

# 输入、输出

理解为主

# 工具和技术

# 1️⃣ 偏差分析

  • 用于将基准实际结果进行比较,以确定偏差是否处于临界值区间内或是否有必要采取纠正或预防措施。

# 2️⃣ 趋势分析

  • 旨在审查项目绩效随时间的变化情况,以判断绩效是正在改善还是正在恶化。

  • 确定偏离范围基准的原因和程度,并决定是否需要采取纠正或预防措施,是项目范围控制的重要工作。

范围蔓延
  • 未对时间、成本和资源做相应调整,未经控制的产品或项目范围的扩大。(P168)
    • 来自团队内部原因造成的范围蔓延称为 “镀金
    • 来自团队外部原因造成的范围蔓延称为 “范围潜变”。
镀金
项目人员为了 “讨好” 客户而做的不解决实际问题、没有应用价值的项目活动。
范围潜变
范围潜变是指客户不断提出小的、不易察觉的范围改变,如果不加控制,累计起来导 致项目严重偏离既定的范围基准,导致项目失控和失败

如果已经出现了范围蔓延,需要补变更流程。如果变更没有获得批准,需要取消不良变更。