阅读以下关于信息系统项目管理过程中项目范围管理方面问题的叙述，回答问题1至问题2。

    M集团是信管信息技术有限公司(CNITPM )多年的客户，CNITPM已经为其开发了多个信息系统。最近，M又和CNITPM签订了新的开发合同，以扩充整个企业的信息化应用范围，张工担任该项目的项目经理。张工组织相关人员对该项目的工作进行了分解，并参考了公司同M曾经合作的项目，评估得到项目，总工作量60人月，计划工期6个月。项目刚刚开始不久，张工的高层经理S找到张工。S表示，由于公司运作的问题，需要在4个月内完成项目，考虑到压缩工期的现实，可以为该项目在增派两名开发人员。张工认为，整个项目的工作量是经过仔细分解后评估得到的，评估过程中也参考了历史上与K企业合作的项目度量数据，该工作量是客观真实的。目前项目已经开始，增派的人手还需要一定的时间熟悉项目情况，因此即使增派两人也很难在四个月内完成。如果强行要求项目组成员通过加班等方式追逐4个月完成的目标，肯定会降低项目的质量，造成用户不满意。因此，张工提出将整个项目分为两部分实现，第一部分使用三个半月的时间，第二部分使用三个月的时间，分别制定出两部分的验收标准，这样不增派开发人员也可以完成。高层经理认为该方案可以满足        公司的运作要求，用户也同意按照这种方案进行实施。六个月以后，项目在没有增加人员的前提下顺利地完成，虽然比最初计划延长了半个月的工期，但既达到了公司的要求，客户对最终交付的系统也非常满意，项目组的成员也没有感受到很大的压力。

    【问题1】(10分)

    请不超过500字，指出张工是如何保证项目成功的？

    【问题2】(15分)

    请不超过500字，试结合案例指出项目范围管理的工作要点？

    这是一个成功的项目管理案例，项’目经理张工有效的运用范围管理，在不同的项目干系人中达成一致，使项目的结果同时满足了高层经理、客户和项目组成员的要求。

    作为一个项目管理者，必须熟练掌握和应用项目管理九大领域涵盖的知识与技能，对于进行信息系统开发项目而言，范围管理是其中最重要的技能之一。

    软件项目的范围主要是由系统需求构成的，而系统需求既是难以把握的，也是容易调整和控制的。软件系统的需求来源于用户需求，在软件项目目标是满足用户需求的情况下，对于相同的用户价值可以定义出不同的系统需求。举一个简单的例子，用户的需求是“解决口渴的问题”，那么最简单的系统需求可以是递上一杯水，复杂一些的可能是递上一杯热水，更复杂的是递上一杯经过多层过滤的纯净水，当然也可以是打一桶虎跑泉的水，然后沏上一杯龙井茶。

    用户当然希望用买矿泉水的钱换一杯正宗的龙井茶，但这样的项目范围肯定会导致项目失败。聪明的软件项目经理总是从范围管理开始，先界定系统的边界，然后再在明确的范围内进行时间、成本、风险等的管理。

    在项目中，时间、成本和范围构成了一个稳固的三角形，如图2-1所示。

    对于该三角形来说，任何一边都不可能孤立地改变。换句话说，我们不可能固定其中两边而试图缩短第三边。其实这也是很容易理解的问题，如果项目需要做的东西已经确定(项目范围固定)，项目的人员也已经确定(项目成本固定)，那么项目需要的时间就也是固定的。同理，已经固定的项目投入和项目时间也只能做出固定的工作。对于这个三角形而言，非但不可能孤立地改变某一边的长短，就是三边的变化比例不一致也不可能。不成比例的变化与孤立的改变某一边是一样的，都将破坏三角形的结构，违反项目的客观规律，最终招致失败。因此有效的范围管理更像一门艺术，可以帮助项目经理在已经确定的时间和成本下完成项目目标。

    在本案例中，高层经理S就提出了试图打破这个三角形的要求。他要求，项目组可以增加部分资源，但要提前两个月完成。初一看，并没有在不增加投入的情况下要求项目提前完成，似乎合情合理，比起既要马儿跑又不让马儿吃草的要求好得多，但细一想，增加的资源和提前的时间还是不成比例。项目经理张工深知此中奥妙，因此在听到高层经理的要求后，马上意识到这是一个不可能完成的任务。

    那么该如何解决这个矛盾呢？还是要从这个三角形入手。既然时间和资源的变化已经打破了项目规律，那么不妨根据新的时间和资源来重新划定合理的项目范围，保证项目的正常运作。于是，张工将这个项目拆分为两部分，重新定义这两部分的项目范围，使每一部分的范围都可以与已经确定的资源和时间匹配起来，让项目的运作又重新满足了项目的客观规律，最终取得了成功。

    在案例中，还有一些细节需要考生注意。张工最初估算整个项目需要花费60人月的总工作量，但如果考虑到拆分为两个阶段后会增加设计的复杂度，增加了额外的验收过程等因素，超出原计划半个月是正常的。计划在6个月内完成。在把项目拆分后，实际是用了6个半月的时间，也就是花费了65人月完成了项目。对于上面介绍的时间、成本和范围的关系而言，仅是在理想情况下成立，即项目成员始终能以固定的成本完成固定的工作。而在实际情况下，项目的工期、复杂度等因素都会对项目造成影响。在案例中，虽然看似两部分工作的总和等于没有拆分前的项目，但这仅对于最终目标而言，拆分后的项目增加了若干中间成果，项目的范围实际上还是扩大了。

    因为软件项目的范围直接与需求相关，所以，很多人误认为控制项目范围就是控制需求，而控制的方法就是减少需求的内容。这种理解是完全错误的。

    范围控制体现在软件开发的各个阶段，很多范围控制并非是针对客户的要求而进行的。例如，本案例中，范围控制就是针对高层经理的要求进行的。再比如，在设计中，我们既可以设计刚刚够用甚至略有欠缺，通过牺牲系统的扩展性、维护性等方面来简化设计，也可以对系统进行充分良好的设计，甚至可能是过度设计。采取哪一种设计策略也是软件项目范围管理的一部分。项目经理可以根据目前的项目的目标与环境出发，综合考虑质量和成本的约束，制定明确的项目范围，保证项目的成功。根据笔者的经验，即时需求已经确定，通过有效的范围管理仍能给项目带来很大的收益，可以在不牺牲软件质量的前提下通过范围管理来降低项目成本，缩短项目工期。

    上面主要针对张工在范围控制方面进行了分析，实际在整个案例中，张工还进行了其他的范围管理工作。

    首先，在项目刚刚开始，张工就对项目范围进行了定义，进而划分了WBS并对项目进行了估算和计划。在S提出需要缩短工期的要求后，张工首先进行了项目范围的控制，缩小了第一步需要完成的项目范围。紧接着张工又对两阶段需要完成的项目范围进行了重新定义，制定了验收标准。最后，张工对重新定义的范围进行了确认，与客户和高层经理达成一致。

    对于项目而言，仅仅管理范围仍不能保证项目的成功。在这个案例中，张工也运用了其他的管理手段。其中包括，张工对项目进行了估算，这属于项目时间管理的范畴；张工协调了多个项目干系人之间的矛盾，这属于沟通管理的范畴。

    有了上面的分析，这道考题的答案也就很清晰了。

    【问题1】(10分)

    (1)张工首先对最初的项目范围进行了清晰的定义，并根据定义对工作进行了分解，制定了WBS。

    (2)张工对项目进行了估算，且估算结果真实可信，对项目工作量有量化的把握。(2分)

    (3)在出现新的项目目标后，张工对项目进行了范围控制，缩小了第一阶段实现的范围。(2分)

    (4)张工对重新定义的项目范围进行了确认，与高层经理和客户达成一致。(2分)

    (5)张工对项目进行了沟通管理，协调了多个项目干系人之间的矛盾。(2分)

    【问题2】(15分)

    项目范围管理的要点：

    (1)范围管理计划。(2分)

    (2)范围定义。(2分)

    (3)工作分解。(2分)

    (4)范围确认。(2分)

    (5)范围控制。(2分)

    在本案例中，张工首先进行了范围定义和工作分解，得到了清晰的项目范围；在出现新的项目目标后，张工进行了范围控制，重新定义了两个阶段的项目范围；最后，张工将重新定义的范围与项目干系人进行了确认。(5分)

   阅读以下关于信息系统项目管理过程中项目范围管理方面问题的叙述，回答问题1至问题3.

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

    进入编码阶段后，李工因故移民加拿大，需要离开项目组。张工考虑到系统需求已经定义，项目已经进入编码期，李工的离职虽然会对项目造成一定的影响，但影响较小，因此很快办理好了李工的离职手续。

    在系统交付的时候，M公司的业务代表认为已经提出的需求很多没有实现，实现的需求也有很多不能满足业务的要求，必须全部实现这些需求后才能验收。此时李工已经不在项目组，没有人能够清晰地解释需求说明书。最终系统需求发生重大变更，项目延期超过50%, M的业务代表也因为系统的延期表示了强烈的不满。

 【问题1】(8分)

