项目范围管理系统案例

1、围管理案例项目的国管理影响到信息系统项目的成功。在实践中，需求蔓延”是信息系统失败最 常见的原因之一，信息系统项目往往在项目启动、计划、执行、甚至收尾时不斷加入新功能，无论 是客户的要求还是项目实现人员对新技术的试验，都可能导致信息系统项目国的失控.从而使得信 息系 统项目无论在时间、资源和质量上都受到严重影响。2. 1案例一：围定义阅读以下关于信息系统项目管理过程中围管理方面问题的叙述，回答问题1至问题3。案例场景希賽信息技术（CSAI原本是一家专注于企业信息化的公司，在电子政务如火如荼的时 候，开始进军电子政务行业。在电子政务的市场中，接到的第一个项目是开发一套工商审批 系统。由于电子政务

2、要求，该系统涉及到两个互不联通的子网：政务网和政务外网。政务网 中储存着全部信息，其中包括部分信息：政务外网可以对公众开放，开放的信息必须得到授 权。系统要求在这两个子网中的合法用户都可以访问到被授权的信息，访问的信息必须是一 致可靠，政务网的信息可以发布到政务外网，政务外网的信息在经过审批后可以进入政务网 系统。工是该项目的项目经理，在捕获到这个需求后认为电子政务建设与企业信息化有很大的 不同，有其自身的特殊性，若照搬企业信息化原有的经验和方案必定会遭到惨敗。因此釆用 了严格瀑布模型，并专门招聘了滋悉网络互通互联的技术人员设计了解决方案，在经过严格 评审后实施。在项目交付吋，虽然系统完全满足

3、了性的要求，但用户对系统用户界面提出了 较大的异议，认为不符合政务信息系统的风格，操作也不够便捷，要求彻底更换。由于最初 设计的缺陷，系统表现层和逻辑层紧密耦合，导致70%的代码重写，而第二版的用户界面 仍不能满足灵终用户的要求，最终又重写的部分代码才通过脸收。由于系统的反复变更，项 目组成员产生了强烈的挫折感，士气低落，项目工期也超出原计划的100%。【问题1】请不超过300字，对工的行为进行点评？【问题2】请从项目国管理的角度找出该项目实沌过程中的主要管理问题？不超过200 字回答。【问题3】请结合你本人实际项目经脸，指出应如何避免类似问题？不超过200字回答。案例分析这是一个失败的项目，

4、工在项目管理中既有闪光点，也有失败的地方。但项目管理中的 任何差错都会影响项目的结果，而围管理的失误对项目的影响更为明显。模糊的项目国定5G 错误的工作分解、缺失的国确认和无力的围控制都将严重影响项目的结果。工对项目国有一定的把握。在国定艾中，工发现了不同行业间具有不同的特点，电子政 务行业对系统运行环境有着特殊的要求。根据国家对电子政务的要求，政务网与政务外网是 该行业一致的标准，这与企业信息化是完全不同的。工捕获到该需求，并对这个需求进行了 淸晰的定义，根扌居瀑布模型的要求，对设计和实现都进行了严格的控制，因此在系统交付时 完全满足了用户对性的要求。在这一点上，工是成功的。如果在国定狡时忽

5、略了行业标准， 项目育定会招致更大的失敗。但用户界面的风格和操作的便捷性也属于系统国的一部分。与系统运行环境一样，我们 通常称这类需求为隐性需求。这类需求往往不是由用户直接提出，而且受行业特点决定的围 所约束。对于电子政务来说，系统保持一致的风格非常重要。作为政府对公众开放的窗口而 言，并不需要很强的个性化，但一致的界面风格可以体现出政务的严肃性。考虑到全体民众 层次差异较大，大多数访问系统的用户一般都没有接受过系统使用的培训，操作的便捷性也 是政务系统必须实现的功能之一。很明显，对于这些系统的隐性需求工没有充分考虑.从而 导致一而再，再而三的变更。对于轶件项目，所有的需求都必须经过清晰的定艾

6、，这些需求都是项目围的一部分。工 仅仅注意了其中的一部分.而忽略了用户界面，最终导致项目的失败。对于电子政务信息系统，尤其是面向公众开放的信息系统，国定狡更加困难。这些系统 的灵终用户几乎不会参加需求开发的工作，他们的需求撷是间接的，通过政府部门的负责人 传递到项目纽。但最终用户的意见对项目的结果会有巨大的影响，这是就对围管理提出了更 高的要求。除了在国定狡方面的问题外，工在国确认和国控制方面也存在不小的失误。当系统第一 次更改时，就应该意识到系统界面风格和操作便捷性的重要性。这时应该清晰地定狡系统的 界面风格和操作风格，并设法进行确认。如果釆取了恰当的措施，第二次的变更是完全可以 避免的。在

