其实我本来是想找PMP考友的，但是无人应征，又看到版主的号召，所以就贴个实践经验分享贴，也找点志同道合者交流交流实践经验吧。
先说说自己的情况，制造型企业，集团公司，比较多的下属企业（几十个吧），总部IT部门，项目一般都是实施第三方软件，所以做项目不是内部的非软件项目（比如，制度建立之类）就是实施类项目。当中也会写到一些甲方的想法，有乙方同志看到的不要怒，就当了解了解甲方的思想吧。

我自己标准的职位叫做项目管理，所以部门内的别人的项目也要管，自己也要做项目。写得会比较凌乱，想到啥写啥，如果写得多了再回头整理，看的同志不要郁闷。此外，我可能比较多的说到失败经验，因为我自己比较喜欢分享失败的经验，觉得成长比较快。

1.选择供应商。A项目，这个项目是个集团级 的项目，总裁啥的都非常重视。分为阶段一和阶段二，但是是一个合同里的。是IT和部门C合作的。选择供应商的过程极为漫长而曲折，从3月份开始到10月份才选定。我们选供应商不是公开招投标的，虽然招标，但实际上最后是根据IT和业务部门的人一起讨论得出来的，不是那种正规做法的当场打分，然后公布结果的。当初来过交流的供应商有 a b c d f 四家，a 成名已久，大家都知道，但是在我们项目方面看起来经验最少；b 是风险投资的企业，发展很快，1年就从400人到了1500人，行业客户数量居第二，但是都是大型客户；c 是小公司；d 是小公司，但从市场占有率看来却是最高；f 是大公司，经验也还可以。

第一轮看下来，f 虽然大，但是从朋友那里打听到，他在某公司做的项目内部宣布失败，大家肯定不敢要。c 公司小，而且经验一般，加上过来演示的人实在不怎么样，说话带着浓重的口音，我们实在听不懂，加上技术构架不怎么样，里面还有非常陈旧的技术，所以第一轮基本就淘汰了 f 和c。乙方的同志，知道一个好的售前，除了业务能力还需要什么么，极好的沟通能力，形象好（这不一定是美貌，而是感觉很professional，很白骨精的样子，就是有气势了）。

当初在前期交流的时候，我的领导W就看上了d公司的售前R，要求我们的项目由R当项目经理，当初d 公司的销售总监也是答应了。所以第二轮的时候W就向部门C的领导J推荐了d 公司，和d 公司也谈妥了，d 拿到中标通知书之后，就开始干活。看起来一切顺利，我们把 J 领导签字的中标通知书给了 d 公司， d 公司也马上派了 项目经理过来做需求调研。但是问题马上出来了（1） d 公司派出来的项目经理不是当初承诺的 R ，而是另外一个沟通能力不太好的人，和客户交流了半天好像也说得不甚明白，反应比较慢 （2）d 公司在投标文件里面写到，有Oracle 的产品，但是实际交流中发现，Oracle的产品只是在开发，至少等3个月才能出来。（3）这是最重要的一点，我们希望供应商直接进场开始干活了，做完需求做实施，合同要等到详细需求调研完了确定完项目准确的难度、范围之后再签合同，时间上也会拖上1个多月，在合同没有签订的时候供应商也要干活；但是供应商觉得只能做一个简单的需求调研，只是作为合同附件用的，必须要等合同签订了才能进场。

我的领导W其实是非常讲究供应商选择和管理的，其实后来我才明白，一开始他就压供应商c 要求不签合同就拿了中标通知书开始干活，实际上也不是蛮横不讲道理，他有他的理由。

