《509案例：项目经理的阴谋诡计.ppt》由会员分享，可在线阅读，更多相关《509案例：项目经理的阴谋诡计.ppt（11页珍藏版）》请在三一办公上搜索。
1、,案例:项目经理的“阴谋诡计”,从CIO那里接下为市场部开发费用管理系统的任务后，Sam回到办公室，翻出了以前的项目档案。原来3年前开发部曾经为市场部开发过一个类似的系统，但是由于当时正赶上公司的业务方向调整和组织结构变动，导致了系统刚刚上线即面临下马的窘况。究其原因，很大程度上是因为当时的系统设计不够灵活，流程都是固化在程序里，根本无法适应业务的调整，而重新修改代码的代价又太高，工期也无法保证，所以只好选择放弃。放下手中的项目档案，Sam感到压力重重。市场部是公司的“消费大户”，每年在市场营销上的投入高达几千万，然而市场部却是公司唯一没有成功实施信息系统的部门，一直靠人工的方式来管理庞大的营
2、销费用，整个市场部没有谁能说得清这么多钱到底花在了哪里，是否获得了预期的效果，有没有被挪用和浪费，甚至被贪污。,从当前费用管理的情况来看，存在着业务流程混乱，计划变更频繁，合同管理松散，费用报销严重滞后，工作效率低下等诸多问题；总部对各分公司的费用管理和控制基本处于半失控的状态，没有什么手段和依据来限制分公司对营销费用的使用；对营销费用的投入和收效知之不详，制定费用预算时往往只能“跟着感觉走”，没有切实可信的数据可供参考。眼前状况堪忧，前方荆棘密布，Sam犯了难，这个项目到底该怎么做呢？,案例参考意见,首先，明确项目定位。市场部作为公司营销策略的制定者和执行者，其营销行为的成功与否，对整个供应
3、链的销售、生产、采购等环节都有着直接或间接的影响，其重要性毋庸置疑。市场部本身的业务繁多，包括营销策略的制定、市场公关、创意企划、费用管理等等，从信息化的难易程度、紧迫性和重要性来看，对数额巨大的营销费用的监管和控制无疑是重中之重。因此，项目的切入点应当首选“营销费用管理”这块业务。根据目前信息化的发展趋势和业务需要，Sam将项目定义为“市场营销费用管理平台”，把建立起一个包括“预算管理计划制定计划变更管理合同管理费用报销”在内的营销费用全周期管理的闭环回路作为项目目标，为市场部提供一个灵活完善的营销费用管理平台。,其次，确定解决方案这个项目的难点在于对业务的理解和把握上，既要考虑到现有的业务
4、流程的实现，也要兼顾到对业务流程的优化，既要符合基层用户的习惯，也要满足高层领导的管理和分析的需要；另外，因为已经有过一次失败的经历，为了增强用户的信心和重塑开发部的信誉，一定要尽量降低项目的风险，保证成功上线。因此，选择一个合适的解决方案至关重要。在设计上，Sam采用了灵活的审批流设计和简洁的界面风格；在技术上，Sam决定放弃刚刚引进、还没有成功应用的新技术，而选择了成熟的、已经广泛实施的现有技术架构，这样既降低了技术风险也便于实现代码重用。,再次，充分的需求分析 由于现有业务流程的混乱，在项目初期，恐怕没有人能够提出一份全面细致的业务需求，而且市场部（尤其是分公司）的市场人员对信息系统的认
5、识和接受能力普遍比较差。因此，为了能够充分了解业务需求，加强与用户的沟通和交流，Sam决定在需求分析阶段通过建立系统原型来配合需求的收集和分析。通过系统原型的建立，可以将空泛的业务流程具体化、形象化，使其更加直观地展现在用户面前，让用户可以亲身感受到系统上线之后会给自己的工作所带来的改变，并逐步培养他们使用系统的习惯，以及使用系统来解决实际问题的能力。既便于全面收集各方的需求，也为系统的顺利实施奠定了基础。,然后，选择生命周期模型 需求分析阶段的系统原型，因为采用的是成熟的技术架构，故而可以将其一直迭代到代码开发阶段，直至系统交付，所以采用“迭代原型法”的开发模式是最恰当的选择。采用“迭代原型
6、法”的开发模式具有很明显的优势，可以尽量在项目早期发现问题，降低项目后期发生需求变更的风险。,最后，循序渐进地实施项目 为了保证系统最终能够成功上线，必须注意实施过程中所采取的方法和步骤。费用管理的业务涉及到总部市场和全国所有的分公司，系统的最终用户遍布全国，而且人员众多，水平参差不齐，因此想要在所有分公司一次性同时上线，几乎是不可能的。比较合理的方式是，首先在总部市场和北京分公司做试点，因为他们与开发部在同一个办公地点，并且用户的计算机水平也相对比较高，培训和调试的成本比较低。等到系统稳定运行一个月以后，再向全国推广，届时有了总部和北京分公司的成功经验，可以达到以点带面的示范效果，将会大大降
7、低实施风险。,Sam还需要一些无伤大雅的“阴谋诡计”来保证项目的顺利进行，正所谓，“兵者，诡道也”。简单点说，就是以下几点。项目初期，以用户为中心 项目初期，用户刚刚开始接触系统原型，系统的界面风格、操作模式、按钮设置等是用户最直观的感受，尤其是对于以前没有使用过信息系统的市场人员来说，这些操作层面的简便性、易用性将直接影响到他们对系统的感受。在这一时期，为了让用户能够比较容易接受，项目经理要尽量按用户的习惯来设计和修改，在这些特性上可以做出最大程度的妥协，只求能让用户慢慢习惯使用系统即可。,项目中期，树立项目经理的专业权威 到了项目中期，系统的界面风格和基本流程已经确定，在这一阶段，要“怀柔
8、”与“高压”并用。怀柔对于一个非关键、双方有争议的功能需求，项目经理可以先按照用户的想法来做，但是一定要事先强调自己的看法，并指出用户的想法可能存在的风险，同时保留自己的意见。待功能按用户的要求实现之后，用户会发现，这样做果然是会出问题的，还是项目经理说的对。这个时候，项目经理在用户心中的专业权威就树立起来了，以后再出现争议的时候，用户就会给予项目经理充分的信任和尊重。高压当项目经理在用户心中成为权威之后，对于一些开发成本很高而使用价值不大的功能需求，项目经理就可以利用自己的权威来向用户“高压”一下，使用户同意取消该需求或者放到项目的二期、三期的时候再实现。,项目后期，“威逼”加“利诱”在后期
9、的实施过程中，项目经理要学会“威逼”和“利诱”。对先期的试点用户“威逼”对于第一个吃螃蟹的人，困难是可想而知的，为了保证不会半途而废，除了对其加强培训之外，取得高层领导的支持，通过高压手段保证系统真正用起来并且能够用下去，是十分必要的。对后期跟进的用户“利诱”前期的成功经验已经摆在那里，项目经理所作的就是将实施系统所带来的效率的提高、工作量的降低、流程透明度的增加等，充分的介绍给准用户知道，使他们对系统上线和随之而来的好处充满信心。,案例,A公司为B运营商建立一个业务平台，并采用合作分成的方式。所有的投资由A负担，平台投入商用之后运营商所收取的收入按照一定的比例与A分成。同一时间，B运营商与C
10、公司合作建立这样一个业务平台，设备以及技术均独立，也就是说同时有两个平台提供同一种服务，两个平台分别负责不同类型的用户。但是整个项目进行了10个月，并经历了一个月试用期之后。准备商用的第一天，运营商在没有任何通知的情况下，将所有用户转到了C公司建立的平台上去，也就是停止使用A的平台。整个项目投资超过两百万，包括软、硬件以及各种集成、支持、差旅费用等等。现在A所有的设备被搁置但不能搬走，并没有被遗弃，运营商口头声称还会履行合同，按照原来的分成比例给A收入。但是A无法得知每个月的使用情况、用户多少，所以根本无法知道A究竟应该拿到多少分成。所以，运营商的口头承诺根本如同鸡肋。1.从项目管理的九大知识体系来讲，我们能不能避免这样的事情发生？2.出这样的事情，项目经理有没有责任？,
