2. 获得buy-in的优势
从项目整个Team而论，项目管理者最应获得的是项目成员（含供应商与客户）的buy-in, 即项目组成员的关注、忠诚、被收买的愿意付出的精神，这种核心凝聚力对于保持项目组的士气、用户的关注度、供应商的关注度有极为重要的作用，是属于项目成功必不可少的隐性因素。采用分阶段实施，可以使项目的短期成果被迅速的分享出来，对于供应商和用户都是即为鼓舞士气的做法。
就客户而言，因为客户在整个项目过程中始终参与在其中，没有一个长期的松弛过程，客户保持了一贯的关注度，对于前期需求的调研也能记住更多的部分，减少了最后提出“这不是我要的东西”的风险；在实施过程中因为持续的参与能够逐渐获得一种“这是我做的产品”印象，能够加深对所生成产品的认可度，项目管理者在这个过程中也逐渐得到了客户的buy-in；项目短期成果被迅速分享和公布，使得客户对于他们的上级有更多可汇报的成果，自己也能获得成就感，他们就能持续保持对项目的关注度和参与度，形成了良好的心理循环。
就供应商而论，虽然因为工作关系不得不勤奋的工作，但他们同样是项目管理者的事业伙伴，这意味着获得他们的buy-in也同样重要。通过划分阶段在短期即可获得可公布的阶段性成果，这种做法对供应商来说是价值得到认可，他们将获得工作被认同、自我成就感形成的良好心理感觉，在精神愉悦的同时，项目管理者也逐渐获得了他们的buy-in。

3. 需求受控的优势
当然，用分阶段实施也同样存在一定的风险，客户在能使用第一阶段产品之后及第二阶段产品出来之前，可能会对第一阶段产品做持续的研究和使用，这意味着他们提出质疑、提出更多需求的机会将大大增加，此时，控制需求将成为项目管理者必须关注的问题。但从另外一个角度来讲，这种方式可以将需求变动的风险前移。项目管理者的职责是控制项目，即控制风险，但控制风险除了将某些风险的发生率降到最低外，将风险发生的时间和阶段迁移同样也是增强风险控制的方法。
在上述两种情况中，客户在持续使用产品后，提出新的需求的风险是同样会发生的，在分阶段实施中，这个风险被移到了实施步骤整个过程，并且在整个过程中有更长的时间通过各种手段消化掉因需求增加而导致的项目周期延长的风险，在不分阶段实施中，这个风险被移到了实施的最后1/3部分，在这1/3部分中因为客户本职工作的时间冲突，导致测试不充分、产品应用理解不深入会使新需求提出的风险再度被延后到试运行阶段，再往后，这种风险将被转嫁到企业信息部人员头上。项目的不可控风险就会大大增加。以下是两种情况下需求增加/变动的风险出现的示意图

不分阶段实施，出现的需求变动的时间会更靠后，试运行阶段有更大的风险成为需求频繁变动期，试运行期以及用户测试期对于供应商而言是较为懈怠的期间，此时发生频繁的变动容易引起整个项目时间的延迟，因此会引起整个项目的急躁情绪，从而难以在整体上有规划、宏观的掌握需求变动，易于出现因改A模块，忘记修改 B模块中关联的部分，系统Bug较多的情况（当然，如果供应商的开发管控很严格，也可以降低这种风险），如果项目组为了赶时间进度放弃部分需求，在系统关闭后这些需求仍然会转嫁到企业信息部的头上；而分阶段实施，需求变动的时间更靠近系统实施期，因频繁的交流和阶段性成果的公布，项目组的心态容易处于斗志高昂的状态，整体效率较高；时间较为充裕，整体进度中出现的任何延迟都可以通过较为合理的分配在较长的一个时间区域内得到消化，因此，此时任何变动对整体时间进度影响都会比后期出现相同大的需求变动对整体时间进度影响小。

4. 产品质量优势
分阶段实施，可以在无形中实现迭代开发。

每个迭代开发的过程都包含

顺便罗嗦一句，现在有些实施方法论，叫“导航仓”，其实和迭代的意思差不多，就是先根据客户需求配好，客户用第一轮，用了再出需求，再调整配置系统，客户用第二轮；完了再来上一轮，一共三轮，系统才使用得比较稳定了，没有更多的需求出来了。原理上都差不多的。

