第七章 IT项目控制管理实践.ppt

* * 案例分析 分析11：标题：合同类型????? 出现这种情况在中国应该是很正常的，目前要确定所签合同的类型，如果是CPPC、CPIF、CPFF合同那就不用怕;如果是FPPIF、FFP合同，那就要亡羊补牢了，尽快草拟项目的范围清单和客户协商确认，并提示客户会尽量满足更改的要求，但可能会影响交货日期！??  案例分析 分析12：标题：太简单了???? 最简单的办法，亡羊补牢? 既然已经造成这种局面，双方就诚心、诚信、平等地面对面地谈? （1）确定详细的范围，确定后续变更范围的处理方法；? （2）确定所有的工期，按照工期投入资源；?（3）经常沟通，最大限度的了解业主的意图，最大限度的让项目组的人了解项目的要求。和人打交道是最难的。 ??  案例分析 分析13：标题：是，所有的项目都是可以管理好的??? 所有的项目都是可以管理好的，关键是要按照项目成功的法则去管理，不要把不正确的、不合适的管理理所当然的认为是正确的管理。?? 事后控制——风险管理报告 无论项目进展的情况如何，都必须将风险管理的计划、行动、结果整理、汇总、进行分析，形成风险管理报告。风险管理的持续性要求风险管理报告的连贯性和不间断性，因此，该报告不是仅仅在项目结束之后才制作的，而是应该视项目的进展状况、项目计划、报告的对象等条件采取书面或口头、不定期的或阶段性的等多种方式，为项目的实施、控制、管理、决策提供信息基础。  案例分析-如何控制好用户的变更需求 （一）案例正文 目前，我在负责一个海外的IT通信工程项目，客户是当地的电信领域一个运营商。 由于客户是新进入当地市场，所以相关的经验比较匮乏。加之我公司对当地的一些情况不是很清楚（我们曾努力过，但需要时间），这样从合同签订开始，用户的需求变更就非常频繁，直接带来了成本和人力等方面的增加。 在PM层面，我们可以制约他们的PM。但是有时客户往往把一些事情上升到总裁的层面，我们PM执行层面临来自市场的压力，往往就答应了变更。 请大家帮忙分析一下，在这种情况该如何控制用户的需求变更？  案例分析 变更，既是客户的权力，也是客户的为难之处，乙方应该真诚体谅和积极配合。问题是，不能让权力滥用，不能把本来不好意思的变更，宠惯养成堂而皇之的坏毛病。所以，作为乙方的PM，我们确实要想办法“控制变更”，目的是保证我们的有限资源能够尽可能配合“有效变更”，同时尽可能减少“无效变更”对成本、工期和履约带来的负面影响。这是基本原则。 对待客户频繁的、自上而下的需求变更，建议迅速采取以下办法应对，避免事态蔓延，不让客户养成随意变更的毛病。  案例分析 1）?立即建议客户建立变更审批/下达制度，要求明确审批环节、审批人员、审批事项、审批流程、审批表格样式……，目的有两个：第一，将客户下达变更的流程尽可能地复杂化、官僚化和长期化，减少张嘴就来的非必要、非紧急、非合理、非高层领导意图的“无效变更”。第二，留下书面依据，为今后可能的成本变更和索赔准备好“变天账”。凡未履行审批程序的“变更”，一律是无效变更不予受理，在避免乙方损失的同时，也有助于减少客户无谓的风险。让我们以“加强管理、优质服务”为理由，说服客户把变更审批流程变得更困难些吧！  案例分析 2）?强化自身计划管理和节点控制的功夫，立即向客户正式提交一份各阶段主要工作节点和技术关键事项的完成计划，注明任何可能的变更必然引起的时间、事件、成本/工期的代价和增加的具体工作量，建议/要求客户配合这个计划，确定变更时限，控制变更规模，过时变更不候，离谱的变更不做，保大局弃小变，推进项目前进。  案例分析 3）?对于已经形成惯例的零星变更，要努力争取“集中研究、批量处理”，每周或每两周甚至每月召开一次变更专题会议，集中研究处理这些零碎变更事项，主动控制好工作节奏，硬着头皮顶住要求随时处理这些零星变更的压力，尽量避免由于处理零碎变更而影响项目运行的总体态势。  案例分析 4）?最后，按照客户爱走上层路线的习惯，乙方PM也要随机应变，手眼通天，善变求生，将有关措施和意见随时抄报双方最高层留档备案，采取简报、文件、传阅、抄报、抄送、会议等多种形式，掌握舆论主动权，逐步让不合理的随意频繁变更，成为客户不好意思开口的尴尬事件，尽快形成正常的项目执行氛围和良好的工作习惯，也为可能受到影响的项目和变更所带来的责任问题留下伏笔。  案例分析 分析1：?? 标题、老板的决定是对的???? 变更带来的不一定就是成本的增加，客观分析变更内容，站在技术的角度向客户分析利弊，如果确需变更，即使增加了成本也要满足客户需要，这是市场的要求，我相信满意的产品会给你们带来应得的收入，有耐心就会有收获。  分析2：?? 标题、我的建议?? 用户需求