论需求管理和范围管理

1、论项目范围管理【摘要】2010年4月，我所在的单位承担了某市安全生产综合信息化管理平台的建设工作。我 有幸参与了该项目并担任了项目经理，主要负责系统整体规划、组织实施和管理控制工作。本文结合作者的实践经验就项目管理工作中的需求管理和项目范围管理进行翔实的论 述，首先讨论了需求开发、需求管理和范围管理的区别与联系。以该项目为例，介绍了在项 目需求管理和范围管理中所采取的措施和手段，包括制定符合项目实际情况的项目范围管理 计划、定义清晰的项目需求和范围、创建WBS和WBS清单、进行项目范围确认、项目范围 控制五个方面的内容。最后总结了在这个项目中，需求管理和范围管理所收到的效果和不足 之处。【正文

2、】项目概述2010年4月，我所在的单位受某市安全生产监督管理部分的委托为其开发一套安全生 产综合信息化管理平台，该平台包括安全生产监测监控系统、应急救援抢险系统、安全生产 监督信息管理系统和门户网站四个系统21个子系统组成。安全生产监测监控系统实现将全 市煤矿瓦斯监测数据、井下人员定位数据、重大危险源监测监控数据通过接入到应急指挥中 心，实现对全市煤矿、重大危险源全天候24小时监控，将安全生产事故消灭在萌芽状态。 安全生产监督信息管理系统实现将全市被监管企业信息全方位、动态化管理，为安全执法检 查提供信息支持。应急救援抢险系统以地理信息平台为基础实现可视化的指挥调度、有序调 度救援物资、救援力

3、量，综合分析各种因素科学准确决策；门户网站实现各类监管信息、工 作动态等发布，实现监管部门与公众互动。经过项目团队的努力工作和建设方的大力支持项 目于2010年10份顺利通过验收。需求开发、需求管理和范围管理的区别与联系需求开发是通过调查与分析，获取用户需求并定义最终产品需求；需求管理是确保各方 对需求的一致理解，管理和控制需求的变更，实现从需求到最终产品的双向跟踪；项目范围 管理是确保项目包含且包含所必须完成的工作。需求管理贯穿于信息系统项目的整个生命周 期，只有经过需求分析才能确定项目范围。需求的变更会引起项目范围的变更。需求管理和 范围管理是项目管理工作的重点和难点。含糊的需求和频繁变动

4、的项目范围让建设方和承建 方吃尽了苦头。制定合理的范围管理计划凡事预则立不预则废。项目范围管理计划是对如何进行项目范围控制、项目范围管理中 使用工具和技术、变更决策依据等内容做出详细的规定。符合项目实际情况的范围管理计划 是有效进行项目范围管理工作的前提和依据。针对该项目技术复杂、建设方信息化程度低、 涉及面广等客观现实。项目启动后项目小组根据该项目的技术协议、合同、技术方案、项目 管理计划为依据，利用公司其他类似项目范围计划编制的成果，编制项目范围管理计划。主 要包括：包括详细的范围说明，就是实现安全生产事故提前预警、事故发生后快速响应，提 高执法效率。同时包含创建工作分解结构的初步计划及验

5、收确认等内容。项目范围管理计划编制完成后，组织公司有关方面的专家及具备类似经验的人员，经过 反复讨论、审查、修改，最后形成定稿。将项目范围管理计划作为指导项目范围管理的纲领 性文件，在后期执行过程中对照范围管理计划展开项目范围管理工作。定义清晰的项目需求和范围据调查显示在众多失败的信息系统项目中，由于项目范围导致的原因占了很大一部分， 由于需求不明确、范围蔓延导致项目的失控。明确的、清晰表达的、切实可行的需求是需求 管理和项目范围管理的基础，也是需求变更控制的基线。由于建设方信息化水平不高，最终 用户对信息技术知识了解深。鉴于需求对项目范围的重要性，与该项目的销售代表对项目的 背景知识进行详细