我在第一次需求调研也是第一次见d 公司的项目经理后把发现的3个问题马上报告了W，他立刻意识到问题的严重性。（1）d 公司 没有派出当初承诺的 R，来的一个人是这个公司的八大元老，沟通能力一般，说明d公司很可能是没人了。前面说过了，d 是个小公司，所以得力的人力资源一定是个问题。 （2）d 公司有欺骗行为 ，这样W想起之前有两次， d 公司承诺什么时间给出的文档都拖了时间，W是个很严谨的人，所以开始怀疑d 公司的诚信度。同时我们打电话问d公司怎么回事的时候，他们一开始的态度是抵赖。（3）其实这才是最重要的一点，同志们，相信吧，所有老板不是希望一件事做得漂亮，而是希望一件事可控，可控的失败比不可控的胜利更被他们需要。W 会要求供应商不签合同就进场的方式，是打消供应商的气焰，让他们被自己控制。但是不要误会，不会是欺压，只是可控，W其实也讲究和供应商的良好和长期合作，一开始的压是为了掌握主动权，之后其实他对供应商还是很好的，并且他承诺的东西（比如合同）是绝对说话算数的。W教育我，要供应商可控，一开始要大力打压，让他们听话，但是承诺的东西一定要做到，同时在项目过程中，要友好合作，不要欺压供应商，要以理服人，友好协商。控制供应商是为了在关键点上不要走偏了。这个问题上W没有压住供应商 d 。

于是问题（2）就成了问题（3）的一个藉口，白纸黑字的d 也跑不掉，我们召回了中标通知书。这个时候 d 公司跑来又是道歉，又是承诺可以先进场再签合同，还说项目还在接着做。整整4天，我们没有任何回应。

其实这4天当中，W还在观察d 公司，但是 d 公司的人不知道，只是Sales天天打电话，喊口号说我们还在接着做你们的项目，我们还是很有诚意的。 这4天当中，做项目的人一个也没看见，文档一篇也没有，邮件一封都没有。W 终于死心了，觉得 d 公司没有诚意。于是 d 被彻底的干掉了。

由此说明，乙方的同志们，其实很多时候，事情并没有看上去那么绝望，如果想挽回什么就真正的表达诚意，如果4天当中，d 公司的技术人员等等真的和我们在联系、在认真工作，我相信 d 公司还是有机会的。只是d 公司自己放弃了，所谓自助者天助，d 放弃了，我们更没有理由坚持。
看样子说得太详细了，决定说简单点。喜欢知道细节的，想知道为什么当时会那样决定的可以再详细讨论。

直接说结果吧，当初因为 C 部门的人和我都喜欢 供应商b，所以 W 顺从了我们的意愿。选了b，但是不幸，在 是否提前进场这个问题上，W 又和 b 干上了（其实甲方和乙方的利益点是不同的，在这种问题上几乎是一定会出问题）。之后W和b 公司的高层吵了一架，大家彻底崩了。我们再度建议改为供应商 a ，但是因为许多的原因， C 部门的人选择了 供应商 b。
之后项目出了很多问题，从源头上讲，选择错了供应商是最根本的原因。我把W选择供应商的几条标准和原因告诉大家，给甲方和乙方的人一点参考。

1、高层关系良好。这是为了实现W的第一目标，供应商可控。不要觉得奇怪，我的几个老板都是这条原则优先的。W常用的几个方法，比如，供应商实施顾问在我们一开始这里不听话的时候，他会当着实施顾问的面打电话给 供应商的高层，把实施顾问臭骂一顿，声色俱厉，如果这个时候供应商的高层马上道歉，并且接着声色俱厉的把手下骂一顿，那么这个供应商基本还是可控的；反之，这个供应商非常危险。当然还会有要求提前进场一类的事情发生，W 就是要突破供应商的底线，但是前面说了，W绝对遵守承诺。

2、项目资源明确并优良。因为供应商不管多大，里面的人一定是良莠不齐的，再好的公司也有不好的实施顾问，但是公司的管理不一定跟得上，常常是项目delay了，客户忍无可忍了才被发现。业界超牛的公司做砸项目的比比皆是，而成败，常常是系于做项目的这几个人身上的，其中最重要的当然是项目经理。

3、重视案例。方法论每个公司都有，见多了绝对没啥新鲜的，方法论是必须落地的，所以案例就是方法论啊、公司的资历啊一大堆的落地表现，所以我们常常花更多的时间去了解供应商的案例情况。

