信息系统项目的范围管理难点解析，如何走出范围管理的困境

（一）IT项目范围管理的重要性

　　在现实的项目管理中，可以看到很多因为项目范围管理不到位而导致项目失败的例子。我们可以看下面一个例子:
　　1992年我国某大型企业决定建造一座38层大厦，预计投资2亿元，工期两年。半年后该公司决定改为54层。后来又因为同省另外一个城市计划建造63层全国最高的建筑，为了使该大厦成为企业所在城市的标志性建筑，该企业又改为建造64层。1994年，有人认为“64”不吉利，遂改为70层，投资增加到12亿元。1996年，该大厦完成基础工程，但这时由于该企业已将大量资金转到别的行业，而且投资失败了，大厦资金告急，公司发生财务危机。1997年，因为大厦未能如期完工，购买者要求退款，大厦停工，最终导致该公司名存实亡。这个例子是项目范围设置太大的典型表现，一个不切实际的项目—目标大大超过了自身能力却又要求及时完成，是造成项目失败的一个重要原因。
　　虽然在IT项目管理中可能很少出现像上面例子中提到的那样严重的后果，但是因为项目范围管理导致的各种问题的情况已经屡见不鲜。比方说IT项目管理中最容易出现的范围蔓延现象，一般项目经理都比较容易意识到大的范围改变，从而及时采取措施，但是对于小的改变却很少能有这么敏感。这种情况下经常出现一种趋势，在项目进行过程中，不断添加额外的工作而并不经过仔细的考虑。当项目接受了太多小的变化之后，所有这些小的变化结合在一起时，项目小组才意识到需要做的额外工作太多，但是这个时候采取措施已经为时过晚了，超出预算，延误工期已在所难免。
　　出现这样的情况往往和项目管理中的一些误区有一定关系，通常大家都说“客户是上帝”，以致项目小组就把客户当成了真的“上帝”，缺乏说“不”的勇气，一开始就难以平等地交流，以至于有求必应，甚至为了讨好用户而去做一些额外的工作或者“镀金”工程。这实际上和项目范围管理中反复强调的项目范围是.‘项目所包含的工作，且仅限于项目所包含的工作”是有很大出入的。从这里我们可以看出来，项目范围管理是影响项目成功的重要因素。 范围管理的重要性还体现在另外一个方面，即项目范围管理是时间、成本、风险等的管理基础。我们知道影响项目成败有四个相互制约的条件，即范围、时间、成本和质量。但对于一个企业的正式项目，满足客户要求是基本目标，在这个前提下，项目的质量是很难偷工减料的，牺牲质量的结果，轻的是收不回款，严重的是失去用户，最致命的是对整个公司形象的影响。所以在质量要求不可能有太大变更的前提下，范围的增加将直接导致工期的延长，而在实际项目执行过程中，项目工期的延长将直接导致项目成本的增加。
　　事实上，如果没有确定项目的范围，或者项目范围不在控制之内，实际上根本没有办法做出可靠的项目计划和项目预算。另外，对于IT项目来说，往往用户前期对整个项目范围并没有清晰的了解，如何才能够很好地做好项目管理?只有帮助客户理清他们真正需要的需求，做到优先排序，才会为项目后续的开展提供坚实的基础;反过来，如果没有做好这个工作，则可能会对整个项目带来很大的影响。所以我们说范围管理确实是做好项目管理的第一步，也是最关键的一步。

（二）IT项目范围管理的难点

