第五章 项目范围管理
2021-10-16 14:02:21 0 举报PMP学习笔记
作者其他创作
大纲/内容
在项目环境中，“范围”这一术语由两种含义
产品范围
某些产品、服务或成果所具有的特征和功能。
产品范围的完成情况是根据产品需求文件来衡量的。
项目范围
为交付具有规定特性与功能的产品、服务或成果而必须完成的工作。
项目范围有时也包括产品范围
项目范围的完成情况是根据项目需求计划来衡量的。
项目范围管理的目的
项目范围管理包括确保项目做且只做所需的全部工作，已成功完成项目的各个过程。把该干的干了。
管理项目范围主要在于定义和控制哪些工作应该包括在项目内，哪些不应该包括在项目内。明确范围的界限。
范围蔓延（scope creep）
未经控制的成本或项目范围的扩大（未考虑对时间、成本和资源的影响）被称为范围蔓延。
范围蔓延，将挤压项目的成本、时间和资源，将把项目推向失败的边缘。
范围蔓延分类
镀金
来自团队内部原因造成的范围蔓延成为“镀金”
镀金往往是项目人员为了“讨好”客户而做的不解决实际问题、没有应用价值的项目活动。
范围潜变
来自团队外部原因造成的范围蔓延称为“范围潜变”
范围潜变是指客户不断提出小的、不易察觉的范围改变，如果不加控制，累计起来导致项目严重偏离既定的范围基准，导致项目失控和失败。
范围管理过程
子主题
规划范围管理
规划范围管理是为记录：如何定义、确认和控制项目范围及产品范围，而创建需求管理计划和范围管理计划的过程。
主要作用：
在整个项目期间对如何管理范围提供指南和方向。
范围管理计划
是项目或项目集管理计划的组成部分，描述将如何定义、制定、监督、控制和确认项目范围。
本过程仅开展一次或仅在项目预定义点开展。
子主题
输入
项目章程
项目管理计划
质量管理计划
项目生命周期描述
开发方法
事业环境因素
组织过程资产
工具与技术
专家判断
数据分析
适用于本过程的数据分析技术包括备选方案分析。
本技术用于评估收集需求、详述项目和产品范围、创造产品、确认范围和控制范围的各种方法。
会议
输出
范围管理计划
范围管理计划是项目管理计划的组成部分，描述将如何定义、制定、监督、控制和确认项目范围。
范围管理计划将用于下列工作的管理过程作出规定
1.制定项目范围说明书
2.根据详细项目范围书创建WBS
3.确定如何审批和维护范围基准
4.正式验收已完成的项目可交付成果
根据项目需求，范围管理计划可以是正式或非正式的，非常详细或概括的。
需求管理计划
需求是指根据特定协议或其他强制性规范，项目必须满足的条件或能力，或者产品、服务或成果必须具备的条件或能力。
需求是来自相关方的量化的、书面记录的需求和期望。
需求管理计划描述将如何分析、记录和管理项目和产品需求。
需求管理计划与生命周期模型的选择有很大关系。
项目经理应该为项目选择最有效的阶段间关系，并将此记录在需求管理计划中。
需求管理计划的内容
1.如何计划、跟踪和报告与需求相关的活动。
2.配置管理相关活动：变更的发起、分析评估、跟踪、报告，以及批准变更的授权级别。
3.确定需求优先级的流程。
4.产品的度量指标，以及使用这些指标的理由。
5.可跟踪的结构。哪些需求特征将被跟踪，对应于需求文件中的哪一项需求。
收集需求
什么是需求
需求是指根据特定协议或其他强制性规范，产品、服务或成果必须具备的条件或能力。
它包括发起人、客户和其他相关方的已量化且书面记录的需求和期望。
应该足够详细地探明、分析和记录这些需求，将其包含在范围基准中，并在项目执行开始后对其进行测量。
需求将成为工作分解结构（WBS）的基础，也将成为成本、进度、质量和采购规划的基础。
收集需求是为实现目标而确定、记录并管理相关方的需要和需求的过程。
本过程的主要作用是，为定义产品范围和项目范围奠定基础，且仅开展一次或仅在项目的预定义点开展。
子主题
输入
项目章程
项目管理计划
范围管理计划
需求管理计划
相关方参与计划
项目文件
假设日志
经验教训登记册
相关方登记册
商业文件
协议
事业环境因素
组织过程资产
工具与技术
专家判断
数据收集
头脑风暴
是一种用来产生和收集对项目需求与产品需求的多种创意的技术
目的：在短时间内获得大量创意。
适用于团队环境，有一个会议引导者。
参与者不限项目团队。
结论：收集到的需求，并且进行了确认。
传统的头脑风暴法不包含投票或排序，但延申的头脑风暴可以包括两个部分：创意产生和创意分析。
子主题
访谈
访谈时通过与相关方直接交谈，来获取信息的正式或非正式的方法。
访谈的典型做法是向被访者提出预设和即兴的问题，并记录他们的回答。
访谈经常是一个访谈者和一个被访者之间的“一对一”谈话，但也可以包括多个探访者和/或多个被访者。
访谈有经验的项目参与者、发起人和其他高管，以及主题专家，有助于识别和定义所需产品可交付成果的特征和功能。
访谈也用于获取机密信息。
焦点小组Focus Groups
参与者
1.训练有素的主持人（moderator）
2.事先通过资格确认的相关方、领域专家
目的：了解他们对产品/服务/成果的期望和态度。
方法
1.协调人带领会议
2.互动讨论
3.Conversation，而不是一问一答，而不是interview
问卷调查
事先准备一系列书面问题，快速收集意见。
适用性：
受众广。
需要快速完成调查。
人员地理分布广。
可以开展统计分析。
标杆对照
把实际或计划的做法（如流程和操作过程）与其他组织的做法进行比较，识别最佳实践，形成改进意见。
对比组织可以是内部的，也可以是外部的。
Benchmarking的最大优点是可以使绩效跃进，而不是逐渐改进。
子主题
数据分析
文件分析
包括审核和评估任何相关的文件信息
通过分析现有文件，识别与需求相关的信息来获取需求
有助于获取相关需求的文件很多
协议
商业计划
业务流程或接口文档
业务规则库
现行流程
市场文献
问题日志
政策和程序
法规文件，如法律、规则、法令等
建议邀请书
用例
决策
投票
投票是一种为达成某种期望结果，而对多个未来行动方案进行评估的集体决策技术和过程。
本技术用于生成、归类和排序产品需求。
投票技术示例包括：
1.一致同意。
每个人都同意某个行动方案。
2.大多数同意。
获得群体中超过50%人员的支持，就能做出决策。
把参与决策的小组人数定为奇数，可防止因平局而无法达成决策。
3.相对多数同意。
根据群体中相对多数人的意见做出决策，即便未能获得大多数人的支持。
通常在候选项超过两个时使用。
多标准决策分析
该技术借助决策矩阵，用系统分析方法建立诸如风险水平、不确定性和价值收益等多种标准，以对众多创意进行评估和排序。
子主题
独裁型决策制定
采用这种方法，将由一个人负责为整个集体制定决策。
数据表现
亲和图
用来对大量创意进行分组的技术，以便进一步审查和分析。
思维导图
把从头脑风暴中获得的创意（概念/观点/创意idea）整合成一张图，用以反映创意之间的共性与差异，激发新创意。
人际关系与团队技能
名义小组技术
名义小组技术是用于促进头脑风暴的一种技术，通过投票排列最有用的创意，以便进一步开展头脑风暴或优先排序。
名义小组技术是一种结构化的头脑风暴形式，有四个步骤组成：
1.向集体提出一个问题或难题。每个人在沉思后写出自己的想法。
2.主持人在活动挂图上记录所有人的想法。
3.逐个讨论每一个idea，直到所有人都完全清楚这个idea的意思。
4.个人私下对各个idea的优先级进行投票（1-5分）。为坚守idea的数量，可进行数论投票。每轮投票后，都将清点选票，得分高的想法被选出来继续投票。
观察/交谈
也叫job shadowing：工作影子、工作跟随。
外部观察：站旁边看
参与型观察：跟着做
适用情形
1.用户不愿意或者不能说出他们的需求时，可以采用观察的方法。
2.了解他们的工作流程，挖掘隐藏的需求。
引导
参与者：关键的跨职能的相关方
目的：快速定义各职能的需求，协调相关方之间的差异。
好处：
1.建立互信关系，提出沟通效果，有助于达成一致。
2.相比单独的会议，把这些人叫到一起，可以快速发现和解决问题。
举例
联合应用设计或开发（JAD）
JAD会议适用于软件开发行业。这种研讨会注重把业务主题专家和开发团队集中在一起，以收集需求和改进软件开发过程
质量功能展开（QFD）
制造行业则采用QFD这种引导技能来帮助确定新产品的关键特征。
QFD从收集客户需要（又称“客户声音”）开始，然后客观地对这些需求进行分类和排序，并为实现这些需要而设定目标
用户故事
用户故事是对所需功能的简短文字描述，经常产生于需求研讨会。
用户故事描述哪个相关方将从功能中收益（角色），他需要实现什么（目标），以及他期望获得什么利益（动机）
系统交互图
对产品范围的可视化描述
是范围模型的一个例子
展示业务系统、人及其他系统之间的交互方式
系统交互图显示了业务系统的输入、输入提供者、业务系统的输出和输出接受者。
原型法
在正式建造产品之前，给相关方提供一个目标产品的工作模型，来征集相关方的需求。
原型包括微缩产品、计算机生成的二维和三维模型、实体模型或模拟。
允许相关方对模型进行体验和操作，而不是空谈抽象的概念。
原型法支持：渐进式开发方法、渐进明细。
采用迭代式开发方法：模型-用户体验-收集反馈-原型修改-提供模型-用户体现-收集反馈-...-实现全部需求。
输出
需求文件
需求文件描述了所有需求，以及各个需求如何满足项目的商务需求。
需求从高层需求开始不断细化。
需求基准化之前的要求：可度量、可测试、可跟踪、完整性、一致性。得到关键相关方的认可。
需求文件的格式多种多样，既可以是一份按相关方和优先级分类列出全部需求的简单文件，也可以是一份包括内容提要、细节描述和附件等的详细文件。
需求分类
1.业务需求。
整个组织的高层级需要，实施项目的原因。
2.相关方需求。
相关方或相关方群体的需求。
3.解决方案需求。
产品、服务或成果必须具备的特性、功能和特征。解决方案需求又进一步分为功能需求和非功能需求。
4.功能需求。
功能需求描述产品应具备的功能。
5.非功能需求。
非功能需求是对功能需求的补充，是产品正常运行所需的环境条件或质量要求，例如，可靠性、保密性、性能、安全性、服务水平、可支持性、保留或清除等。
6.过度和就绪需求。
这些需求描述了从“当前状态”过渡到“将来状态”所需的临时能力，如数据转换和培训需求。
7.项目需求。
项目需求满足的行动、过程或其他条件，例如里程碑日期、合同责任。
8.质量需求。
用于确认项目可交付成果的成功完成或其他项目需求的实现的任何条件或标准，例如测试、认证、确认等。
需求跟踪矩阵
RTM(requirement traceability matrix)
RTM(requirement traceability matrix)
是一个表格。记录每个需求的生命周期
项目过程中：需求的起源-细化-设计-实现检验-验收。
使用这个表格的好处
1.确保每个细化的需求都和项目的整体商务需求相关，都能贡献价值。
2.确保需求文件中定义的每个需求最后都能实现。
3.对产品的范围的变更进行有效管理。
RTM表格中记录每个需求的属性，包括：
唯一的识别符
对需求的文字表述
为什么要有这个需求
负责人
来源
优先级
版本
当前状态（被批准、被取消、被延后...）
完成日期
稳定性
复杂性
验收标准
定义范围
定义范围是制定项目和产品详细描述的过程。
主要作用是，描述产品、服务或成果的边界和验收标准。
定义范围过程可能需要多次反复开展。
在迭代型生命周期的项目中，先为整个项目确定一个高层级的愿景，再一次针对一个迭代期明确详细范围。通常，随着当前迭代期的项目范围和可交付成果的进展，而详细规划下一个迭代期的工作。
子主题
输入
项目章程
项目管理计划
范围管理计划
项目文件
假设日志
需求文件
风险登记册
事业环境因素
组织过程资产
工具和技术
专家判断
数据分析
可用于本过程的数据分析技术包括备选方案分析。
备选方案分析可用于评估实现项目章程中所述的需求和目标的各种方法。
备选方案分析可用于评估实现项目章程中所述的需求和目标的各种方法。
尽可能多地识别备选方案。
常用的方法有：
头脑风暴法
横向思维（水平思考）
子主题
决策
包括多标准决策分析。
多标准决策分析是一种借助决策矩阵来使用系统分析方法的技术，目的是建立诸如需求、进度、预算和资源等多种标准来完善项目和产品范围。
人际关系与团队技能
引导
产品分析
产品分析可用于定义产品和服务，包括针对产品或服务提问并回答，以描述要交付的产品的用途、特征及其他方面。
每个应用领域都有一种或几种普遍公认的方法，用以把高层级的产品或服务描述转变为有形的可交付成果。
首先获取高层级的需求，然后将其细化到最终产品设计所需的详细程度。
产品分析技术包括：
产品分解（PBS）
需求分析
系统分析
系统工程
价值分析
价值工程
购买的不是产品本身而是产品功能-实现了同功能的不同材料（成本更低）之间的代用
节约资源、提高效用、降低成本的有效方法。
价值工程的实施顺序
1.这是什么？
2.这是干什么用的？
3.它的成本多少？
4.它的价值多少？
5.有其他方法能实现这个功能吗？
6.新的方案成本多少？功能如何？
7.新的方案能满足要求吗？
核酸检测的混检方案，就是典型的价值工程。
输出
项目范围说明书
项目范围说明书记录了整个范围，包括项目和产品范围；详细描述了项目的可交付成果；明确范围边界；还包括假设条件和制约因素。
用途
1.代表项目相关方之间就项目范围所达成的共识。
2.项目范围说明书使项目团队能进行更详细的规划，在执行过程中指导项目团队的工作。
3.为评价变更请求或额外工作是否超过项目边界提供基准。
项目文件更新
假设日志
需求文件
需求跟踪文件
相关方登记册
创建WBS（工作分解结构）
把项目可交付成果和项目工作分解成较小的、更易于管理的组件
对所要交付的内容提供一个结构化的视图。
仅开展一次或仅在项目的预定义点开展
如果项目中的一部分分包给第三方，那么这部分的工作由第三方完成WBS，作为整个项目WBS的一部分。
什么是WBS
WBS是项目团队为实现项目目标、创建可交付成果而需要实施的对全部工作范围的层级分解。
WBS组织并定义了项目的总范围，代表着经批准的当前项目范围说明书中所规定的工作。
WBS最底层的元素被称为工作包（work package）。可以对工作包：规划进度、估算成本、监督和控制。
在“工作分解结构”这个词语中，“工作”是指作为活动结果的工作产品或可交付成果，而不是活动本身。
WBS的表现形式
子主题
子主题
输入
项目管理计划
范围管理计划
项目文件
项目范围说明书
需求文件
事业环境因素
组织过程资产
工具与技术
专家判断
分解
分解是一种把项目范围和项目可交付成果逐步划分更小、更便于管理的组成部分的技术。
工作包是WBS最底层的工作，可对其成本和持续时间进行估算和管理。
分解的程度取决于所需的控制程度，以实现对项目的高效管理。
分解的步骤
1.识别和分析可交付成果及相关工作
仔细研读《项目范围说明书》
2.确定WBS的结构和编排方法
方式1
第一层：项目
第二层：阶段
第三层：产品或可交付物成果
---工作包
第二层：阶段
第三层：产品或可交付物成果
---工作包
子主题
方式2
第一层：项目
第二层：可交付物成果
第三层：阶段 ---工作包
第二层：可交付物成果
第三层：阶段 ---工作包
子主题
3.自上而下逐层细化分解
对WBS较高层组件进行分解，就是要把每个可交付成果或组件分解为最基本的组成部分，即可核实的产品、服务或成果。
如果采用敏捷方法，可以将长篇故事分解成用户故事。
4.为WBS组成部分制定和分配标识编码
WBS元素的识别符。
每个WBS元素，都有一个唯一的编码识别符（a unique identifier）。
这个识别符是按照一套账户编码（a code of accounts）来分配的。
可以通过这个识别符来按照层级汇总成本、进度、资源等信息。
5.核实可交付成果分解的程度是否恰当
分解程度取决于所需的控制程度，以实现对项目的高效管理。
可以分配到具体的人员或者单位。
可以对工作所需的时间进行可靠的估算。
可以对工作所需的成本进行可靠的估算。
可以对工作是否完成进行度量。
经验教训：工作所需的历时不超过80小时/40小时/8小时。
WBS分解完成后的检查
项目管理工作要包含在内。
100%原则验证分解的正确性：充分且必要。
可以不平衡：WBS中不同分支的分解层数可能不同。
需要平衡：分解的越细，越便于估算和管理，但是管理成本会上升。
滚动计划法（rolling wave planning）：项目中有的可交付物成果要在很远的将来才交付，现在还没有详细信息-等到有详细信息再分解。
输出
范围基准
是PMP(project management plan)的组成部分。
包括
项目范围说明书
WBS
控制账户
控制账户是WBS中人为设置的一个管理控制点。在这个点上，把范围、成本和进度进行整合，然后和实现价值（挣值）进行对比，得出其绩效度量。
每个控制账户中包含若干个工作包，但是每个工作包只能对应一个控制账户。
规划包
是一种低于控制账户而高于工作包的工作分解结构组件，工作内容已知，但详细的进度活动未知。
一个控制账户可以包含一个或多个规划包。
工作包
WBS的最低层级是带有独特标识号的工作包。
这些表示为进行成本、进度和资源信息的逐层汇总提供了层级结构，构成账户编码。
WBS、控制账户、规划包、工作包的关系
子主题
WBS词典
针对WBS中的每个组件，详细描述可交付成果、活动和进度信息的文件。
WBS词典对WBS提供支持，其中大部分信息由其他过程创建。
WBS词典内容包括：
1.账户编码标识
2.工作描述
3.假设条件和制约因素
4.负责的组织
5.进度里程碑
6.相关的进度活动
7.所需资源
8.成本估算
9.质量要求
10.验收标准
11.技术参考文献
12.协议信息
衡量项目的范围完成情况，比照的是项目管理计划。
衡量产品的范围是否完成，比照的是产品的需求。
项目文件更新
假设日志
需求文件
确认范围
确认范围是正式验收已完成的项目可交付成果的过程。
主要作用是，使验收过程具有客观性；同时通过确认每个可交付成果，来提高最终产品、服务或成果获得验收的可能性。
本过程应根据需要在整个项目期间定期开展。
控制质量过程关注可交付成果的正确性是否满足质量要求，确认范围关注可交付成果的整体验收。
子主题
输入
项目管理计划
范围管理计划
需求管理计划
范围基准
项目文件
经验教训登记册
质量报告
需求文件
需求跟踪矩阵
核实的可交付成果
工作绩效数据
工具与技术
检查
通过手段，确定工作和可交付物成果是否满足需求和验收标准。
方法有：
评审、产品评审
审计
巡检walkthrough
测量
测试
确认
验证
决策
可用于本过程的决策技术包括投票。
当由项目团队和其他相关方进行验收时，使用投票来形成结论。
输出
验收的可交付成果
符合验收标准的可交付成果应该由客户或发起人正式签字批准。
应该从客户或发起人那里获得正式文件，证明相关方对项目可交付成果的正式验收。
这些文件将提交给结束项目或阶段过程。
工作绩效信息
包括项目进行信息，例如，哪些可交付成果已经被验收，哪些未通过验收以及原因。
这些信息应该被记录下来并传递给相关方。
变更请求
项目文件更新
经验教训登记册
需求文件
需求跟踪矩阵
控制范围
过程目的：监督项目和产品的范围状态，根据范围基准管理变更，并对范围基准进行维护。
在整个项目期间开展。
通过该过程，保证所有以下的情况都能通过“整体变更控制”过程进行统一处理。
1.请求的变更
2.推荐的纠正措施或预防措施
3.已经实际发生的变更
范围蔓延（scope creep）：未经控制的产品或项目范围的扩大。
镀金
来自团队内部原因造成的范围蔓延
镀金往往是项目人员为了“讨好”客户而做的不解决实际问题、没有应用价值的项目活动。
范围潜变
来自团队外部原因造成的范围蔓延
指客户不断提出小的、不易察觉的范围改变，如果不加控制，累计起来导致项目严重偏离既定的范围基准，导致项目失控和失败。
子主题
输入
项目管理计划
范围管理计划
需求管理计划
变更管理计划
配置管理计划
范围基准
绩效测量基准
项目文件
经验教训登记册
需求文件
需求跟踪矩阵
工作绩效数据
组织过程资产
工具与技术
数据分析
偏差分析
用实际状况和范围基准进行比较
分析偏差的严重程度（临界值内？）
分析偏差原因
确定是否需要纠正或预防措施
趋势分析
评估项目绩效随时间的变化情况，以判断绩效是正在改善还是正在恶化
输出
工作绩效信息
关于项目和产品范围的、实施情况与范围基准对照的、考虑了项目管理及各种环境背景信息的绩效情况
包括
1.收到的变更的分类
2.识别的范围偏差和原因
3.偏差对进度和成本的影响
4.对将来范围绩效的预测
变更请求
项目管理计划更新
范围管理计划
范围基准
进度基准
成本基准
绩效测量基准
项目文件更新
经验教训登记册
需求文件
需求跟踪矩阵
0 条评论
下一页
