C、某客户要求“方便”的查询设备位置，于是开发人员设计了一个界面可以按各种条件来查询设备的所在位置。当移交系统时，客户发现与预想的不一样，原来客户的“方便”是指用图形化界面的方式直观的表现。项目组只好延期几天来开发这一功能。
3、 项目组人员不能区分客户真正需求和镀金需求，全盘接受客户的变更请求。当然这样做也是为让客户满意，但是实际上不一定能达到目的。
三、 范围变更管理
首先，签订合同时就需要明确定义项目的范围，这当然需要熟悉信息系统集成项目的人员参加合同谈判。合同中定义好的项目范围可以为以后各项工作的开展奠定深厚的基础。
其次，合同中的项目范围应该还只是粗线条的约定，必须进行细化和深入。编制范围说明书和范围管理计划是其中重要的部分。范围说明书应该包括项目论证、产品简介、主要可交付物、验收标准等。另外必须为项目组预留足够的时间来进行详细需求的调研，并提出工作分解结构（WBS）和需求分析报告。WBS可以为项目执行绩效评测和项目控制提供一个基准。
在系统需求分析阶段，项目组成员和客户的深入交流是项目成功的关键。但是由于双方的误解通常使交流难以进行。AMT的刘立军先生总结的Why、What、How方式可以非常有效的使沟通顺畅。简单的说，在项目初期，项目经理首先需要考察客户做这个项目有什么用处，就是“为什么”，这样才能真正从客户的角度来考虑系统的设计；接下来需要总结出整个项目是“做什么”，并能概括出各个子任务，让开发人员对项目内容的大方向有很好的把握；最重要的当然是“怎么做”了，对信息系统集成项目而言，这个阶段多花点时间绝对值得。其中也有些小技巧：需求分析报告应以客户认为易于翻阅和理解的方式进行编写，同时也要有助于开发人员开发出真正需要的系统；项目组成员最好就需求分析报告给客户详细的讲述，并达成共识，沟通手段在这里很重要；另外，需求确认之后，最好让客户方管理层书面签字，作为终止需求分析过程的标志，但是绝不是作为拒绝范围变更的手段。
四、 行之有效的变更控制
一个项目的范围计划可能制订的非常好，但是想不出现任何改变几乎是不可能的。项目经理和项目小组必须意识到范围变更本身并没有什么不对，事实上很多时候这会让你的系统更健壮、更实用。客户通常不能一开始就确定所有需求，而且情况会随时间而变化，如果不能包容变更，那么最终解决方案可能就达不到应有的价值。
但是如果变更失控，后果也非常严重，甚至于导致整个项目的失败。根据1995年斯坦迪什公司的研究结果，最可能引起IT项目失败的前三个因素分别为：缺乏用户参与、不完整的要求和说明、易变的要求和说明，这几个因素都直接或间接与范围变更管理有关。
因此，必须进行范围变更管理。潘东先生认为：“变更控制的目的不是控制变更的发生，而是对变更进行管理，确保变更有序进行。”
此文章共有4页 上一页 1 2 3 4 下一页
|
Leadge.com首页 > 知识库 