同样，这样的过程具有迭代模型的优点和缺点
优点：客户能很早对动态的软件产品提出意见；客户能够看到项目的实际进展，增加客户对项目的信心
缺点：要求有较强的设计和实施能力，保证增加构件时不会破坏已经开发出的工作产品；难以把握迭代的次数和最终的交付期。
适用：需求不清晰，开发时间较充裕，设计能力较强或各子系统之间的耦合很低时，实现方案没有把握时。即迭代模型对于企业用户需求不够确定、明确的项目具有较好的作用。
不分阶段实施应用了瀑布模型，瀑布模型具有如下优点和缺点：
优点：强调了设计，避免了后期的混乱；因为有详细的文档，降低了维护费用。
缺点：客户在初期只能通过静态的规格说明去了解动态的软件产品；对一些要求快速开发的项目来说，产生了过多的文档；最后才进行交付，客户感觉速度慢；需求变更的维护成本很大。
适用：需求明确；架构易设计；系统的可靠性要求高；项目开发风险小。
企业的实施类项目通常的周期不会短于1个月，企业的用户需求通常也并不清晰，大多数情况下都是在使用中提出了更多的需求，所以分阶段的实施具有的隐性迭代开发模型，更适用于企业的实施项目。

之后就是总结的分阶段和不分阶段的优劣对比。

利用人性的特点赢取成功

企业的项目通常都会遇到一个项目中，所有项目成员都是兼职的情况，因为项目成员的时间、精力不能保证，导致项目时间延迟。
这种情况在某企业有一个成功案例。该企业属于“领导为主”型企业，风格比较类似国企。该企业通常的项目都会因为涉及面广，项目组成员都有许多本职工作要做，而没有足够的时间按进度完成项目，大部分项目的延迟都高达80%以上，多者达到150％。但这种通常情况在该企业的一个人力资源项目（主要内容为各部门的所有人员的职务分析）上得到了转变。该人力资源项目要求的时间极为紧迫，即便是项目成员全部全职的情况下都要有50％的时间加班才有可能完成，而该项目所有成员推掉了日常工作，将其的重要性排在第一位，加班加点的按时完成了。
在研究了项目资料后，发现，该项目的做法可整理如下：
（1） 会议无论大小均发送相关项目组成员，并抄送他们的领导；会议完成后必有会议纪要，或交代事宜，或做项目例会，纪要必定抄送各大小领导；如果有项目组成员不参加会议，要求向部门长请假。
（2） 项目当中，每周召开一次项目例会，内容大抵都是谁完成了什么，没完成什么；每次项目例会必有文字记录，当中均记录如哪个部门提前完成了什么，哪个部门还有什么没有完成，各部门做得好的有表扬，做得不好的没有批评
这种做法在标准的项目管理中似乎并不新鲜，但却收到了极为良好的效果，原因何在？
该企业属于国企风格，各成员都极为重视个人在领导心目中的形象，大小会议动辄抄送领导，暗合这部分人的心理：每做一件小事都被领导看见；如果请假，却需要有十分充足的理由向部门长说明，没有万分需要的理由，也不会请假。同时每次会议必有会议纪要，抄送各大小领导，则无论事情大小均会被项目组成员、各领导以为是重要的事件，虽然各领导未必会看，但项目组成员的意识中被烙下了“重要项目”的印象，同时也有工作成果被重视的感觉，所以所有成员都不得不重视起来，项目管理者获得了他们的buy-in。
项目例会的定时定点召开在数周之后已经形成习惯，每当这个时候项目成员从本部门消失，部门人员都会自然而然知道他们是参加人力资源项目了。这在无形中形成了一种群体效应，所有的人都在谈论这个项目，询问进度。于是在外部氛围上，项目组成员再一次感受到了压力和自我价值体现感觉。
每次会议中，各部门都汇报本部门的进度，如果某个部门的进度大大落后于大家，则很容易感觉上“没有面子”，在之后发送的项目例会报告中，各部门完成了什么、没完成什么、哪个部门的谁收到了表扬都有详细阐述，这在各部门人心中形成了一个隐形的看板“kanban”。看板最初来自于精益制造理论，是个日语名词，表示一种挂在或贴在盛装在制品的容器上或一批零件上的标签或卡片，或流水线上各种颜色的小球或信号灯、电视图象等。看板是揭示牌，可以作为交流厂内生产管理信息的手段。但在这里，是一种比较看板。上面并未批评哪个部门，但之间的比较却一目了然，这种方法利用了人的好胜与自尊心作为引导他们前进的“胡萝卜”与促使他们前进的“大棒”，效果非常卓越。如果有部门长偶尔看上一眼，表扬一下或者问问“怎么别的部门都完成了，我们还没有呢？”，实际效果将更加明显。当然这个个案仅就国企而言，但中国人的心理都具有类似性，可以进一步探讨。
人天生就有爱慕虚荣（面子）、贪好功绩、喜欢成就的特点，在这里只能说是特点，因为人性的特点并没有善与恶的区别，只有一个程度的区别，而善于利用人性的特点在项目没有奖金、特殊荣誉（胡萝卜）以及批评、工资克扣（大棒）的时候显得尤为重要。利用人性来进行项目管理的方法在许多地方都有微妙的用处，需要项目管理者对于人性有深刻的理解。

