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