PMP备考_第五章_项目范围管理

项目范围管理

前言

今天学习项目范围管理的内容，深切的感受到了原单位在项目管理方面存在的问题，今天在这里做一个总结，既相当于对项目范围的一个学习整理，也相当于自己对项目实践过程中存在问题的一个思考。

项目范围管理的内容

项目范围管理在五大过程组中共占用了两个部分，即规划过程组和监控过程组

在项目规划阶段，项目范围管理包括

规划项目范围管理计划、规划需求管理计划
收集需求
范围管理
创建WBS

在监控过程中，项目范围管理包括

确认项目范围
控制项目范围

1.规划项目范围管理计划，规划需求管理计划

这一部分的主要内容是为需求管理和范围管理做一个整体的把控，也相当于正式实施之前的一个准备计划。

项目规划需求和范围管理的目的是为了后续范围管理有理有据，而需求是范围管理的关键内容，所以其输出内容应该有两个

项目范围管理计划

如何搜集需求(需求的确定计划)
如何定义范围(范围管理的方法)
如何记录范围如何创建WBS(需求记录的方法、创建WBS的方法)
如何核实项目范围(项目范围不是技术人员说了算的，如何确认范围，给出方法)
如何管理和控制范围(范围管理的已知方法)

项目需求管理计划

如何搜集需求
需求如何记录
如何管理需求

正因为对项目需要进行需求和范围进行管理，所以需要在已知条件下进行管理，做计划前需要的输入有：

项目章程

项目章程是对项目的一个总体定义，是最先出来的一份文档，所以在需求和范围管理之前，一定要明确这个项目的核心内容，要做什么，怎么做，干系人是谁等

项目管理计划

项目管理计划，我的理解是做项目的时候需要如何进行，打算如何管理，谁来控制
项目管理计划其实有一些关键的思考点(这里的项目管理计划实际上是组织过程资产，需要人来总结分析的)

组织过程资产

以前做项目的一些经验，需要参考

事业环境因素

公司的项目氛围和实际情况，只有事业环境因素确定，才知道在企业中如何把一个项目做好，否则一个初来乍到的人是不可能很快做好一个项目的

规划的事情主要是由上层制定的，也即我们所说的专家和会议形式，通过有经验的人总结，才可以为项目范围管理提供一些有用的素材和经验。

2.收集需求

这里需要说明的是，由于范围管理的前提条件是有了用户需求，所以其管理的第一步便是将需求定义清楚，只有清晰的需求才可以作为项目范围管理的依据。

收集需求的目的很明确，需要输出一份需求的文件，这个文件指的就是（这两个文档其实是可以合成为一个文档的，内容主要是记录着所有的需求，并且有一个需求映射的关系关联）

需求文档
需求跟踪矩阵

对此需要提供一些输入文件才可以进行需求的收集

需求管理计划（之前规划需求管理的输出文件，这时候需要根据事先拟定好的方式来进行需求收集）
范围管理计划(即使是需求收集部分，也需要知道范围管理的计划)
干系人管理计划（干系人的处理对策）
项目章程（项目怎么做，做什么）
干系人登记册(需要知道干系人是谁)(项目需求搜集是对人的搜集，所以需要处理好干系人之间的关系，这个是需求管理的基本要求)
~~组织过程资产（必备，前人经验）(这部分内容主要在规划管理计划的时候已经有了)~~
~~事业环境因素（必备，熟悉公司环境）(这部分内容主要在规划管理计划的时候已经有了)~~

收集需求来说，最主要的还是在行动上，因为需求的搜集是最难的，不同人对需求的理解不同，需求错误或者理解不到位，直接回导致工作内容无法评估，工作量巨大。

访谈(座谈)（一个人一个人交流沟通）
问卷调查（对很多人快速沟通，适用于项目范围比较大的地方，类似于推广活动）
观察(适用于体力活动，可以通过观察发现需求)(这里我认为脑力活动也可以，需求就是从麻烦开始的)
原型法/标杆对照法（这是两个方法，但是由于非常类似，一个是自己做一个原型来与客户沟通，另一个是拿行业中有名的单位或者产品举例，可以快速的明确自己的内容）
内部沟通/群体创新技术（这种属于内部需求挖掘）（头脑风暴，德尔菲技术，亲和图技术，名义小组技术，多标准决策技术，思维导图）
决策技术/群体决策技术（这种属于内部的需求确定）（一致同意技术，大多数原则，相对多数原则，独裁）

3.范围管理

有了项目的需求，不管需求的准确还是不准确，都需要开始进行项目的范围管理了，项目范围管理主要目的是为了分解任务和工作，所以其输出文件是

