项目管理案例分析71099实用文档.doc

项目管理案例分析71099实用文档(实用文档，可以直接使用，可编辑 优秀版资料，欢迎下载）项目管理案例及其分析姓名 ： 班级学号 :项目管理案例项目经理应该为这些问题负责吗？【摘 要】项目管理是在有限的资源约束下，运用系统的观点、方法和理论，对项目涉及的全部工作进行有效地管理。即从项目的投资决策开始到项目结束的全过程进行计划、组织、指挥、协调、控制和评价，以实现项目的目标。 项目是指一系列独特的、复杂的并相互关联的活动,这些活动有着一个明确的目标或目的，必须在特定的时间、预算、资源限定内,依据规范完成。通过此案例，分析项目管理中的项目经理,项目计划问题。【关键词】 项目管理，项目经理，项目计划一 案例正文 陈伟明是公司的项目经理，在项目A筹备阶段就作为项目经理助理参与该项目，项目正式实施后被公司任命为项目经理。但使陈感到恼火的是：其他职能部门的经理虽然为该项目安排了时间和人手，但他们更热衷于其他项目。同时陈还被告之不要干涉部门经理对资源的调度和费用的预算。 半年之后，陈借向公司管理层汇报项目进度的机会向管理层说明了由于职能经理不合作而造成的项目严重拖期情况，这次汇报引起了公司管理层的注意,他们投入了更多的资源来使项目回到正常轨道上来，陈伟明不得不花费很多时间来准备文案、报告和投影以及各种各样的会议。 公司管理层还为陈指定了一个项目经理助理，该助理认为应该通过计算机程序把各种问题程序化，于是公司又投入了12个人来开发这个程序,在花费了巨额资金之后，陈发现这个程序并不能实现其目标，他向一个软件供应商进行了咨询，得知若要完成该程序，还需要多花费数倍的资金和两个月的时间,无奈之下,陈只好放弃了该程序. 这个时候项目的情况已经很困难了，项目滞后了9个月，但还没有成型的单元完成，客户对项目拖期问题非常关注，陈不得不花大量时间向客户解释存在的问题和补救计划。 三个月之后,项目仍然没有大的进展，客户开始不耐烦了,尽管陈进行了大量的解释和说明，但客户仍然不能接受严重拖期，于是指派了一个代表到项目现场监督工作。客户代表要求找出问题并持续更新，继而试图参与进来解决问题，陈和客户代表在一些问题上产生了激烈的冲突，导致两人关系恶化。二 案例分析1。从案例中可以分析得出,身为项目经理，陈需要为这些问题负责。造成这些问题的主要原因有以下两个： (1） 沟通方面的问题 (2） 项目计划的制定、监控及修正的问题2。以下对两个主要原因进行分析：(1)沟通方面的问题1）没能与职能部门进行很好的沟通，协调资源；从这个案例可以看出，该公司的整个运营链不流畅,有十分严重的部门墙存在。而陈作为项目经理，和各职能部门的协调沟通不够，造成公司资源（人力和资金等）的严重浪费。案例片段：“其他职能部门的经理虽然为该项目安排了时间和人手，但他们更热衷于其他项目.同时陈还被告之不要干涉部门经理对资源的调度和费用的预算。”分析：项目经理陈由于没能与职能部门的经理进行很好的沟通而导致人力资源的效用没能完全的发挥（为该项目安排了时间和人手）。作为一个从项目经理助理晋升为项目经理的项目负责人来说其的确不能去干涉其他部门的资源调度，但是项目经理要做到的并不是去干涉，而是去协调，使其他部门的资源更好的为自己的项目组所用。陈不可能强硬地要求其他部门经理随时满足他的资源和费用要求,更不可能要部门经理主动来配合他的工作。陈没有得到其需要的资源时没有试着和部门经理沟通，向他们说明项目的紧迫性、重要性和项目拖延的严重后果,也没通过其他办法来获得资源,只是怒气地埋怨部门经理的不配合，后来更犯了团队合作的大忌没有经过与职能部门经理沟通就直接向管理层报告“职能经理不合作而造成的项目严重拖期情况”。把责任直接推到职能经理的身上。这样虽然他能暂时得到了项目需要的资源却和职能部门经理结下不良的合作关系。2）没有及时向上级管理者汇报项目的问题，并获得上级管理者的支持；案例片段：“半年之后，陈借向公司管理层汇报项目进度的机会向管理层说明了由于职能经理不合作而造成的项目严重拖期情况。”分析:陈应该为项目建立有效的项目汇报及沟通制度，定期向公司高层递送项目存在的问题和解决情况，而不是在问题出现半年之久才汇报，在这半年期间将浪费大量的时间和资源,并且会因为资源的问题而打乱项目的开发计划。3）没有做好外围沟通 ；案例片段：“陈发现这个程序并不能实现其目标，他向一个软件供应商进行了咨询，得知若要完成该程序，还需要多花费数倍的资金和两个月的时间,无奈之下，陈只好放弃了该程序。”分析：这个程序开发的失败正是陈缺乏沟通造成的严重后果。首先他没有做好外围沟通,一个新的项目的开展就要做好咨询特别是自己不熟悉的领域而不是出现问题才咨询软件供应商，这样不但难以纠正问题更浪费开发的时间和金钱。其次，在新项目出现问题时没有和管理层沟通而是自己咨询软件供应商就决定放弃程序，把重要的决定握在手里,所以他应该为他沟通的失误而为失败买单.4）没有和客户保持紧密的联系，没有发挥客户的积极作用。案例片段：“陈不得不花大量时间向客户解释存在的问题和补救计划.”“客户代表要求找出问题并持续更新，继而试图参与进来解决问题，陈和客户代表在一些问题上产生了激烈的冲突，导致两人关系恶化。” 分析:在客户对项目进行情况很不满的时候,陈“花大量时间向客户解释”正正也表现了他的沟通问题，在项目进行中应该保持和客户的紧密联系，发挥客户监督的积极作用，这样就不至于后来出现许多大的问题让用户觉得不可理解。在向客户说明时并不能像向上级汇报一样把问题归咎为部门经理的不配合,而是应该向客户列出问题的困难性和解决计划，争取得到客户的理解和支持。与客户意见不一的时候更应运用良好的沟通技巧,不要一味的想说服客户接受自己的方案而是走出最后的解决办法，最重要的保持良好的合作关系，继续取得客户的信任。总的来说，陈在项目开发中犯了缺乏有效沟通的问题，以至于很多问题不能在刚产生时就能得到有效的解决，导致大量人力、物力、资金和时间资源的浪费，是项目最终超时、超预算的一个重要原因。项目计划的问题对于一个项目，在论证初期都应该进行详细的调研和方案的确定，包括各项资源的分配与管理、监控手段等，并在实施过程中,定时开展项目例会跟踪项目进度，在项目的每个关键时间接点做项目评审，从质量、成本、进度三个方面进行审核,并根据审核情况不断修正方案，这样其他职能部门经理也好对部门工作做好统筹安排，以确保该项目的顺利完工。在该项目中,项目经理陈对整个项目执行的管理非常失败,具体如下:1）项目进行初期没有制定严格的项目计划 ；案例片段：“半年之后，陈借向公司管理层汇报项目进度的机会向管理层说明了由于职能经理不合作而造成的项目严重拖期情况。”分析:陈在项目进行半年之后，才向公司管理层汇报项目进度，提出项目的严重拖期情况。项目进行初期没有制定严格的项目计划，对项目运行中的困难估计不足.项目实施之后，陈对项目刚开始的进度拖期，并没有去想办法解决问题,去努力协调资源分配,也没有及时争得上级领导的重视，这些都使项目在刚开始就出现严重的拖期。2）在启动问题程序化系统开发前没有进行周密的评估，缺乏必要的可行性分析；案例片段:“公司管理层还为陈指定了一个项目经理助理,该助理认为应该通过计算机程序把各种问题程序化，于是公司又投入了12个人来开发这个程序，在花费了巨额资金之后，陈发现这个程序并不能实现其目标，他向一个软件供应商进行了咨询”分析：在项目实施过程中，启动的一个问题程序化系统开发，是不符合制定决策的基本要求。在准备投入资金开发问题程序化系统时，项目经理对该系统开发没有进行周密的评估,包括必要性评估、资金投入评估和风险评估等，匆忙上手,都会导致项目质量、费用、时间等方面的严重浪费；在投入了巨额资金，但没有实现其目标时,陈没有进行认真地分析问题和请示公司管理层,而自己决定放弃该程序，导致公司之前的投入白费。3)在项目严重滞后，没有及时修正项目计划,并积极采取改进措施。案例片段:“陈不得不花大量时间向客户解释存在的问题和补救计划。”分析：在项目严重滞后，客户对项目拖期问题非常不满，并最后派人监督项目的情况时,陈没有及时修正项目计划，并积极采取改进措施，包括项目组自身工作的改进、请求公司其他资源支持等，以加快项目进度，而是一味地花费大量时间向客户解释存在的问题，其完全在做无用功。此外,该项目经理还存在一些其他问题，如：决策不够严谨,盲目采纳助理的建议；在投入了巨额资金但没有实现其目标时，陈没有进行周密的分析和请示公司管理层，而自己决定放弃该程序，导致公司之前的投入白费。因此,陈被撤换是必然的结果，他所犯的错误导致了整个项目不能在计划的时间内，计划的成本中完成. 当然，在该项目中，公司也负有一定的责任，如:项目的目标并没有得到项目各执行部门的一致关注，其主要原因是公司对该项目的重视程度不足，才会出现“不要干涉部门经理对资源的调度和费用的预算”的情况.项目管理案例分析 背景：西游记是我国古代四大名著之一.如果我们将小说中的去西天取经看作一个项目的话，这个项目的赞助人是唐太宗，他给了唐僧九环锡杖、锦斓袈裟，一匹白马,一个紫金钵盂，以及通关文牒,这些资源能够帮助唐僧顺利到达西天。项目时间为三年，项目范围或项目的主要工作是经历九九八十一难,以完成项目目标取得西天大乘佛法. 问题:  1. 作为项目经理，唐僧具在能力上，有哪些优势和不足？  2.孙悟空为什么不能成为一个优秀的项目经理? 分析：1。 唐僧能力上的优势: （1）团队管理能力：唐僧的三个徒弟都不是自己挑选的，而是观音菩萨直接指派的,而且三个徒弟对抗妖怪的能力都比他强，但这并不妨碍唐僧成为一名成功的项目经理。这源于他较强的团队管理能力.他知人善用，合理分配工作.根据徒弟们的性格特点和特长，团队有了较好的合作.心高气傲的孙悟空的武功最为高强，所以一路上降妖除魔的任务就交给了他,同时,唐僧也利用紧箍咒对孙悟空的不当行为进行限制。猪八戒的能力在三个土地中属于中等，但是较为懒惰,唐僧让他与孙悟空协同工作，同时利用八戒良好的沟通能力，给他分配了化斋、问路等工作。对于勤勤恳恳但是武功不太高强的沙僧，则分配给他技术要求不高，但对工作态度有较高要求的枯燥工作，例如挑行李。 (2）交流沟通能力 ：取经路上，经常需要化斋、借宿、办理通关文牒等，很多时候由于他的三个徒弟长得比较怪异,所以他需要亲自去做这些与人沟通的事情。他能够很好地组织自己的语言,把自己的想法说出来，很会交流和沟通。 （3)学习能力: 唐僧在取经开始时，不会管理团队，造成团队成员间经常发生冲突，甚至还要赶走项目成员.但是，经过观音菩萨这个上级领导的指点，唐僧很快学会了管理，团队之间越来越默契，摩擦和争执也越来越少。 作为项目经理，必须具有很强的学习能力. （4)以身作则、以德服人的能力： 唐僧具有良好的品德。至始至终，他都能保持良好的德行，并给团队成员树立了良好的学习榜样。 作为项目经理,个人的品行决定了自身价值。品德有问题的项目经理是不可能再团队中形成强大的凝聚力的。 唐僧能力上的不足: 1。 项目缺乏计划： 唐僧接到要去西天取经的任务后，并没有对项目内容做任何分析和计划,仅凭借自己对佛法的热爱，就仓促上路。 2. 缺少时间管理:项目开始前，唐僧认为三年时间就能完成项目,但是实际整整花费了十四年的时间。这也与项目缺乏计划有关系。 3。 缺少对项目成员的激励：项目经理应该让项目成员主动参与到工作中来。我们看到，在取经过程中，孙悟空经常会和唐僧发生冲突，赌气不想再帮助唐僧取得真经，猪八戒也经常偷懒，对他们来说，是否取得真经不是非常重要.这对完成项目是非常不利的。项目经理在领导项目团队实现项目目标的同时，也应该将项目视为团队成员提高自身价值的良好机会，让团队成员意识到自己在做一件对提升自身价值有意义的事情.所以唐僧应该在这方面加强,给三个徒弟塑造美好的愿景，让他们在取经过程中更加齐心，风雨无阻。  2. 因为孙悟空在取经这个项目中属于降妖除魔的技术专家.让项目专家充当项目经理有一定的危险性，因为技术专家的技术越高，越容易沉湎于技术细节，而忽略了管理问题。项目经理必须了解如何有效地发挥团队成员的作用,如何很好地与人相处，而这些往往是技术人员薄弱之处。孙悟空在取经过程中比较傲慢，目中无人，不能与团队内外的人们很好地相处，只想着打妖怪，而忽略了取经的根本任务。 孙悟空如果做了项目经理，他的管理作风属于强硬型。对下属强硬并不是一个好的项目管理的风格,项目经理应该给下属充分自由的空间，创造良好的工作气氛. 另外，孙悟空不像唐僧那样仁德,不能形成团队的凝聚力。案例分析一:项目管理过程项目背景某市电子政务信息系统工程，总投资500万，主要包括网络平台建设和业务办公应用系统开发，通过公开招标，确定工程的承建单位是A公司，按照合同法的要求与A公司签订了工程建设合同，并在合同中规定A公司可以将机房工程这样的非主题、非关键性子工程分包给具备相关资质的专业公司B，B公司将子工程转手给了C公司。在随后的应用系统建设过程中，监理工程师发现A公司提交的需求规格说明书质量较差,要求A公司进行整改.此外，机房工程装修不符合要求,要求A公司进行整改。项目经理小丁在接到监理工程师的通知后，对于第二个问题拒绝了监理工程师的要求，理由是机房工程由B公司承建，且B公司经过了用户方的认可,要求追究B公司的责任，而不是追究自己公司的责任。对于第一个问题，小丁把任务分派给程序员老张进行修改，此时，系统的设计工作已经开始，程序员老张独自修改了已进入基线的程序，小丁默许了他的操作.老张在修改了需求规格说明书后采用邮件通知了系统设计人员。合同生效后,小丁开始进行项目计划的编制，开始启动项目。由于工程紧张,甲方要求提前完工，总经理比较关心该项目，询问项目的一些进展情况，在项目汇报会上，小丁向总经理递交了进度计划，公司总经理在阅读进度计划后，对项目经理小丁指出任务之间的关联关系不够清晰，要求小丁重新更改一下计划，新的项目计划出来了，在计划实施过程中，由于甲方的特殊要求,需要项目提前2周完工，小丁又更改了项目进度计划，项目最终按时完工。案例问题问题1小丁在合同生效后进行的项目计划编制工作应该如何进行？小丁在接到任务后开始项目计划的编制工作,应包括：项目总计划：范围计划、工作范围定义、活动定义、资源需求、资源计划、活动排序、费用估算、进度和费用计划项目辅助计划:质量计划、沟通计划、人力资源计划、风险计划、采购计划等问题2小丁在处理监理工程师提出的问题上处理是否正确?你作为项目经理，应该如何处理？依据中华人民共和国招投标法第48条：中标人应当根据合同约定履行义务，完成中标项目。中标人不得向他人转让中标项目，也不得将中标项目肢解后分别向他人转让。中标人按照合同约定或经招标人同意,可以将中标项目的部分非主体、非关键性工作分包给他人完成.接受分包的人应具备相应的资格条件,并不得再次分包。本案例中,A公司将子项工程分包给B，B又将其分包给C，显然违背了招标法第48条规定“中标人应当就分包项目向招标人负责，接受分包的人就分包项目承担连带责任"，A公司显然要承担责任，B公司也负连带责任问题3在项目执行过程中，由于程序员老张独自修改了以进入基线的程序，小丁默许了他的操作，小丁的处理方式是否正确?你作为项目经理，应该如何处理？项目经理小丁不应默许老张的行为，且修改后的东西没有经过评审。项目缺乏变更控制体系，同时,项目团队其他成员不清楚变更程序的步骤和要求.建立配置管理体系建立变更请求流程组建变更控制委员会CCB问题4该案例中，项目管理的哪些方面需要改进？从项目管理9大知识体系出发阐述改进方面;本项目管理交弱的方面是重点改进方向：项目经理法律法规的理解（招投标管理）项目进度管理项目变更控制配置管理和计划的变更将导致成本、质量的变化案例分析二：项目变更控制项目背景某软件中心(A方）承担了某大型上市公司（B方）ERP系统开发与实施项目。项目计划确定后，在实施过程中,几次发生计划变更，原因如下：(1）证监会要求上市公司执行新的会计制度，需要修改ERP系统财务子系统；（2)B方首付资金未能按时支付，导致A方开发计划推迟；（3）A方盲目确定进度目标，实际难以完成；(4）B方因机构重组改变了业务流程，需要修改项目范围；（5）A方的前期设计有疏漏，需要修改设计方案；（6）B方提出增加合同审计功能,需要修改项目范围；(7）由于B方需求表达不清，A方理解有误，双方沟通不够，导致项目实施时发现需求偏差，需要纠偏；（8）B方自行负责的机房工程延误,影响了实施进度；(9）A方开发人员跳槽，影响了开发进度；（10）B方行业主管部门发布了新的行业ERP实施规范,需要修改项目实施方案.案例问题问题1项目变更的内部因素和外部因素分别指什么？由项目执行偏差导致项目计划变更的各种诱发因素称为项目变更的内部因素。由项目目标变化导致项目计划变更的各种诱发因素称为项目变更的外部因素。问题2上述5条变更，哪些属于内部因素？哪些属于外部因素？（2）（3）（5）（7）（8）(9）属于项目变更的内部因素；(1）（4)（6）（10）属于项目变更的外部因素问题3由于内部因素导致变更，从而可能增加建设经费？是否一定要由承建方承担？（3）（5)（9)属于A方责任，由此增加的项目费用由A方承担；(7）属于双发责任，A、B双方协商分摊；其余各条，无论B方是否负有责任，均应承担由此增加的项目费用.问题4对于由于内部因素和外部因素引发的变更请求，变更评估的重点有何不同？对于由内部因素引起的变更请求,变更评估的重点是确定最优变更方案；对于由外部因素引起的变更请求，应重点评估变更的必要性。案例一:范围定义项目背景黎明信息技术原本是一家专著于企业信息化的公司,在电子政务如火如荼的时候,开始进军电子政务行业。在电子政务的市场中,承接的第一个项目是开发一套工商审批系统.由于电子政务保密要求（国家要求)，该系统涉及到两个互不联通的子网：政务内网和政务外网。政务内网中储存着全部信息，其中包含部分机密信息；政务外网可以对公众开放，开放的信息必须得到授权。系统要求在这两个子网中的合法用户都可以访问到被授权的信息,访问的信息必须一致可靠，政务内网的信息可以发布到政务外网，政务外网的信息在经过审批后可以进入政务内网系统。丁伟是该项目的项目经理，在捕获到这个需求后认为电子政务项目建设和企业MIS项目有很大不同，有其特殊性,若照搬企业信息化项目原有的经验和方法必定失败。丁伟在该项目中采用了严格的瀑布模型，并专门招聘了熟悉网络互联互通的技术人员参与设计了解决方案，在经过严格评审后开始实施项目。在项目交付时，虽然系统完全满足了项目保密性要求，但用户对系统用户界面提出了较大异议，认为不符合政务信息系统的要求和风格,操作也不够便捷，要求彻底更换。由于最初设计的缺陷,系统表现层和逻辑层紧密耦合，导致70%的代码重写，而第二版的用户界面仍然没有达到用户的要求，最终又重写了部分代码才勉强通过用户验收。由于整个项目反复变更，项目组成员产生了强烈的挫折感，士气低落，项目工期也必原先的计划超出一倍，项目成本超出预算的100，项目用户满意度较低.该项目最终的结果与公司的期望偏差很大，黎明公司决定暂时放弃进军电子政务市场，并要求相应的事业部进行业务转型，大幅度裁员，骨干技术人员流失严重！问题1如何评估丁伟的项目管理行为？1。注意到了系统运行环境的特殊性，在良好设计和实现的情况下满足了用户要求2.忽略了系统用户的潜在要求，在用户界面和操作风格上范围定义不清,造成项目交付时产生重大变更3.第一次问题发生后仍没有对范围进行有效管理，造成项目第二次变更4.没有对用户界面是否能够满足要求的风险进行有效的管理，而采用抗风险较弱的瀑布模型组织开发5.没有对设计的质量进行有效控制，造成表现层和业务逻辑层紧密耦合,直接导致增加了变更代价问题2从项目范围管理的角度找出项目实施过程中的管理问题？1。没有挖掘到系统的全部隐形需求，缺乏精确的范围定义2.当发生第一次变更时，丁伟仍没有进行有效的范围管理，直接造成项目的第二次变更3。重复的系统变更说明丁伟对项目范围控制不足，导致项目范围接二连三的变更、反复问题3从范围管理的角度出发，如何避免类似问题的发生？有效的范围管理包括了从范围定义到范围控制等众多方面的工作，每一项工作都是重要的1。结合行业特点进行需求分析充分挖掘系统隐形需求2.通过原型法来验证需求的定义,避免范围定义不清的问题3.在发生需求变更时应进行有效的需求控制，在满足用户需求前提下缩小需求范围，避免需求再次变更案例点评这是一个失败的项目，丁伟在项目管理过程中既有闪光的地方，也要失败的地方;项目范围管理的失误是造成失败的关键原因：模糊的范围定义错误的工作分解缺失的范围确认无力的范围控制也暴露出风险管理、系统设计方面的问题案例分析丁伟对项目范围有一定把握（闪光点）发现了不同行业间具有不同的特点捕获到了政务内、外网的需求，并进行了定义，严格控制了这一需求的设计和实现如果忽视这一行业标准，项目将招致更大的失败丁伟对于像用户界面的风格和操作便捷性的需求没有充分考虑,导致一而再，再而三的变更没有意识到系统“隐形需求"的重要性行业特点决定范围约束（用户界面、操作便捷性)丁伟对项目范围和需求的定义理解并不完整电子政务行业特点,使对项目范围定义更加困难最终用户不参加需求和开发工作需求的间接性丁伟在范围确认和范围控制方面存在失误第一次变更就应该充分认识界面、操作的重要性应该立即采取措施清晰的定义界面风格、操作风格丁伟没有进行充分的风险管理隐形行规和行业特点意味着项目范围定义的风险采用瀑布模型增加了风险发生后带来的损失这个案例中，缺乏良好的设计也是明显的缺陷用户界面中耦合了大量的业务逻辑，增加了变更代价总结语项目的闪光点在于对项目运行环境进行了清晰的定义，并最终满足了用户的要求不充分的范围定义和范围确认导致了项目的失败采用抗风险较弱的瀑布模型和低质量的设计增加了项目范围变更得代价案例二：范围管理工作要点项目背景A集团是黎明信息技术的多年客户，黎明公司已经为其开发了多个信息系统，最近A集团又和公司签订了新的开发合同，以扩充整个企业信息系统的业务范围；张凡被任命为该项目的项目经理。项目经理张凡组织相关人员对该项目的工作进行了分解，并参考了黎明公司和A集团曾经合作的项目，评估得到项目总工作量为60人月，计划工期为6个月。项目刚刚开始不久,张凡的高层经理孙总找到张凡，孙总表示由于公司运作的需要，要求张凡在4个月内完成项目，考虑到压缩工期的现实,可以为该项目增派两名开发人员.张凡认为，整个项目的工作量是经过仔细分解后评估得到的，评估过程也参考了历史上与A集团合作的项目度量数据，该工作量是客观现实的。目前项目已经开始,增派新的开发人员还需要一定时间的熟悉，因此即使增派两人也很难在四个月内完成项目，如果强行要求项目组成员通过加班加点方式追逐4个月完成项目的目标，肯定会降低项目的质量，造成用户的不满.对此，张凡提出的解决方案是：将整个项目分成两部分实现，第一部分使用三个半月的时间，第二部分使用三个月的时间，分别制定出两部分的验收标准,这样不增派开发人员也能完成项目.高层经理孙总认为该方案可以满足公司运作的要求，用户也同意按照这种方案进行实施。六个半月以后,项目在没有增加人员投入的情况下顺利完成，虽然整个项目比最初的计划延长了半个月,但既达到了公司的要求，客户对交付的系统也比较满意，项目成员也没有感受到很大的压力。问题1点评张凡是如何应对项目范围变更的，采取了哪些措施？1。首先对最初的项目范围进行了清晰的定义，并根据定义对项目任务进行了分解，制定了WBS2。对项目进行了估算，且估算结果真实可信，对项目工作量有量化的把握3。在出现新的项目目标后,对项目范围进行了控制，缩小了第一阶段实现的项目范围4。对重新定义的项目范围进行了确认，与高层经理和客户达成了一致5.对项目进行了沟通管理，协调了多个项目关系人之间的矛盾问题2结合案例指出项目范围管理的工作要点？1。制定范围管理计划2.进行项目范围定义3。项目工作分解WBS4.进行项目范围确认5。对项目范围进行控制本案例中,张凡首先进行了范围定义和工作分解，得到清晰的项目范围；在出现新的项目目标后，张凡进行了范围控制，重新定义了两个阶段的项目范围；最后，将重新定义的范围与项目干系人进行了确认案例点评1。这是一个成功的项目管理案例,项目经理张凡有效的运用范围管理手段，在不同项目干系人中达成一致，使项目的结果同时满足了公司高层经理、客户、项目组成员的要求.2。作为一个项目经理,必须熟练掌握和应用项目管理九大知识领域的技能，对于信息系统开发项目而言，范围管理是其中最重要的技能之一。3.软件项目的范围主要是由系统需求构成的,而系统需求既是难以把握的，也是容易调整和控制的（1)在满足项目目标前提下，可以定义出不同的系统需求(2）根据经验，软件项目管理总是从范围管理开始，先定义系统的边界，然后再在明确的范围内进行时间、成本、质量和风险的管理(3)范围、时间、成本、质量之间的逻辑关系是项目管理的客观规律（4）当范围因素已经确定的条件下，不妨根据时间、资源（成本）的重新计划来调整合理的项目范围4。软件项目的范围变更应重新进行项目计划的调整将项目分解成两部分，实际上项目范围已经被扩大了范围变化导致任务、任务之间的逻辑关系的重新调整需要考虑分割项目的验收标准，这是与用户达成一致的前提5.范围控制并非总是针对客户的要求而进行的控制项目范围控制需求,这个公式是错误的设计策略是项目经理可以把握的（够用策略、牺牲质量特性策略、过度设计）即使需求已经确定，有效的范围管理仍能给项目带来巨大收益范围管理的空间很大，带来的收益是降低成本、缩短工期6.案例中,张凡还运用了其他范围管理手段项目刚开始，对项目范围进行了定义划分了项目WBS,并对项目进行了估算、计划在孙总提出缩短工期的要求后，首先进行了范围控制，缩小了第一步需要完成的项目范围，接着又对两阶段需要完成的项目范围进行了重新定义制定了两阶段验收标准对重新定义的范围进行了确认，与客户、高层经理达成一致7。总结语张凡在范围管理方面进行全面的控制，此外也运用了其他项目管理手段,包括对项目估算计划（时间管理），协调多个项目干系人之间的矛盾（沟通管理）案例三:范围确认黎明信息技术和M企业签订了一份合同，合同的主要内容是处理黎明公司以前为M公司开发的信息系统的升级工作。升级后的信息系统可以满足M公司新的业务流程和范围；王强被任命为该项目的项目经理,由于该项目是一个现有系统的升级项目，王强特意请来了原系统的需求调研人员李伟担任该项目的需求调研负责人。在李伟的帮助下，很快完成了需求分析的工作，并进入设计和编码,由于M公司的业务非常繁忙，M公司的业务代表没有足够时间投入到项目中,确认需求的工作一拖在拖。王强认为双方已经建立了密切合作的关系，李伟也已经参加了原系统的需求开发工作，对M公司的业务比较熟悉,因此定义的需求是清晰的，故王强并没有催促业务代表在需求说明书中签字。进入编码阶段后，李伟因故移民加拿大，需要离开项目组，王强考虑到系统需求已经定义,项目也进入编码阶段，李伟的离职虽然会对项目造成一定影响，但影响较小，因此很快为其办好离职手续。在系统交付的时候，M公司的业务代表认为甲方已经提出的需求很多没有实现,实现的需求也有很多不能满足M公司现有的业务要求，必须全部实现这些需求后才能验收。此时，李伟已经离开项目组，没有人能够清晰地解释乙方已经完成的需求说明书。最终系统需求发生重大变更，项目延期超过50%，M的业务代表也因为系统的延期表示了强烈的不满。案例问题问题1对王强在项目管理工作中的行为进行点评。1。王强为了更明确地把握系统需求，聘请了原系统需求调研人员李伟，提高了需求定义的效率和质量；2。王强没有对李伟提供的系统需求进行评审核复查，从而使需求的缺陷没有被及时发现；3。王强没有要求用户对已经定义的需求进行确认,从而导致需求理解的偏差；4.王强对需求缺乏有效控制，最终导致项目延期50问题2从项目范围管理的角度找出项目实施过程中的管理问题？项目实施过程中的主要问题包括:1。在范围定义过程中，王强没有对李伟定义的需求进行评审，造成需求中的质量缺陷没有被及时发现；2.在范围确认过程中，王强没有主动要求用户对需求进行确认；3。在范围控制过程中,王强无法进行有效的范围控制，最终造成了重大的需求变更。问题3从范围管理的角度出发，如何避免类似问题的发生？本案例说明项目范围管理中应采取以下规避措施：1。项目经理需要对需求定义的结果进行质量控制，采取评审等方式减少需求定义中存在的缺陷；2。对已经定义的需求要及时与用户进行确认，保证双方理解的一致；3。在发生需求变更时，应采取灵活手段,在满足用户需求的前提下，尽量减少需求变更得范围.案例点评1.这是一个失败的项目，和很多失败的软件项目一样，王强在项目范围（或软件需求）方面栽了跟头；项目经理王强即重视需求，又没有控制好需求的案例开发和定义软件系统的需求是整个项目过程的关键管理项目范围是常识,但往往因为一时的疏忽而造成需求的重大缺陷2。项目实施过程经历了波折，但未引起重视，最终失败！项目开局：充满光明项目中期：出现乌云项目交付：下雨了3。王强在项目管理中成功的方面找到合适的资源进行需求的定义可以快速准确地把握新系统的需求4。王强在范围确认和范围控制方面存在失误认为紧逼客户确认需求不近人情，抱着侥幸心里进入开发阶段未履行需求评审和确认过程，造成缺陷未及时发现需求控制失去基准，导致重大变更5。从项目管理的角度分析,项目范围直接决定了工作量和工作目标，项目范围管理中的关系范围定义：管理的基础范围确认：基线化已定义的范围范围控制：减少变更,保持范围的稳定6。项目范围确认的方法客户代表确认需求说明书（需求报告）召集客户的业务骨干对需求进行评审详细记录原始的调研材料，让客户确认调研报告迭代开发逐步确认需求案例分析五：项目工程网络图的绘制项目背景某化工厂拟进行管道安装工程，工程进度如下表所示，绘制该项目的工程网络图.绘制双代号网路图步骤第1：从起始活动开始，画出第一个活动的紧后工作画出 A 活动和其紧后活动,即 B、C、E、F图2 图1第2：从左到右依次找出紧后活动找出 B、C、E、F 的紧后活动B、C 的紧后活动是 DF 的紧后活动是 GD、E 的紧后活动是 I由于 B、C 活动对 D 是平行工作因此引入虚活动第3:从左到右依次找出紧后活动找出 I、G 的紧后活动D、E、G 的紧后活动为 HD、E、G 对 H 来说是平行工作，因此引入虚活动H、I 活动的紧后活动是 J第4：从左到右依次找出紧后活动找出 J 的紧后活动 K、L第5:从左到右依次找出紧后活动找出 K、L 的紧后活动 M、N由于 K、L 活动对 M 是平行工作因此引入虚活动第6：从左到右依次找出紧后活动找出 M、N 的紧后活动 P完成初步工程网络图该项目的单代号网路图案例分析六:网络图时间参数及关键路径确定项目背景某公司弱电布线工程项目，双代号工程网络图如下所示，确定该项目关键路径。一般网络时间计算第1:计算工作最早时间 ES、EF第一个活动 ES=0ES = max紧前工作的EFEF = ES + 工作延续时间 (t）第2：计算工作最迟时间 LS、LF最后一个活动 LF（n） = EF（n)LF = min紧后工作的LSLS = LF - 工作延续时间 (t）第3：计算总时差TF总时差是指不影响整个项目最早完成时间的前提下，一项工作的完工期可推迟的时间TF = LF EF 或者 TF = LS ES第4：计算自由时差FF自由时差是指不影响紧后工作的最早开始时间的前提下,一项工作的完工期可推迟的时间FF = minES（紧后工作) EF确定关键路径案例分析七：软件项目的时间管理和成本管理项目背景小张为蓝德公司技术总监，最近接到公司任务，负责开发一个电子商务平台，由于公司业务发展需要,公司总裁急于启动电子商务平台项目，要求小张尽快准备关于启动电子商务平台的立项报告小张粗略估算该项目正常速度下的时间和成本在第一次项目策划会议上，项目团队确定了与项目相关的任务在第一次项目策划会议上，项目团队确定了与项目相关的任务,具体任务情况如下第一项任务：调研现有的电子商务平台按正常速度估算完成该任务需10天，成本15000元允许最多加班情况下，需要7天，成本18750元第二项任务：制定项目计划并提交管理层评审估计正常情况下需要5天，成本约3750元加班赶工时可在3天完成,成本为4500元第三项任务：需求分析、系统设计历史估计为15天，成本45000元加班时约需10天,成本58500元设计完成后,有三项工作必须同时进行开发电子商务后台数据库在不加班情况下估计需10天，成本9000元加班情况下估计仅需要7天，成本11250元开发和编码前台网页脚本项目团队估计可在10天完成，成本17500元如果允许加班可缩短2天时间，成本19500元电子表单控件设计与开发采用外包方式进行，需要7天，外包成本8400元没有加班赶工方案整个电子商务平台集成、测试约3天，成本4500元，如果允许加班可节省1天，成本6750元案例问题【问题1】如果不加班，完成此项目的成本和时间是多少？考虑加班，项目可以完成的最短时间和最短时间内完成项目的成本是多少?【解答】需要进行关键路径的计算，根据关键路径法(CPM）注意：最短完成时间路径并不是加班情况下的最短路径，而是最长路径-关键路径关键路径：èèèèèè累计关键路径工期，完成项目需43天，累计成本即项目成本约103,150元累计关键路径中加班后的最短时间，为30天，成本为127,650元【问题2】假定调研其他电子商务平台的任务需要13天而不是原先估算的10天，项目经理小张应采取什么行动来保持项目按正常速度进行且增加的成本最少?【解答】由于调研电子商务平台活动è在关键路径上，导致整个项目工期延长3天，因此应考虑加班赶工来保证整个项目进度,