PMP项目管理 - 范围管理

系列文章目录

系统架构设计
PMP项目管理 - 整合管理
PMP项目管理 - 质量管理
PMP项目管理 - 采购管理
PMP项目管理 - 资源管理
PMP项目管理 - 风险管理
PMP项目管理 - 沟通管理

现在的一切都是为将来的梦想编织翅膀，让梦想在现实中展翅高飞。
Now everything is for the future of dream weaving wings, let the dream fly in reality.

PMP项目管理 - 范围管理

系列文章目录
一、规划范围管理（规划）- 创建范围管理计划，书面描述将如何定义、确认和控制项目范围的过程。在整个项目中对如何管理范围提供指南和方向
二、收集需求（规划） - 为实现项目目标而确定、记录并管理干系人的需要和需求的过程
三、定义范围（规划） - 根据所收集的需求，确定项目团队应该做什么，明确范围边界。明确了范围边界之后，从而明确项目、成果的边界。
四、创建WBS（规划）- 项目可交付成果和项目工作分解成较小的、更易于管理的组成部分
五、控制范围（监控）- 监督项目和产品的范围，管理范围基准的变更
六、确认范围（监控）- 正式验收已完成的项目可交付成果
七、PMP考试要点

在这里插入图片描述

一、规划范围管理（规划）- 创建范围管理计划，书面描述将如何定义、确认和控制项目范围的过程。在整个项目中对如何管理范围提供指南和方向

规划范围管理 过程定义创建范围管理计划，书面描述将如何定义、确认和控制项目范围的过程。在整个项目中对如何管理范围提供指南和方向。

需求大于范围

规划范围管理的输出：范围管理计划
描述将如何定义、制定、监督、控制和确认项目范围。也就是指导如何制定项目范围说明书、如何创建 WBS、如何验收可交付成果、如何处理对范围说明书的变更等等。
规划范围管理的输出：需求管理计划
描述将如何分析、记录和管理项目和产品需求。阶段与阶段间的关系对如何管理需求有很大影响。项目经理为项目选择最有效的阶段间关系，并将它记录在需求管理计划中。

二、收集需求（规划） - 为实现项目目标而确定、记录并管理干系人的需要和需求的过程

需求，是干系人想要什么？
收集需求 过程定义为实现项目目标而确定、记录并管理干系人的需要和需求的过程。收集需求，为定义和管理项目范围奠定基础。收集需求，是收集“人”的需求，因此与人有关系，输入参考干系人参与计划、干系人登记册。

收集需求的工具：数据收集（问卷调查、标杆对照）
（1）问卷调查：适用于干系人特别多，想要快速完成调查、受访者地理位置分散。

（2）标杆对照：将实际或计划的产品、过程和实践，与其他可比组织的实践进行比较，以便识别最佳实践，形成改进意见，并为绩效考核提供依据。标杆对象来自组织内部或外部项目。
收集需求的工具：决策（投票、多标准决策分析）
（1）投票
（a）大多数原则：少数服从多数，40%的要服从 60%的。
（b）相对多数原则：适合候选超过 2 个的时候，每一个都没超过 50%。比如第一个35%，第二个 20%，第三个 45%。这时服从相对多数的 45%。
（c）一致同意：德尔菲技术。一群专家主观预测，背靠背不见面以匿名形式回答问卷，然后交给主持人，最后取得相对一致意见。
（d）独裁：一个人说了算。
（2）多标准决策分析 ：借助决策矩阵，用系统分析方法建立诸如风险水平、不确定性和价值收益等多种标准，从而对众多方案进行评估和排序的一种技术。
收集需求的工具：数据表现（亲和图、思维导图）
（1）亲和图：将大量创意按照亲和性直观地进行逻辑分类。（归纳）

（2）思维导图：把头脑风暴中获得的创意，用一张简单的图联系起来，目的在于激发思维、激发引导新的创意。（演绎、扩散）
收集需求的工具：人际关系与团队技能（名义小组技术、观察/交谈、引导）
（1）名义小组技术：头脑风暴产生的创意散乱无规律，通过投票排列头脑风暴中最有用的创意、排列优先顺序，小组成员各自先不通气（只是名义上的）。
（2）观察/交谈：干系人难以或不愿意说明他们的需求时使用。
（3）引导式研讨会：跨职能、跨部门召集主要干系人开会，定义产品需求。是快速定义跨职能需求和协调干系人差异的重要技术。实际应用的实例，像联合应用开发 JAD、质量功能展开 QFD、用户故事等等。
用户故事，在敏捷方法中用的较多，用户诉说一个小故事的形式表达自己的需求，PM和团队听故事来获取需求。
1）联合应用开发（JAD）：用户与项目开发团队一起共同定义需求；
2）质量功能展开（QFD）：客户需求转化为指标数字，分类排序，设定目标。
收集需求的工具：原型法
制造预期产品之前先造出这个产品的一个模型，然后来收集反馈意见。
收集需求的输出：需求文件、需求跟踪矩阵
（1）需求文件：收集的需求都被记录在需求文件当中。包括了业务需求、干系人需求、项目需求等。
（2）需求跟踪矩阵（RTM）：把产品需求从其来源连接到能满足需求的可交付成果的一种表格。RTM 提供了在整个项目生命周期中跟踪需求的一种方法。

