多个项目经理的失败教训总结，项目成败都有原因

(一)我的五次项目失败，经验总结

一路走来，我渐进地的体会到，有些项目虽然按时、保质的发布和交付，在项目的意义上算是成功了，但在产品的意义上算是失败的。

我属于半路出家的和尚，有幸在与硬件打交道的时候接触到软件；早在几年前我就经历了4家公司，5个比较大的项目；它们的成功或失败，让我切身体会到教科书里说的（注：软件工程）：大多数的软件项目都是失败的。

实际上，约80%以上的项目都是不成功的，或者是因为超预算或延期或需求定位不准，或因功能缺失或资金断裂，或几种因素都有；其中，30%的软件被执行得十分糟糕以至于在没有完成之前就被迫取消。并且，问题出现得越早，越早调整战术和战略，损失就越小；就好像大人常说：小孩越早教容易教，容易影响。

项目失败解析

第一个项目是在做功能添加和压力测试时候出现的，没有发布就“流产”了。

我不是计算机专业出生，所以具体的功能显示在压力测试在哪个范畴我是不知道的，感觉就是软件的架构或者测试的方式上有了很大的争议吧，原型是我画的，但是到最后也没有一个能拍板的，导致项目进展缓慢，讨论了很久，也被其他的项目改BUG给耽误了，最后由于人力资源和项目进展监控不到位，导致其他组员被调离或辞职，渐渐的为了权衡项目的周期发布和整体项目组规划就这样砍调了。

第二个项目是进展在研发阶段被叫停了。

因为公司改组和资金链断裂因素，那个项目最后做了转移，可以说这是无法把控的，作为基层员工的我，加深了对”项目发起应该是自上而下”的认识，项目的开始是需要经过详细的需求分析，做一次深入市场和行业调研的，这就为我后期工作打下了牢固的基础；在项目发起阶段也需要老板（这里所指的老板就是直接的上级，这或许是个人见解）的支持后才靠谱，无论哪个项目没有高层强有力的支持完全是白搭，而且开始做的努力没有得到大家的任何和所做的努力突然流失，会觉得很失落。 

第三个项目（也可以说是一个新的产品）早起的市场调研阶段结束，收集到很多的行业资料和数据以及竞品信息，所以这个项目得继续走下；于是下面的需求分析及产品PPT汇报就顺理成章的接着走；高层接受了建议；做了大胆的决策；我们就加紧做出了产品解决方案，由于公司的代理商及OEM、ODM商对于自家的产品都有不同的建议，导致运营和售前收到了很多的需求（他们认为客户的需求就是需求）。

然而，市场上的迭代很快就打乱了原有的需求计划，变成最后的整改项目；将所涉及的客户所需要的都改一遍，导致每天都是BUG；都是用户投诉，以至于最后高层不得不叫停，到我正式接收；我就重新设置条件，确认需求准入条件，建立项目章程和项目立项标准；最后，采用敏捷管理才走出了危机，这也算一次失败的项目经历吧，因为最终的项目没有做成，却是一次大清洗和大整改，心都累了。一句老话：早一步是先驱，后一步是先烈。如果不抓紧实施需求而转客户需求进行改善，这是要命的；并且客户的需求并一定都产品需求，经典的例子：我想要一匹快的马，不是马不好，而是速度跟不上！这才是关键！

第四个项目算正常的了，成功研发，顺利发布；之后就是运营和维护，一整套流程全部走完。这个项目让我学到了很多的东西，我跟这个项目跟了一年；做了详细的市场调研和竞品分析、需求分析、原型绘制、项目排期，特别是项目后期上线后，运营及营销策略的制定，其实还有很多不完善，售后的跟踪和反馈，客服的答疑、技术支持、财务及定价及和增值业务的协调合作等。

第五个项目是和其他公司共同做的项目，感觉很高大上，规划很有战略性，但因为一些需求没有沟通好以及一些我无法把控的因素，现在还在一步步的走着；第一次的发布和第二次的发布都出现了延期；现在第三次发布看来有拖很久了，还有就是一个APP的方案敲定，我都i已经修改了很多次，每一次PPT的汇报都没有一定的结果，导致拖到年中才规划，满足不了用户的期望，达不到商业目的，算是比较失败的项目吧；很多的细节都是缺少了沟通才导致后面出现了变异，这就像我提到过的一样，需求分析才是产品经理的重头戏，没有好的需求分析，产品第一步没有走好，注定是坎坷的一生。

项目的坎坷的一生讲完了，接下来就是如何避免出现项目风险，以下是个人建议，欢迎交流：