6、了解，主要了解建设方决策层对项目的战略目标与整体要求、管理层对项 目期望与支持度，项目的发起原因、发起人等。通过和销售代表的沟通对项目背景有了初步 的了解，然后和建设决策层主要领导进行多次沟通后确定了项目整体目标、要实现的战略构 想、总体范围。根据决策层的总体目标和战略要求，我组织团队成员对管理层人员和最终系 统的使用者进行初步调研，根据初步调研的结果建立系统原型。利用原型和客户进行交流， 征求使用意见，根据反馈结果对原型进行改进，优化后再次交给用户新的原型，经过多次交 流和反馈，使项目团队对需求理解更加透彻，客户看到原型后，对系统有了一个直观认识， 提升了客户满意度和信心。最后召开了由建设方

7、主要项目干系人、其他相关人员、销售代表 和项目团队成员需求确认会，将需求说明书提前发给参会人员，结合系统原型对需求进行讨 论，形成对需求理解一致，双方对需求说明书签字确认最为后期需求变更控制的基线。创建WBS和WBS清单创建工作分解结构是将项目的主要可交付成果和项目工作细分为更小的、更易于管理的 部分。根据项目特点，同项目团队成员进行充分讨论后确定以项目生命周期的各个阶段作为 工作分解结构的第一层，即需求分析、系统设计、编码、测试、验收和项目管理作为第一层。 将各个系统/子系统作为分解结构的第二层，然后各系约子系统按模块组再次分解，直到最 底层的工作包工作时间不大于80小时。在各个分解层次上保

8、持项目的完整性便于管理需要， 工作单元的细节信息在分解结构的字典中加以描述。在项目工作包的分解过程中我们邀请建 设方代表一起参与工作任务的分解，是双方对工作任务达成一致的理解避免理解上的差异。 建设方代表参与分解过程，使建设方对项目范围有了更深刻的理解，在项目后期实施中能够 理解项目的进展、面临的问题。项目范围确认项目范围确认就是与建设方对项目所交付的成果和所开展的项目活动达成一致理解。很 多信息系统项目由于忽视了项目范围确认工作或认为项目范围确认是走过场，最终导致执行 过程中项目范围蔓延项目延期交付。范围去人是项目范围管理中非常重要的一项活动。项目 的WBS分解完成后，我们组织由建设方代表、

9、销售经理和项目团队成员组成的项目范围确 认小组，依据技术协议文件、投标技术方案和项目合同对项目需求和WBS进行讨论确认。 我们事先将会议资料发给参会人员，会议以原型讲解和讨论的方式进行，保证所有项目参会 人员对项目交付成果的功能、目标机项目所开展的各项活动达成一致理解。最后所有参会人 员对讨论修改后的项目需求和WBS进行签字确认，将确认后的项目需求和WBS作为执行过 程中变更控制的基准。项目范围控制在项目的实施过程中为了防止项目范围的蔓延保证项目顺利进行，要求建设方所有变更 以书面形式提出。对于建设方提出的变更请求我们首先分析是否在既定的项目范围内，如果 在项目范围内，组织相关技术骨干对造成的

10、影响从技术、成本、进度和质量方面进行评估， 根据评估结果制定应对措施。如果变更请求在项目范围外，组成有建设方代表、销售经理和 相关人员进行评估决定是否变更，由建设方代表、销售经理和项目经理共同签字后方可实施 变更。在项目实施过程中我们建立了周工作例会制度对项目的范围、成果和进度及时通报， 对重要问题及时做出决策。邀请建设方代表参加周例会，使建设方能够不断对项目范围及已 经取得的成果进行确认，避免了在项目实施后期范围变更的巨大风险。同时保证在项目过程 中对重要问题及时做出决策。对关键事项我们邀请建设方代表一起参与讨论决策，增加双方 沟通交流机会，使建设方代表充分了解项目的范围、实施进展、面临的问题及其解决方法， 并对项目的实施形成共识，避免项目范围及进展理解上的差异，有利于项目的顺利实施。此 外，根据工作任务分解阶段形成的里程碑在阶段性工作结束后对阶段工作进行评审和确认。【总结】项目自去年10月份至今已经1年多，在实际的应用中安全生产事故得到了有效的控制、 执法水平有了明显的提升，得到了客户和公司领导的一致好评。软件项目的需求管理和范围 管理是