项目经理除了脚踏实地做好项目管理之外，也要学会用兵之道，关键时刻耍点手腕、来点阴谋诡计也是十分必要的。Sam是一家电脑制造企业的信息化项目经理，几年来大大小小的IT项目也做了不少，从最开始的费力不讨好，到现在的合作愉快，Sam经历了一个漫长而痛苦的过程，从一个单纯的技术人员逐渐成长为一个优秀的项目经理。
　　
　　完胜
　　
　　刚刚参加完为市场部开发的营销费用管理平台的验收会，在会上，市场部的领导对该项目的实施效果大加赞赏。项目顺利通过验收，可谓完胜，Sam心情大好。
　　
　　经过3个月的系统试运行，市场部数额庞大的营销费用变得清晰了--每一笔费用都可以准确追溯到预算、计划、执行、报销各步骤的具体情况，同时还可以看到该笔费用在执行过程中与各方签订的合同情况；并且系统还记录了每个步骤的修改、变更以及相关人员的审核审批记录。
　　
　　一旦审核人员发现疑点，可以轻松追查到所有相关的责任人，以前让人头痛的费用管理变得不那么可怕了，相反可以为管理者提供清晰可靠的决策依据，帮助管理者随时掌握营销费用的使用情况，再结合销售部门的销售数据，可以准确了解投入的营销费用对销售业绩作出的贡献。
　　
　　翻开手中的验收报告，Sam的思绪不由得飘回了半年前刚接到项目的时候，那时的心情可远没有现在的轻松呀。
　　
　　缘起
　　
　　从CIO那里接下为市场部开发费用管理系统的任务后，Sam回到办公室，翻出了以前的项目档案。原来3年前开发部曾经为市场部开发过一个类似的系统，但是由于当时正赶上公司的业务方向调整和组织结构变动，导致了系统刚刚上线即面临下马的窘况。
　　
　　究其原因，很大程度上是因为当时的系统设计不够灵活，流程都是固化在程序里，根本无法适应业务的调整，而重新修改代码的代价又太高，工期也无法保证，所以只好选择放弃。
　　
　　放下手中的项目档案，Sam感到压力重重。市场部是公司的消费大户，每年在市场营销上的投入高达几千万，然而市场部却是公司唯一没有成功实施信息系统的部门，一直靠人工的方式来管理庞大的营销费用，整个市场部没有谁能说得清这么多钱到底花在了哪里，是否获得了预期的效果，有没有被挪用和浪费，甚至被贪污。
　　
　　从当前费用管理的情况来看，存在着业务流程混乱，计划变更频繁，合同管理松散，费用报销严重滞后，工作效率低下等诸多问题；总部对各分公司的费用管理和控制基本处于半失控的状态，没有什么手段和依据来限制分公司对营销费用的使用；对营销费用的投入和收效知之不详，制定费用预算时往往只能跟着感觉走，没有切实可信的数据可供参考。
　　
　　眼前状况堪忧，前方荆棘密布，Sam犯了难，这个项目到底该怎么做呢？
　　
　　谋定
　　
　　考虑再三，Sam决定先分析项目的整体情况，再决定如何推进，谋定而后动，尽量减低项目风险，避免失败。经过一番深思熟虑之后，初步的项目推进方案出炉了。
　　
　　首先，明确项目定位。
　　
　　市场部作为公司营销策略的制定者和执行者，其营销行为的成功与否，对整个供应链的销售、生产、采购等环节都有着直接或间接的影响，其重要性毋庸置疑。市场部本身的业务繁多，包括营销策略的制定、市场公关、创意企划、费用管理等等，从信息化的难易程度、紧迫性和重要性来看，对数额巨大的营销费用的监管和控制无疑是重中之重。因此，项目的切入点应当首选营销费用管理这块业务。
　　
　　根据目前信息化的发展趋势和业务需要，Sam将项目定义为市场营销费用管理平台，把建立起一个包括预算管理->计划制定->计划变更管理->合同管理->费用报销在内的营销费用全周期管理的闭环回路作为项目目标，为市场部提供一个灵活完善的营销费用管理平台。
　　
　　其次，确定解决方案。
　　
　　这个项目的难点在于对业务的理解和把握上，既要考虑到现有的业务流程的实现，也要兼顾到对业务流程的优化，既要符合基层用户的习惯，也要满足高层领导的管理和分析的需要；另外，因为已经有过一次失败的经历，为了增强用户的信心和重塑开发部的信誉，一定要尽量降低项目的风险，保证成功上线。因此，选择一个合适的解决方案至关重要。
　　
　　在设计上，Sam采用了灵活的审批流设计和简洁的界面风格；在技术上，Sam决定放弃刚刚引进、还没有成功应用的新技术，而选择了成熟的、已经广泛实施的现有技术架构，这样既降低了技术风险也便于实现代码重用。
　　
　　再次，充分的需求分析。
　　
　　由于现有业务流程的混乱，在项目初期，恐怕没有人能够提出一份全面细致的业务需求，而且市场部(尤其是分公司)的市场人员对信息系统的认识和接受能力普遍比较差。因此，为了能够充分了解业务需求，加强与用户的沟通和交流，Sam决定在需求分析阶段通过建立系统原型来配合需求的收集和分析。
　　
　　通过系统原型的建立，可以将空泛的业务流程具体化、形象化，使其更加直观地展现在用户面前，让用户可以亲身感受到系统上线之后会给自己的工作所带来的改变，并逐步培养他们使用系统的习惯，以及使用系统来解决实际问题的能力。既便于全面收集各方的需求，也为系统的顺利实施奠定了基础。
　　
　　然后，选择生命周期模型。
　　
　　需求分析阶段的系统原型，因为采用的是成熟的技术架构，故而可以将其一直迭代到代码开发阶段，直至系统交付，所以采用迭代原型法的开发模式是最恰当的选择。
　　
　　采用迭代原型法的开发模式具有很明显的优势，可以尽量在项目早期发现问题，降低项目后期发生需求变更的风险。