4、公司成长性和稳定性。这是两个有点矛盾的要素，成长性当然是为了能跟上我们公司的发展，但是又要稳定的成长。风险投资的企业常常的问题就是发展神速，管理跟不上，我们的项目就是吃了这个亏，没人管了。所以一年规模就翻个翻的企业，其实值得甲方好好考虑。当然如果甲方足够的大，大到什么公司都不敢轻视你也不会有这个问题，但常常就是甲方只是一般的大而已，己方在发展过程中，对新员工的培训等等根本不足，大项目多，人手不足，于是一个新手就成了你的项目经理，后患无穷。
接着说，项目计划。

因为每个项目都有在需求确定情况下，都会有一个大致合理的工期，因为进度与成本的关系并非单调变化，一般呈U形，所以这个合理的工期（成本最低、效益最大）的工期是存在的，只是甲方多半是不知道的。

对甲方来说，要知道非常简单，要求供应商提供解决方案的时候就提交计划，通常说来，差别不会不靠谱（万一真的不靠谱，就在讲标的时候问，看看他们能说出什么道理来），所以取个居中的时间差不多就是这个最合理的工期。一般没事的时候，最好不要强压供应商说一定要什么什么时间完成，强压会导致供应商加人，事实上不是人加一倍，进度就快一倍，常常是人加一倍，进度只能少1/4，沟通成本、整合成本其实是在成倍增加的，所以甲方的同志，要相信乙方对时间的估算。
其实项目前期的需求分析，就是招标之前写初步需求也是一个非常重要的环节，只是这个项目失败是因为供应商选择的问题，所以先写那个了，这里补上 需求调研 环节。

做项目的需求分析，就叫RFP吧，免得和后面的供应商的需求搞混了，在企业做项目，一定要知道自己的Stake Holder（利益干系人）是谁，尤其是部门长级别的Stake Holder，一方面要知道他对这个项目的定位，也就是范围、深度，另一方面要知道他们的兴趣点是什么。现在没人会指着你做个系统就所有事情OK了，只要你解决了他头疼的2-3个问题，他就会开心了，IT部门的绩效就出现了。

不是说不关心下面人想什么，而是说要优先关心那2成的东西。事实上我的感觉是比如做10个模块，就2个是部门长感兴趣的，也是让他决定要不要说你项目有用、做得好的2个决定性的模块，或者2成的功能是他感兴趣的，项目实施过程中客户提出来的问题8成都是些不好用之类的小问题，真的有问题的就2成，看起来2/8原则基本上是处处成立的。

如果大老板们和下面的人提出的东西彼此之间可以有一定的独立性的话，建议把项目分成几个阶段（RFP里面就要告诉供应商要分阶段），不是传统说法上那种，需求-实施-测试……这种阶段，也不是一期二期那种，就是一个合同之内，一个项目之内的事情分成几个阶段。比如，打算做8个模块，就先做大老板关心的1-2个模块+报表模块，其他的再慢慢做。建议周期在3个月以上的项目都可以考虑一下分阶段。这个当然不是每个项目都成立的，有的时候很不幸几个模块彼此关联性非常大，必须一起做，这就没辙了。

分阶段实施的时候，可以第一阶段需求完成了，供应商开发的时候，就开始做第二阶段的需求，一来时间可以向前挪动一些，二来，用户和咨询顾问不会出现在开发阶段无所事事的空当期，三来，用户使用模块的周期比较长，有更多的机会在前期就暴露出开发中的问题。

