管理信息系统案例——案例3.ppt

* ——面对客户的需求变更 在某公司的项目管理课堂上，小李，小王等人正在七嘴八舌地议论纷纷。原来，大家正在讨论小王的公司最近遇到的两个颇为有趣的项目。 据小王介绍，这两个项目分别由两个项目经理来担任。其中，项目经理A属于“谦虚”型，对于客户提出的问题，无论大小都给与解决，客户对此非常满意，然而，项目进度却拖得比较长，而且，客户总想把所有的问题都改完再说，项目已经一再延期。 相比之下，项目经理B显得稍有些“盛气凌人”，对于客户提出的问题，大多都不予理睬，客户对此不是很满意，不过，该项目的进度控制得比较好，基本能够按期完成项目。? 话刚一说完，小李就抢着说：“A比较像我，一般在和我的一些战略客户打交道的时候，我基本是有求必应，与客户的关系处得如鱼得水，这样做肯定不会错。就像前天我连合同都写错了，找到客户，人家二话没说就同意改了。你说如果是B的话可能吗？”? * 小王对此不以为然，“对项目经理来说，成本、质量和时间是最为重要的三要素。与客户的关系当然很重要，但也要全盘考虑项目的各要素。对于用户的要求，应该在有限的范围内给与解决，但不可以做出太大的牺牲。一味的迁就用户将会使整个项目失败。”? 小林接着小王的话说：“当前，国内的项目一般情况下是由销售处出面签单，再由项目经理接手后续的工作，因此客户关系多在事前已经搞定。发生新的情况后，可以由公司的公关部出面与客户进行协调，项目经理可以在此过程中坚持一下原则，与公司的公关部一个红脸，一个白脸，唱出一出好戏。” 小赵反驳道：“不管怎样，客户才是第一位的。客户可以给你带来收入，也可以给你带来更多的客户和工作，有什么道理不多配合一下他们呢？说实话我对B的做法蛮欣赏的，可惜行不通。因为客户是上帝，如果照B的做法，后果会造成做一次项目丢掉一个客户，太不划算了。”? * 问题：? 1、如果你的项目遇到需求变更问题，你会采用哪种方式去应对？??????? 2、分析这两种应对需求变更方式的优缺点。 * 这个问题是项目管理过程中的一个经典问题。 变更管理的几个关键点： 第一：所谓客户提出的“问题”到底是什么？? 第二：如何“管理”这些问题？ 第三：如何与管理时保证良好客户关系？? 从案例中的提供信息来看，这里的谈到的“问题”大概指“变更”。项目中常见的变更有两种，“范围变更”和“需求变更”。? * 范围变更可以通过事前工作说明书中中的明确定义进行界定，判断和管理都相对简单。对于工作范围中没有定义的内容，项目经理就可以明确拒绝（但怎么说“不”非常有讲究！），并可以转化成为商务问题由销售出面解决。? 而需求变更不但数量大，且界定和管理都要复杂的多。软件项目中，例如界面风格的改变，数据库字段的变化等，都涉及极大的工作量，而且在需求分析阶段很难保证一次正确。我所在的公司中，这类变更也是让项目经理最头疼的。 因为范围变更相对容易，接重点谈谈如何管理“需求变更”。先要扭转一个观念：管理变更的目的绝对不是不让客户变更，更不是扳着面孔一口回绝，而是要让变更受控，让变更有秩序的进行。 * 为此，一个比较有效的方法是在项目开始前就制定变更管理流程，并与客户达成一致。 变更管理流程可以根据项目的具体情况设计，但个人认为有四个关键控制点一定不能放松，那就是：授权，审核，评估，确认。 * 授权：只有经过授权的客户接口人才能提交变更单，只有经过授权的项目接口人才能接受变更单。这样做一来可以保证变更都被有效记录，二来可以避免客户内部尚未达成一致的变更被提出来。? 审核：项目经理要对书面的变更分析，分出轻重缓急，并与客户沟通。哪些应该回绝，哪些可以推迟，哪些可以接受。经过项目经理过滤之后，变更的数量应该可以大大减少。? 评估：请技术人员对于变更的涉及的范围，引发的工作量和风险，以及对进度的影响进行客观的量化评估。切忌不可夸大，否则会丧失客户的信任，造成额外的困难。? 确认：将评估的结果与客户一起进行讨论，与客户一起决策。告诉客户“我可以改，但对项目的影响是…”，客户也是讲道理的，大多数情况会达成一致。即使有时客户一时难以接受，但讨论的焦点也会集中到客观的评估结果上来，而不是涉及项目经理的性格、甚至对客户尊重不尊重的这类问题。 * 上述方法是变更管理的基本要点。但如果只能执行管理流程，对项目经理来说那才仅仅是及格。优秀的项目经理，还能够在这个过程中保持甚至加深与客户的关系！?? 如何做到这点呢？理解客户！仔细思考就会发现，客户需求的表面之下，往往隐含着真正的“需要”。举个生活中的例子，买衣服时对颜色、款式和面料等会有多方面的需求；而这之下隐含的需要却可能是为了“御寒”，可能是为了“漂亮”，还可能是为了“体面”。如果能够弄清客户的需要，往往能够提供服务时能起到事半功倍的效果。? * 小H貌不惊人，甚至一着急还会有点口吃