项目管理里面合同有很多种类别，但是大家肯定都想把风险转嫁到另外一方头上，所以选择合同类型要谨慎，对自己有利，同时也要保持激励机制

1、Fixed-Price（FB）固定价格。这种合同中国人最喜欢用，因为感觉价格OK了，己方的风险就固定了。而且因为工作量评估就是IT行业评估成本的主要办法，但是工作量评估实在是不够准，尤其是一些风险看不清的项目，实际能有评估的两倍的都有。但是，我个人觉得，因为中国的很多项目都是谁做谁评估，所以大家都有习惯朝多了评估，这种方式未见是最合适的。但是如果风险非常大，或者就是不知道风险在哪里，到底多大的项目，甲方的建议用这种方式，可以转嫁风险，同时要获得乙方高层的承诺，保证即便工作量大量超出也不加钱，这样的风险的确转嫁了不少。

2、框架协议+time Material。说白了就是做多少，算多少。这种比较适合供应商在现场办公的，先有个框架协议，表示甲方和乙方的合作方式，一天多少钱等等，供应商来一天就签一个time sheet，然后最后算总账。外国的公司最喜欢这种方式。在风险比较明确的时候，而且确保供应商人品的情况下（不是诋毁供应商，但是为了避免有人磨洋工），也就是一些大公司的感觉比较Professional的那种实施顾问，而且管理比较严格一点的公司，可以采用。这样的公司比较保险，一方面可以和乙方的管理经理沟通，这样的项目大概要多少时间，他们有信誉保证，也不会冤甲方的，另外大公司项目都做不完，它都犯不着和你耗时间。为什么风险比较明确的时候用这种好一点呢，因为大公司都会有比较严格一点的人力成本核算方式，超过成本是比较严重一点的，如果采用FB的话，他们就会严格按照官方的流程来估计，比如测试三轮、啥啥N轮，这样按照官方的手册做才能保证不超支（或者说超支了才有官方的手册做借口），实际上可能风险比较明确，两轮测试就够了，但是因为一般甲方是保证效果的，如果第二轮测试就没问题了，多半也不会非做第三轮不可，从成本上说，甲方就损失了一些钱，还不如time sheet，大公司的实施人员还是有良好的职业素养的，所以这样大家都好。

3、项目管理里面的合同还有其他的我都没有用过，但是真的很鼓励大家用用，因为合同是真的有激励作用的。抄下来给大家。
a) Cost-Plus-Fixed Fee(CPFF，成本报销加固定费用)/Cost-Plus-Percentage-Fee(CPPF，成本报销加百分比费用)
用于无法确定准确价格的情况
成本变化但费用不变
卖方风险低
会没有成本控制的动机。

b)Guranteed Maximum-Shared Saving(GMSS) 确保最大限度的节省
卖方付固定价格，按实际造价报销至顶限价格
在确保线下节省部分双方共享
卖方负责超过顶限的部分
谈判合同中最好的一种形式。
这种方式看上去我觉得是风险不固定时候甲方和乙方比较共赢的方式，但是好像合同类的难度在于合同模板，没有找到一个法律上比较严密的模板。

c)Fixed-Price-Incentive-Fee(FPIP)固定价格加鼓励费用
为卖方提供固定价格加奖励费用
鼓励卖方降低成本
双方共享结余，共担风险
这种觉得长期研发的项目可以用

d)Cost-Plus-Incentive-Fee(CPIF)成本报销加鼓励
报销允许量的成本加上预先规定的奖励优越表现的奖金
如果实际成本低于目标成本，买方和卖方按规定的方法分享节省的部分
这种也觉得长期研发的项目可以用

项目没有开始的时候，甲方好比挑老婆，那可要睁大眼睛看，乙方的长处、缺点、特点都要摸得一清二楚。之后就是平衡，在众多老婆中间挑一个。
合同签了，乙方都是甲方的老婆了，没有原则性错误的时候，甲方最好和乙方是一家人，大家是利益共同体。

