16--论信息系统项目的范围管理

摘要

2013 年 8 月，笔者作为项目经理参与XX省电子政务网一期工程的建设工作。作为该单位的重点战略项目，该项目总投资为3200万人民币，项目周期为26个月，共有7个单位参与建设。该项目采用 B/S 结构，系统基于oracle数据库的JAVA/Java EE多层体系结构，以linux为主的作为操作系统， 应用面向对象设计、面向服务（SOA）、面向接口技术、组件式开发技术，采用mvc、ORM、WEB Service、ajax技术。

该项目按照统一组织领导、统一规划建设、统一数据标准、统一外网平台、统一公文办理及事务处理平台、统一集中部署的要求，项目建成以后，实现全省公务员跨地区、跨部门和跨层级的信息传输、公文传输、信息共享和业务协同。

2015年 12月，该项目通过了客户的验收，赢得了甲方及各参与的一致好评，成为电子政务行业的成功案例，得到业内的一致认可。本文结合笔者的实际经验讨论了项目的范围管理，主要从制定范围计划、定义范围、创建 WBS，以及核实范围、控制范围这几个方面进行论述。

正文

2013 年 8 月，笔者作为项目经理参与XX省电子政务网一期工程的建设工作。该项目搭建省、市、县、乡各级政府电子政务办公平台以及移动办公平台，使全省行政机关通过电子政务平台统一办公，构建“一体化”政府的战略而立项，是十二五期间省电子政务中的重点项目。一期项目的建设周期为26个月，从2013年8月开始，到2015年12月验收结束，项目总投资为人民币3200万。该项目为了实现全省公务员跨地区、跨部门和跨层级的信息传输、公文传输、信息共享和业务协同。

该项目采用 B/S 结构，系统基于ORACLE11g数据库的RAC共6个节点的集群，JAVA/JAVAEE多层体系结构，采用应用面向对象设计、面向服务（SOA）、面向接口技术、组件式开发技术，采用MVC、ORM、Web Service、AJAX技术。操作系统已Redhat的Linux6.5为主，以及微软的windows2008等，中间件采用IBM的WebSphere并做集群，终端以各单位的个人电脑以及智能终端。项目采用矩阵型组织结构，从各职能部门抽调主干成员，组成专门的项目团队。我被任命为该项目的项目经理，负责项目的管理工作，直接向公司总经理报告。下面我将结合本项目从制定范围管理计划、定义范围、创建工作分解结构、核实范围、控制范围这几个方面对项目的范围管理进行介绍。

一、制定范围管理计划

针对一些 IT 项目开发中，没有制定范围管理计划，就进行范围定义的问题，或者是边定义范围、边制定计划的情况，我们严格按照 PMBOK 的规范要求，尤其重视制定范围管理计划，制定范围管理计划看似花费大量时间，但没有范围管理计划，以后的范围管理工作就无章可依，出现范围定义不清、范围蔓延、范围边界不清等问题。

因此，在该项目中，我非常重视范围计划的制定，在正式做计划之前，我先查找了公司组织过程资产，找出制定范围管理计划的模板，再结合以往项目的经验，制定出一份初步的计划，然后召集项目团队成员讨论，对计划进行修改和完善，在全体参与下，最终完成一份 详细的、科学的范围管理计划，用于指导项目如何定义、分解以及核实和控制范围。

二、定义范围

根据范围管理计划和项目章程等资料，项目组开始了范围定义工作。在该工作中，我们尤其注意了干系人分析、专家判断和产品分析等工具和方法的使用。该项目涉及从省办公厅，省经信委、省信息中心等14个单位的工作人员，还有项目领导小组，干系人众多，众口难调，需求复杂。在项目的早期阶段，我带领团队，到了客户现场收集需求，我组织了客户的电子政务部门、服务质量部门、信息中心以及我的需求团队，召开需求讨论会，共同商讨项目范围。通过前期的访谈，大多数电子政务工作人员对需要什么样的系统功能，自身都没有一个清晰的认识，针对这种情况，我们在干系人沟通中，演示了为其他集团开发的电子政务系统，通过实际操作，工作人员对系统功能有了感性认识，以这个系统为基础，充分挖掘用户的需求，并基于团队自身的经验以及专业水平，对客户的需求进行引导、细化，将其模糊的概念形象化，粗糙的需求具体化。

基于需求文件，我召集项目的主要干系人进行开会讨论，同时邀请了系统的最终用户代表对系统功能做评价，通过用户的角度，去发现和改进系统的功能，以此最终形成了完整的项目范围说明书，主要包含：（1）项目目标：实现全省互联互通，信息共享，业务协同，同时确定各子项目的成本、进度、技术和质量等要求；（2）产品范围描述：包括人员和组织机构数据库，统一认证系统，数据交换系统、公文与实务处理系统、门户管理系统等；（3）项目边界：该项目涉及数据交换，不涉及协调各单位数据等；（4）项目的可交互物：如项目管理报告和文档等；（5）项目的验收标准：系统运行稳定性，功能满足业务要求，相关文档齐全等；（6）项目的约束条件：如合同和项目章程中相关条款等；（7）项目的假设条件等。

