范围管理

一、 制定范围计划

作为一名合格的项目管理者，做任何事之前都应该先做好计划。好的计划，是成功实施项目的基础。有些人为做项目范围计划花费了太多时间，不如把它们用于执行工作，项目将会更快更好地完成，我认为这是一个错误的想法，通过省略范围计划制定，虽然能短暂时间内节省一定的时间，但在长期来看，常常会因缺乏管理计划指导而使得范围定义不清、范围蔓延，以致无法完成项目。

因此，在该项目中，我非常重视范围计划的制定，在正式做计划之前，我先查找了公司组织过程资产，结合企业环境因素，项目章程，同时找出信息系统管理中制定项目范围管理的模板，结合以往类似项目的经验，制定了一份项目管理计划。然后召集项目组全体成员，对项目管理计划进行初步的讨论修改。在全体参与下，最终完成了一份详细的、科学的范围管理计划，用于指导项目如何定义、分解以及确认、控制。

二、制定范围说明

范围说明书也就是范围定义，从这个意义上讲就是项目应该做什么，不应该做什么，以及如何做。恰当的范围定义对项目的成功十分关键，当范围定义不明确时，变更就会频繁的出现，很可能会造成返工、延长工期、降低团队士气等一系列不良后果。结合该项目，我们的范围说明书主要包含以下内容：

（1） 项目目的。目的是打破孤岛，拆除烟囱，整合数据资源，集成业务系统，形成省、市、县三级统一的综合办公门户。

（2） 产品范围描述。对综合办公系统的包含的8大模块37个功能，以及集成的17个业务系统，进行功能、性能、操作等方面进行表述，随着项目的进展，范围描述会逐步细化。

（3） 项目的可交付物。综合办公平台的可交付物为统一的门户，公文管理、信息管理、财务管理、报账管理，合同管理、档案管理，党建廉政管理人员绩效和工资等模块的实施和维护。

（4） 项目的边界。定义了该项目的设计，实施，维护为本项目要完成的事项，代用户录入数据，新建表单等内容不属于项目的范围。

（5） 项目的验收条件。明确了该项目的界面符合主流的div+css技术，整体框架使用SOA框架进行开发，功能模块要符合合同中规定要求进行。

（6） 项目的约束条件。 例如：项目的时间要求，进度要求等等。

三、作工作分解结构

WBS的建立对项目来说意义非常重大，他使得原来看起来非常笼统、相对模糊的项目，逐步完成项目落地，使得项目有据可依，使得项目团队的目标更加明确了。如果没有完善的WBS，变更就会不断的出现，很可能也会造成返工、项目延期、降低团队士气等一系列不利后果。制定一个好的WBS的思想是逐步深入，先将项目成功框架确定下来，按照子模块功能将项目进行分解，然后每层下面再把工作分解。针对本项目，我按照如下步骤制定出WBS：

（1） 识别该项目的交付物和相关工作。

（2） 对WBS的结构进行组织。根据识别出的交付物分解模块。每个模块要完成的功能再进行分解。

（3） 对WBS进行分解。将功能模块分解成工作包，也就是分解成为可测量，可控制的工作，一般分解为一个人80小时能完成的工作。

（4） 对WBS中各级工作分配标识符。

（5） 对当前分解的WBS进行检验，确认工作分解的程度是必要和充分的，体现在检查工作包分解的对不对。

四、范围确认

范围确认是项目干系人正式接受已完成项目交付物。项目范围确认是很困难的事情，范围确认始终贯穿项目始终。客户总是认为什么都没有看到，怎么能进行确认呢？出现客户范围确认不配合的情况。而我们希望客户尽快确认，以便开展下面的工作。我们通过和客户进行很好的沟通，尤其是和客户方项目经理多沟通，告诉他们虽然项目范围确认是正式的，但并不意味这项目的范围就一成不变，不能再修改了，只是无论是现在更改范围还是将来更改范围，都会引起项目的时间，进度和资源的变化。 例如，在实际工作做，我们每次希望得到甲方的确认以便尽快开展下一项工作，为了防止客户认为自己什么也没有看到这种情况，在 WBS确定后，我建立了多个里程碑，每一个里程碑都是重要的节点，我邀请项目干系人参加阶段评审会，重点对客户一线操作人员进行沟通和讲解，详细介绍系统的设计原理，让他们站在使用角度思考问题然后向甲方业务部门作出需求讲解。这样既有益于专业人员之间的沟通，也有益于客户业务部门对系统范围的认可和信任，虽然变更不可避免，但是，只要按照变更流程走，且审批通过，都可以进行变更，这样就消除了客户的顾虑，便于快速，高效地完成项目确认。

五、控制范围

控制范围就是监督项目的范围状态，管理范围基础变更的过程。因此在项目中，我定期组织召开项目状态审查会，审查项目的范围，通过对照范围基础，找出范围偏差，并做分析，严格杜绝一切的范围蔓延以及镀金。 例如，在一次状态审查会上，我发现项目的功能模块中，系统管理以及库存管理模块多了登录日志以及盘库两块功能，我查了一下系统变更日志，未找到有类似的变更记录，于是我参照责任分配矩阵，分别找到这两个模块开发的负责人询问原因， A成员告诉我，他增加登录日志这个功能，是因为客户在一次电话中，向他提过希望在系统管理模块中加一个登录日志的功能， B成员则是因为在开发库存管理模块时，发现整个库存管理没有库存盘点的功能，他认为做库存管理，肯定需要用到盘点功能，而且这是个亮点，所以他私自增加了这一功能。针对这两种情况，我首先向这两名成员强调了范围基准以及变更流程的重要性；其次，针对这两项多出来的功能，我要求相关人员提交正式的变更申请，走正常的变更控制流程。 从事项目管理工作的我深知，项目范围不是一经定义，就一成不变的，项目干系人出于项目利益以及各种情况考虑，总会有一些需求变更，管理这些变更，需要在项目规划时，就制定好变更控制流程以及成立一个专门的需求变更控制委员会（ CCB）。因此，我和我的团队在项目早期就制定了一套标准的变更流程：①提交变更申请；②评估变更；③报 CCB审批；④实施变更并调整基准；⑤将变更信息通知相关干系人；⑥对变更的结果进行追踪与审核。有了这些流程以及 CCB的控制，项目的需求变更得以良性发展，变更带来更多的是项目利益以及效率的提升。