(精品)项目范围失控的影响

,*,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,单击此处编辑母版标题样式,项目团队成员：苏凯莉、段敬熙、,周帅、王晶、高永红、,缪广然、原华雄,希赛信息技术有限公司范围失控案例分析,希塞信息技术公司项目范围管理失控分析,项目范围管理,项目范围管理失控案例,工作成员矩阵,案例简介,原因,影响,措施,项目失控,工作分解结构图,成员,任务,苏凯莉,创建工作分解,结构、案例讨论,段敬熙,项目团队成员责任,矩阵、案例讨论,缪广然、原华,雄,案例分析,范围失控的原因,王晶、高永红,案例分析,范围失控的影响,周帅,工作总结和制,作,PPT,、案例讨论,项目团队成员责任矩阵,：,责任分配矩阵是用来对项目团队成员,进行分工,，,明确其角色与职责,的有效工具，通过这样的关系矩阵，项目团队每个成员的角色，也就是谁做什么，以及他们的职责，也就是谁决定什么，得到了直观地反映。项目的每个具体任务都能落实到参与项目的团队成员身上，确保了项目的事有人做，人有事干。,案例简介,希赛信息技术有限公司,CSAI,原本是一家专注于企业信息化的公司，在电子政务如火如荼的时候，开始进军电子政务行业。在电子政务的市场中，接到的第一个项目是,开发一套工商审批系,统,。,张,工是该项目的项目经理，在捕获到这个需求后认为电子政务建设与企业信息化有很大的不同，有,其自身的特殊性,，若照搬企业信息化原有的经验和方案必定会遭到惨败。因此采用了严格,瀑布模型,，并专门招聘了熟悉网络互通互联的技术人员设计了解决方案，在经过严格评审后实施。在项目交付时，虽然系统完全满足了保密性的要求，但用户对系统,用户界面,提出了较大的异议，认为不符合政务信息系统的风格，操作也不够便捷，要求彻底更换。由于最初设计的缺陷，系统表现层和逻辑层紧密耦合，导致,70,的代码重写，而第二版的用户界面,仍不能满足最终用户的要求,，最终又重写的部分代码才通过验收。由于系统的反复变更，项目组成员产生了强烈的挫折感，士气低落，,项目工期也超出原计划的,100,。,项目范围失控的原因,首先，值得肯定的是张,工对,项目范围,有一定的把握。在范围定义中，张工发现了不同行业间具有不同的特点，电子政务行业对系统运行环境有着特殊的要求。根据国家对电子政务的要求，政务内网与政务外网是该行业,一致的标准,，这与企业信息化是完全不同的。张工捕获到该需求，并对这个需求进行了清晰的定义，根据瀑布模型的要求，对设计和实现都进行了,严格的控制,，因此在系统交付时完全满足了用户对保密性的要求。在这一点上，张工是成功的。,项目范围失控的原因,但美中不足的是：,用,户界面的风格,和,操作的便捷性,也属于系统范围的一部分。与系统运行环境一样，我们通常称这类需求为,隐性需求,。这类需求往往不是由用户直接提出，而且受行业特点决定的范围所约束。对于电子政务来说，系统保持一致的风格非常重要。作为政府对公众开放的窗口而言，并不需要很强的个性化，但一致的界面风格可以体现出,政务的严肃性,。考虑到全体民众层次差异较大，大多数访问系统的用户一般都没有接受过系统使用的培训，,操作的便捷性,也是政务系统必须实现的功能之一。很明显，对于这些系统的隐性需求张工没有充分考虑，从而导致一而再，再而三的变更。,项目范围失控的原因,除了在,范围定义,方面的问题外，张工在,范围确认,和,范围控制,方面也存在不小的失误。当系统第一次更改时，就应该意识到系统界面风格和操作便捷性的重要性。这时应该清晰地定义,系统的界面风格,和,操作风格,，并设法进行确认。如果采取了恰当的措施，第二次的变更是完全可以避免的。,项目范围失控的原因,因此可以考虑采取,原型法,等方式来提前,暴露风险,，减少风险带来的损失。,对于这个案例，,缺乏良好的设计,也是很明显的缺陷。,项目范围失控的原因,综上所述,，项目经理张工在整个案例中，针对范围管理做了一些工作，但不全面，在,风险管理,和,质量管理,上也都存在缺陷。,(1),张工没有挖掘到系统的全部,隐性需求,，缺乏精确的,范围定义,。,(2),在发生第一次变更时，张工仍没有有效的,范围管理,，从而造成系统的二次变更。,(3),重复的系统变更说明张工对系统,范围控制,不足，导致一而再再而三的反复。,项目范围失控的原因,4),张工忽略了系统用户的,潜在要求,，在用户界面和操作的风格上,范围定义,不清晰，造成系统交付时的重大变更。,(5),张工没有对用户界面是否能够满足要求的,风险,进行有效的,管理,，而是采用了对,风险适应性较差,的,瀑布模型,组织开发。,(6),张工没有对设计,质量,进行有效的,控制,，造成表现层中耦合了业务逻辑，增加了修改的代价。,项目范围失控的影响,项目管理,中的,任何差错,都会影响,项目的结果,，而,范围管理,的失误对项目的影响更为明显。模糊的项目,范围定义,、错误的工作分解、缺失的,范围确认,和无力的,范围控制,都将严重影响项目的结果。,在,范围定义,时忽略了,行业标准,，项目肯定会招致更大的失败。所有的需求都必须经过清晰的定义，忽略了用户界面，最终也会导致项目的失败,对于,电子政务信息系统,，尤其是面向公众开放的信息系统，范围定义更加困难。这些系统的最终用户几乎不会参加需求开发的工作，他们的需求都是间接的，通过政府部门的负责人传递到项目组。但,最终用户,的意见对项目的结果会有巨大的影响，这就对范围管理提出了更高的要求。,项目范围失控的影响,在刚刚进入一个陌生领域的时候，其中充满了各种各样的风险。,隐性的行规,和,行业特点,都是项目范围的风险。面对这些风险，即使再细致的调研也无法完全避免，也不能完整定义系统的范围。,在案例中，张工也没有进行充分的,风险管理,，采,用,严格的瀑布模型,增加了风险发生后带来的损,失。,不充分,的,范围定义,和,范围确认,招致了项目的失败，而采用了,抗风险能力较弱,的,瀑布模型,和低质量的,设计,又雪上加霜，最终导致项目延期,100%.,对本案例项,目范围失,控的总结：,防止项目范围失控的,措施：,有效的,范围管理,包括了从,范围定义,到,范围控制,等多方面的工作，每一项工作都是重要的。对于本案例，要结合,行业特点,进行需求分析，挖掘系统潜,在的需求,，同时通过,原型,等方法来辅助需求的定义，避免范围定义不清晰的问题。,在发生需求变更时需要进行有效的,需求控制,，尽量在满足用户需求的前提下缩小,需求范围,，坚决避免需求的,再次变更,。,谢谢！O(_)O,