计划项目管理计划与案例分析题.doc

-/ 案例分析一：项目管理过程 项目背景 某市电子政务信息系统工程，总投资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.首先对最初的项目范围进行了清晰的定义，并根据定义对项目任务进行了分解，制定了WBS 2.对项目进行了估算，且估算结果真实可信，对项目工作量有量化的把握 3.在出现新的项目目标后，对项目范围进行了控制，缩小了第一阶段实现的项目范围 4.对重新定义的项目范围进行了确认，与高层经理和客户达成了一致 5.对项目进行了沟通管理，协调了多个项目关系人之间的矛盾 问题2 结合案例指出项目范围管理的工作要点？ 1.制定范围管理计划 2.进行项目范围定义 3.项目工作分解WBS 4.进行项目范围确认 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 的紧后活动是 D F 的紧后活动是 G D、E 的紧后活动是 I 由于 B、C 活动对 D 是平行工作 因此引入虚活动 第3：从左到右依次找出紧后活动 找出 I、G 的紧后活动 D、E、G 的紧后活动为 H D、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=0 ES = max{紧前工作的EF} EF = ES + 工作延续时间 (t) 第2：计算工作最迟时间 LS、LF 最后一个活动 LF(n) = EF(n) LF = min{紧后工作的LS} LS = LF - 工作延续时间 (t) 第3：计算总时差TF 总时差是指不影响整个项目最早完成时间的 前提下，一项工作的完工期可推迟的时间 TF = LF – EF 或者 TF = LS – ES 第4：计算自由时差FF 自由时差是指不影响紧后工作的最早开始时间的 前提下，一项工作的完工期可推迟的时间 FF = min{ES(紧后工作)} – 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天，因此应考虑加班赶工来保证整个项目进度，为保证项目进度，需赶工3天 赶工原则是“优先考虑赶工费率最低的工作” 根据赶工费率分析， 活动②—③和④—⑥费率最低 活动②—③只有2天可赶工时间，还差1天 但选择活动④—⑥赶工1天将导致④—⑤也需赶工1天 活动④—⑥赶工1天的实际赶工费率是1,750元 因此，应选择①—②赶工1天，费率是1,250元 【答案】 选择①—②赶工1天， ②—③赶工2天，此方案增加的成本是2,000元（=1250+275*2） 【问题3】 假定老总想在35天内完成项目，项目经理应采取什么措施达到预期要求？ 在35天完成项目将花费的成本是多少？ 【解答】 显然需要在制定赶工调整方案，但必须考虑关键路径上活动的变化导致其他非关键路径的变化情况，关键路径上的工期：10+5+15+10+3=43天 关键路径上正常工期43天，需赶工8天（=43-35） 根据赶工费率分析，赶工方案为 ②—③赶工2天，①—②赶工3天，④—⑤/④—⑥各赶工2天 ⑧—⑨赶工1天 总成本=103,150+750+3750+3500+2250=113,400元 ②—③赶工2天，①—②赶工3天，④—⑤/④—⑥各赶工2天，⑧—⑨赶工1天 总成本 = 18750+4500+45000+11250-750+19500+8400+6750=113,400元 案例分析 活动排序、编号 绘制工程网络图 案例分析八：活动排序和进度控制 项目背景 蓝德公司承担一项网络工程项目的实施，公司系统集成工程师小丁接到任务后分析了项目任务，并开始进行活动手工排序 小丁分析出活动A所需时间为5天，完成活动B所需时间为6天，完成活动C所需时间为5天，活动D所需时间4天，活动C、D必须在活动A完成后才能开工。完成活动E所需时间为5天，且在活动B、C完成后开工，活动F在活动E之后才能开始，所需时间为8天，完成活动B、C、D完成后，才能开始G、H，所需时间分别为12天、6天。活动F、H完成后才能开始活动I、K，所需时间分别为2天、5天。完成活动J所需时间为4天，只有当活动G和I完成后才能进行。项目经理据此画出工程施工进度网络图 案例问题 【问题1】 该项目经理在制定进度计划中有哪些错误？ 请计算相关活动时间的6个基本时间参数？ [ 错误 ]没有表现出活动 G 的前置条件是B、C、D的完成[ 改正 ]增加虚活动 ③—⑦ 顺推法确定最早开始、最早结束时间 项目工期29天，逆推法确定最晚开始、最晚结束时间 【问题2】 项目经理于12天检查时，活动D完成了一半的工作，活动E完成了2天的工作，以最早时间参数为准判断D、E的进度是否正常？ [ 分析 ]1.由表中分析活动D最早完成时间应为9日 ，2.活动E最晚时间应为15日 [ 结论 ]1.活动D已延期，还需2天 ，2.活动D实际完成（12+4/2）=14天完成，延期5天 3.活动E在第15天完成，实际（12+3）=15，进度正常 【问题3】 由于D、E、I使用同一台设备施工，以最早时间参数为准，计算设备在现场的空闲时间？ 【解答】 活动D、E、I的时间跨度分析如下，由于使用同一设备，完成活动所需时间累计为4+5+2=11天，三个活动最早开始与5（活动D），最早完成为25日（活动I）跨度20，因此设备闲置累计9天（20-11） [ 结论 ]1.活动D最早完成为第9天，E最早开始于第10天，设备闲置1天 2.E最早完成为第15天，I在第23天开始，设备闲置8天 【问题4】 H工作由于工程师的变更指令，持续时间延长为14天，计算工期延迟天数 [ 结论 ]1.活动H延长导致最早时间递延变化，2.最终项目在30天完成 3.整个项目延期1天（30-29） 案例分析 根据案例信息，编制项目工作分解结构（WBS） 案例分析九：项目状态分析 项目背景 某工程项目各个项目周期预算如表9-1 第8周项目检查点任务完成情况如表9-2 第8周项目实际费用花费如表9-3 案例问题 【问题1】 根据上述项目实际数据，计算该项目每期累计挣得值？ 挣得值BCWP=计划工作量x预算定额 由表9-1预算情况和表9-2实际工作完成情况可计算出各期挣得值，如表9-4 【问题2】 根据第8周检查结果，预测该项目完成的总费用和进度情况。 费用偏差 CV = BCWP – ACWP = 54 – 68 = -14 进度偏差 SV = BCWP – BCWS = 54 – 64 = -10 费用执行指标 CPI = BCWP/ACWP = 54 / 68 = 0.79 进度执行指标 SPI = BCWP/BCWS = 54 / 64 = 0.84 费用预测 预测值 = 总预算/CPI = 100/0.79 = 126.58 进度预测 预计完成时间 = 计划完成时间/SPI = 12/0.84 = 14.29 案例分析十：甘特图成本分析 项目背景 某小型项目有4项任务，图10-1是这个项目进度安排的甘特图，预算在蓝色甘特图右侧 第6周末项目检查时各项任务完成情况如图10-2所示，图中红色甘特图是项目实际情况，各项任务的实际费用如图中第2列数据所示 【问题1】 根据第6周检查所得信息，计算BCWS、BCWP、CV、SV，预测项目完成时的费用和进度？ 【解答1】计算结果如图10-3所示 成本和费用偏差： CV=BCWP-ACWP SV=BCWP-BCWS 计算结果如图10-3所示 费用执行指标 CPI=BCWP/ACWP=285/300 = 0.95 进度执行指标 SPI=BCWP/BCWS=285 /350 = 0.81 费用预测 EAC 预测值 = 总预算/CPI = 500/0.95 = 526 预测值 = ACWP+（总预算-BCWP）/CPI = 300+(500-285) /0.95 = 526 进度预测 预计完成时间 = 计划完成时间/SPI = 9/0.81 = 11 【问题2】 用图分析项目的成本情况，即绘制项目的预算费用曲线、实际费用曲线和挣值曲线。 【解答2】 首先，进行预算费用（Budg）按时间分摊 其次，进行实际费用（ACWP）按时间分摊 第三，进行挣得值（BCWP）按时间分摊 得到图10-4，据此绘制挣值曲线 用图分析项目的成本情况，即绘制项目的预算费用曲线、实际费用曲线和挣值曲线。 案例案例分析十一：项目成本管理 项目背景 蓝德公司决定开发一个保险管理系统（SMIS），该项目任务重、进度要求紧并且成本要求尽可能节省。该公司有着丰富的保险行业项目经验，项目经理在完成系统分析后，预计该软件规模约20万行左右，计划160天完成项目，平均每天完成1250行代码，每天项目成本约2000元， 为达到控制项目成本的目标，项目经理仔细记录了项目组第一阶段的工作情况 项目团队在对系统的设计开发过程中，花了10天进行部分系统的开发 平均完成代码设计1300行，按项目的设计成本，平均每天花费2100元 案例问题 【问题1】 项目在前10天的PV、AC、EV值是多少？判断该项目照此效率是否能按期完成？是否超出原先预算？ 【解答1】 挣值分析的关键指标： PV=计划工作量x预算定额 ，AC=持续时间x实际日成本 EV=已完成工作量x预算定额 ，CV=EV-AC，SV=EV-PV PV = 10天x2000元/天 = 20000元 AC = 10天x2100元/天 = 21000元 EV = 1.6元/行x1300行/天 = 20800元 CV = 20800 – 21000 =-200元 项目处于超支状态 SV = 20800 – 20000 = 800元 项目进度提前与计划进度 【问题2】 根据项目前10天的数据，画出项目的挣值图。根据前10天开工情况，计算项目完工时的总预算（假设后面的开发仍旧照此进度和花费），并说明原因。 【解答2】 由问题1计算得出结论，AC>EV>PV CPI=EV/AC CPI=20800/21000=99% EAC=AC+(BAC-EV)/CPI =21000+(1.6x200000-20800)/0.99=323077元 【问题3】 请简述针对项目情况，应该采取何种措施既能保证进度计划，又能保证成本预算？ 【解答3】 因为存在AC>EV>PV，所以可以得出此项目第一阶段开发中，效率不高（较低），进度较快，投入超前的结论 应该采取的措施可以总结为： 降低开发成本，稍微放缓开发进度，同时应保证项目质量 采取抽调出部分开发人员来放缓开发进度，节省部分费用 案例分析 从案例来看，已收集数据为“规模”和“费用”数据，应从成本管理的角度分析问题 挣值方法是对项目进度和成本进行综合控制的一种方法，是测量项目绩效、效率的常用方法 挣值方法通过与计划完成的工作量、实际挣得收益、实际的成本进行比较，可以确定成本、进度是否按计划执行 挣值分析有几个关键值 预算成本（PV）、实际成本（AC）、实现价值（EV）和完成尚需估算（ETC） 挣值方法有四个评价指标 成本偏差（CV）、进度偏差（SV） 成本绩效指数（CPI）、进度绩效指数（SPI） 使用挣值方法可以确定该项目开工情况（绩效） 案例分析十二：项目范围与需求的质量管理 项目背景 X公司承接了B银行软件开发项目。该公司与B银行以前有过长期的合作，此次项目是一个与证券业相关的新研发项目，没用相同项目开发经验，公司同意在没有完全确定需求的情况下先进行开发，策略是希望在开发过程中不断完善项目需求。 公司为此项目配备的项目经理是张工，三个程序员参与项目开发，B银行派技术人员赵工参与项目的需求分析和进度监督。项目开发初期比较顺利，随着项目的推进，渐渐暴露出一些问题 1、项目需求的不确定性导致开发效率很低，比如一个界面上的小问题由于银行技术人员赵工的不满而导致开发进度停滞不前； 2、由于公司项目组成员和银行技术人员缺乏证券相关知识，导致对业务逻辑理解不一致，使得系统的几个主要流程存在错误； 类似质量问题不断出现，导致最终项目严重延期，项目最终暂停 案例问题 【问题1】 该公司和B银行同意在不确定需求就投入研发，这种做法对软件质量有什么影响？ 如果这种做法有一定客观原因，如何在开发前期弥补？ 软件项目的需求决定了项目的功能和目标，如果不能在项目开发进行前确定需求，就不能确定项目的目标 目标不明确就没法制定下一阶段的工作计划 没有明确的项目计划就不能保证项目的质量 项目质量管理也无从开展 如果由于时间等其他客观原因导致无法在软件项目开发之前明确需求，可采取以下措施弥补 将待定项目分解成几个部分、阶段 开发之前分析、明确一部分需求，然后制定一个子工作计划完成该部分需求的设计和开发 继续分析另一部分需求，然后相应制定另一个子工作计划来实现 通过保证分阶段目标的项目质量来确保整体项目的目标和质量 【问题2】 该项目经理在事情中负有什么责任，如何履行他的责任？ B银行的赵工在事情中负有什么责任，如何履行他的责任？ 该项目经理不了解需求对于项目质量的重要性 对项目需求的重要性缺乏意识，导致后期无序工作，效率低下，最终导致项目失败 该项目经理应采取的措施 与B银行赵工一起将项目按阶段划分，明确阶段目标并制定阶段工作计划，通过分阶段工作目标实现整个项目目标 B银行的赵工对自己的关键责任认识不足 赵工是业主需求提出人，应在项目开始之前明确项目需求，并对需求分析结果及时进行确认 由于项目需求不明，导致整个项目没有清晰的目标，并最终失败 应该根据项目划分明确部分需求，并协调业主方职能部门进一步细化项目其他部分需求 当项目需求变更时，应和张工一起协商，然后才能调整需求，一起调整工作计划 【问题3】 在项目需求分析阶段，如何通过明确需求来保证项目的质量？在项目的其他阶段如何继续保持项目的质量？ 项目负责人和需求提出人需尽早分析相关业务逻辑，通过业务流程明确整个项目需求 在项目需求得到明确的前提下制定相应开发计划 项目实施阶段，进一步明确分阶段的需求，并制定子计划，使整个项目实施得到有效分解 通过保证子计划的质量来保证整个项目的质量 案例分析十三：项目实施过程的质量管理 项目背景 X公司为某证券公司部署一套证券柜面交易系统，经过开发调整系统投入运行，软件某些方面尚不完善，最近证券市场上某些交易规则做了变动，因此需对此柜面系统进行升级。 经过一段时间的准备，升级开发工作已基本完成，