项目管理----项目范围管理

一、项目范围管理基础知识

项目范围的管理也就是对项目应该包括什么和不应该包括什么进行定义和控制，以确保项目管理者和项目干系人对作为项目结果的项目产品和服务以及生产这些产品和服务所经历的过程有一个共同的理解。也就是说，项目范围管理主要关心的是确定与控制哪些应该与不应该包括在项目之内的过程。

我们知道项目是为完成产品或服务所做的一次性努力。因此在这里，范围的概念包含两方面，一个是产品范围，即产品或服务所包含的特征或功能，另一个是项目范围，即为交付具有规定特征和功能的产品或服务所必须完成的工作。在确定范围时首先要确定最终产生的是什么，它具有哪些可清晰界定的特性。要注意的是特性必须要清晰，以认可的形式表达出来，比如文字、图表或某种标准，能被项目参与人理解，绝不能含含糊糊、模棱两可，在此基础之上才能进一步明确需要做什么工作才能产生所需要的产品。也就是说产品范围决定项目范围。

项目范围管理过程：

范围规划（范围计划编制）——制定项目范围管理计划，记载如何确定、核实与控制项目范围，以及如何制定与定义工作分解结构（WBS）

范围定义——制定详细的项目范围说明书，作为将来项目决策的根据。

制作（创建）工作分解结构——将项目大的可交付成果与项目工作划分为较小和更易管理的组成部分。

范围核实（确认）——正式验收已经完成的项目可交付成果。

范围控制——控制项目范围的变更。

上述过程不仅彼此之间相互作用，而且还与其他知识领域过程交互作用。根据项目需要，每个过程可能涉及一个或多个个人或集体所付出的努力。每个过程在每个项目或在多阶段项目中的每一阶段至少出现一次。

二、项目范围管理相关案例分析

项目的范围管理影响到信息系统项目的成功。在实践中，“需求蔓延”是信息系统失败最常见的原因之一，信息系统项目往往在项目启动、计划、执行、甚至收尾时不断加入新功能，无论是客户的要求还是项目实现人员对新技术的试验，都可能导致信息系统项目范围的失控，从而使得信息系统项目无论在时间、资源和质量上都受到严重影响。
案例类型：范围定义
   阅读以下关于信息系统项目管理过程中范围管理方面问题的叙述，回答问题1至问题3。
