注：以下论文由信管网编辑网上摘录，仅供参考（如有侵权请联系我方删除），不一定完全符合论文要求，建议报名信管网培训，由老师指导写作。

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

2015年11月，我作为项目经理参与了某省电力公司运营监测（控）信息支撑系统项目的建设，该项目投资共740万元人民币，项目组织结构为项目型，建设工期为14个月。某省运监中心按照“千里眼、顺风耳、铁算盘、预警机”的定位要求，通过该项目的建设，形成了二级横向协同、纵向贯通的运营监控体系，实现了对公司主营业务的监测分析，促进了公司运营效率和管理水平提升。该项目于2016年12月底正式通过验收并上线运行，得到客户和公司管理层的一致认可。本文结合作者的实际项目经历，以该项目背景为例，讨论了范围管理在信息系统项目管理过程中的重要作用，主要从：编制范围管理计划、范围定义、创建工作分解结构、范围确认、范围控制五个方面予以阐述。

2015年11月，我作为项目经理参与了某省电力公司运营监测（控）信息支撑系统项目的建设，该项目投资共740万元人民币，项目组织结构为项目型，建设工期为14个月。省运监中心按照“千里眼、顺风耳、铁算盘、预警机”的定位要求，通过该项目的建设，形成了二级横向协同、纵向贯通的运营监控体系，实现了对公司主营业务的监测分析，促进了公司运营效率和管理水平提升。该系统整体采用省公司和地市公司运监中心两级部署模式，计划预算、核心资源、关键流程、数据管理、电网运营等功能模块通过界面集成的方式与工作台集成，并利用两级部署的数据中心实现数据流转、处理。两级数据中心间通过DXP进行数据纵向交换；两级监测通过两级ESB级联的方式实现应用集成。可视化与数据中心进行集成，由数据中心将运营监测指标与告警数据等推送到可视化数据。

该系统采用 B/S架构平台和 SSH 主流 Web 应用框架，因本项目对系统的安全以及可靠性等方面有着较高要求，决定采用三层架构模式的 J2EE 环境作为运行环境，采用 oracle 10g企业版为数据库环境。本项目于2016年12月底正式通过了验收并上线运行。

运监业务是公司新的业务领域，我方高层希望将本项目作为公司业务拓展的一个新窗口，本项目是一个综合性的系统工程项目，具有专业性强、涉及面广以及涉及项目干系人众多等特点，范围控制困难可想而知。因此，为了确保项目顺利实施，在本项目中，我按照范围管理理论并结合以往项目经验，通过编制范围管理计划、范围定义、创建工作分解结构、范围确认、范围控制五个过程完成本项目的范围管理。

1. 编制范围管理计划

范围管理计划，是规定如何定义、检验、控制范围，以及如何创建与定义工作分解结构。范围管理计划为项目管理团队如何管理项目范围提供指导。由于运监业务涉及业务系统多、业务逻辑复杂等特点，我邀请了运监业务和数据分析技术方面的多名业务骨干采用头脑风暴形式开展计划的编制，借鉴以往类似项目的范围计划的模板和相关表格开始着手计划编制。最终通过分析讨论整理得出一个概要的项目范围计划，然后结合以往的项目经验对该概要计划进行综合平衡、优化，在计划内加入了对已完成项目的可交付物进行正式的确认和接受等内容，经过评审后发布作为项目范围管理计划。

2.  范围定义

软件的范围直接与需求相关，需求收集和分析的不到位导致项目执行过程中范围不断“蔓延”是信息系统项目失败最常见的原因之一。因此明确项目需求，做好项目范围定义，使项目范围清晰化是项目管理中至关重要的一项工作。为了减少需求遗漏的可能性，我着重加强了项目干系人管理，召集省市公司两级用户代表以及其他重要的干系人进行了多次、逐渐细化的需求分析讨论会，不断明晰用户模糊的需求、挖掘和引导用户的潜在需求，从而使项目范围边界不断清晰。我安排需求分析工程师在功能性需求与非功能性需求上周期性地向用户确认，以保证项目团队与用户在需求理解上达成一致。最后，将已定义的需求整理为项目范围说明书，形成阶段重要可交付物。

3. 创建工作分解结构

工作分解结构 WBS 是组织、管理项目工作的主要依据和基础。WBS 的精度和粒度决定了项目进度和成本规划的准确率，因此，在创建 WBS 过程中，我个人认为最重要的因素有三点：

一是范围说明书的清晰度与完整度。WBS 的建立依赖于成功的需求分析与清晰的范围定义。在本项目中，我是将需求文件做细，将整个过程管理平台分为52个功能模块，每个功能模块分别具有多个子功能，这样需求文件本身便是一个三级的 WBS 雏形，WBS 的分解也相对容易。二是WBS 分解粒度。在本项目中，由于我将 WBS 分解为三级编码结构，最底层工作包平均为 2人天。三是WBS 词典的详细程度。WBS 作为项目的重要文档，可以说是项目开发整个过程的工作手册，WBS 的词典越详细，项目干系人尤是团队成员对于工作包的理解就越趋于一致而减少理解偏差。在以往的项目中，我经常见到 WBS 词典非常粗略甚至缺失带来的许多麻烦，因此，在本项目中，我对 WBS 词典亲自审核并在定稿后专门开会发布。事实证明，这一举措十分有效。

4. 范围确认

范围确认是项目干系人正式接受已完成的项目范围的过程，范围确认需要审查可交付物和工作成果。在本项目中，由于采用了原型法、不断迭代的开发方法，持续性交付阶段性成果范围管理思想，因此范围确认贯穿整个项目始终。在 WBS 制订后，我确定了多个重要里程碑，每个里程碑是一个重要时间节点，我邀请相关干系人参加阶段评审会。评审过程中的偏差和问题都会被记录并马上投入代办事项清单进行解决，评审过程产生的意见都会形成评审意见表并请代表签字以形成正式书面记录。

5. 范围控制

范围控制是监控项目范围状态，确保所有请求的变更和采取的纠正行动，都要通过整体变更控制过程处理。根据我的经验，范围是最可能变更的基线，范围变更也是最常见的变更。一般来说，范围变更源自于用户的前期需求未正确识别或用户中后期新增需求，少数情况下也会出现项目团队内部的范围蔓延，也就是镀金。在本项目中，为了减少范围变更频度和降低相应不利影响，我做了以下工作：一是建立变更控制委员会（CCB）与变更控制流程。二是在范围管理计划中对范围变更控制进行规定。尽量在满足用户需求的前提下缩小范围变更的幅度，降低不利影响，避免理解不一致带来的重复变更，杜绝镀金。

由于项目范围管理得当，本项目于2016年8月完成系统测试及预验收，于 2016 年 9月上线试运行。经历了 3 个月的试运行后，修复了实际使用过程中发现的 Bug 并对系统进行了完善，最终于 2016年12月底顺利通过验收。

本项目在范围管理方面总体比较顺利，但也有一些问题，例如在创建 WBS 时，由于对可视化设计主体设计工作量估计过于乐观，导致估计值不准确，与实际值有一定偏差，造成了几天的工期延误，在通过赶工等手段及时修正了偏差之后，问题才得以解决。这些问题在以后的项目中会加以改进。纵观项目的全过程，做好项目范围管理是本次项目成功的重要保证，也让我由范围管理理论到实际应用有了更加深入的理解，为应对未来更加复杂的项目积累了宝贵经验。