　　首先，对于IT项目来说，要管理好项目范围管理的整个过程，包括启动、规划、定义、核实和控制等所有过程并不是一个简单的工作。
　　在合同签订前销售人员为了能够尽快签单，往往对用户都会有一些不切实际的承诺，等到合同签订时，在客户的印象中我们的产品已经是无所不能无所不包了，使得客户产生很多不切实际的期望，这对后续项目工作真正开展其实是相当不利的。签订合同后如果项目小组和用户没有一个渐进的项目范围交互、降低期望的过程，很容易出现观点冲突的情况，从而对项目的推进造成影响，严重的甚至搁浅。笔者本人就曾碰到过用户抱怨:“这好像根本就不是你们销售时说的东西吗”，而不同意系统按期上线。
　　其次，国内签订的合同一般都比较简单，很少对项目范围会有明确的规定，特别是工T软件项目，这样就造成项目的范围存在很大的不确定性，导致很大的隐藏风险。我们经常发现项目开始实施后，客户与软件公司就会发生这样或那样的分歧和冲突，出现这样的情况，一种可能是客户不停地要求软件公司完成超出原来商定范围的工作，或者和原来商定范围不同的工作，还有一种可能是软件公司以超出合同范围为由拒绝提供实际上应该要做的工作，不管哪种情况都是应该避免的，但是在范围不明确的情况下实际上很难做到。
再次，因为对项目的验收标准也没有一个很一致的说法，对项目的如期验收是一个巨大的挑战。
　　最后IT范围管理比较困难的原因是软件产品本身特点所决定的，不像彩电或冰箱，看的时候什么样，买回去就是什么样，功能既不会比看的时候少，买回去后也不可能再增加新的功能了。而软件产品就不一样了，既看不见，也摸不着，而且是“软”的，客户随时会要求增加新的功能。因而对IT项.目，特别是纯软件项目，范围管理就变得特另il困难，因而也显得特R重要。

（三）如何走出企业信息系统建设项目范围管理的困境？

案例正文：小李是国内某知名IT企业的项目经理，负责西南某省的一个企业管理信息系统建设项目的管理。在该项目合同中，简单地列出了几条项目承建方应完成的工作，据此小李自己制订了项目的范围说明书。

甲方的有关工作由其信息中心组织和领导，信息中心主任兼任该项目的甲方经理。可是在项目实施过程中，有时是甲方的财务部直接向小李提出变更要求，有时是甲方的销售部直接向小李提出变更要求，而且有时这些要求是相互矛盾的。面对这些变更要求，小李试图用范围说明书来说服甲方，甲方却动辄引用合同的相应条款作为依据，而这些条款要么太粗、不够明确，要么小李跟他们有不同的理解。因此小李对这些变更要求不能简单地接受或拒绝而左右为难，他感到很沮丧。如果不改变这种状况，项目完成看来要遥遥无期。 
问题： 
1、该问题产生的原因是什么？如何解决？ 
2、如果你是小李，你怎样在合同谈判、计划和执行阶段分别进行范围管理？ 

分析：1、该问题产生的原因是什么？如何解决？
---需求管理出问题：1）需要对方主任确定需求唯一接口人，由这人负责沟通内部要求杂乱和矛盾
2）需要对方明确需求对应的实效性，提出一个控制时间点
3）涉及重大变更，增加重大工作量需要如果PM层面不能解决，需要及时更高层级领导介入。
2、如果你是小李，你怎样在合同谈判、计划和执行阶段分别进行范围管理？
----1）设定需求变更流程和对口人；2）需求提出和工作量跟踪和记录。
一句话，小李没经验：-） 

  

分析：1、在信息化的过程中普遍存在这样的问题，一是客户本身对自身所以行业的规范用语和名词解释本来就不规范，在管理过程中任何一种管理都会与其他的管理有相交的接口，而实际工作中大多数企业对某个管理的范围界定本来就不清晰，与其他管理的接口问题也没能好好的解决。而实施IT项目的公司一对这个行业的规范用语也不是很明白。而客户方的项目经理又是搞IT的对实际的功能应用是否合理难以决策。最好让双方都能配备一个行业专家。针对范围和变更范围进行商谈。
2、合同谈判过程中对概念要求，写明参照标准或写好用语解释，计划要相关行业专家，技术专家都明白其概念，每个阶段的任务要明确交付成果是什么及标准是什么，并对相关人员进行交底，答疑。如果不明确还要进行进一步沟通。