7、刚刚进入一个陌生领域的时候，其中充满了各种各样的风险。隐性的行规和行业特点 都是项目国的风险。面对这些风险，即使再细致的调研也无法完全避免，也不能完整定狡系 统的围。因此可以考虑釆取原型法等方式来提前暴霜风险，减少风险带来的损失。因此在案例中， 工也没有进行充分的风险管理，釆用严格的瀑布揆型增加了风险发生后带来的损失。对于这个案例，缺乏良好的设计也是很明显的缺陷。用户界面中耦合了大量的业务逻辑， 这必然增加变更的代价，从而导致大部分代码电写。若在项目初期意识到界面变更的风险， 随之釆用良好的设计，将衷现层和业务逻辑彻底分开，系统变更的代价也会小得多。综上所述，项目经理工在整个案例中，针对国管理

8、做了一些工作，但不全面，在风险管 理和质量管理上也都存在缺陷。有了上面的分析，这道题就很容易作答。项目的闪光点在于对系统运行环境进行了淸晰 的定狡，并最终满足了用户的要求：但不充分的国定狡和国确认招致了项目的失败，而釆用 了抗风险能力较弱的瀑布模型和低质量的设计又雪上加霜，最终导致项目延期100%.因此第一题答案的要点就很明确了：(1) 工注意到了系统运行环境的特殊性，在良好设计和实现的情况下满足了用户的要求。(2) 工忽略了系统用户的潜在要求，在用户界面和操作的风格上国定艾不清晰，造成系 统交付的重大变更。(3) 工在第一次问題发生后仍没有对国进行有效的管理，造成了系统第二次的变更。(4)

9、工没有对用户界面是否能够满足要求的风险进行有效的管理，而是釆用了对风险适 应性较差的瀑布模型组织开发。(5) 工没有对设计质量进行有效的控制.造成表现层中耦合了业务逻辑，增加了修改的 代价。对于第二题，是在第一题的基础上考察对国管理的理解，因此可以忽略在其他领域的 问题。在国管理中主要包括如下容：(1) 围管理计划。(2) 围定义。(3) 工作分解。(4) 围确认。(5) 围控制。在本案例中，没有专门设计到国管理计划和工作分解的容。从表面上看，围定义存在明 显的缺陷。但案例中提到系统又发生了第二次变更，由此可见，工在围确认和围控制上也存 在不足。若在问题第一次出现时就进行有效的围确认和围控制，

10、则完全可以避免第二次的变 更。因此，第二题的答案要点如下：(1) 工没有挖掘到系统的全部隐性需求，缺乏精确的围定狡。(2) 在发生第一次变更时，工仍没有有效的围管理，从而造成系统的二次变更。(3) 重复的系统变更说明工对系统国控制不足，导致一而再再而三的反复。在完成第二题后，第三题就是水到渠成了，第三题的要点见参考答案，此处不再赞述。项目管理是一个系统工程，没有哪种单一的手段可以有效地改善项目，反之管理中的任 何疏忽都可能扌召致严重的后果，造成项目的失败。而软件项目的复杂性又决定了项目中的工 作环环相扣，问题也总是相互关联的。在发现问题后，也需要釆取多种手段才能彻底解决问 题。这对信息系统的项

11、目经理来说是莹大的挑战。参考答案【问题1】(1) 工注意到了系统运行环境的特殊性，在良好设计和实现的情况下满足了用户的要求。(2) 工忽略了系统用户的潜在要求，在用户界面和操作的风格上国定艾不清晰，造成系 统交付时的重大变更。(3) 工在第一次问题发生后仍没有对国进行有效的管理，造成了系统第二次的变更。(4) X没有对用户界面是否能够满足要求的风险进行有效的管理，而是釆用了对风险适 应性较差的瀑布模型组织开发。(5) 工没有对设计质量进行有效的控制，造成表现层中耦合了业务逻辑，增加了修改的 代价。【问题2】(1) 工没有挖掘到系统的全部隐性需求，缺乏精确的围定艾。(2) 在发生第一次变更时工仍

