信息系统集成项目中的范围变更管理？
关键词:IT范围管理变更控制
一.前言
范围管理是项目管理中的一个特殊词汇。其主要任务是定义项目包含所有需要完成的工作，并指导其他项目管理工作，以保证项目所有过程的顺利完成。
一般来说，当项目范围确定后，项目的工作边界就确定了，项目的项目目标和主要交付成果也就确定了。对于信息系统集成项目来说，如果项目范围不能明确界定和有效控制，将会产生非常严重的后果。比如，项目的实际需求包括:客户因无法提供完整详细的描述而未能明确界定范围，导致项目的最终解决方案不可用；另一方面，项目范围的扩大或频繁变化会影响项目成本和进度。
根据笔者负责和参与多个项目的实践经验，范围扩散是一件非常可怕的事情，客户总想在一个系统中实现自己的所有需求，导致项目结果臃肿而不切实际。客户有一个想法是非常不可取的:“(开发者)做好了就放在那里，即使不用。万一他们以后用上了呢？”。此外，在项目过程中，尤其是项目后期，客户不断提出修改移交系统的建议，有时甚至刚重新设计就开始改，客户要求改回来或者换另一个型号。“无底洞”是国内大部分项目经理在信息系统集成项目中的相同感受。
“为什么项目总是没完没了？!"
二、原因分析项目经理作为项目的承担者，利用有限的资源，在规定的时间内保质保量完成项目，让客户和公司都满意是最终目标。
但是满足客户就是满足客户无止境的需求？这会导致项目最终失败吗？我们应该分析范围变更中出现问题的根本原因。
1.签订合同时缺乏熟悉信息系统集成项目的人员，导致项目目标描述不清，给后期实施带来混乱。
2.客户和项目组都希望把项目做好。但是，客户可能对信息系统项目缺乏全面的了解，项目团队也没有完全了解客户需求的细节，对实现需求的途径的理解也存在差异。项目初期，双方都没有意识到沟通不畅，导致系统移交时问题暴露。
列举作者遇到的几个具体问题:
a、IT项目的客户往往认为电脑是万能的。有了它们，他们只需要输入几个参数，什么都不用担心。其实任何技术都有局限性。
b、某客户知道自己需要一款库存管理软件，但是是引入新的库存管理思路还是沿用当前的模式还没有考虑，开发人员已经到位，所以要求项目组先按照当前的模式来做。后来客户想改变管理模式，问题就出现了。设计变更导致大量模块重写，工期不可避免延长。
c，一个客户要求“方便”的查询设备的位置，于是开发者设计了一个根据各种条件查询设备位置的界面。在移交系统时，客户发现与他预期的不一样。原客户的“方便”是指以图形界面的形式直观表现。项目组不得不将该功能的开发推迟几天。项目经理联盟文章，深度讨论。
3.项目组成员分不清客户的真实需求和镀金需求，完全接受客户的变更请求。当然这也是为了满足客户，但实际上未必能达到目的。
三、范围变更管理首先需要在签订合同时明确项目的范围，这当然需要熟悉信息系统集成项目的人参与合同谈判。合同中明确的项目范围可以为以后的工作打下坚实的基础。
其次，合同中的工程范围应该只是一个粗略的约定，必须细化和深化。范围规范和范围管理计划的编制是其中的一个重要部分。范围声明应包括项目演示、产品介绍、主要交付成果、验收标准等。此外，必须为项目团队预留足够的时间来调查详细的需求，并提出工作分解结构(WBS)和需求分析报告。WBS可以为项目绩效评估和项目控制提供一个基准。
在系统需求分析阶段，项目团队成员与客户的深入沟通是项目成功的关键。但是，双方的误解通常会导致沟通困难。AMT的刘立军先生总结的为什么、做什么、怎么做，可以非常有效地让沟通变得顺畅。简单来说，在项目初期，项目经理首先需要考察客户为这个项目做了什么，也就是“为什么”，这样才能真正从客户的角度考虑系统设计；接下来要总结整个项目在“做”什么，总结每个子任务，让开发人员很好的把握项目内容的大方向；当然，最重要的是“怎么做”。对于信息系统集成项目来说，在这个阶段花更多的时间肯定是值得的。还有一些小技巧:需求分析报告要用客户认为易读易懂的方式写，也要帮助开发者开发出真正需要的系统；项目组成员最好能把需求分析报告详细告诉客户，达成* * *理解。这里沟通手段很重要。另外，在需求确认后，最好让客户的管理层书面签字，作为终止需求分析过程的标志，但绝不是拒绝范围变更的手段。
四、有效的变更控制一个项目的范围计划可能很好，但是想不变更几乎是不可能的。
项目经理和项目团队必须意识到范围变更本身没有任何问题。事实上，很多时候它会让你的系统更加健壮和实用。客户通常不能在一开始就确定所有的需求，随着时间的推移情况会发生变化。如果他们不能适应变化，最终的解决方案可能达不到应有的价值。
但是如果变更失控，后果会非常严重，甚至导致整个项目的失败。根据standish公司在1995的研究结果，最容易导致IT项目失败的前三个因素是:缺乏用户参与、需求和描述不完整、需求和描述易变，这些因素都与范围变更管理直接或间接相关。
因此，必须进行范围变更管理。潘东先生认为:“变更控制的目的不是控制变更的发生，而是管理变更，保证变更有序进行。”
为了实施变更控制，必须建立有效的范围变更流程。这个过程应该包括确认变更，评估变更的业务价值，分析变更对项目的影响，并将其提交给项目发起人进行评估，以确定是否实施变更。
但是，只有范围变更过程不足以真正控制变更，因为项目团队外部的压力很多，而且与缺乏有效的变更控制手段密切相关。本文转自项目经理联盟。
目前流行的变更管理思想认为，范围变更过程中有四个关键点必须严格控制，即谁有权确认变更，需要实施什么样的变更，变更的影响有多大，客户是否接受变更的成本。
1.谁有权确认变更:
不应允许客户的业务人员直接联系开发人员以节省时间，因此无法控制更改。必须事先明确客户谁有权提出变更请求，项目组谁有权接受变更，变更请求必须有书面材料。
我在参与一个大型信息系统集成项目的实施时深有感触:项目经理曾经提醒过我们，客户付钱给我们去实施，这应该算是一件“公对公”的事情。如果用户以“个人感受”为由要求改变范围，开发者可以拒绝。项目经理联盟，项目管理问题。
当时，如果用户发现因业务变化导致需求发生变化，需要向客户的项目负责人提交书面申请，由项目负责人审批后，交给实施者的项目经理。
这样双方的项目负责人就能知道所有的变化。而且用户在提交书面变更申请时更加谨慎，一般都是在自己部门内部讨论后进行，减少了因用户内部观点不同而导致的重复变更。
2.需要实施哪些变革:
不是所有的更改都需要修改，也不是所有的更改都需要立即修改。必须审查客户提出的范围变更，以决定哪些变更需要修改以及何时修改。
客户普遍对信息系统集成项目不太了解，认为简单的事情可能会被计算机复杂化。因此，项目经理和项目团队应该冷静分析用户想要实现什么，抓住本质需求。如果用户的建议难以实现，你可以和用户沟通，询问用户是否可以通过其他方式达到他的目的。
根据笔者的经验，一般来说，用户对镀金的需求是可以推迟甚至忽略的。如果用户的新需求不影响核心业务的实现，可以在现有功能完善后安排。
3.变化的影响是什么？
项目团队的所有成员都应该意识到改变是有代价的。需要评估变更的成本和对项目的影响，让客户了解变更可能存在的问题，判断是否还应该一起进行变更。
更多工程/服务/采购招标信息，提高中标率，可点击官网客服底部免费咨询:/#/？source=bdzd