下面是以前写的分阶段和不分阶段的比较（当初还写了个文档，哈哈，现在就把比较这段摘出来了，想问更多的再联系），不一定有道理，大家随意反驳
一、分阶段实施
1、项目时间：在供应商人力资源的充足的情况下，可以缩短项目周期
2、客户buy-in：因在短周期内可以出现可使用的成果，客户保持对项目的持续关注和忠诚
3、供应商的buy-in ：因在短周期内可以出现可使用的成果，供应商获得价值被认可的成就感，能保持对项目的忠诚度
4、项目新增需求：在分阶段的过程中，用户通过持续对产品的使用，存在提出更多需求的风险；但同时，这仅是把新增需求的风险放在了项目前面一些的阶段暴露
5、项目质量：因客户可以迭代使用软件产品，软件的二次开发也存在一个迭代的循环，所以这样开发出的产品更符合客户的需求；运行上经过了更长的时间，也更加稳定可靠
6、适用情况 ：实施周期长于一个月，需求不够清晰
二、不分阶段实施
1、项目时间：存在因客户长期处于松弛期，失去对需求的认可，提出“这不是我想要的东西”而导致需求一再变动、项目周期变长的风险
2、客户buy-in：因中间松弛期过长，客户对项目的关注度和忠诚度都较低，极端时，可能会出现“这是信息部的项目，不是我的项目”的想法
3、供应商的buy-in ：因中间松弛期过程，客户与供应商的交流不够充分，供应商逐步遗忘最初调研的需求，做出来的产品存在不够符合客户需求的风险；同时，因为过长的没有出成果的工作期，存在士气低下的风险
4、项目新增需求：因在实施的后期才进行客户测试，客户需求变动的风险较大，这会导致整个项目周期变长
5、项目质量：在实施阶段的剩下1/3部分开始的用户测试导致缺乏一个迭代的过程，软件质量验证、客户需求稳定的周期都不够长，存在较大的质量隐患。
6、适用情况 ：实施周期短，需求清晰

当初还做了个示意图，可惜不知道怎么贴图，就给个文字描述算了。
项目计划制定之初，最应该关心的资源，然后才是时间。

因为项目周期到底多少，前面说过，在招标过程中，基本上都可以圈定一个比较合理的周期。但是资源却是直接影响项目质量的人。
怎么选人，常用做法就多了，看简历，电话面试。如此种种，一定要按照自己的要求选定自己心目中的人选，然后就是确定资源到位的时间。

最近和一个乙方的朋友沟通，他提到说很多时候项目经理派下来的计划根本就是不可能完成的，（通常情况下，不可能完成主要还是资源不足），所以基本上项目还没开始就知道肯定要Delay，只是很多时候项目经理会死抗。拖到了时间才知道。而且我的感觉是，一般供应商资源不足是后台的人手，就是远程开发人员、测试人员，前台的人员因为一般还是onsite的服务，很难偷工减料，但是后台的就很容易了。

项目过程控制

计划做好了，就是启动、开工，说几个项目过程要注意的吧

1、项目一旦开始，就是例外管理和过程控制，说到底目的都一样，就是避免出现更大的篓子，在一开始就把问题扼杀在摇篮里面。所以，越是乙方项目经理说，一切OK，资源到位，进度一天不差，而你却没费什么精力的时候，就是越危险的时候。风险不是暴露在桌面上的东西，因为一旦暴露了，就是可控的，就总有办法解决它，在底下潜伏着的，不知道到底有多大多严重，这才是最危险的。所以甲方的项目经理一定要时刻悬着一颗心。做过项目的人都知道，通常前面看起来越顺利，后面问题越大，所以危机意识是要时时刻刻都有的。
甲方的项目经理在感觉到一切太顺利的时候，就要出手了，常用的办法无非是乙方的人给周报，强势一点的做法是给乙方后台的人打电话，问问进度，增加检查点，没事就给个交付物，大大小小的东西都必须有交付物，不仅有，而且要正式，不是随便谢谢忽悠一下就行。你就随时掌握了进度，可以随时找到偏离。

2、无论对待乙方还是说你的客户，根据每个人的习惯养成自己的提醒点。就是说比如 1月5日交东西，你1月3日就开始提醒他，否则你1月5日再问，他拖一下，至少3天过去了，所以一定要提前提醒才能保证进度。

3、过程中肯定是有很多事情要做，而且不是计划里面的，是为了达成目标衍生出来的很多事情。所以分配事件的时候，还是两点，谁/什么时间完成。这类事情跟踪进度的时候，绝对不能满足说“正在做”，回答就是“做到哪里了？还剩什么？有什么问题？”