12、没有有效的围管理，从而造成系统的二次变更。(3) 重复的系统变更说明工对系统囤控制不足，导致一而再再而三的及复。【问题3】有效的国管理包括了从围定义到围控制等多方面的工作，每一项工作都是重要的。对于 本案例，要结合行业特点进行需求分析，挖掘系统潜在的需求，同时通过原型等方法来辅助 需求的定艾，避免国定狡不清晰的问题。在发生需求变更时需要进行有效的霸求控制，尽量在满足用户需求的前提下缩小需求 围，坚决避免需求的再次变更。2. 2案例二：工作要点阅读以下关于信息系统项目管理过程中项目国管理方面问题的叙述，回答问題1至问题2。2. 2.1案例场景M集因是希春信息技术(CSAI )多年的客户,CSAI

13、已经为其开发了多个信息系统。最近， M又和CSAI签订了新的开发合同，以扩充整个企业的信息化应用围，工担任该项目的项目 经理。工组织相关人员对该项目的工作进行了分解，并参考了公司同M曾经合作的项目， 评估得到项目，总工作量60人月，计划工期6个月。项目刚刚开始不久，工的高层经理S 找到工。S表示，由于公司运作的问题，需要在4个月完成项目，考虑到压缩工期的现实，可 以为该项目在增派两名开发人员。工认为，整个项目的工作莹是经过仔细分解后评估得到的， 评估过程中也参考了历史上与K企业合作的项目度董数据，该工作量是客观真实的。目祈项目已经开始，增派的人手还需要一定的时间熟悉项目情况，因此即使增派两人也

14、 很难在四个月完成。如果强行要求项目组成员通过加班等方式追逐4六个月以后，项目在没有增加人员的前提下顺利地完成，虽然比最初计划延长了半个月 的工期.但既达到了公司的要求，客户对灵终交付的系统也非常满意，项目组的成员也没有 感受到很大的压力。【问题1】请不超过500字，指出工是如何保证项目成功的？【问题2】请不超过500字，试结合案例指出项目国管理的工作要点？2. 2.2案例分析这是一个成功的项目管理案例，项目经理工有效的运用国管理，在不同的项目干系人中 达成一致，使项目的结果同吋满足了高层经理、客户和项目纽成员的要求。作为一个项目管理者，必须熟练掌握和应用项目管理九大领域涵盖的知识与技能，对于

15、 进行信息系统开发项目而言，国管理是其中最莹要的技能之一。软件项目的围主要是由系统需求构成的，而系统需求既是难以把握的，也是容易调整和 控制的。软件系统的需求来源于用户需求，在轶件项目目标是满足用户需求的情况下，对于 相同的用户价值可以定狡出不同的系统需求。举一个简单的例子，用户的需“解决口渴的问 题”，那么最简单的系统需求可以是遏上一杯水，复杂一些的可能是递上一杯热水，更复杂 的是递上一杯经过多层过滤的纯净水.当然也可以是打一桶虎跑泉的水，然后沏上一杯龙井 茶。用户当然希望用买矿泉水的钱换一杯正宗的龙井茶，但这样的项目围肯定会导致项目失 败。聪明的软件项目经理总是从囤菅理开始.先界定系统的边

16、界，然后再在明确的囤进行时 间、成本、风险等的管理。在项目中，时间、成本和囤构成了一个稳固的三角形，如图2-1所示。范*图21项H冃标三角形对于该三角形来说，任何一边都不可能孤立地改变。换句话说，我们不可能固定其中两 边而试图缩短第三边。其实这也是很容易理解的问题，如果项目需要做的东西已经确定（项 目围固定），项目的人员也已经确定（项目成本固定），那么项目需要的时间就也是固定的。 同理，已经固定的项目投入和项目吋间也只能做出固定的工作。对于这个三角形而言，非但 不可能孤立地改变菜一边的长短，就是三边的变化比例不一致也不可能。不成比例的变化与 孤立的改变某一边是一样的，都将破坏三角形的结构，违反

17、项目的客观规律，最终招致失败。 因此有效的围管理更像一门艺术，可以帮助项目经理在已经确定的时间和成本下完成项目目 标。在本案例中，高层经理S就提出了试图打破这个三角形的要求。他要求，项目组可以 增加部分资源，但要提前两个月完成。初一看，并没有在不增加投入的情况下要求项目提前 完成，似乎合请合理，比担既要马儿跑又不让马儿吃草的要求好得多但细一想，增加的资 源和提前的时间还是不成比例。项目经理工深知此中奥妙，因此在听到商层经理的要求后， 马上意识到这是一个不可能完成的任务。那么该如何解决这个矛盾呢？还是要从这个三角形入手。既然吋间和资源的变化已经打 破了项目规律，那么不妨根据新的时间和直源来重新划

