项目计划

    通常是最痛苦的，耗时的，对于需求频繁变化的项目来说是最没有价值的；在标准项目管理过程中计划是最重要的，没有计划项目经理和项目组将丧失方向和感觉，而对于灵活的项目管理中计划也是重要的，但如何计划才能将计划变成有价值的呢？

    对于中小型商业银行的金融项目来说，项目的每一分，每一秒都是重要的，项目是否能多快好省的完成决定了商业银行当年在当地市场的竞争地位，市场变化飞速，如果项目不能及时完成，一步赶不上，步步赶不上。所以商业银行对于项目的期望和要求都很高。

    当项目组遵循标准项目管理流程进行项目计划时，客户会说：“我们需要项目尽快完成，不然我们将不能够完成今年的利润目标，并且工商银行在一个月后就推行这几项业务了，我们要在他们之前完成，你们的老总和销售都向我保证过，可以在此前完成。所以不管如何做，你们现在就开始写程序吧” 或 “你们已经做过此类型项目，你们应该知道怎么做，计划只会拖延时间，所以快点开始”。

    在种种条件迫使下，项目组不得不在极短的时间内产生行之有效的项目计划后进入开发。甚至没有时间做详细的需求。我们不得不面对这样一个矛盾，一方面，需求频繁的变化导致计划纯属浪费时间，而另一个方面，我们必须做计划。

    标准项目管理流程的计划包括大大小小十几二十个计划，从工作列表、甘特图到时间安排、人员选择，成本分析等等方面。我本人不想否定这些计划的制定，这些计划确实能够有效的对项目进行规划和控制，将风险降到最小，成功率升到最大。举例来说：一个商业银行整体解决方案的项目，经过和客户的反复讨论，综合业务系统在保证其原本业务功能的基础上，同时对客户现有系统（如CRM，行长决策，OA，管理系统等）、信贷管理系统和国际业务（包括现有和未来需要的业务功能）提供端口和数据源，将综合业务系统进行必要的改动和优化，对种种情况进行周全的考虑，然后制定一套完整的计划和方案，再进入实施。这样当然最好，但在现实中国社会中，有什么样的银行允许你这么做？

    项目活动和成绩标准的项目管理流程是以项目活动为基础的，也就是说项目按照要做多少事，先做哪件，后做哪件来决定的；当关键的项目活动确定后，资源得以分配，工作量和时间得以估算，次序也就相应排列出来了。标准项目管理通常使用以以前做过的项目所总结出来的通用模版来完成初期的项目计划。

    而灵活的项目管理中，计划的制定是通过确定要完成的目标和里程碑，但不具体到详细的任务。新科技或需求不断变化的项目中的项目经理清楚要达到的目标和一定要按时完成的里程碑，他所不清楚地是非常准确的任务，所以在此情况下，制定一个在任务列表的基础上的完整而详尽的项目计划就不切实际了。如果要这样做，只会起到反效果。这大概就是灵活的项目管理和标准项目管理之间微妙而关键的不同。

    在灵活的项目管理中，通常有多种方法推进项目并解决项目中出现的问题，项目经理不能以机械的方法按照标准项目管理的方法来实施项目。而有丰富经验的项目组成员也经常对不了解项目性质的项目管理层有抵触。他们不喜欢对不确定的业务功能和系统功能作出承诺，因为他们知道这些需求会改变或正在改变中。可是，他们会对确定要按时完成的里程碑作出承诺，如果项目经理对他们如何做不太多进行干涉。

    项目估算和承诺

    在此类项目中，项目估算的关键点是相信项目组成员的承诺，而不是从上至下WBS的估算，只要能够实现系统层面上对于客户业务上的运作畅通，换一句话说：是将客户商业运作上的要求在系统中实现，设身处地的在业务层面上为客户着想。

    这就要求项目组和客户不得不在整体上进行考虑，然后在细节方面逐步实现需求。在中国软件开发项目中很常见的一个现象是客户和项目组的考虑重点不同，导致误差和困扰。如果项目组和客户在同一个思路上思考，项目的难度会减小很多。这样在计划阶段双方很容易达到共识，而富有技术和业务经验的项目组成员可以更好的发挥他们的优势而达到双赢。

    你，作为项目经理可以把重点放在你的优势上，协调、沟通、整合系统，保持它的完整性。

    当然，基于此基础上制定计划和进度安排不是个容易的事情，因为系统中的各部分有着千丝万缕的联系，而一个大集成系统中的各系统之间也是相互依靠的。所以所有项目组需要有效的共同工作。

    出于这些原因，项目计划的网络图比甘特图在计划中更加有效，更能够展现项目中可实现目标的途径。