4、阶段性评审很重要。我们往往做阶段性评审是为了展示成果，但是项目管理理论中说阶段性评审还是为了获得进行下一阶段的通行卡。我们往往强调前者，忽略后者，反省起来还是应该以暴露问题为主，并且设好质量关卡。实际项目中，很多时候为了赶进度，就留下长串的buglist，供应商信誓旦旦的说什么时候怎么解决，然后直奔下一阶段去了，但是因为后面的工作量也非常饱满，前面的buglist无法解决彻底，一拖再拖，最后跟滚雪球似的，上线前，雪崩了。所以说，还不如，每个阶段就是必须达到什么样的质量标准后再放行，宁愿集中几天解决这个阶段的问题，也不要说总是用承诺来换取下一阶段的冒进。当然我说的不是一个问题都没有，这就不可能，但是buglist上面，不要有重量级的问题留着。
关于烂项目

这几天和一个朋友聊天，我们都经历过烂项目，所以就一起总结了一下烂项目的特点。这个很多都是他总结的，不敢略人之美。

1、烂项目多半都resource分配混乱。——防治策略就是你让乙方项目经理给你一个resource分配表，然后时常跟踪一下，如果当中的人，比如开发人员之类，知道自己在开发什么，下一阶段要做什么，时间点在哪，就是好的。反之，如果这些人觉得一会做这个，一会做这个，项目一会忙得要死，一会闲得要死，不知道下面要做什么，那这个项目多半迟早出问题。

2、烂项目多半都沟通不明，如果所有人都在抱怨不清楚的时候，这个项目差不多玩完了。需求人员说不知道项目范围在哪里，开发人员说需求不清楚（那他如果开发就是想当然的东西，拿到手一看绝对不是客户要的东西），客户说不知道进度在哪里，问题在哪里，项目迟早玩完。所以每个人知道自己要做什么，该怎么做，就激发了他们的内在动力，要不就成了各自为政的瞎忙乎，最后凑一起看，什么都不是。

3、客户不知道阶段目标和验收标准。这是那个朋友提出来的。是非常非常之正确的。客户一旦不知道阶段达成标准，就会过程中需求变来变去，阶段验收的时候这个也要做，那个不行也不给过，搞得来80%的时间都去搞一点点小问题了。
项目经理有很大的作用就是引导客户想明白每个阶段的验收标准。通常客户都是一句话，能用，好用，客户的描述是感性的语言，但是项目经理就有必要将它量化、明确化。以前看丰田案例，日本鬼子做凌志的时候，目标就是改变大家对丰田中档车的观念，要做一款高档车，他做的需求调研就是为客户为什么觉得奔驰、宝马高档，得到的答案就是
（1） 身份地位与尊容的形象
（2）高品质
（3）转售的价值
（4）性能（例如，操控、乘坐、马力）
（5）安全性
最后他根据客户这些感性的词语，翻译出了凌志的目标
（1）最高时速：250 km/h（比奔驰多28，比宝马多30）
（2）耗油量：每加仑行驶23.5英里以上（比奔驰多 4.5，比宝马多4.7）
（3）噪音情形：100km/h 时速为58分贝，200km/h为78分贝（奔驰为 61/76,宝马为63/78）
（4）空气动力……
（5）汽车重量……
PM同样要承担翻译者的角色，引导客户明确阶段验收标准，什么功能必须能用，系统速度多少，什么样的功能可以放一放，标准明确，并且所有人都知道，项目是很好做的。问题往往就是最终目标不明，每个环节的人都不知道轻重缓急，沟通又没有传达到位，大家各自为政了，一到环节交接的时候就完了。

4、烂项目常常在1-2个月的时候忽然大大的延期一把，并且原因不是非常成立。然后这个项目就会在后面几个月时间里一再延迟，而且每一次延迟的时间都更长，如果第一次是半个月，第二次就成了1个月，第三次就成了3个月……。所以一旦某个项目延期了第一次，感觉上比较突然，而且原因似乎都是可以协调的原因（比如，他说有个技术难题，你可要问清楚了，什么技术难题，一定要找这方面的专家问清楚了，这样的问题通常会不会花那么多时间；人力资源不足等等。很多时候，这些原因会看上去表面合理，但是一旦你深究了，就会发现不对劲，所以带着危机意识去问为什么为什么为什么是必须的），那么你要警惕了，这个项目极有可能会成为一个烂项目。
终于找到以前关于分阶段的DD了，现在贴上来，会非常的长，大家不想看可以直接跳过，到第三页23楼以后。