记录每一个需求产生的原因、需求存在的价值、目标是什么、产生哪个成果、怎么设计、怎么开发、怎么做测试？确保每个需求都能有商业价值。
需求跟踪矩阵（RTM）：溯源、商业价值、监控过程输出。
需求文件&需求跟踪矩阵：
需求文件：将相关方需求文档化，业务解决方案，技术解决方案，功能（产品需求），非功能（管理需求）；
需求跟踪矩阵：从来源到可交付成果的一种表格，确保每个需求具有商业价值，需求的溯源；（谁说的、分量如何、是否可行、价值如何）

三、定义范围（规划） - 根据所收集的需求，确定项目团队应该做什么，明确范围边界。明确了范围边界之后，从而明确项目、成果的边界。

定义范围 根据所收集的需求，确定项目团队应该做什么，明确范围边界。明确了范围边界之后，从而明确项目、成果的边界。根据所收集的需求，确定项目团队应该做什么，明确范围边界。明确了范围边界之后，从而明确项目、成果的边界。

定义范围的工具：产品分析
用于把高层级的产品描述转变为有形的可交付成果。比如产品分解：
产品设计之 KISS 原则
Keep It Simple and Stupid KISS 是指在产品设计当中应当注重简约的原则。简约并不简单比如：IPAD、微信
定义范围的输出：项目范围说明书
记录了整个范围，包括项目和产品范围；详细描述了项目的可交付成果。
项目范围说明书包括了：产品范围描述、验收标准、项目可交付成果、项目的除外责任（哪些工作该做、哪些不该做）。
相关方之间就项目达成的共识，项目章程是一个高层次描述而项目范围说明书是一个详细描述，SMART 原则（specific 具体的，measurable 可衡量的， attainable 能够达到的，relevant 相关的，time-abund 有时限的）

（1）产品范围描述：逐步细化在项目章程和需求文件中所述的产品、服务或成果的特征。
（2）验收标准：可交付成果通过验收前必须满足的一系列条件。
（3）可交付成果：在某一过程、阶段或项目完成时，必须产出的任何独特并可核实的产品、成果或服务能力。
（4）除外责任：哪些工作不该做。

四、创建WBS（规划）- 项目可交付成果和项目工作分解成较小的、更易于管理的组成部分

创建WBS 定义把项目可交付成果和项目工作分解成较小的、更易于管理的组成部分。

创建 wbs 的工具：分解
分解是把项目范围和可交付成果逐步划分为更小、更便于管理的组成部分的技术。
分解的程度 取决于所需的控制程度，以实现对项目的高效管理。
WBS 是项目范围的最准确定义，WBS 组织并定义了项目的总范围。项目范围说明书是文字层的大框架定义，WBS 是结构化的视图。

比方说这是个家庭装修项目的 wbs。创建 WBS 是以可交付成果为对象，自上而下进行分解，越往下越详细。
不同的可交付成果可以分解到不同的层次。比如说厨房、洁具，他们是不同的可交付成果，分解的层次也不一样。
工作包是 WBS 最底层的工作，可对其进行成本和持续时间估算、管理。水池、上水管、下水道、龙头阀门、过滤网，就是最底层的工作包，能够可靠的计算它们的时间和成本。
项目管理、外包都要包含进 WBS 中。项目管理产生的可交付成果要包含进 wbs 当中。并且有些可交付成果没办法自行开发，需要找供应商外包，这些外包的也必须包含进来，而不能剔除。
WBS 中的两个层级可交付成果：控制账户、规划包
控制账户：是范围、时间、成本的综合管控点。每一个控制账户都可以包括一个或者多个工作包，但是每一个工作包只能属于一个控制账户。控制账户可以包括一个或者多个规划包。
比如说把厨房当作一个控制账户，pm 就针对某个时间点监控他的进度和成本、范围的完成情况
规划包：层级在控制账户之下，工作内容已知，但详细的进度活动未知。规划包是指模糊的，不具体的，需要渐进明细。
如果一旦采用规划包，就需要使用滚动式规划
100%原则：通过把 S WBS 底层的所有工作逐层向上汇总，确保既没有遗漏的工作，也没有多余的工作。是 S WBS 的核心特点。
创建 WBS 的输出：范围基准
范围基准包含了：项目范围说明书、WBS、WBS 词典。
范围基准 是经过批准的范围说明书、WBS 和相应的 WBS 词典，只有通过正式的变更控制程序才能进行变更，它被用作绩效比较的基础。
WBS 词典：是针对每个 WBS 组件，详细描述可交付成果、活动和进度信息的文件。它对WBS 提供支持。