项目成败的关键要素

1、项目干系人

一定要和项目干系人沟通、交流清楚，最好有一定的记录和邮件作为事后记录发布，让大家做一次参考，与项目干系人的交流会加深对产品的理解和做产品后期的规划，项目干系人分很多，包括项目组成员、老板、运营、营销、财务、人力资源、高层、用户、代理商、OEM/ODM商、用户等；做一次深入的交谈和做一个简单的Dome演示，我想这就是产品效果展现最好的佐证。

2、需求分析

需求分析是检验产品经理的标准。需求分析技术一定要用好工具和做好需求交流，面对PPT和原型不要胆怯，尽量去打开你的眼界和心结做出好的产品，因为，这是你思想火花碰撞最强烈的时候，不要去阻挡。

3、数据和资料要充足

资料和数据也是造成项目的成败关键，数据是依据，资料是基础；数据用来做宣讲和佐证的，没有数据的支撑项目的发展也没有说服力，为什么要去找数据呢？大量的数据证明才是最有力的证据，资料是项目的基础所遇到的问题都可以去查找资料，用来说明和支持项目进展。

4、项目监控

每个项目都有其风险存在，做一个全面的风险识别和应对，这样有了项目风险也可以积极的应对，不会造成很大的损失和导致项目流产；项目如果没有了监控就会乱，没有监控就没有质量保证、没有监控就没有进度，这也是项目最关键的！

任何的项目都存在失败和成功，关键就是沟通和取舍，不能为了满足客户而丢掉用户，产品是为用户服务不是纯粹的客户。