三、创建 WBS

基于项目范围说明书，我和我的团队通过使用工作分解结构的模板开始对项目范围进行分解，以形成该项目的 WBS。 在分解过程中，我按照以下原则进行分解。

（1）在各层次上保持项目的完整性；该项目涉及的项目管理、需求阶段、系统设计开发阶段试、系统集成阶段、项目验收阶段等，避免遗漏必要的组成部分。

（2）一个工作单元只能从属于某个上层单元；对于该项目中的数据库设计，我就只将其归入系统设计单元中，在其他单元不再重复出现，避免了交叉从属。

（3）相同层次的工作单元应用相同的性质；对于系统设计单元下的数据库设计、接口设计、系统设计等设计内工作，它们从属性 上来讲，都属于设计，因此我将其一并归入系统设计单元下。

（4）工作单元应能区分不同的责任者和不同的工作内容；对于该项目中每个工作包，我都指定唯一的负责人和其负责的工作内 容，便于项目管理进行计划和控制的管理。

（5）便于管理和控制；对于该项目的每个工作包，我都对其进行编号， 并与组织结构图和成本控制点深度融合，便于项目的日后管理。

（6）应包括项目管理工作，包括 分包出去的工作。

通过逐层分解，WBS 的最低层次的工作单元是工作包，同时对WBS进行编码设计；对于该项目中工作单元，我参照 8/80 小时原则细化成具体的工作包，并指定具体的负责人。同时制作 WBS 词典，对工作包做具体描述。

四、范围核实

范围确认并不是件容易的事情，在与客户的沟通上，我们希望客户尽快确认以便尽快开展后续的开发阶段工作，而客户则可能认为自己什么也没看到，怎么确认呢？针对这种情况，我在提交文档给客户的相关干系人后，重点对客户的 IT 人员进行沟通培训，详细介绍系统的设计，然后用他们的声音去向客户的业务部门做出介绍，这样既有益于专业人员之间的技术沟通，也有益于客户业务部门对系统范围的认可与信任。同时，在与客户的业务部门沟通时，我重点强调，虽然范围确认是正式的，但这并不意味着项目的范围就是铁板一块，不能再修改了，只要走标准的变更流程，且审批通过的，都是可以进行变更的。这样就消除了客户的顾虑，便于快速、高效地完成范围确认。

五、范围控制

控制范围就是监督项目的范围状态，管理范围基础变更的过程。因此在项目中，我定期组织召开项目状态审查会，审查项目的范围，通过对照范围基础，找出范围偏差，并做分析，严格杜绝一切的范围蔓延以及镀金。

例如，在一次状态审查会上，我发现系统管理模块多了登录日志功能，我查了一下系统变更日志，未找到有类似的变更记录，于是我参照责任分配矩阵，分别找到这两个模块开发的负责人询问原因，A 成员告诉我，他增加登录日志这个功能，是因为客户在一次电话中，向他提过希望在系统管理模块中加一个登录 日志的功能，针对这种情况，我首先向这名成员强调了范围基准以及变更流程的重要性；其次，针对这项多出来的功能，我要求相关人员提交正式的变更申请，走正常的变更控制流程。

从事项目管理工作的我深知，项目范围不是一经定义，就一成不变的，项目干系人出于项目利益以及各种情况考虑，总会有一些需求变更，管理这些变更，需要在项目规划时，就 制定好变更控制流程以及成立一个专门的需求变更控制委员会（CCB）。因此，我和我的团队 在项目早期就制定了一套标准的变更流程：①提交变更申请；②评估变更；③报 CCB 审批；④实施变更并调整基准；⑤将变更信息通知相关干系人；⑥对变更的结果进行追踪与审核。 有了这些流程以及 CCB 的控制，项目的需求变更得以良性发展，变更带来更多的是项目利益以及效率的提升。

经过我和我的团队不懈努力，该项目最终于2015 年 9 月试运行成功，并在同年 11月通过了客户验收小组的验收，得到了甲方的好评。项目最终能成功完成，得益于我在项目中有效的范围管理，采用科学的范围管理方法、工具和技术，为项目的范围管理带来了事半功倍的效果。同时，在该项目的实施过程中，也 出现了一些问题，本人觉得处理得不是很好，主要在于项目中的冲突管理以及项目风险识别方面还存在不足，后续我将加强这两个方面的学历与知识积累，不断提升自身项目管理水平，为中国电子政务行业的信息化发展添砖加瓦。