其次，确定解决方案。

　　这个项目的难点在于对业务的理解和把握上，既要考虑到现有的业务流程的实现，也要兼顾到对业务流程的优化，既要符合基层用户的习惯，也要满足高层领导的管理和分析的需要；另外，因为已经有过一次失败的经历，为了增强用户的信心和重塑开发部的信誉，一定要尽量降低项目的风险，保证成功上线。因此，选择一个合适的解决方案至关重要。

　　在设计上，Sam采用了灵活的审批流设计和简洁的界面风格；在技术上，Sam决定放弃刚刚引进、还没有成功应用的新技术，而选择了成熟的、已经广泛实施的现有技术架构，这样既降低了技术风险也便于实现代码重用。

　　再次，充分的需求分析。

　　由于现有业务流程的混乱，在项目初期，恐怕没有人能够提出一份全面细致的业务需求，而且市场部（尤其是分公司）的市场人员对信息系统的认识和接受能力普遍比较差。因此，为了能够充分了解业务需求，加强与用户的沟通和交流，Sam决定在需求分析阶段通过建立系统原型来配合需求的收集和分析。

　　通过系统原型的建立，可以将空泛的业务流程具体化、形象化，使其更加直观地展现在用户面前，让用户可以亲身感受到系统上线之后会给自己的工作所带来的改变，并逐步培养他们使用系统的习惯，以及使用系统来解决实际问题的能力。既便于全面收集各方的需求，也为系统的顺利实施奠定了基础。

　　然后，选择生命周期模型。

　　需求分析阶段的系统原型，因为采用的是成熟的技术架构，故而可以将其一直迭代到代码开发阶段，直至系统交付，所以采用“迭代原型法”的开发模式是恰当的选择。

　　采用“迭代原型法”的开发模式具有很明显的优势，可以尽量在项目早期发现问题，降低项目后期发生需求变更的风险。

　　不过，它也有一个缺点，在原型迭代的过程中，开发人员很容易陷入对细节的无止境的纠缠当中，从而导致需求蔓延和需求“镀金”。在这一点上，Sam提醒自己一定要注意对项目的管理，定期进行检查点回顾，时刻注意检查项目进度，一旦发现“蔓延”的趋势必须及时修正，保证主要功能和流程的开发进度，将风险消灭在萌芽状态。

　　后，循序渐进地实施项目。

　　为了保证系统终能够成功上线，必须注意实施过程中所采取的方法和步骤。

　　费用管理的业务涉及到总部市场和所有的分公司，系统的终用户遍布，而且人员众多，水平参差不齐，因此想要在所有分公司一次性同时上线，几乎是不可能的。

　　比较合理的方式是，首先在总部市场和北京分公司做试点，因为他们与开发部在同一个办公地点，并且用户的计算机水平也相对比较高，培训和调试的成本比较低。等到系统稳定运行一个月以后，再向推广，届时有了总部和北京分公司的成功经验，可以达到以点带面的示范效果，将会大大降低实施风险

　　诡道

　　以上都是在项目进行过程中必须要考虑和解决的问题，都是光明正大的措施和手段。但是，除了要做到以上这几点之外，作为一名项目经理，在管理这样一个复杂的，容易反复的，而且曾经有过失败经历的项目时，Sam还需要一些无伤大雅的“阴谋诡计”来保证项目的顺利进行，正所谓，“兵者，诡道也”。简单点说，是以下几点。

　　项目初期，以用户为中心

　　项目初期，用户刚刚开始接触系统原型，系统的界面风格、操作模式、按钮设置等是用户直观的感受，尤其是对于以前没有使用过信息系统的市场人员来说，这些操作层面的简便性、易用性将直接影响到他们对系统的感受。

　　在这一时期，为了让用户能够比较容易接受，项目经理要尽量按用户的习惯来设计和修改，在这些特性上可以做出大程度的妥协，只求能让用户慢慢习惯使用系统即可。

　　项目中期，树立项目经理的专业权威