（二）项目管理成败皆有原因

    一个项目的成败既有项目外部的因素，也有项目内部的因素。对于项目外部的因素项目组一般是难以扭转的，例如项目经费的削减，组织的业务方向的变更，客户对合同的违约等等。但是对于项目内部的因素造成项目的成败却是与项目经理的素质和管理是密不可分的，大多数项目经理在项目管理中存在以下四个失误：
    1、  需求把握不好：没有控制好需求，使需求陷于反复变更之中，既浪费了项目的时间，有容易使开发工作失去重心。有这么一个例子：我做的车辆年费征收系统的项目里，有一个收费折免功能，稽查队、车管所、路桥处都会用到，只是折免权限不同，最开始项目组在车管所调研，车管所提出折免界面应该输入免去多少金额，等这项功能做好以后，拿到稽查队去，而他们提出折免界面应该输入折后实收多少金额，后来到了路桥处就要输入打几折，项目组为这项功能反复变更了三次。正确的做法应该是，在确定某项需求时，要把与这项功能相关联的所有客户的需求都收集起来，提出一种合适的解决方法，然后得到与这项功能相关联的所有客户的确定，有时候需要让客户自己先到达一致，然后再与客户确定需求。
    2、  做事欠条理：条理清晰是做管理的基本要求，条理不清晰容易使工作迷失方向，抓不到重点，做事没有条理大多是没有认真作计划造成的。有这么一为项目经理，有一天，本来要审核测试报告的，可是客户一个电话要变更一个需求，他马上匆匆忙忙到客户那里讨论需求，回来后马上要做这项需求的开发人员根据变更的需求更改程序，而这项需求刚好做了测试，测试报告还没有来得及审核。这样既浪费测试人员的时间，又使做这项需求的开发人员没有根据测试报告及时修正程序。正确的做法应该是：自己继续审核测试报告，派做这项需求的开发人员与客户交流，开发人员回来后，与开发人员、测试人员一起讨论需求的变更，同时根据测试报告形成一个修正方案，开发人员再进行修改程序。
    3、  专注做项目中的某项工作而没有看到项目全局：项目经理如果没有全局观念，就不能及时觉察到项目中出现的种种迹象，从而发现可能出现的问题。其实有很多事情，如果在刚有苗头时及时采取措施，是完全可以避免的。一个项目的成功是项目整体的成功，如果严重影响项目的风险没有避免，哪怕项目经理做的模块做得再好也于事无补。原来自己负责一个教育资源管理系统得开发，由于自己也是技术骨干，负责系统的核心模块教育资源存取的开发，自己整天沉浸于自己负责的模块的开发中，没有觉察到做系统管理的开发人员由于情感问题情绪低落，还一味根据自己的进度对他进行加压，在他做了70％时，他主动提出离开项目组，而且由于我的不懂人情对我产生了怨恨而带走所有源码，这件事对项目产生很大影响。
    4、  配置管理混乱：大凡在项目开始时，大家还比较清楚各自所做的工作产品的版本和更改情况，但时间一长，东西一多就会混乱。有许多开发人员认为严格的配置管理太麻烦，有时偷点懒觉得没关系，其实到了出现问题时，就后悔莫及。我就在做教育资源管理系统时由于开始都是个人自己管理自己做的模块的文档与代码，等一个模块全部做完了再提交给测试人员进行测试。由于做系统管理的开发人员带走了所有源码，我这里什么都没有，我真的后悔死了。
    另外，一个成功的项目有以下四个特点：
    1、  依着一个目标前进：一个项目必须有一个统一的目标，要使得整个项目组向这个目标前进。其实在一个项目组中，每个项目成员可能有自己的小算盘，有的想通过做项目学习新的技术，有的更注重获得经济效益，也有的想积累项目经验，这样需要项目经理把大家的精力集中到项目的方向上来。我做过一个多媒体教室的项目，其中项目组有两个小伙子很有上进心，喜欢钻研技术，不喜欢作细致完备的工作，于是我把系统所用到的技术分为几个主题，每一周召开一个主题的研讨会，在研讨会我就给他们讲任何先进的技术并不在于其本身的先进，而在于其应用的先进性和完备性。一个程序员的技术水平的高低并不只是由于他掌握了先进的技术，正如《卖油翁》所说的高手其实就是唯手熟而。后来在开发中这两个小伙子积极性很高，而且做事也越来越认真细致。
    2、  让规章说话：项目组在容易出现争执或难以控制的地方制定合理的规章制度，按规章办事虽然不能保证样样是好的，一般可以保证70％是正确的，同时可以避免项目组有些矛盾的激化。尤其在与客户确定需求时，必须制定一套确定客户需求的规章，不能哪个客户说什么就作什么，在项目组和客户之间按照一定的规章来确定需求，这样做，就不存在项目组的某个人得罪了某个客户。我在做一个进销存系统时，由于在现场开发，如果没有一套确定客户需求的规章，一个客户跑过来讲一个自己的想法，不一会儿另一个客户跑过来讲一个自己的想法，会使整个项目开发工作都难以进展，于是我们在第一次与客户交流时就与客户制定了确定需求的规章，并且打印出来人手一份，规章里规定客户有一个确定需求的负责人员，每一个需求及需求更改必须以书面形式，并且有负责人员签字，项目组才予以承认，到项目组后，必须有项目经理的签字或授权认可，这项需求才成为正式需求，开发人员才进行程序更改。这样虽然不能保证100％按照规章执行，但可以杜绝大多数的因为需求变更而出现的问题。
    3、  按照计划行事：凡事预则立，不预则废。制定合理的项目计划，就是让项目组的每一个成员在项目中的任何时间都知道自己应该作什么，如果一天不知道自己该干什么，就浪费了一天，一个小时不知道该干什么，就浪费了一个小时。其实有很多项目的延迟，都是平时一天一天的浪费，一个小时一个小时的浪费造成的。我做项目，一般三个月以上的，项目计划精确到周；另外每一个项目组成员都要制定个人工作计划，不要详细，心里明白就行，个人计划必须到天，至少可以保证不会浪费一天。
    4、  按照条例检查：对于工作产品的质量检查和软件测试，必须先制定需要检查的和测试的条例，然后按照条例进行检查和测试。这样可以做到有的放矢，事半功倍。我接触到有这么一个项目组，该项目组开发的系统已经开始运行了，但存在很多BUG，于是项目组招进了三个测试人员，这三个测试人员没有多少测试经验，对系统也不了解，业务也不熟悉，项目经理给每个人分配一台电脑，里面装有一套项目开发的系统，对他们说：这个星期，你们对这套系统进行测试。一个星期到了，项目经理来检查，发现他们除了发现几个界面上的错误外，没有发现什么BUG，项目经理埋怨他们工作不尽力。其实他这种做法好比拿一个古董给一个外行人去鉴别真伪，不知道从何下手，既浪费时间，又没有什么效果。我做项目的一般做法是：对于质量检查，质量保证人员根据项目的质量标准和公司的相关规范列出一个质量检查表，质量保证员根据质量检查表逐个检查就行。对于软件测试，在测试前必须撰写测试案例，一般测试案例的撰写都是要根据前一个工作产品为基准，对于界面测试，我们对每种控件都规定若干测试条例，例如下拉列表框，我们需要测试以下几个方面：回车键、TAB键的选定及焦点的变化，下拉选项的长度和宽度，鼠标的单击的选定，无选择项的选定，鼠标的滚轮的选择，关联快捷键的操作，是否可以编辑（编辑的测试条例另外给出）等。测试人员只要拿着测试案例和条例逐个测试，然后把测试结果记录下来就行了。
    项目管理有着很好的理论和实践，例如ISO9000的质量控制体系，CMM的软件过程改进，美国项目管理委员会提出的项目管理知识体系，我觉得对于一个项目管理人员来说，如何把这些管理理论化为自己做项目中的具体的操作方法和步骤是最为关键的。影响项目成败的因素还有很多，我在自己做项目过程对上述几点体味最为深刻，希望对大家有所帮助。

