项目范围管理
前言
今天学习项目范围管理的内容，深切的感受到了原单位在项目管理方面存在的问题，今天在这里做一个总结，既相当于对项目范围的一个学习整理，也相当于自己对项目实践过程中存在问题的一个思考。
项目范围管理的内容
项目范围管理在五大过程组中共占用了两个部分，即规划过程组和监控过程组
在项目规划阶段，项目范围管理包括
- 规划项目范围管理计划、规划需求管理计划
- 收集需求
- 范围管理
- 创建WBS
在监控过程中，项目范围管理包括
- 确认项目范围
- 控制项目范围
1.规划项目范围管理计划，规划需求管理计划
这一部分的主要内容是为需求管理和范围管理做一个整体的把控，也相当于正式实施之前的一个准备计划。
项目规划需求和范围管理的目的是为了后续范围管理有理有据，而需求是范围管理的关键内容，所以其输出内容应该有两个
- 项目范围管理计划
- 如何搜集需求(需求的确定计划)
- 如何定义范围(范围管理的方法)
- 如何记录范围如何创建WBS(需求记录的方法、创建WBS的方法)
- 如何核实项目范围(项目范围不是技术人员说了算的，如何确认范围，给出方法)
- 如何管理和控制范围(范围管理的已知方法)
- 项目需求管理计划
- 如何搜集需求
- 需求如何记录
- 如何管理需求
正因为对项目需要进行需求和范围进行管理，所以需要在已知条件下进行管理，做计划前需要的输入有：
- 项目章程
- 项目章程是对项目的一个总体定义，是最先出来的一份文档，所以在需求和范围管理之前，一定要明确这个项目的核心内容，要做什么，怎么做，干系人是谁等
- 项目管理计划
- 项目管理计划，我的理解是做项目的时候需要如何进行，打算如何管理，谁来控制
- 项目管理计划其实有一些关键的思考点(这里的项目管理计划实际上是组织过程资产，需要人来总结分析的)
- 组织过程资产
- 以前做项目的一些经验，需要参考
- 事业环境因素
- 公司的项目氛围和实际情况，只有事业环境因素确定，才知道在企业中如何把一个项目做好，否则一个初来乍到的人是不可能很快做好一个项目的
规划的事情主要是由上层制定的，也即我们所说的专家和会议形式，通过有经验的人总结，才可以为项目范围管理提供一些有用的素材和经验。
2.收集需求
这里需要说明的是，由于范围管理的前提条件是有了用户需求，所以其管理的第一步便是将需求定义清楚，只有清晰的需求才可以作为项目范围管理的依据。
收集需求的目的很明确，需要输出一份需求的文件，这个文件指的就是（这两个文档其实是可以合成为一个文档的，内容主要是记录着所有的需求，并且有一个需求映射的关系关联）
- 需求文档
- 需求跟踪矩阵
对此需要提供一些输入文件才可以进行需求的收集
- 需求管理计划（之前规划需求管理的输出文件，这时候需要根据事先拟定好的方式来进行需求收集）
- 范围管理计划(即使是需求收集部分，也需要知道范围管理的计划)
- 干系人管理计划（干系人的处理对策）
- 项目章程（项目怎么做，做什么）
- 干系人登记册(需要知道干系人是谁)(项目需求搜集是对人的搜集，所以需要处理好干系人之间的关系，这个是需求管理的基本要求)
组织过程资产（必备，前人经验）(这部分内容主要在规划管理计划的时候已经有了)事业环境因素（必备，熟悉公司环境）(这部分内容主要在规划管理计划的时候已经有了)
收集需求来说，最主要的还是在行动上，因为需求的搜集是最难的，不同人对需求的理解不同，需求错误或者理解不到位，直接回导致工作内容无法评估，工作量巨大。
- 访谈(座谈)（一个人一个人交流沟通）
- 问卷调查（对很多人快速沟通，适用于项目范围比较大的地方，类似于推广活动）
- 观察(适用于体力活动，可以通过观察发现需求)(这里我认为脑力活动也可以，需求就是从麻烦开始的)
- 原型法/标杆对照法 （这是两个方法，但是由于非常类似，一个是自己做一个原型来与客户沟通，另一个是拿行业中有名的单位或者产品举例，可以快速的明确自己的内容）
- 内部沟通/群体创新技术（这种属于内部需求挖掘）（头脑风暴，德尔菲技术，亲和图技术，名义小组技术，多标准决策技术，思维导图）
- 决策技术/群体决策技术（这种属于内部的需求确定）（一致同意技术，大多数原则，相对多数原则，独裁）
3.范围管理
有了项目的需求，不管需求的准确还是不准确，都需要开始进行项目的范围管理了，项目范围管理主要目的是为了分解任务和工作，所以其输出文件是
工作包- 项目说明文件(用于将需求转换为内部需要的做什么的文件)
- 项目文件(更新)
输入文件是：
- 项目范围管理计划
- 需求文件
需求跟踪矩阵（范围管理不涉及需求跟踪矩阵，只有实施和监控的时候才需要这个文件）- 项目章程
- 组织过程资产(以前的范围管理的经验)
工具与技术
- 会议/引导式研讨会(会议是群体决策，可以讨论出应该干什么吧)
- 专家判断(这种需要经验的活动，一般需要专家参与)
- 产品分析(分析做什么，不知道与研讨会有什么区别，这里只知道需要进行质量管理和价值分析)
- 产品分解
- 系统分析
- 需求分析
- 系统工程
- 价值工程
- 价值分析
- 备选方案生成（做一个备用方案，目的是什么，暂时不清楚）
4.WBS分解
当需求定下来了，项目管理的范围也定下来了，接下来我们需要对工作进行进一步的细分，WBS分解的主要目的是为了细化需要做的内容，所以其输出文件应该是
- 范围基准(WBS分解文件)
- 项目文件更新
输入应该是
- 范围管理计划(所有与项目范围有关的文件都要有吧，全面)
- 需求文件
- 范围说明文件(项目范围说明书)
- 事业环境因素
- 组织过程资产(学习前人是如何分解的)
工具与技术是
- 会议
- 专家判断
5.项目范围确认
项目范围确认是监控过程组，是监控过程组的内容，所以其输出应当是跟监控相关的文件
- 验收的可交付成果
- 变更请求
- 工作绩效信息
- 项目范围说明书(更新)
输入
项目章程- 项目范围管理计划
项目说明文件项目范围基准(范围基准实际上已经是WBS任务包，这里确认范围不需要这么细)- 需求文件
- 需求跟踪矩阵(范围确认的过程实际上是对需求的一些梳理，所以需要明确需求是什么)
- 核实的可交付成果(因为是监控过程，所以拥有的文件数量也会增多，这个是执行过程组中产生的一些文件，可以用来核对需求，填写跟踪矩阵)
- 工作绩效数据(怎么评估绩效，现在还不明确)
工具与技术
项目范围确认需要与多个干系人沟通，确认最终范围，并尽量避免修改
- 检查
- 群体决策
6.项目控制范围
项目可以确认范围，但是监控的主要目的还是为了控制项目范围，所以项目控制范围过程中拥有的数据应该是
- 工作绩效数据
- 变更请求/
变更文件(注意措辞准确，变更的结果只是提出请求，并没有执行) - 项目管理计划(更新) （范围的变化会带来项目管理计划的变化）
- 项目文件(更新) （项目的说明文件内容也跟着变）
- 组织过程资产（更新） （组织积累了一些关于控制范围的手段和方法）
输入文件是
- 项目
范围管理计划（需要根据计划进行管理和控制） - 需求文件
- 需求跟踪矩阵（如果项目范围变化了，需要走流程）
- 工作绩效数据
事业环境因素（也不能瞎控制，需要组织的支持和配合）- 组织过程资产(吸收前人控制项目范围的经验)
工具和技术
偏差分析技术
组织流程（有流程文件的话可以走一下流程） （控制范围，但不是变更管理）- 会议（需要讨论一下如何控制范围） （这就是偏差分析的一个手段）
- 专家判断(项目范围变化后，需要专家判断是否继续啊) （这个也是偏差分析的手段）
实际总结：
实际在做项目的过程中，没有这么多繁琐的流程内容，但是理论上将需要或多或少的用到了一些相关的内容。在原单位的一些问题总结：
- 规划范围管理 需求管理中，没有制定出任何一份需求需求管理和范围管理的计划，也没有参考的模板，导致所有的项目经理都是自己摸索，带来了效率的浪费
- 需求收集过程中，项目人员参与太少，只是通过销售的口来了解需求，导致前期的需求分析不充足，项目已经开始实施了，才开始进行需求分析，结果导致了时间上的紧张，最好是能在合同签订后第一时间确定需求，或者在更早起就让专家去接入客户，了解真实的项目需求
- 范围管理过程中，公司没有组织专门的会议去讨论项目做什么，如何做，只有临时指派的项目经理去摸索和探索，导致项目经理的个人素质直接决定了项目的成败
- WBS分解，没有人告诉项目经理如何分解，如何去做，这些都需要公司成立相应的部门，定期组织项目讨论和理解，提出一些共同的组织过程资产分享给各个项目经理
- 确认项目范围，这个环节由于前期工作不到位，不停的进行，总在确认项目范围，属于前期工作不到位的问题
- 项目范围控制，缺乏相应的经验培训等工作