论项目的范围管理

论项目的范围管理摘要：2017年2月，我参加了移动管理平台项目，担任本项目的项目经理。该项目投资500万，建设工期1年，该项目为了通过发挥移动应用的价值加快XX省电网故障抢修速度，提升公众服务能力。移动管理系统功能包括移动应用商店管理、移动运行监控、信息推送管理、平台配置。本文结合作者的实践，以移动管理平台项目为例，讨论了该项目建设过程中的范围管理，包括规划范围管理、收集需求、定义范围、创建WBS、范围确认、范围控制。最后总结分享项目管理的成功经验，以及项目存在的不足及具体的改进措施。2017年2月，通过发挥移动应用的价值加快XX省电网故障抢修速度，提升公众服务能力，充分利用互联网+带来的机遇，结合应用系统的现状和业务部门的移动信息化需求，规划并建设了基于营销、运维检修、客户服务、电力交易、信通技术的移动业务应用。建设方迫切需要一套统一的移动管理平台，该项目历时1年，总投资500万。为顺利完成移动管理平台系统的实施、部署工作，特成立了系统实施领导小组，包括实施组、技术支持组、质量管控组3个子项目组，我有幸担任本项目的项目经理。移动管理平台系统功能包括用户管理、应用管理、应用商店、设备管理、内容管理、邮件管理、安全管理、管理员管理、平台管理。由于该项目业务复杂、范围涉及面广、项目干系人众多等特点，因此，进行良好的范围管理是保证项目按要求完成的重要保障。项目范围管理是将用户的需求转化成系统资源的需求，并经用户确认的过程。要做好范围管理需要做好三方面：一、明确范围边界，即哪些工作包含在范围内，哪些不包含在范围内。二、监控项目的执行，即范围内的哪些工作做了，哪些没做，并且杜绝做额外的工作。三、防止范围蔓延。本文结合作者的实践，以移动管理平台项目为例，讨论该项目建设过程中的范围管理，主要从规划范围管理、收集需求、定义范围、创建WBS、范围确认、范围控制这几个方面进行论述。1、 规划范围管理规划范围管理是编制范围管理计划，描述如何定义、确认和控制项目范围的过程，在整个项目中对如何进行范围管理提供指南和方向。在正式制定计划之前，我先查找了公司组织过程资产，找出制定范围管理计划的模板，再结合公司以往项目的经验，制定出一份初步的计划，然后召集项目组成员和项目干系人，对计划进行修改和完善，在团队成员的参与下，最终完成了一份详细、科学的管理计划，用于指导项目如何定义、分解以及核实和控制范围。2、 收集需求需求是软件项目成功地核心所在，它为其他许多技术和管理活动奠定了基础。科学充分地收集需求并不是一件容易的事，因为大多数干系人无法完整地描述需求，因此，只有与干系人有效地合作才能成功。我带领的我的项目团队到客户现场进行调研，并召集了所有干系人进行业务交流。针对客户对需求描述不清楚的情况，防止甲乙双方对需求理解不一致的问题，我们采用原型法根据已经获取的需求，根据以往项目的成果，定制了一个产品 DEMO，演示已获得的需求功能，并引导客户把所提的需求形象化，具体化，并开展了引导式研讨会。在客户和团队成员共同努力下，终于完成了需求文件，并进行了签字确认。3、 定义范围为了明确收集的需求哪些包含在项目范围内，哪些排除在项目范围外，明确产品、服务或成果的边界，进行了定义范围这项工作。基于需求文件，我召集了项目的主要干系人开会讨论，同时邀请了系统的最终用户代表对系统功能进行评价，通过用户的角度，去发现和改进系统的功能，最终形成了详细的范围说明书，主要包括产品范围描述、验收标准、可交付成果、项目的除外责任、制约因素、假设条件等内容。4、 创建WBS基于项目范围说明书，我和我的团队开始对项目范围进行自上而下分解，以形成该项目的WBS，在分解过程中，我邀请了全体项目团队成员、用户、干系人共同参与，按照以下原则进行分解：在各层次上保持项目的完整性，我将项目涉及的需求调研、系统设计、开发、测试等模块一一列出，避免遗漏必要的组成部分。一个工作单元只从属于某个上层单元。对于项目中的数据库设计，我只将其归入系统设计单元中，在其他单元不再重复出现，避免了交叉从属。相同层次的工作单元应有相同性质；对于系统设计单元下的数据库设计、接口设计等工作，都属于设计。工作单元应能分开不同的责任者和不同的工作内容；对于该项目中的每个工作包，我都对其进行编号，并与组织机构图和成本控制点进行融合，便于项目的日后管理。应包括分包出去的工作。对于该项目，我将项目管理和外包的AP部署也一并纳入WBS中，并逐层分解。WBS的最低层次的工作单元是工作包，对于该项目中的工作单元，我参照8/80原则细化成具体的工作包，并确定具体的负责人。5、 确认范围范围确认是项目干系人正式接受已完成项目交付物的过程。项目范围确认是很困难的事情。客户总是认为什么都没有看到，怎么能进行确认呢？出现客户范围确认不配合的情况。而我们希望客户尽快确认，以便开展下面的工作。我们通过和客户进行很好的沟通，告诉他们虽然项目范围确认是正式的，但并不意味这项目的范围就一成不变，不能再修改了，只是无论是现在更改范围还是将来更改范围，都会引起项目的时间，进度和资源的变化。例如，在实际工作时，我们每次希望得到甲方的确认以便尽快开展下一项工作，为了防止客户认为自己什么也没有看到这种情况，范围确认始终贯穿项目始终，在 WBS 确定后，我们建立了多个里程碑，每一个里程碑都是重要的节点，我邀请项目干系人参加阶段评审会，这样既有益于专业人员之间的沟通，也有益于客户业务部门对系统范围的认可和信任，虽然变更不可避免，但是，只要按照变更流程走，且审批通过，都可以进行变更，这样就消除了客户的顾虑，便于快速，高效的完成项目确认。6、 控制范围范围控制就是监督项目范围状态，管理范围基础变更的过程，因此，在项目中，我定期组织召开项目状态审查会，审查项目的范围，找出范围偏差，并作分析、严格杜绝一切的范围蔓延及镀金。例如，在一次的阶段审查会上，我发现项目的查询功能模块中，程序员正在添加一个申报分类查询显示功能，但这个功能在合同和需求中根本没有，同时又查了项目系统变更日志，未找到相关的变更记录，于是我参照责任分配矩阵，找到这个模块的负责人小张，最终通过了解，是甲方的支付中心主任与项目组程序员小张属于朋友关系，此需求是由甲方的支付中心主任直接找到程序员小张提出要求增加的，由于小张碍于朋友关系且认为难度不大所以没有申请变更直接给予增加。这个由于不符合变更流程，于是，我找到甲方的支付中心主任，提出了异议，并说明这样会影响项目的进度，经过与甲方支付中心主任的协商，最终决定将此需求作为补充，走变更流程，在二期开发中进行开发。通过此次审查发现并及时进行开会强调变更控制的重要性，避免了后期项目实施过程中类似情况的发生。在我的领导下，经过全体项目成员的共同努力，项目于 2018 年2 月份顺利通过验收，正式上线，系统目前运行良好，并得到了公司和用户方的一致好评。回顾整个项目的实施过程，项目的成功很大程度上