分析：产生问题的原因：
1． 是因为项目的范围确定，一定要关键用户的参与，并且达成一致才可以的，这样才能避免许多无意义的需求提出。
2． 项目团队的建立，一定要把关键部门的领导纳入团队，这样才能在前期明确需求，减少后期的需求变更。
3． 项目经理最好是业务经理，信息中心主任无法对具体的业务进行整体分析。
4． 变更是一定会产生的，但是变更的流程一定要确定下来，组成专门的变更评估小组，对各个变更进行整体的分析，就会避免前后矛盾的变更了。
5． 变更发生分歧的时候，要注意沟通，不能简单的认为范围中没有，就不在工作范围之内，这样只会造成客户的逆反心理！一定要和客户详细说明，如果变更会造成那些问题，投入要多少，需要多少时间等等。这样客户才会接受不变更的理由。
解决方法：
合同谈判
1． 在谈合同的时候，对合同的目标，预算，时间，范围，组织有明确的说明。
2． 有明确的绩效标准，明确的交付物规定。
3． 在项目计划和项目执行的阶段，不断完善合同的条款。
项目计划
1． 组建项目团队，选择企业的实权人物，作为项目经理，把关键用户的领导纳入团队。
2． 团队参与建立范围说明书，范围说明书一定要达成共识，并且签字确认！
3． 根据范围说明书，定义活动，估算时间，建立进度计划，这个过程也要项目团队集体参与评估的。
4． 当大家对项目的范围，预算，进度都达成共识后，才能进行下一步的工作！

分析：看完之后觉得有几个不妥的地方：
1、项目合同比较简单，这可能无可厚非，因为实际情况中出现这种情况的可能性很大，但是据此小李自己制定了项目的范围说明书却是不妥的做法。项目范围说明书是项目的根本，是项目计划制定的基础，而项目的计划又是项目成功与否最重要的一环。因此项目范围说明书的签订，如果无法根据合同获取有效信息，则必须和客户进行详细、全面、反复的沟通确认，这样的一份说明书才能作为项目后期工作开展的基础。
2、既然已经确定信息中心主任作为甲方项目经理，沟通的主要对象应该为该主任，应要求客户的相关需求变更、建议先汇总到该主任处，我方再从其处获取。这样一方面，有利于甲方负责人充分了解需求的变更情况，在后期需求出现变更时作为一个数据来说话时，甲方负责人也是心知肚明的，会起到一定的过滤作用；其次甲方的各个部门的相关人员在提相关变更时也会有个充分的考虑，不会盲目的提出不合理的需求。
解决方案：
1、计划阶段做好需求的收集、分析、确认工作。
2、执行阶段明确沟通机制，做好需求变更控制。
补救措施：
1、与客户进行一次关于范围和需求的会议，明确项目范围，对不明确的需求进行确认。
2、明确沟通机制
3、建立需求变更流程
4、本人经验浅薄，如有错误，请各位大侠及时指正。
5、建立变更团队，对所有的需求变更总体分析。
执行阶段
1．根据执行的实际情况，不断完善控制流程，比如里程碑，交付物，变更流程。
2．对变更做好版本管理。
3．定期检查实际实施情况和计划有无偏差，如果出现偏差要作出相应的措施进行纠正。

分析：首先，合同管理没有专门人员，没有充分理解合同的内容，“项目经理简单列出承包方要完成的工作，就编制项目范围说明书”，这是承包方的大忌。其次，合同中可能存在：甲方没有项目的具体负责人，双方没有变更控制委员会（ccb）。第三，签订的合同内容存在问题，“甲方却动辄引用合同的相应条款作为依据，而这些条款要么太粗、不够明确，要么小李跟他们有不同的理解”。第四，项目经理的沟通管理计划存在问题，范围说明书是根据合同制定的。最后一个企业不能只为了拿到项目而签订有问题的合同。

分析：这种情况在现实中也大有存在，合同只是罗列大概，但是具体内容也就是范围说明书，或者需求说明书也好，都需要PM带领团队去详细调研，形成一份详细的说明书，提交客户签字确认项目的范围。
如果没有这个基本的范围确认，项目组依赖什么依据去完成项目，以什么标准确认，这个是信息系统建设项目的基本步骤，一是明确自身需要完成的内容，二需要客户确认完成的范围，避免没完没了地变更。
这个谈不上困境，而是领导需要自身完善项目管理知识，认识到规范管理的好处，坚持按流程办事，中国人做事不喜欢白纸黑字，因为不喜欢担责任，客户更乐意你不言明，而到时如果你们的所谓关系不到位，诸多指责和变更都会拖着公司和项目组举步为艰。
其实没有那么难，不要期望客户能够傻乎乎凭几条模棱两可的条款就能让项目过关。