分阶段论述一

企业的实施类项目（以成熟的产品为基础，辅以少量二次开发的项目）常见的步骤（有的企业叫做阶段，但为与另一概念区别，在此使用“步骤”）可划分为：开始，立项，需求调研，合同，系统实施（含二次开发、供应商测试、用户测试），试运行，结束。具体的划分方法、名称上各个企业有所不同，但是大抵上大同小异。具体做法上企业也大抵上如此分派，一个项目的每期一个合同、一个阶段划分，系统实施的步骤中是本期范围内的所有模块（含二次开发的部分）同时上线。但实际上，企业的项目的实施阶段大可按照开发工作量的不同做多个阶段的划分。以下将详细论述分阶段做的优势与劣势。
（一） 定义
首先，做几个假设定义。
期：一个项目可以划分为一期、二期、三期，假设每期是一个单独的合同。以某企业资金信息管理项目为例，假设此项目一期的内容是完成银企直联接口，报表，票据管理，内部调拨及计息管理，信用额度管理；二期的内容是资金计划管理，与ERP银行日记帐对帐，外汇风险管理。每期都是一个单独的合同。
阶段：每期（每个合同）内项目的内容上的划分。同上例，根据二次开发工作量的不同，可把银企直联接口、报表作为第一阶段，票据管理、信用额度管理作为第二阶段，内部调拨及计息管理作为第三阶段。
步骤：同本文开篇所述，分为开始，立项，需求调研，合同，系统实施（含二次开发、供应商测试、用户测试），试运行，结束。
用户或客户：企业中参与该项目、使用该软件产品的业务部门用户
供应商：提供软件产品、项目实施、二次开发服务的产品和服务供应商
（二） 不分阶段实施
正常情况下，企业通常的做法可以用如下图示示意：
（见第一个图）
示意图说明：1）以资金项目为例，时间仅做一个较长的跨度假设
2）假设详细需求调研是在合同签订前完成，合同签订步骤无需客户参与
3）合同签订与系统实施是串行关系，不能同时进行
4）假设系统实施步骤中，2个月处于二次开发、单元测试、集成测试等供应商为主的工作，最后1个月处于用户测试以及反复修改的过程
系统实施步骤长达3个月，期间包括各模块的并行开发、测试、用户测试等等，在通常情况下，会出现：3个月中，前面2个月是处于用户和供应商没有交流的开发真空期，供应商和实施期的最后1个月内用户密集测试，工作量很大。
（见第二个图）
蓝色部分表示出整个项目阶段中有2个半月（含合同步骤和实施的前2/3步骤）客户与供应商处于少接触的真空阶段，比起项目一期整个6个月的时间，有2.5/6=41.7%的时间客户处于松弛状态，而在实施步骤的最后一个月内，客户又处于密集的用户测试阶段，加上本职工作的时间冲突，使得这个系统实施步骤的最后一个部分中，时间会比预期的更长；而此时客户已经忘记了前面需求调研的内容，在后期测试中经常会提出“这不是我想要的东西”的质疑，导致的系统一再的反复修改，在时间紧迫的情况下，可能没有时间做整体规划，成了客户说什么就做什么的供应商，整个系统多处修修补补，稳定性、整体性、一致性都不高。
（三） 分阶段实施
如果我们换一个做法，在系统实施阶段，按照模块的二次开发工作量的大小来划分阶段，把二次开发工作量小的模块放在前面实施，二次开发工作量大的模块放在后面阶段实施。如资金项目案例，可把银企直联接口、报表这种几乎没有二次开发工作量的模块实施作为第一阶段，票据管理、信用额度管理等做少量二次开发就可以直接应用的模块实施作为第二阶段，内部调拨及计息管理有大量二次开发的模块实施作为第三阶段。
2. 获得buy-in的优势
从项目整个Team而论，项目管理者最应获得的是项目成员（含供应商与客户）的buy-in, 即项目组成员的关注、忠诚、被收买的愿意付出的精神，这种核心凝聚力对于保持项目组的士气、用户的关注度、供应商的关注度有极为重要的作用，是属于项目成功必不可少的隐性因素。采用分阶段实施，可以使项目的短期成果被迅速的分享出来，对于供应商和用户都是即为鼓舞士气的做法。
就客户而言，因为客户在整个项目过程中始终参与在其中，没有一个长期的松弛过程，客户保持了一贯的关注度，对于前期需求的调研也能记住更多的部分，减少了最后提出“这不是我要的东西”的风险；在实施过程中因为持续的参与能够逐渐获得一种“这是我做的产品”印象，能够加深对所生成产品的认可度，项目管理者在这个过程中也逐渐得到了客户的buy-in；项目短期成果被迅速分享和公布，使得客户对于他们的上级有更多可汇报的成果，自己也能获得成就感，他们就能持续保持对项目的关注度和参与度，形成了良好的心理循环。
就供应商而论，虽然因为工作关系不得不勤奋的工作，但他们同样是项目管理者的事业伙伴，这意味着获得他们的buy-in也同样重要。通过划分阶段在短期即可获得可公布的阶段性成果，这种做法对供应商来说是价值得到认可，他们将获得工作被认同、自我成就感形成的良好心理感觉，在精神愉悦的同时，项目管理者也逐渐获得了他们的buy-in。