（三）我的一个失败项目教训

当我的合伙人和我在2004年创立公司后，我们三个人包办从编码到跟客户沟通一切业务。当我们公司发展壮大时，很明显我们有必要变得更加高效。在追求效率的过程中，我们太注重工作流程，而对客户需求不够重视。

事情经过

我们创建了手机行情软件和基于网页平台的市场应用软件。我们的软件开发模型基本上是这样的：一组成员跟客户沟通，设计并细化一个项目，然后交给另外一个团队编制软件。这个模型中组与组之间没有太多的资源共享共享，也没有机会 交流 反馈。这让很多的员工都饱受挫折。

去年底当我们意识到开发模型引起的问题比解决掉掉的问题还多，这就触发到问题的实质了。这个开发流程不灵活---团队没有理念的共享，而变更正在进行的设计也是一个挑战。员工缺乏拥有感，因为没能看到整个项目的全貌。

还有，公司的开发人员严重脱离了项目的轨道。到他们必须开始做项目时，很多的设计和决定都势在必行了。实在是个问题：许多的客户不知道并不真正知道需求，比应该可能知道的还少很多。 如果我们成功地做好我们自己的工作，帮助客户确认了他们的最终需求，并想出了最后的办法达成这个需求—不管是开发一个新的应用程序，或者改写一个他们已经有的应用程序。但如果我们的开发人员游离于项目之外，开发的技术再好也无从谈起了。

所以我们问我们自己，如果这个方法不再有效，为什么还照着做？我们觉得有必要追根溯源—并为40个员工找到行之有效的方法。

现在回想，似乎那么明显：发挥团队的力量而不是各自为战。把业务分析人员同开发人员结合起来，看他们会产生什么好的想法。

就如拨开乌云见青天，我们把项目的拥有感从头到尾的归还给员工。然后提供给客户他们需要的模型。

综合两个开发模型成就最好的开发模型。

过去的项目管理一直采用瀑布开发模型。把非线性的流程转化为线性的工作流。从流水作业的观点看似乎很有效，但从创造性的角度看并不是那样。最常用的替代方法是敏捷开发模型，把项目细分成零碎的步骤。工作计划通常一次覆盖一到两周，其间客户不清楚会有多大开销，也不知道时间的开销，直到项目完成才有概念。除了创造性方面的自由，敏捷开发模型有一些明显的缺陷。

后来我们从中发明了一个方法—正在替他取一个很酷的名字。这个理念从设计填充到投入使用，大概经历了半年多的时间。但对我们来说已经是个了不起的成功了。

这个开发管理模型包括用客户的大概预算设计出初略的雏形，一两个月为项目的阶段性目标。每一个阶段有一个小瀑布模型，这样才能适应新的想法和需求的改变，其间严格遵从可预见的时间表。因为能够给予客户所需要的，业务分析师比较满意；另一方面开发人员也乐意帮助定位项目，也能有效推动项目进度。

这样整个团队都理解了客户的最终目标。这个行业倾向于在凌晨两点提供工程的重大进展。如果开发人员越能明白客户的需求，那么在凌晨两点项目的进展方向就可能越正确。

如何满足客户需求

很容易看到我们在管理方面取得的成就。这些成功归功于提高员工的士气，士气的提高意味着能够更容易地招聘和留住好的人才，这样能给客户提供更好的产品，也等于提高了公司效益。2008年我们的年收入为510万美元，2009年的年收入由于经济危机下降到460万美元。今年有望达到600万美元，公司的成功同新的项目管理方法关系重大。

有一件事能证明我们的成绩：最近一个客户在内部产品开发上面遇到问题，找到我们并且想要把这个工作外包给我们公司。后来我们明白他们需要的不是技术，而是开发的管理模式。他们见识了我们怎么改进项目管理流程—以及其间怎么提高大家士气—现在我们会相同的方式为他们的项目提供帮助。