分析：1、项目范围说明书确定后需要甲方的签字确认，否则你制作的范围说明书只能是一厢情愿！
2、项目可以变更，但一定要走流程，应该由甲方的项目经理来给你协商变更事宜吧，其他人可以拒绝变更！
3、对于变更，尽量同甲方协商，那些是可以变更的，那些是暂时不可以变更的（可以放在二期），并且一定要先说明变更会引发的问题，看引发的新问题客户能发接受！
个人认为主要是沟通上面出了问题！一定要加强沟通！
另外制定合同时，能说清楚的最好用合同逐条列清楚，不能为了急于签合同而不考虑项目后期的制作和验收！

分析：1、关于项目组织架构设置与职责。
这直接涉及小李如何确定项目范围问题。尤其对于信息化项目，本身就是无终极目标或清晰接顶界定，应更为小心。在组织架构与职责未明晰前提下，很难开展工作。
2、在合同中应附录建设总体计划。
此类项目，往往在签定合同前需要协商的。因此，将建设总体计划作为附件，会有力于工作推进的。哪怕做贡献，也有出处。
3、提交阶段工作报告。其重要性不言而喻，磨刀不误砍柴工。
供参考。

分析：问题1：项目边界的不确定
从案例中可以看出，该项目的范围说明书没有得到甲方的确认。这样是很容易在变更中发生超出项目边界的情况。
解决方案：
暂停项目的实施，和甲方重新坐下来，确认项目的边界
问题2：甲方项目关键人的缺失
因为甲方的项目经理是由甲方的一位领导兼任，由于没有专职的人员负责收集甲方的需求，造成需求提出的不统一，以至于小李无所适从。
解决方案：
建议甲方确定一位专职的人员，用以收集需求
问题3：项目关键节点（里程碑）没有确定
项目没有定义关键节点，那么，也就缺少在关键节点，甲方对乙方的工作的认可，甚至可以进行否认，因为，小李没有拿到相应节点的甲方签字。
解决方案：
迅速的对计划进行调整，同时增加相应的节点，某一项工作完成后，与甲方的项目经理进行确认，并对生效点进行签字认可。
问题4：需求变更的无序
由于合同条款太粗，同时，由于需求的不统一，导致小李无法对需求进行统一的管理，并造成混乱
解决方案：
1。和甲方一起重新确定变更流程，并对其签字生效。
2。和甲方（前面提到的甲方项目关键人）一起识别变更，确认优先级别，并记录在案
3。根据变更的优先级别，并在项目组承受能力范围内，给予解决，对于超出预算的，应该坚决的否决。毕竟，没有接受，就无法拒绝。
4。和甲方一起，识别出否决的需求，同时包括甲方还未提出的需求，建议甲方启动该项目的2期，并给出甲方该项目的2期实施方案。
综上所述：
一个IT项目的实施成功与否，最终决定于甲方项目经理的参与程度。
1。合同的签订
在总合同的基础上，应该添加其他的合同附件，包括项目组成员、技术标准、实施方案、验收方案、付款条件等
2。制订可实施的计划，同时给出关键节点的期限，并进行签字生效。
3。在每个关键节点（里程碑），与甲方一起进行签字生效，以避免不必要的麻烦。 

分析：1、小李自己制订了范围说明书，有没有与甲方取得共识，获得甲方批准？这一环节缺乏沟通。
2、既然有项目经理，甲方应该由项目经理与小李交涉，小李可以建议。没有规矩、不讲程序，这个活当然没法干。因而这一环节既是甲方缺乏沟通，又是小李缺乏沟通。甚至于连与甲方间的沟通程序都没有定，实施中不乱套才是怪事呢。
3、变更的原因没有弄明白。如果是IT项目本身的问题，那客户的合理要求必须满足，项目应在范围内追求满意度。这一得靠分析二得靠沟通。
综合上述三点，小李应该加强沟通，解决眼前的困境，相信项目会成功的。

分析：1.最终用户能用合同的相应条款作为依据提出变更，说明用户的要求有合理的方面。用户的要求没有包含在范围说明书中，是范围说明书编写时没有与最终用户沟通细化。
2.用户需求相互矛盾，应由用户方项目经理解决。
3.范围说明书用户签字了吗?
4.组织用户方用户与项目负责人开会,重新细化需求,并签字确认.由用户方项目经理提出变更,小李经理需提出变更带来的影响.最后确认是否变更?如何变更.

