项目范围管理案例

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