甲方要不厌其烦的告诉乙方：项目有什么问题，你告诉我，不能协调的资源我们出面，有问题我们共同承担。乙方的人常常对自己内部不能协调的资源难以启口，好比没法说自己娘家人的不是，所以有的时候乙方会掖着藏着，或者自己拼命协调，等上面说No的时候项目又拖了不少时间了。所以甲方友好的态度很重要。

甲方还要不厌其烦的告诉乙方：我没办法帮你加钱，但是可以帮你省钱。就是说合同没法改，但是可以尽快完成项目，减少彼此的时间+人力资源费用。

虽然甲方这么想，但未必乙方这么想。所以，甲方一定还要设定自己的底线。比如，项目经理一定要符合几大要求（有责任心、沟通能力强……），某个时间一定要完成什么里程碑，诸如此类，甲方的友好是要有条件的。但是一定要态度够温和，而立场够坚定。

双方都记得万万不好撕破脸。一旦撕破脸，很多时候大家都绕着走，慢慢的就会形成沟通障碍。而且越是高层越会发现障碍不可逾越，也许这就是人性的弱点，高位的人是容不得某些事情的。

一句话，有合作，有斗争。

我是东一个主题，西一个主题的胡写，想起什么说什么，主题之间未必有太大关系了。大家也就胡乱看吧。

最早之前说过的，因为F部门坚持选了一个我的老大W不能控制的供应商，后果在验收的时候就会出来。F部门希望我们可以为他们开发报表，所以我们要求供应商提供数据字典和数据流向说明，主外键关系。供应商是死活不给。然后出现供应商总是说：
1.当初我们约定初验的时候没有说那些东西，所以我们只是在说初验。
2.你们最后的一批需求我们也是说在终验前做完，但是你们初验都没做，我们就是在做最后的开发，没到终验，也就没有成果。

说白了就是供应商和我们掐上了，他们不给我们最最后的一批需求，我们不给他们初验。他们会一天打2、3个电话到F部门坚持选他们的人那里去，于是，终于连最后一个支持者都倒戈了……

可怜的F部门的原支持者，完全没有和供应商阶级斗争的经验，难过无比。

这个惨痛的项目告诉我们什么呢

1）通常来说，如果选供应商的意见不一致，可以上报，由更高级的人仲裁，如果是势均力敌的两方谁也没有依附谁的那种，就可能出现其中一方把很多责任推到选供应商的那方头上，而且承担责任多的这方又没有 PM以及和供应商斗争的经验的话，基本一开始就注定了结果是失败的。

2）高层关系重要呀重要，甲方PM和乙方PM一定会因为很多原因大打出手，还不是靠彼此高层协调。高层不合，他们就是神仙打架，我们凡人遭殃；高层琴瑟和谐，我们就是小孩子拌嘴，风轻云淡就过去了。

3）早期的高层PK就是占领心里制高点，赢了就插上自己的旗帜，万一输了，尤其是甲方输了，最好赶紧撤退，换个阵地，不要硬抗呀。

因为甲方乙方的PM都知道事情搞不定就上报，到时候就是高层PK。所以早期甲方和乙方斗争的时候就决定了胜利方掌握主动权，失败方产生心理阴影，大家都是人啊，没啥不同，想想自己就知道高层也多少都会这样的。
a) 甲方早期斗争获胜。甲方老大兴高采烈的控制住了乙方老大，如果甲方PM搞不定了，老大也会出面轻松搞定，毕竟乙方老大心理上已经输了一筹，有了心理阴影就容易听话得多。
b) 甲方早期斗争失败。甲方老大就会绕着走，不和乙方的老大接触，你们F部门当初谁选的，谁负责。老大们都是顶顶爱惜面子的，一旦失败，就不会说我脱了面子求你。事情就没法解决了，要么就是拖着，要么就是甲方的人吃了亏。

4）没有项目管理经验的职能部门，不要和IT部门硬争。善良的职能部门，长期对内工作着，不知道外面有多么险恶的供应商，不是人人都想和你搞好关系长期合作的，而且有的时候是供应商最早是想长期合作的，但是过程不尽人意，他们也知道只怕第一单就是最后一单了，所以也不怕惹急你了，收回钱才是上上策。当初惹火了自己的IT部门，焦头烂额的时候，就没有人帮忙了。
甲方的人内部团队多重要呀，咱们一定要注重内部的和谐啊，这样才是相互扶持的团队嘛。