它和 WBS 配套使用的，对 wbs 图进行补充，文字的描写，显示了 WBS 中每个工作包的详细信息。相当于是个名词解释的文档。
那么通俗来讲，WBS 词典是干什么的呢？
WBS 是个视图，光看图万一没看懂怎么办？出来了一个词典，对图来进行补充和解释。比如一个 WBS 组件“水池”要做到什么程度？做多宽？多长？用什么材料？进展到哪一步了，这些在 WBS 词典里面进行了一个解释。
所以，范围基准里的范围说明书、WBS、WBS 词典，三者缺一不可。
范围基准
1）范围说明书：项目范围、验收标准、主要可交付成果、假设和制约
2）WBS：最底层 40-80，团队建设机会，尽可能多的人参与，自上而下，100%原则
3）WBS 词典：资源需求（工时与工种），验收标准，工作说明，逻辑关系

五、控制范围（监控）- 监督项目和产品的范围，管理范围基准的变更

控制范围 定义监督项目和产品的范围，管理范围基准的变更。确保做、且只做范围内的事！如果范围真的有变化，需要变更，确保必须走正式的变更管理流程来变基准。

控制范围工具：数据分析（偏差分析、趋势分析）
1）偏差分析：把实际绩效与计划作对比，发现差异程度
2）趋势分析：看一段时间内的走势，分析未来会改善还是会恶化，含有预测的成分。

镀金、范围蔓延/范围潜变、渐进明细三者区别：
（1）镀金：是项目人员为了“讨好”客户而“画蛇添足”做的项目活动。PMI 觉得镀金的项目是失败的，反对镀金。
（2）范围蔓延/范围潜变：没有得到控制的范围扩大、没有得到控制的变更，没有走变更管理流程。比如：客户和某个团队成员关系很好，他提出要加一个功能，这个成员直接就帮他加了。客户没正式提出变更请求，没走流程。团队成员私自帮他加了内容，这是范围蔓延。属于镀金的一种形式。
（3）渐进明细 是正常的，因为项目范围不可能在开始的时候就非常清晰，需要不断地细化、完善。比如计划买双鞋，没有确定颜色、款式、价位，到商场后看到了好多双鞋，慢慢的对自己要买的鞋的颜色、款式、价位都有了明确的认识。这是渐进明细。渐进明细是正常的，逐步细化。而范围蔓延和镀金都是不正常的，PMI 主义反对镀金、反对范围蔓延。

控制范围的意义：
1）减少资源，PM 应变更范围；
2）控制范围=防潜变+必要变更；
3）范围潜变=镀金 or 蔓延；
4）结尾客户小变更，撤销转替代方案；
5）结尾客户大变更，走合同。

偏差分析：
在这里插入图片描述

六、确认范围（监控）- 正式验收已完成的项目可交付成果

确认范围 过程定义正式验收已完成的项目可交付成果。

确认范围的输入：核实的可交付成果
是指已经完成，并被控制质量过程检查为正确的可交付成果。
控制质量关注可交付成果的正确性以及是否满足质量要求，通常由项目团队参与；确认范围关注可交付成果的验收，通常由客户或发起人参与。
一般来说，先做控制质量、后做确认范围。因为先是内部检验、再有外部验收。
控制质量得到核实的可交付成果，作为了确认范围的输入，经过确认范围的外部检查，得到了输出“验收的可交付成果”。验收的可交付成果又作为了结束项目或阶段的输入，这是项目收尾的必要条件。
确认范围的输出：验收的可交付成果
符合验收标准的可交付成果应该由客户或者发起人正式签字批准
确认范围的输出：变更请求
未通过验收的可交付成果需要提出变更，开展缺陷补救。
项目管理的成果线
变更线
绩效线