案例场景：
   信管信息技术有限公司(CNITPM原本是一家专注于企业信息化的公司，在电子政务如火如茶的时候，开始进军电子政务行业。在电子政务的市场中，接到的第一个项目是开发一套工商审批系统。由于电子政务保密要求，该系统涉及到两个互不联通的子网：政务内网和政务外网。政务内网中储存着全部信息，其中包括部分机密信息；政务外网可以对公众开放，开放的信息必须得到授权。系统要求在这两个子网中的合法用户都可以访问到被授权的信息，访问的信息必须是一致可靠，政务内网的信息可以发布到政务外网，政务外网的信息在经过审批后可以进入政务内网系统。
    张工是该项目的项目经理，在捕获到这个需求后认为电子政务建设与企业信息化有很大的不同，有其自身的特殊性，若照搬企业信息化原有的经验和方案必定会遭到惨败。因此采用了严格瀑布模型，并专门招聘了熟悉网络互通互联的技术人员设计了解决方案，在经过严格评审后实施。在项目交付时，虽然系统完全满足了保密性的要求，但用户对系统用户界面提出了较大的异议，认为不符合政务信息系统的风格，操作也不够便捷，要求彻底更换。由于最初设计的缺陷，系统表现层和逻辑层紧密耦合，导致70％的代码重写，而第二版的用户界面仍不能满足最终用户的要求，最终又重写的部分代码才通过验收。由于系统的反复变更，项目组成员产生了强烈的挫折感，士气低落，项目工期也超出原计划的100％。
    【问题1】(10分)
    请不超过300字，对张工的行为进行点评？
    【问题2】(9分)
    请从项目范围管理的角度找出该项目实施过程中的主要管理问题？不超过200字回答。
    【问题3】(6分)
    请结合你本人实际项目经验，指出应如何避免类似问题？不超过200字回答。
案例分析：
    这是一个失败的项目，张工在项目管理中既有闪光点，也有失败的地方。但项目管理中的任何差错都会影响项目的结果，而范围管理的失误对项目的影响更为明显。模糊的项目范围定义、错误的工作分解、缺失的范围确认和无力的范围控制都将严重影响项目的结果。
    张工对项目范围有一定的把握。在范围定义中，张工发现了不同行业间具有不同的特点，电子政务行业对系统运行环境有着特殊的要求。根据国家对电子政务的要求，政务内网与政务外网是该行业一致的标准，这与企业信息化是完全不同的。张工捕获到该需求，并对这个需求进行了清晰的定义，根据瀑布模型的要求，对设计和实现都进行了严格的控制，因此在系统交付时完全满足了用户对保密性的要求。在这一点上，张工是成功的。如果在范围定义时忽略了行业标准，项目肯定会招致更大的失败。
    但用户界面的风格和操作的便捷性也属于系统范围的一部分。与系统运行环境一样，我们通常称这类需求为隐性需求。这类需求往往不是由用户直接提出，而且受行业特点决定的范围所约束。对于电子政务来说，系统保持一致的风格非常重要。作为政府对公众开放的窗口而言，并不需要很强的个性化，但一致的界面风格可以体现出政务的严肃性。考虑到全体民众层次差异较大，大多数访问系统的用户一般都没有接受过系统使用的培训，操作的便捷性也是政务系统必须实现的功能之一。很明显，对于这些系统的隐性需求张工没有充分考虑，从而导致一而再，再而三的变更。
    对于软件项目，所有的需求都必须经过清晰的定义，这些需求都是项目范围的一部分。张工仅仅注意了其中的一部分，而忽略了用户界面，最终导致项目的失败。
    对于电子政务信息系统，尤其是面向公众开放的信息系统，范围定义更加困难。这些系统的最终用户几乎不会参加需求开发的工作，他们的需求都是间接的，通过政府部门的负责人传递到项目组。但最终用户的意见对项目的结果会有巨大的影响，这是就对范围管理提出了更高的要求。
    除了在范围定义方面的问题外，张工在范围确认和范围控制方面也存在不小的失误。当系统第一次更改时，就应该意识到系统界面风格和操作便捷性的重要性。这时应该清晰地定义系统的界面风格和操作风格，并设法进行确认。如果采取了恰当的措施，第二次的变更是完全可以避免的。
    在刚刚进入一个陌生领域的时候，其中充满了各种各样的风险。隐性的行规和行业特点都是项目范围的风险。面对这些风险，即使再细致的调研也无法完全避免，也不能完整定义系统的范围。因此可以考虑采取原型法等方式来提前暴露风险，减少风险带来的损失。因此在案例中，张工也没有进行充分的风险管理，采用严格的瀑布模型增加了风险发生后带来的损失。
    对于这个案例，缺乏良好的设计也是很明显的缺陷。用户界面中耦合了大量的业务逻辑，这必然增加变更的代价，从而导致大部分代码重写。若在项目初期意识到界面变更的风险，随之采用良好的设计，将表现层和业务逻辑彻底分开，系统变更的代价也会小得多。
    综上所述，项目经理张工在整个案例中，针对范围管理做了一些工作，但不全面，在风险管理和质量管理上也都存在缺陷。
    有了上面的分析，这道题就很容易作答。项目的闪光点在于对系统运行环境进行了清晰的定义，并最终满足了用户的要求；但不充分的范围定义和范围  确认招致了项目的失败，而采用了抗风险能力较弱的瀑布模型和低质量的设计又雪上加霜，最终导致项目延期100%.
    因此第一题答案的要点就很明确了：
    (1)张工注意到了系统运行环境的特殊性，在良好设计和实现的情况下满足了用户的要求。
    (2)张工忽略了系统用户的潜在要求，在用户界面和操作的风格上范围定义不清晰，造成系统交付的重大变更。
    (3)张工在第一次问题发生后仍没有对范围进行有效的管理，造成了系统第二次的变更。
    (4)张工没有对用户界面是否能够满足要求的风险进行有效的管理，而是采用了对风险适应性较差的瀑布模型组织开发。
    (5)张工没有对设计质量进行有效的控制，造成表现层中耦合了业务逻辑，增加了修改的代价。
    对于第二题，是在第一题的基础上考察对范围管理的理解，因此可以忽略在其他领域的问题。在范围管理中主要包括如下内容：
    (1)范围管理计划。
    (2)范围定义。
    (3)工作分解。
    (4)范围确认。
    (5)范围控制。
    在本案例中，没有专门设计到范围管理计划和工作分解的内容。从表面上看，范围定义存在明显的缺陷。但案例中提到系统又发生了第二次变更，由此可见，张工在范围确认和范围控制上也存在不足。若在问题第一次出现时就进行有效的范围确认和范围控制，则完全可以避免第二次的变更。因此，第二题的答案要点如下：
    (1)张工没有挖掘到系统的全部隐性需求，缺乏精确的范围定义。
    (2)在发生第一次变更时，张工仍没有有效的范围管理，从而造成系统的二次变更。
    (3)重复的系统变更说明张工对系统范围控制不足，导致一而再再而三的反复。
    在完成第二题后，第三题就是水到渠成了，第三题的要点见参考答案，此处不再赘述。
    项目管理是一个系统工程，没有哪种单一的手段可以有效地改善项目，反之管理中的任何疏忽都可能招致严重的后果，造成项目的失败。而软件项目的复杂性又决定了项目中的工作环环相扣，问题也总是相互关联的。在发现问题后，也需要采取多种手段才能彻底解决问题。这对信息系统的项目经理来说是重大的挑战。
参考答案：
    【问题1】(10分)
    (1)张工注意到了系统运行环境的特殊性，在良好设计和实现的情况下满足了用户的要求。(2分)
    (2)张工忽略了系统用户的潜在要求，在用户界面和操作的风格上范围定义不清晰，造成系统交付时的重大变更。(2分)
    (3)张工在第一次问题发生后仍没有对范围进行有效的管理，造成了系统第二次的变更。(2分)
    (4)张工没有对用户界面是否能够满足要求的风险进行有效的管理，而是采用了对风险适应性较差的瀑布模型组织开发。(2分)
    (5)张工没有对设计质量进行有效的控制，造成表现层中耦合了业务逻辑，增加了修改的代价。(2分)
    【问题2】(9分)
    (1)张工没有挖掘到系统的全部隐性需求，缺乏精确的范围定义。(3分)
    (2)在发生第一次变更时，张工仍没有有效的范围管理，从而造成系统的二次变更。(3分)
    (3)重复的系统变更说明张工对系统范围控制不足，导致一而再再而三的反复。(3分)
    【问题3】(6分)
    有效的范围管理包括了从范围定义到范围控制等多方面的工作，每一项工作都是重要的。对于本案例，要结合行业特点进行需求分析，挖掘系统潜在的需求，同时通过原型等方法来辅助需求的定义，避免范围定义不清晰的问题。
    在发生需求变更时需要进行有效的需求控制，尽量在满足用户需求的前提下缩小需求范围，坚决避免需求的再次变更。

三、项目范围管理论文

论信息系统项目范围管理

【摘要】 

2008年3月，我参与了“某某市行政权力网上公开透明运行”项目的建设，在项目中我非常荣幸担任项目经理一职，该项目作为全省首批试点城市，受到省市相关领导的高度重视。该系统将政府的行政权力和服务类项目全部在网上公开透明运行，办事人员坐在家里通过互联网就可以方便地办结相关事项、查询收费标准、法律依据等，打造真正的“阳光政府、透明政府”。 
本文结合作者的经验就项目管理进行详实的论述，以该项目为例介绍项目的需求，范围定义以及范围管理实施过程中采取的措施、方法，包括项目动员会、评审大会等等，最后列举了项目范围管理中存在的不足之处。 

【正文】 

为了提高政府工作的透明度和公信力，推动党风廉政建设和反腐败工作的开展，在省市领导的高度重视和支持下，“某某市行政权力网上公开透明运行”项目作为全省首初试点城市。该系统不仅涵盖了政府职能部门的行政权力事项，而且还根据需要增加了行政审批中心网上办事大厅的功能，依托电子政务内网和政府门户网站，对全市65个部门1300多条行政许可、行政征收、行政处罚、行政强制等行政权力和1800多条服务类项目通过外网受理、内网处理，外网反馈的形式进行全部在网上透明运行，取消原先纸质文件的流转，黑箱操作的可能，坚决杜绝政府工作人员“吃拿卡要”现象，提高政府办事效率。该项目2008年3月启动，总投资380万元，要求2008年12月1日前全面竣工并投入使用。 
整个项目由行政权力阳光平台、电子监察平台、法制监督平台和网上办事大厅组成，以行政权力库为基本数据构成一库五平台。其中行政权力阳光平台、电子监控平台、法制监督平台和办事大厅部分功能基于Windows Server 2003操作系统+SQL Server 2005数据库，采用.NET的开发工具，B/S模式，业务工作流采用公司定制的工作流。外网受理反馈模块采用基于Linux操作系统+Apache平台（客户为了节约资金），Linux平台最大优点就是投入少、安全性高。 
由于涉及到的部门多，业务面广，时间紧，事项权力复杂，一些关键职能部门领导的抵触情绪等原因，我们在省市政府的亲切关怀下，业主的通力配合与支持下，我与项目组全体同仁一起并肩作战，通过近9个月的努力，终于在2009年11月20日前全面通过验收，比计划提前了10天。在此笔者就该项目采取的一些方法做简略的介绍，望各位读者给予批评指正。 

一、 提前与销售经理介入项目，充分做好需求分析调研工作。 

业务需求分析是准确确定范围的基础，为了保证业主需求分析的全面、准确，在向业主进行需求分析调研时，首先制定了需求制定计划，明确需求调研时间，业主参加人员，调研内容，实施人员；同时依据项目背景资料做好需求调研准备，认真做编制需求分析问询表，详细列出调研问题提纲，避免在调研过程中遗漏相关内容；在调研过程中对业主人员进行启发和诱导，使业主有条理、系统地描述需求，在调研过程中详细记录调研问题的答案。为何与销售经理提前介入，原因有二：1、防止销售经理对业主许诺过多的功能，增加项目的范围和难度；2、由于在业务调研阶段就已经接触了业主的相关干系人，便于以后项目实施过程的沟通工作。 

二、 加强组织领导，召开全市行政权力网上公开透明运行项目动员大会 

考虑到项目涉及到的部门多，业务面广，事项权力复杂，一些关键职能部门领导的抵触情绪等原因。在项目启动之初，通过与业主的主要负责人坦诚沟通后，业主方面成立以常务副市长为首的某某市行政权力网上公开透明运行领导小组，在项目动员大会上，业主要求各单位安排主要负责同志和办公室联络人到会签约“项目责任状”。在这次会议上，我作为项目经理向各项目干系人，就项目的主要项目目标、项目范围、范围管理计划、进度计划安排、沟通方式作了详细的介绍，希望各项目干系人能够积极配合我们的工作，我们将尽量满足他们的要求，方便大家今后的使用。 

三、 定义规划好项目范围，充分做好项目的范围管理工作 

在完成项目需求分析设计后，我们通过与项目干系人多次沟通后就项目所要达到的目标、项目需求、项目边界、项目的可交付物、产品接受标准、项目的约束条件、假设条件、项目组织结构、进度里程碑等一系列描述达成一致意见，并形成书面的项目范围说明书。 
另外我们还采用MS Project 2003作为项目管理工具。通过Project，我们建立了项目的WBS，对WBS的每个任务明确了其可交付物，对每一个任务我们都要求细化到每个人在一周内完成，保证每一项目都是可控的，可管理的。同时我们还制定了完善了项目范围管理计划、WBS字典、范围变更计划及规程，并交由业主、项目监理单位审核后，经业主签字确认保存形成项目范围基线。 

四、 开展项目评审会，做好范围变更控制工作 

我们在项目范围定义时确定好重要项目的里程碑。在每个里程碑结束后，我们邀请相关项目干系人参与项目的评审工作，目的是为了防止需求偏差、遗漏，以及收集新的需求，每次评审都给我们带来不少好的建议，让我们充分发现系统中的不足之处，发现了诸多业务上的偏差。会后我们按照项目范围变更计划，与业主、监理单位一起对这些建议进行逐一评估，将那些有益于项目建设的纳入范围管理中来，对有益于项目建设的建议分别处理对待：1、该建议实施起来比较简单，投入成本比较低廉的、对项目实施进度影响不大的按照范围变更的程序进行实施，同时对实施的结果进行跟踪；2、对花费成本较高，对项目实施进度影响较大的建议则记录在案，留于下一版本开发或作为附加项目开发。 

五、 落实项目小组责任，分别对待干系人的变更请求 

在项目实施过程中，由于项目小组成员和业主许多部门许多人有联系，他们是最经常会遇到范围更改请求的人，因此我们强调统一口径，不是任何人提出的请求都必须响应，必须经过项目发起人同意的变更才可以响应，同时项目小组成员不得随意对项目的进行“镀金”变更。 
另外我们还加强项目小组内部的沟通和交流，提高项目开发团队的开发效率，加强质量措施的落实，对成员的职责和绩效进行考核，杜绝由于项目质量问题或技术问题引起的不必要的范围变更。 

六、项目存在的不足与展望 

项目实施成功后，通过了省相关部门组织的验收，同时作为先进典型模式向 
周边市区推广，该系统至今运行良好。但是回顾过去，系统实施过程中也存在许多不足之处。 
1、 前期调研虽然做了认真细致的部署但是还不够充分，如没有考虑到 
垂直系统部门的权力事项，没有考虑到并联审批的情形等。在系统实际运行过程，没有考虑到乡镇实际困难，好多部门的信息化普及远远跟不上，相关的工作人员使用起来比较不熟练。 
2、 测试的时间太短，没有专门的测试人员，没有全面而系统的测试， 
所以系统交付之后，发现了不少问题，虽然没有威胁到系统的运行，但是作为项目经理，我觉得如果多给一些时间和人员，我做得更好。 
在以后的工作中，我将继续努力学习，总结经验和教育，为电子政务建设和企业信息化作出更多的贡献。

xn4545945收集整理，部分资料来源于信管网。