请以400字对张工在项目管理工作中的行为进行点评。

    【问题2】(9分)

    请从项目范围管理的角度找出该项目实施过程中的问题，以500字内回答。

    【问题3】(8分)

    请结合你本人项目经验，谈谈应如何避免类似的问题，以500字内回答。

    这是一个失败的软件项目，与很多失败的软件项目一样，在系统需求上栽了跟头。开发与定义软件系统的需求在整个软件开发过程中是最重要的一环，这是每个从事信息系统建设的项目经理都清楚的事情，但往往又因为一时的疏忽而造成需求的重大缺陷，最终导致项目的失败。案例中的项目经理张工就是既重视需求又没有控制好需求的一个例子。·

    在案例中，张工接手了一个系统升级的软件项目。对于这样的项目，首先需要熟悉原有的系统，然后才能谈升级的问题。因此张工专门找到了原系统的需求调研人员李工来解决新系统的需求问题。这无疑是一个很好的办法，可以快速准确地把握新系统的需求。从这一点上来说，张工是成功的，找到了合适的资源进行需求的开发与定义。李工也没有让张工失望，很快就整理出了新系统的需求，并进入了设计和编码阶段，除了客户太忙没有时间确认需求外，一切尽在张工的掌握之中。这是一个阳光灿烂的开端，如果一切顺利的话，项目的成功也就是早晚的事情。就如同大多数经典的悲剧故事一样，故事的序幕是美好的。

    晴朗的天空飘来一块乌云，李工要移民加拿大。不过仅仅是一片乌云而已，并没有下起雨来。开发出的需求都已经过设计，一些编码工作也已经开始，李工的工作已近圆满完成，毕竟，一些细枝末节的问题还可以同客户直接沟通。

    经过项目组努力，项目终于完成开发，准备发布了。这时，乌云开始下雨，问题爆发了。客户不认可项目组的工作，认为很多需求没有实现，实现的功能也与需求不符。

    谁是这个项目组的罪人呢？李工？还是张工？换一个思路考虑一下，如果李工没有离开项目组，结果又会是什么样呢？客户会因为李工还在项目组就认可这个系统吗？很显然，不会。至多可以在双发的协商下少一些变更，项目延期不是50%,而是30％而已。如果非要区分50％和30％的区别，也不过是五十步笑百步而已。

    从项目管理的角度来说，项目范围直接决定了工作量和工作目标，所以项目经理必须管理项目的范围。在范围管理中，范围定义、范围确认和范围控制又是最核心的三项活动，缺一不可。范围定义是基础的活动，不进行范围定义就不能进行范围确认和范围控制。范围确认则是基线化已定义的范围，是范围控制的依据。范围控制的作用在于减少变更，保持项目范围的稳定性。在案例中，由于张工没有进行范围确认，最后的范围控制也就变成了无本之木，控制过程肯定变成了讨价还价，失去本身的意义。

    在软件系统的开发中，系统需求就是项目的范围。从软件诞生至今的几十年中，人们探索出了很多获取系统需求的方法，但是熟悉软件开发的人都知道，无论哪种方法都不可能定义出完美无误的需求，需求中的缺陷必然存在，无法完全避免。因此需求确认或者说是范围确认就显得更为重要。

    有人可能会说，很难说服客户在需求上签字，很难让客户为需求的缺陷负责。以现在软件行业的情况，这种说法是不无道理的。让客户在需求上签字很困难，但并不等于就不需要进行范围确认，而且范围确认的方法也不仅仅只有需求签字这一种方法。召集客户的业务代表对需求进行评审、详细记录最原始的调研材料，让客户确认调研报告、采用迭代开发逐步确认系统需求，都是可以采用的方法。这些方法虽然没有直接确认需求分析报告，但至少可以让现有需求在项目组和客户之间达成一致，提供范围控制的基准，一样可以达到范围确认的目的。

    再回到这个案例，项目经理张工乐观认为李工开发的需求没有什么问题，也误认为双方已经有良好的合作，在不紧逼要求客户代表签字显得不近人情，于是就抱着侥幸信息进入了开发。然而最终的结果是，项目延期严重，业务代表反而更不满意，张工也要承担项目延期造成的成本增加的责任。

    有了上面的分析，后面问题的答案就不难得出。首先看第一个问题，对张工的行为进行点评。前面已经提到，张工注意到了需求的问题，专门找到了原系统需求负责人李工进行需求开发，这是对项目有利的一面。但由于缺少需求评审和确认的过程，造成需求中的缺陷没有被及时发现，系统需求没有与客户确认，造成缺少需求控制的基准，最终导致需求的重大变更。

     对于第二题，联系范围管理的知识，我们不难发现张工在范围确认和范围控制中都有重大的缺陷，在范围定义中也由于缺乏评审造成需求的质量问题。

    在完成第二题后，第三题就水到渠成了，第三题的要点见参考答案，此处不再赘述。

    【问题1】(8分)

    (1)张工为了更明确地把握系统需求，聘请了原系统的需求调研人员李工，提高了需求定义的效率和质量。(2分)

    (2)张工没有对李工开发的系统需求进行评审和复查，从而使得需求的缺陷没有被及时发现。

    (3)张工没有要求用户对已经定义的需求进行确认，从而导致需求理解的偏差。(2分)

    (4)张工对需求的不能进行缺乏有效控制，最终造成项目延期50%.(2分)

    【问题2】(9分)

    该项目实施过程中的主要问题包括：

    (1)在范围定义中，张工没有对李工定义的需求进行评审，造成需求中的质量缺陷没有被及时发现。(3分)

    (2)在范围确认中，张工没有主动地要求用户对需求进行确认。(3分)

    (3)在范围控制中，张工无法进行有效的范围控制，最终造成了重大的需

求变更。(3分)

    【问题3】(8分)

    对于本案例，项目经理需要对需求定义的结果进行质量控制，采取评审等方式减少需求中的问题。对已经定义的需求需要与用户进行确认，保证双方理解的一致。在发生需求变更时，也应该采取灵活的手段，在满足用户需求的前提下，尽量减少需求变更的范围。