1、项目管理综合案例分析 项目范围管理,岐兵 ,案例一：范围定义,岐兵 ,案例一：范围定义,项目背景黎明信息技术有限公司原本是一家专著于企业信息化的公司，在电子政务如火如荼的时候，开始进军电子政务行业。在电子政务的市场中，承接的第一个项目是开发一套工商审批系统。由于电子政务保密要求（国家要求），该系统涉及到两个互不联通的子网：政务内网和政务外网。政务内网中储存着全部信息，其中包含部分机密信息；政务外网可以对公众开放，开放的信息必须得到授权。系统要求在这两个子网中的合法用户都可以访问到被授权的信息，访问的信息必须一致可靠，政务内网的信息可以发布到政务外网，政务外网的信息在经过审批后可以进入政务内网系
2、统。,案例一：范围定义,案例场景丁伟是该项目的项目经理，在捕获到这个需求后认为电子政务项目建设和企业MIS项目有很大不同，有其特殊性，若照搬企业信息化项目原有的经验和方法必定失败。丁伟在该项目中采用了严格的瀑布模型，并专门招聘了熟悉网络互联互通的技术人员参与设计了解决方案，在经过严格评审后开始实施项目。在项目交付时，虽然系统完全满足了项目保密性要求，但用户对系统用户界面提出了较大异议，认为不符合政务信息系统的要求和风格，操作也不够便捷，要求彻底更换。,案例一：范围定义,案例场景由于最初设计的缺陷，系统表现层和逻辑层紧密耦合，导致70%的代码重写，而第二版的用户界面仍然没有达到用户的要求，最终又
3、重写了部分代码才勉强通过用户验收。由于整个项目反复变更，项目组成员产生了强烈的挫折感，士气低落，项目工期也必原先的计划超出一倍，项目成本超出预算的100%，项目用户满意度较低。该项目最终的结果与公司的期望偏差很大，黎明公司决定暂时放弃进军电子政务市场，并要求相应的事业部进行业务转型，大幅度裁员，骨干技术人员流失严重！,案例一：范围定义,案例问题问题1如何评估丁伟的项目管理行为？问题2从项目范围管理的角度找出项目实施过程中的管理问题？问题3从范围管理的角度出发，如何避免类似问题的发生？,案例一：范围定义,案例点评这是一个失败的项目，丁伟在项目管理过程中既有闪光的地方，也要失败的地方；项目范围管理
4、的失误是造成失败的关键原因；模糊的范围定义错误的工作分解缺失的范围确认无力的范围控制也暴露出风险管理、系统设计方面的问题,案例一：范围定义,案例分析丁伟对项目范围有一定把握（闪光点）发现了不同行业间具有不同的特点捕获到了政务内、外网的需求，并进行了定义，严格控制了这一需求的设计和实现如果忽视这一行业标准，项目将招致更大的失败丁伟对于像用户界面的风格和操作便捷性的需求没有充分考虑，导致一而再，再而三的变更没有意识到系统“隐形需求”的重要性行业特点决定范围约束（用户界面、操作便捷性）丁伟对项目范围和需求的定义理解并不完整,案例一：范围定义,案例分析电子政务行业特点，使对项目范围定义更加困难最终用户
5、不参加需求和开发工作需求的间接性丁伟在范围确认和范围控制方面存在失误第一次变更就应该充分认识界面、操作的重要性应该立即采取措施清晰的定义界面风格、操作风格丁伟没有进行充分的风险管理隐形行规和行业特点意味着项目范围定义的风险采用瀑布模型增加了风险发生后带来的损失,案例一：范围定义,案例分析这个案例中，缺乏良好的设计也是明显的缺陷用户界面中耦合了大量的业务逻辑，增加了变更代价总结语项目的闪光点在于对项目运行环境进行了清晰的定义，并最终满足了用户的要求不充分的范围定义和范围确认导致了项目的失败采用抗风险较弱的瀑布模型和低质量的设计增加了项目范围变更得代价,案例一：范围定义,问题解答问题1：如何评估丁
6、伟的项目管理行为？注意到了系统运行环境的特殊性，在良好设计和实现的情况下满足了用户要求忽略了系统用户的潜在要求，在用户界面和操作风格上范围定义不清，造成项目交付时产生重大变更第一次问题发生后仍没有对范围进行有效管理，造成项目第二次变更没有对用户界面是否能够满足要求的风险进行有效的管理，而采用抗风险较弱的瀑布模型组织开发没有对设计的质量进行有效控制，造成表现层和业务逻辑层紧密耦合，直接导致增加了变更代价,案例一：范围定义,问题解答问题2：从项目范围管理的角度找出项目实施过程中的管理问题？没有挖掘到系统的全部隐形需求，缺乏精确的范围定义当发生第一次变更时，丁伟仍没有进行有效的范围管理，直接造成项目
7、的第二次变更重复的系统变更说明丁伟对项目范围控制不足，导致项目范围接二连三的变更、反复,案例一：范围定义,问题解答问题3：从范围管理的角度出发，如何避免类似问题的发生？有效的范围管理包括了从范围定义到范围控制等众多方面的工作，每一项工作都是重要的结合行业特点进行需求分析充分挖掘系统隐形需求通过原型法来验证需求的定义，避免范围定义不清的问题在发生需求变更时应进行有效的需求控制，在满足用户需求前提下缩小需求范围，避免需求再次变更,案例二：范围管理工作要点,岐兵 ,案例二：范围管理工作要点,项目背景A集团是黎明信息技术有限公司的多年客户，黎明公司已经为其开发了多个信息系统，最近A集团又和公司签订了新
8、的开发合同，以扩充整个企业信息系统的业务范围；张凡被任命为该项目的项目经理。,案例二：范围管理工作要点,案例场景项目经理张凡组织相关人员对该项目的工作进行了分解，并参考了黎明公司和A集团曾经合作的项目，评估得到项目总工作量为60人月，计划工期为6个月。项目刚刚开始不久，张凡的高层经理孙总找到张凡，孙总表示由于公司运作的需要，要求张凡在4个月内完成项目，考虑到压缩工期的现实，可以为该项目增派两名开发人员。张凡认为，整个项目的工作量是经过仔细分解后评估得到的，评估过程也参考了历史上与A集团合作的项目度量数据，该工作量是客观现实的。目前项目已经开始，增派新的开发人员还需要一定时间的熟悉，因此即使增派
9、两人也很难在四个月内完成项目，如果强行,案例二：范围管理工作要点,案例场景要求项目组成员通过加班加点方式追逐4个月完成项目的目标，肯定会降低项目的质量，造成用户的不满。对此，张凡提出的解决方案是：将整个项目分成两部分实现，第一部分使用三个半月的时间，第二部分使用三个月的时间，分别制定出两部分的验收标准，这样不增派开发人员也能完成项目。高层经理孙总认为该方案可以满足公司运作的要求，用户也同意按照这种方案进行实施。六个半月以后，项目在没有增加人员投入的情况下顺利完成，虽然整个项目比最初的计划延长了半个月，但既达到了公司的要求，客户对交付的系统也比较满意，项目成员也没有感受到很大的压力。,案例二：范
10、围管理工作要点,案例问题问题1点评张凡是如何应对项目范围变更的，采取了哪些措施？问题2结合案例指出项目范围管理的工作要点？,案例二：范围管理工作要点,案例点评这是一个成功的项目管理案例，项目经理张凡有效的运用范围管理手段，在不同项目干系人中达成一致，使项目的结果同时满足了公司高层经理、客户、项目组成员的要求。作为一个项目经理，必须熟练掌握和应用项目管理九大知识领域的技能，对于信息系统开发项目而言，范围管理是其中最重要的技能之一。,案例二：范围管理工作要点,案例分析软件项目的范围主要是由系统需求构成的，而系统需求既是难以把握的，也是容易调整和控制的在满足项目目标前提下，可以定义出不同的系统需求根
11、据经验，软件项目管理总是从范围管理开始，先定义系统的边界，然后再在明确的范围内进行时间、成本、质量和风险的管理范围、时间、成本、质量之间的逻辑关系是项目管理的客观规律当范围因素已经确定的条件下，不妨根据时间、资源（成本）的重新计划来调整合理的项目范围,案例二：范围管理工作要点,案例分析软件项目的范围变更应重新进行项目计划的调整将项目分解成两部分，实际上项目范围已经被扩大了范围变化导致任务、任务之间的逻辑关系的重新调整需要考虑分割项目的验收标准，这是与用户达成一致的前提范围控制并非总是针对客户的要求而进行的控制项目范围控制需求，这个公式是错误的设计策略是项目经理可以把握的（够用策略、牺牲质量特性
12、策略、过度设计）即使需求已经确定，有效的范围管理仍能给项目带来巨大收益范围管理的空间很大，带来的收益是降低成本、缩短工期,案例二：范围管理工作要点,案例分析案例中，张凡还运用了其他范围管理手段项目刚开始，对项目范围进行了定义划分了项目WBS，并对项目进行了估算、计划在孙总提出缩短工期的要求后，首先进行了范围控制，缩小了第一步需要完成的项目范围，接着又对两阶段需要完成的项目范围进行了重新定义制定了两阶段验收标准对重新定义的范围进行了确认，与客户、高层经理达成一致,案例二：范围管理工作要点,案例分析总结语张凡在范围管理方面进行全面的控制，此外也运用了其他项目管理手段，包括对项目估算计划（时间管理）
13、，协调多个项目干系人之间的矛盾（沟通管理）,案例二：范围管理工作要点,问题解答问题1：点评张凡是如何应对项目范围变更的，采取了哪些措施？首先对最初的项目范围进行了清晰的定义，并根据定义对项目任务进行了分解，制定了WBS对项目进行了估算，且估算结果真实可信，对项目工作量有量化的把握在出现新的项目目标后，对项目范围进行了控制，缩小了第一阶段实现的项目范围对重新定义的项目范围进行了确认，与高层经理和客户达成了一致对项目进行了沟通管理，协调了多个项目关系人之间的矛盾,案例二：范围管理工作要点,问题解答问题2：结合案例指出项目范围管理的工作要点？制定范围管理计划进行项目范围定义项目工作分解WBS进行项目
14、范围确认对项目范围进行控制本案例中，张凡首先进行了范围定义和工作分解，得到清晰的项目范围；在出现新的项目目标后，张凡进行了范围控制，重新定义了两个阶段的项目范围；最后，将重新定义的范围与项目干系人进行了确认,案例三：范围确认,岐兵 ,案例三：范围确认,项目背景黎明信息技术有限公司和M企业签订了一份合同，合同的主要内容是处理黎明公司以前为M公司开发的信息系统的升级工作。升级后的信息系统可以满足M公司新的业务流程和范围；王强被任命为该项目的项目经理。,案例三：范围确认,案例场景由于该项目是一个现有系统的升级项目，王强特意请来了原系统的需求调研人员李伟担任该项目的需求调研负责人。在李伟的帮助下，很快
15、完成了需求分析的工作，并进入设计和编码，由于M公司的业务非常繁忙，M公司的业务代表没有足够时间投入到项目中，确认需求的工作一拖在拖。王强认为双方已经建立了密切合作的关系，李伟也已经参加了原系统的需求开发工作，对M公司的业务比较熟悉，因此定义的需求是清晰的，故王强并没有催促业务代表在需求说明书中签字。,案例三：范围确认,案例场景进入编码阶段后，李伟因故移民加拿大，需要离开项目组，王强考虑到系统需求已经定义，项目也进入编码阶段，李伟的离职虽然会对项目造成一定影响，但影响较小，因此很快为其办好离职手续。在系统交付的时候，M公司的业务代表认为甲方已经提出的需求很多没有实现，实现的需求也有很多不能满足M
16、公司现有的业务要求，必须全部实现这些需求后才能验收。此时，李伟已经离开项目组，没有人能够清晰地解释乙方已经完成的需求说明书。最终系统需求发生重大变更，项目延期超过50%，M的业务代表也因为系统的延期表示了强烈的不满。,案例三：范围确认,案例问题问题1对王强在项目管理工作中的行为进行点评。问题2从项目范围管理的角度找出项目实施过程中的管理问题？问题3从范围管理的角度出发，如何避免类似问题的发生？,案例三：范围确认,案例点评这是一个失败的项目，和很多失败的软件项目一样，王强在项目范围（或软件需求）方面栽了跟头；项目经理王强即重视需求，又没有控制好需求的案例开发和定义软件系统的需求是整个项目过程的关
17、键管理项目范围是常识，但往往因为一时的疏忽而造成需求的重大缺陷项目实施过程经历了波折，但未引起重视，最终失败！项目开局：充满光明项目中期：出现乌云项目交付：下雨了,案例三：范围确认,案例分析王强在项目管理中成功的方面找到合适的资源进行需求的定义可以快速准确地把握新系统的需求王强在范围确认和范围控制方面存在失误认为紧逼客户确认需求不近人情，抱着侥幸心里进入开发阶段未履行需求评审和确认过程，造成缺陷未及时发现需求控制失去基准，导致重大变更,案例三：范围确认,案例分析从项目管理的角度分析，项目范围直接决定了工作量和工作目标，项目范围管理中的关系范围定义：管理的基础范围确认：基线化已定义的范围范围控制
18、：减少变更，保持范围的稳定项目范围确认的方法客户代表确认需求说明书（需求报告）召集客户的业务骨干对需求进行评审详细记录原始的调研材料，让客户确认调研报告迭代开发逐步确认需求,案例三：范围确认,案例分析总结语项目的闪光点在于认识到需求的重要性，资源合理未履行范围评审和确认导致了项目的重大变更范围控制成为无本之木，控制过程成为讨价还价，失去本身的意义，导致项目的失败！,案例三：范围确认,问题解答问题1：对王强在项目管理工作中的行为进行点评。王强为了更明确地把握系统需求，聘请了原系统需求调研人员李伟，提高了需求定义的效率和质量；王强没有对李伟提供的系统需求进行评审核复查，从而使需求的缺陷没有被及时发
19、现；王强没有要求用户对已经定义的需求进行确认，从而导致需求理解的偏差；王强对需求缺乏有效控制，最终导致项目延期50%,案例三：范围确认,问题解答问题2：从项目范围管理的角度找出项目实施过程中的管理问题？项目实施过程中的主要问题包括：在范围定义过程中，王强没有对李伟定义的需求进行评审，造成需求中的质量缺陷没有被及时发现；在范围确认过程中，王强没有主动要求用户对需求进行确认；在范围控制过程中，王强无法进行有效的范围控制，最终造成了重大的需求变更。,案例三：范围确认,问题解答问题3：从范围管理的角度出发，如何避免类似问题的发生？本案例说明项目范围管理中应采取以下规避措施：项目经理需要对需求定义的结果进行质量控制，采取评审等方式减少需求定义中存在的缺陷；对已经定义的需求要及时与用户进行确认，保证双方理解的一致；在发生需求变更时，应采取灵活手段，在满足用户需求的前提下，尽量减少需求变更得范围。,