分析：1.范围的确定不够清晰明确。建议在借鉴成熟的范围定义条件下同项目关系人增加沟通以得到完整，清晰的范围定义。同时分析了解项目关系人，任何可以影响到项目的人/该项目会影响的人都应事先做出分析，比如考虑到系统与销售部相关，可以在项目开始前通过客户的项目经理了解销售部意见。
2.对于工作流程，对于客户中其他部门提出的意见要统一与客户的项目经理讨论解决，或者请其将多方召集起来一起解决，这样大家自然会对有冲突的要求有判断的。毕竟是客户要求，只是未通过项目经理提出，那么我们就将其纠正回去就是。

分析：1、合同中的项目范围（我们项目一般叫需求规格说明书）没定义完整、清晰及可管理，可能是一句话包含了一大块功能，如果这样显然在实施过程中处于被动。
2、工作流程有问题，客户必须有项目经理，所有变更需求均得有甲方得项目经理提交给我们，而不是谁都直接提过来，导致根本无法执行需求变更流程。

（四）如何解决项目范围管理问题

　　这个案例所反映的问题在信息系统实施中是比较普遍的。在开始实施时a、b公司所碰到的表面上的种种分歧，归结起来本质上主要是项目的范围管理问题。
　　糟糕的范围管理是导致项目失败的致命伤，通常在实施PDM项目时会遇到下列问题：
　　咨询公司或系统集成商往往有一种“never say no”的气魄。的确，一个实力雄厚的咨询公司是可以通过二次开发和客户化，提出适应客户个性化需求的解决方案。但是，客户化开发需要做的工作，客户往往并不清楚——工作量有多大，由谁来进行，费用是多少，如何配合整体实施进度？不过，如果销售人员对这类问题谈得过深过细，很有可能影响签单。因此，在许多情况下，这些问题被有意回避，成为双方合作和实施中的定时炸弹。
　　遗憾的是，不少软件公司的销售人员并不十分了解PDM系统的原理与概念，甚至不了解本公司产品的功能，至于对行业存在问题的了解就更难说了；他们主要的特长是“关系学”。在接触客户甚至签单的过程中，销售人员往往会过度承诺（over-promise），他们关心的是“签单”，也就是“成交”，而售后服务顾问关心的是“客户满意”，也就是“成功”。
　　“成交”和“成功”虽然仅有一字之差，但是公司对两类人员有不同的考核指标，对前者的考核是完成多少销售额，对后者的考核是完成多少服务天数。这种公司内部销售和技术支持部门之间的矛盾，对公司和用户都非常不利。
　　一旦项目开始进行了，在进一步讨论项目实施的范围时，客户与软件公司就会发生这样那样的分歧，一种可能是，客户不停地要求软件公司完成超出原来商定范围的工作，或者和原来商定范围不同的工作；还有一种可能就是，软件公司以超出合同范围为由拒绝提供实际上应该要做的工作。
　　范围蔓延：很多项目经理能够意识到大的范围改变，但是对于小的改变却没有那么敏感了。现在有一种趋势，就是不断地进行项目，不断添加额外的工作而并不经过仔细的考虑。范围蔓延指的是当项目接受了太多小的变化之后所出现的情况。当所有这些小的变化结合在一起，项目小组才意识到需要做的额外工作太多，以至于要超出预算，延误工期。
　　没有发起人的同意：有时软件供应方项目经理会从最终用户，或者客户经理那里收到变更请求。由于这些人都是客户公司内部的，他们认为这些请求都应该被接受。很多项目陷入麻烦是因为他们认为他们获得了进行范围修改的批准，但是后来却发现有权决定这种变更的人—发起人，并没有同意这样做。
　　项目小组的责任：由于项目小组成员和客户有很多联系，他们是最经常会遇到范围更改请求的人。因此，整个项目小组必须理解范围变化管理的重要性。他们必须在范围变化发生的时候立即发现它，并且及时把它反馈给项目经理。如果他们自己答应进行一些额外的工作，他们的这种行为就很有可能导致他们不能够按时完成自己的工作，从而危及整个项目的进行。
　　科学的范围管理是项目成功的第一步，它的基础是一个科学的范围管理流程，其中包括范围规划、范围定义、范围确认和范围变更。