3. 需求受控的优势
当然，用分阶段实施也同样存在一定的风险，客户在能使用第一阶段产品之后及第二阶段产品出来之前，可能会对第一阶段产品做持续的研究和使用，这意味着他们提出质疑、提出更多需求的机会将大大增加，此时，控制需求将成为项目管理者必须关注的问题。但从另外一个角度来讲，这种方式可以将需求变动的风险前移。项目管理者的职责是控制项目，即控制风险，但控制风险除了将某些风险的发生率降到最低外，将风险发生的时间和阶段迁移同样也是增强风险控制的方法。
在上述两种情况中，客户在持续使用产品后，提出新的需求的风险是同样会发生的，在分阶段实施中，这个风险被移到了实施步骤整个过程，并且在整个过程中有更长的时间通过各种手段消化掉因需求增加而导致的项目周期延长的风险，在不分阶段实施中，这个风险被移到了实施的最后1/3部分，在这1/3部分中因为客户本职工作的时间冲突，导致测试不充分、产品应用理解不深入会使新需求提出的风险再度被延后到试运行阶段，再往后，这种风险将被转嫁到企业信息部人员头上。项目的不可控风险就会大大增加。
不分阶段实施，出现的需求变动的时间会更靠后，试运行阶段有更大的风险成为需求频繁变动期，试运行期以及用户测试期对于供应商而言是较为懈怠的期间，此时发生频繁的变动容易引起整个项目时间的延迟，因此会引起整个项目的急躁情绪，从而难以在整体上有规划、宏观的掌握需求变动，易于出现因改A模块，忘记修改B模块中关联的部分，系统Bug较多的情况（当然，如果供应商的开发管控很严格，也可以降低这种风险），如果项目组为了赶时间进度放弃部分需求，在系统关闭后这些需求仍然会转嫁到企业信息部的头上；而分阶段实施，需求变动的时间更靠近系统实施期，因频繁的交流和阶段性成果的公布，项目组的心态容易处于斗志高昂的状态，整体效率较高；时间较为充裕，整体进度中出现的任何延迟都可以通过较为合理的分配在较长的一个时间区域内得到消化，因此，此时任何变动对整体时间进度影响都会比后期出现相同大的需求变动对整体时间进度影响小。

4. 产品质量优势
分阶段实施，可以在无形中实现迭代开发。
每个迭代开发的过程都包含

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

之后就是总结的分阶段和不分阶段的优劣对比。
大家看晕了吧，吼吼……Sorry啊

**一切内容来源于网络搜索，禁止一切商业应用，否则后果由其承担，本站及主题作者不负法律及连带责任**