阅读以下关于信息系统项目管理过程中项目范围管理方面问题的叙述，回答问题1至问题3.
案例场景
某信息技术有限公司(CSAI)刚刚和M签订了一份新的合同，合同的主要内容是处理公司以前为M公司开发的信息系统的升级工作。升级后的系统可以满足M公司新的业务流程和范围。由于是一个现有系统的升级，项目经理张工特意请来了原系统的需求调研人员李工担任该项目的需求调研负责人。在李工的帮助下，很快地完成了需求开发的工作并进入设计与编码。由于M公司的业务非常繁忙，M公司的业务代表没有足够的时间投入到项目中，确认需求的工作一拖再拖。张工认为，双方已经建立了密切的合作关系，李工也参加了原系统的需求开发，对业务的系统比较熟悉，因此定义的需求是清晰的。故张工并没有催促业务代表在需求说明书中签字。
进入编码阶段后，李工因故移民加拿大，需要离开项目组。张工考虑到系统需求已经定义，项目已经进入编码期，李工的离职虽然会对项目造成一定的影响，但影响较小，因此很快办理好了李工的离职手续。
在系统交付的时候，M公司的业务代表认为已经提出的需求很多没有实现，实现的需求也有很多不能满足业务的要求，必须全部实现这些需求后才能验收。此时李工已经不在项目组，没有人能够清晰地解释需求说明书。最终系统需求发生重大变更，项目延期超过50%,M的业务代表也因为系统的延期表示了强烈的不满。
【问题1】(8分)
请以400字对张工在项目管理工作中的行为进行点评。
【问题2】（9分）
请从项目范围管理的角度找出该项目实施过程中的问题，以500字内回答。
【问题3】(8分)
请结合你本人项目经验，谈谈应如何避免类似的问题，以500字内回答。
参考答案： 【问题1】(8分）
(1)张工为了更明确地把握系统需求，聘请了原系统的需求调研人员李工，提高了需求定义的效率和质量（2分）
(2)张工没有对李工开发的系统需求进行评审和复查，从而使得需求的缺陷没有被及时发现。（2分）
(3)张工没有要求用户对已经定义的需求进行确认，从而导致需求理解的偏差。（2分）
(4)张工对需求的不能进行缺乏有效控制，最终造成项目延期50%.(2分）
【问题2】（9分）
该项目实施过程中的主要问题包括：
(1)在范围定义中，张工没有对李工定义的需求进行评审，造成需求中的质量缺陷没有被及时发现。（3分）
(2)在范围确认中，张工没有主动地要求用户对需求进行确认。（3分）
(3)在范围控制中，张工无法进行有效的范围控制，最终造成了重大的需求变更。(3分）
【问题3】(8分）
对于本案例，项目经理需要对需求定义的结果进行质量控制，采取评审等方式减少需求中的问题。对已经定义的需求需要与用户进行确认，保证双方理解的一致。在发生需求变更时，也应该采取灵活的手段，在满足用户需求的前提下，尽量减少需求变更的范围。
解题思路： 案例分析
这是一个失败的软件项目，与很多失败的软件项目一样，在系统需求上栽了跟头。开发与定义软件系统的需求在整个软件开发过程中是最重要的一环，这是每个从事信息系统建设的项目经理都清楚的事情，但往往又因为一时的疏忽而造成需求的重大缺陷，最终导致项目的失败。案例中的项目经理张工就是既重视需求又没有控制好需求的一个例子。
在案例中，张工接手了一个系统升级的软件项目。对于这样的项目，首先需要熟悉原有的系统，然后才能谈升级的问题。因此张工专门找到了原系统的需求调研人员李工来解决新系统的需求问题。这无疑是一个很好的办法，可以快速准确地把握新系统的需求。从这一点上来说，张工是成功的，找到了合适的资源进行需求的开发与定义。李工也没有让张工失望，很快就整理出了新系统的需求，并进入了设计和编码阶段，除了客户太忙没有时间确认需求外，一切尽在张工的掌握之中。这是一个阳光灿烂的开端，如果一切顺利的话，项目的成功也就是早晚的事情。就如同大多数经典的悲剧故事一样，故事的序幕是美好的。
晴朗的天空飘来一块乌云，李工要移民加拿大。不过仅仅是一片乌云而已，并没有下起雨来。开发出的需求都已经过设计，一些编码工作也已经开始，李工的工作已近圆满完成，毕竟，一些细枝末节的问题还可以同客户直接沟通。
经过项目组努力，项目终于完成开发，准备发布了。这时，乌云开始下雨，问题爆发了。客户不认可项目组的工作，认为很多需求没有实现，实现的功能也与需求不符。
谁是这个项目组的罪人呢？李工？还是张工？换一个思路考虑一下，如果李工没有离开项目组，结果又会是什么样呢？客户会因为李工还在项目组就认可这个系统吗？很显然，不会。至多可以在双发的协商下少一些变更，项目延期不是50%,而是30%而已。如果非要区分50%和30%的区别，也不过是五十步笑百步而已。
从项目管理的角度来说，项目范围直接决定了工作量和工作目标，所以项目经理必须管理项目的范围。在范围管理中，范围定义、范围确认和范围控制又是最核心的三项活动，缺一不可。范围定义是基础的活动，不进行范围定义就不能进行范围确认和范围控制。范围确认则是基线化已定义的范围，是范围控制的依据。范围控制的作用在于减少变更，保持项目范围的稳定性。在案例中，由于张工没有进行范围确认，最后的范围控制也就变成了无本之木，控制过程肯定变成了讨价还价，失去本身的意义。
在软件系统的开发中，系统需求就是项目的范围。从软件诞生至今的几十年中，人们探索出了很多获取系统需求的方法，但是熟悉软件开发的人都知道，无论哪种方法都不可能定义出完美无误的需求，需求中的缺陷必然存在，无法完全避免。因此需求确认或者说是范围确认就显得更为重要。
有人可能会说，很难说服客户在需求上签字，很难让客户为需求的缺陷负责。以现在软件行业的情况，这种说法是不无道理的。让客户在需求上签字很困难，但并不等于就不需要进行范围确认，而且范围确认的方法也不仅仅只有需求签字这一种方法。召集客户的业务代表对需求进行评审、详细记录最原始的调研材料，让客户确认调研报告、采用迭代开发逐步确认系统需求，都是可以采用的方法。这些方法虽然没有直接确认需求分析报告，但至少可以让现有需求在项目组和客户之间达成一致，提供范围控制的基准，一样可以达到范围确认的目的。
再回到这个案例，项目经理张工乐观认为李工开发的需求没有什么问题，也误认为双方已经有良好的合作，在不紧逼要求客户代表签字显得不近人情，于是就抱着侥幸信息进入了开发。然而最终的结果是，项目延期严重，业务代表反而更不满意，张工也要承担项目延期造成的成本增加的责任。
有了上面的分析，后面问题的答案就不难得出。首先看第一个问题，对张工的行为进行点评。前面已经提到，张工注意到了需求的问题，专门找到了原系统需求负责人李工进行需求开发，这是对项目有利的一面。但由于缺少需求评审和确认的过程，造成需求中的缺陷没有被及时发现，系统需求没有与客户确认，造成缺少需求控制的基准，最终导致需求的重大变更。
对于第二题，联系范围管理的知识，我们不难发现张工在范围确认和范围控制中都有重大的缺陷，在范围定义中也由于缺乏评审造成需求的质量问题。
在完成第二题后，第三题就水到渠成了，第三题的要点见参考答案，此处不再赘述。>>>立即刷题