项目管理是一个非常复杂和系统性的工作，一个项目的成功往往能带来巨大的经济效益，一个项目的失败也可能浪费大量的人力物力。中培课堂《IT项目管理最佳实践》培训专家王老师根据自己多年的工作经验，就项目管理失败的原因谈了自己的看法。王老师指出，项目失败的原因，有技术上的也有管理上的，以下是导致项目失败常见的5个原因。

错误一：采用平庸的开发团队

软件设计是有难度的，而且不幸的是，很多自称程序员的人确实不能胜任软件设计。尽管这是项目失败的首要原因，你也不曾从官方的失败报告中得知。在所有的行业，软件业，物流业，或者客服业，人们对同事的无能都太过宽容。你从来都不会听到有人说“我们团队没有足够的智慧来完成这件事”。为什么要这样伤人的心呢？显而易见的，如果这队分得了任务的人员并不擅长这份工作，他们的工作会日复一日，日复一日……等等……但软件却没有做出来。你也不用太担心 HR 会阻挠你招聘一班废物。在大多数的案例里，我向你保证，HR 对此毫无建树。

错误二：按周来定目标

假设你想改造你的厨房。你请来的师傅已经搞过很多厨房，而且不作详细蓝图就能估算出这项工作的成本。但软件开发者是在制造前所未有的东西。如果前所已有，他卖张拷贝的光盘给你就行了。因此，粗略的估计是不可能的。他们需要在写代码之前做好详尽的计划。无论你是客户还是开发经理，你的责任就是确保开发人员带着详尽计划来开展工作。当你向开发人员询问计划时，他们大多数人可能只会给你一份把进度按周来划分的时间表。这看似非常合理，但其实不然。如果你让软件团队提交一份大粒度的时间表(大是指需要两天以上的工作，那么你可以认定他们没有考虑到所有需要实现的细节，而这些细节将会积累，导致延期。

错误三：为截止时间而谈判

还有什么比按周划分软件项目更糟糕？就是要求团队承诺大大地提早完成工作。根据我的经验，大多数开发者都会乐观地接受你的暗示并参与讨价还价。然后你会得到一份友好的协定时间表，但却无法按时执行。

试想以下情况：海象妈妈会在怀孕 15 到 16 个月后，生出小海象。你可能会叫海象妈妈保证在 15 个月内做到，而她也说没问题。或者你说，“15 个月？疯了吧？我们要在 8 个月内生出”。当然，这样谈判是无法促进事成的，而且即使得到一份 8 个月的进度表，我还是告诉你一个小秘密：这是不可能实现的。你可以取得一份 11 个月的时间表，但你还是要等 15 个月，因为小海象就是要 15 个月才能出产，有时甚至 16 个月。

　错误四：均分任务

这里有一个破坏项目的好方法。列出人们需要做的所有工作，然后给重新均分给各人。如果 Mary 有太多的工作，就分一些给 John。这听起来完全合理，使得你不会被质疑。但我向你保证，时间一长肯定会出现问题。那是因为当一个开发者去替代另一个时，我们有理由假设效率降为十分之一。John 将会花费无数小时去搞清楚 Mary 其实已经熟悉的那部分代码。而且 John 改 bug 也不及 Mary 快，因为 Mary 才了解所有的陷阱在哪里。

错误五：工作到深夜

让我们假设有个项目要每周工作 40 小时，连续六个月才能完成。如果你让所有人每周工作 60 小时，那么持续四个月就能完全搞定软件团队可能甚至会接受这个挑战

然而现实是　　软件开发者花费大量的脑力劳动。即使是最好的程序员，也很少有能坚持几小时以上的高强度脑力劳动。另外，他们还需要休息一下大脑。这就是为什么你好像总能撞到他们在上网或玩游戏。

强迫他们投入更长时间坐在电脑前，并不会转化为更多的产出——即使会，那都将是劣质的产品。当软件开发者的大脑完全发烧，他们几乎做错多过做对，写出无法使用的代码，或者引入大量的 bug

一旦你有时间表在手，不要尝试提前截止日期。如果项目不能在你能谅解的时间内完成，解决方法不应是去交涉一个“好听的”时间表，而应该是争取更多资源，或者推迟上线，或者拿掉一些功能。

当项目正在进行时，你会多次被诱导而想重新分配工作。但你要谨慎地重分配。所换的新人需要花不少时间去驾驭原作者的代码。我觉得让人员在不同岗位上轮换有助于消除不可替代性，但我是谨慎地安排这事，并且在时间表里加入额外的三周给新人以学习新代码，和额外的一周给旧人去教新人。

最后，鼓励你的员工按合理的工时，一周干 40 小时。在技术的世界里，应该将一个大项目看成是一次马拉松，而非一次短跑。