18、定合理的项目国，保证项目的正常运 作。于是，工将这个项目拆分为两部分重新定狡这两部分的项目围，使每一部分的国都可 以与已经确定的资源和时间匹配起来，让项目的运作又重新满足了项目的客观规律，最终取 得了成功。在案例中，还有一些细节需要考生注意。工最初估算整个项目需要花费60人月的总工 作量，但如果考虑到拆分为两个阶段后会增加设计的复杂度，增加了额外的验收过程等因素， 超出原计划半个月是正常的。计划在6个月完成。在把项目拆分后，实际是用了 6个半月 的时间，也就是花费了 65人月完成了项目。对于上面介绍的时间、成本和围的关系而言. 仅是在理想请况下成立，即项目成员始终能以固定的成本完成固定的工作。

19、而在实际情况下， 项目的工期.复杂度等因素棘会对项目造成影响。在案例中，虽然看似两部分工作的总和等 于没有拆分前的项目，但这仅对于灵终目标而言，拆分后的项目增加了若干中间成果，项目 的围实际上还是扩大了。因为软件项目的国直接与需求相关，所以，很多人误认为控制项目囤就是控制需求，而 控制的方法就是减少需求的容。这种理解是完全错误的。囤控制体现在软件开发的各个阶段，很多围控制并非是针对客户的要求而进行的。例如, 本案例中，国控制就是针对离层经理的要求进行的。再比如，在设计中，我们既可以设计刚 刚够用甚至略有欠缺，通过牺牲系统的扩展性、维护性等方面来简化设计，也可以对系统进 行充分良好的设计，甚至可

20、能是过度设计。采取哪一种设计我略也是软件项目围管理的一部 分。项目经理可以根据目前的项目的目标与环境出发，综合考虑质量和成本的约束，制定明 确的项目国，保证项目的成功。根据笔者的经验，即吋需求已经呦定，通过有效的囤管理仍 能给项目带来很大的收益，可以在不牺牲软件质量的前提下通过围管理来降低项目成本，缩 短项目工期。上面主要针对工在围控制方面进行了分析，实际在整个案例中，工还进行了其他的围管 理工作。首先，在项目刚刚开始，工就对项目囲进行了定狡，进而划分了 WBS并对项目进行了 估算和计划。在S提出需要缩短工期的要求后，工首先进行了项目围的控制，缩小了第一 步需要完成的项目国。紧接着工又对两阶段

21、需要完成的项目国进行了重新定狡，制定了验收 标准。最后，工对重新定义的国进行了确认，与客户和离层经理达成一致。对于项目而言，仅仅管理囲仍不能保证项目的成功。在这个案例中，工也运用了其他的 管理手段。其中包括，工对项目进行了估算，这属于项目时间管理的畴；工协调了多个项目 干系人之间的矛盾，这属于沟通管理的畴。有了上面的分析，这道考題的答案也就很清晰了。2. 2.3瘙考答案【问题1】(1) 工首先对最初的项目围进行了淸晰的定艾，并根据定狡对工作进行了分解，制定了 WBS。(2) 工对项目进行了估算，且仕算结果真实可信，对项目工作量有量化的把握。(3) 在出现新的项目目标后，工对项目进行了国控制，缩

22、小了第一阶段实现的围。(4) X对重新定义的项目国进行了确认，与鬲层经理和客户达成一致。(5) 工对项目进行了沟通管理，协调了多个项目千系人之间的矛盾。【问题2】项目围菅理的要点：(1) 围管理计划。(2) 围定义。(3) 工作分解。围确认。(5)围控制。在本案例中，工首先进行了囤定狡和工作分解，得到了淸晰的项目囤；在出现新的项目 目标后.工进行了国控制，重新定狡了两个阶段的项目围；最后，工将莹新定狡的囤与项目 干系人进行了确认。2. 3案例三：围确认阅读以下关于信息系统项目管理过程中项目國管理方面问题的叙述，回答问题1至问题32. 3.1案例场景希赛信息技术(CSAI )刚刚和M签订了一份新