~~工作包~~
项目说明文件(用于将需求转换为内部需要的做什么的文件)
项目文件(更新)

输入文件是：

项目范围管理计划
需求文件
~~需求跟踪矩阵（范围管理不涉及需求跟踪矩阵，只有实施和监控的时候才需要这个文件）~~
项目章程
组织过程资产(以前的范围管理的经验)

工具与技术

会议/引导式研讨会(会议是群体决策，可以讨论出应该干什么吧)
专家判断(这种需要经验的活动，一般需要专家参与)
产品分析(分析做什么，不知道与研讨会有什么区别，这里只知道需要进行质量管理和价值分析)

产品分解
系统分析
需求分析
系统工程
价值工程
价值分析

备选方案生成（做一个备用方案，目的是什么，暂时不清楚）

4.WBS分解

当需求定下来了，项目管理的范围也定下来了，接下来我们需要对工作进行进一步的细分，WBS分解的主要目的是为了细化需要做的内容，所以其输出文件应该是

范围基准(WBS分解文件)
项目文件更新

输入应该是

范围管理计划(所有与项目范围有关的文件都要有吧，全面)
需求文件
范围说明文件(项目范围说明书)
事业环境因素
组织过程资产(学习前人是如何分解的)

工具与技术是

会议
专家判断

5.项目范围确认

项目范围确认是监控过程组，是监控过程组的内容，所以其输出应当是跟监控相关的文件

验收的可交付成果
变更请求
工作绩效信息
项目范围说明书(更新)

输入

~~项目章程~~
项目范围管理计划
~~项目说明文件~~
~~项目范围基准(范围基准实际上已经是WBS任务包，这里确认范围不需要这么细)~~
需求文件
需求跟踪矩阵(范围确认的过程实际上是对需求的一些梳理，所以需要明确需求是什么)
核实的可交付成果(因为是监控过程，所以拥有的文件数量也会增多，这个是执行过程组中产生的一些文件，可以用来核对需求，填写跟踪矩阵)
工作绩效数据(怎么评估绩效，现在还不明确)

工具与技术

项目范围确认需要与多个干系人沟通，确认最终范围，并尽量避免修改

检查
群体决策

6.项目控制范围

项目可以确认范围，但是监控的主要目的还是为了控制项目范围，所以项目控制范围过程中拥有的数据应该是

工作绩效数据
变更请求/~~变更文件~~ (注意措辞准确，变更的结果只是提出请求，并没有执行)
项目管理计划(更新) （范围的变化会带来项目管理计划的变化）
项目文件(更新) （项目的说明文件内容也跟着变）
组织过程资产（更新）（组织积累了一些关于控制范围的手段和方法）

输入文件是

项目范围管理计划（需要根据计划进行管理和控制）
需求文件
需求跟踪矩阵（如果项目范围变化了，需要走流程）
工作绩效数据
~~事业环境因素（也不能瞎控制，需要组织的支持和配合）~~
组织过程资产(吸收前人控制项目范围的经验)

工具和技术

偏差分析技术

~~组织流程（有流程文件的话可以走一下流程）（控制范围，但不是变更管理）~~
会议（需要讨论一下如何控制范围）（这就是偏差分析的一个手段）
专家判断(项目范围变化后，需要专家判断是否继续啊) （这个也是偏差分析的手段）

实际总结：

实际在做项目的过程中，没有这么多繁琐的流程内容，但是理论上将需要或多或少的用到了一些相关的内容。在原单位的一些问题总结：

规划范围管理需求管理中，没有制定出任何一份需求需求管理和范围管理的计划，也没有参考的模板，导致所有的项目经理都是自己摸索，带来了效率的浪费
需求收集过程中，项目人员参与太少，只是通过销售的口来了解需求，导致前期的需求分析不充足，项目已经开始实施了，才开始进行需求分析，结果导致了时间上的紧张，最好是能在合同签订后第一时间确定需求，或者在更早起就让专家去接入客户，了解真实的项目需求
范围管理过程中，公司没有组织专门的会议去讨论项目做什么，如何做，只有临时指派的项目经理去摸索和探索，导致项目经理的个人素质直接决定了项目的成败
WBS分解，没有人告诉项目经理如何分解，如何去做，这些都需要公司成立相应的部门，定期组织项目讨论和理解，提出一些共同的组织过程资产分享给各个项目经理
确认项目范围，这个环节由于前期工作不到位，不停的进行，总在确认项目范围，属于前期工作不到位的问题
项目范围控制，缺乏相应的经验培训等工作

来自为知笔记(Wiz)