23、的合同，合同的主要容是处理公司以前为 M公司开发的信息系统的升级工作。升级后的系统可以满足M公司新的业务流程和国。由 于是一个现有系统的升级，项目经理工特意请来了原系统的需求调研人员工担任该项目的需 求调研负责人。在工的帮助下，很快地完成了需求开发的工作并进入设计与编码。由于M公 司的业务非常緊忙，M公司的业务代表没有足够的时间投入到项目中，确认需求的工作一拖 再拖。工认为，双方已经建立了密切的合作关系，工也参加了原系统的需求开发，对业务的 系统比较熟悉，因此定狡的需清晰的。故工并没有催促业务代表在需求说明书中签字。进入编码阶段后，工因故移民加拿大，需要离开项目组。工考虑到系统需求已经定义，

24、项目已经进入编码期，工的离职虽然会对项目造成一定的影响，但影响较小.因此很快办理 好了工的离职手续。在系统交付的时候，M公司的业务代表认为已经提出的需求很多没有实现，实现的需求 也有很多不能满足业务的要求，必须全部实现这些需求后才能验收。此时工已经不在项目纽， 没有人能够淸晰地解释需求说明书。最终系统需求发生重大变更，项目延期超过50%, M的 业务代表也因为系统的延期表示了强烈的不满。【问题1】请以400字对工在项目管理工作中的行为进行点评。【问题2】请从项目围管理的角度找出该项目实施过程中的问题，以500字回答。【问题3】请结合你本人项目经验，谈谈应如何避免类似的问题，以500字回答。2.

25、 3. 2案例分析这是一个失败的软件项目，与很多失敗的软件项目一样，在系统需求上我了跟头。开 发与定艾软件系统的需求在整个软件开发过程中是置重要的一环，这是每个从事信息系统建 设的项目经理都清楚的事情，但往往又因为一时的疏忽而造成需求的重大缺陷，最终导致项 目的失败。案例中的项目经理工就是既重视需求又没有控制好需求的一个例子。在案例中，工接手了一个系统升级的软件项目。对于这样的项目，首先需要熟悉原有的 系统，然后才能谈升级的问题。因此工专门找到了原系统的需求调研人员工来解决新系统的 需求问題。这无疑是一个很好的办法，可以快速准确地把握新系统的需求。从这一点上来说，工是 成功的，找到了合适的资源

26、进行需求的开发与定狡。工也没有让工失望，很快就整理出了新 系统的需求，并进入了设计和编码阶段，除了客户太忙没有时间确认需求外，一切尽在工的 掌握之中。这是一个灿烂的开端，如果一切顺利的话，项目的成功也就是早晚的事情。就如 同大多数经典的悲剧故事一样，故事的序幕是美好的。晴朗的天空飘来一块乌云，工要移民加拿大。不过仅仅是一片乌云而已，并没有下起雨 来。开发出的需求都已经过设计，一些编码工作也已经开始，工的工作已近圆满完成，毕竞. 一些细枝末节的问题还可以同客户直接沟通。经过项目组努力，项目终于完成开发，准备发布了。这时，乌云开始下雨，问题爆发了。 客户不认可项目组的工作，认为很多需求没有实现，实

27、现的功能也与需求不符。谁是这个项目纽的罪人呢？工？还是工？换一个思路考虑一下，如果工没有离开项目 组，结果又会是什么样呢？客户会因为工还在项目组就认可这个系统吗？很显然.不会。至 多可以在双发的协商下少一些变更，项目延期不是50汕而是30%而已。如果非要区分50% 和30%的区别，也不过是五十步笑百步而已。从项目菅理的角皮来说，项目围直接决定了工作童和工作目标，所以项目经理必须管理 项目的国。在国管理中.围定艾、国确认和国控制又是就核心的三项活动，缺一不可。围定 艾是基础的活动，不进行国定狡就不能进行国确认和国控制。围确认则是基线化已定艾的国， 是围控制的依据。围控制的作用在于减少变更，保持项

28、目国的稳定性。在案例中，由于工没有进行国确认，最后的围控制也就变成了无本之木，控制过程肯定 变成了讨价还价，失去本身的意狡。在软件系统的开发中，系统需求就是项目的围。从软件诞生至今的几十年中.人们探索 出了很多获取系统需求的方法，但是熟悉软件开发的人都知道，无论哪种方法都不可能定狡 出完美无误的需求，需求中的缺陷必然存在，无法完全避免。因此需求确认或者说是国确认 就显得更为重要。有人可能会说，很难说服客户在需求上签字，很难让客户为需求的缺陷负责。以现在软 件行业的情况，这种说法是不无道理的。让客户在需求上签字很困难，但并不等于就不需要 进行围确认，而且围确认的方法也不仅仅只有需求签字这一种方法。召集客户的业务代表对 需求