随着项目管理知识的普及，很多人已经意识到这些神话的本质——它实际上误导了管理者和项目人员对项目管理的态度，从而引发了严重的问题。然而，由于习惯和态度的根深蒂固，项目神话遗风犹在。

1、管理神话

像所有的职场人士都有大小不同的压力一样，项目经理也肩负着维持预算、保证进度和提高质量的压力。在应对困难走头五路时，就像溺水人抓住稻草一样，项目经理经常依赖项目神话中的信条，只要它能够减轻以上的工作上的压力（即使是暂时性的）。

神话1：我们已经有了一本写满项目开发标准和规程的宝典，大家就应该遵守！

事实：这本宝典也许的确已经存在，但它是否在实际中采用了？项目人员是否知道这本书的存在呢？它是否反映了项目工作的现状？是否全面？是否可以适应不同的应用环境？是否在缩短交付时间的同时还关注产品质量的保证？在很多情况下，问题的答案是否定的。

神话2：如果我们未能按时完成计划，我们可以通过增加人员数量而赶上进度。

事实：软件开发并不是像机器制造那样的机械过程。布鲁克斯（《人月神话》的作者）法则告诉我们：“在项目工作中，为赶进度而增加人手只能使进度更加延误。”初看，这种说法似乎与直觉不符。然而，当新人加入到一个项目后，原有的开发人员必须要牺牲本来的开发时间对后来者进行培训，因此减少了本应用于高效开发的时间。只有在有计划且有序进行的情况下，增加人员对项目进度才有意义。

神话3：如果决定将工作外包给第三方公司，就可以放手不管，完全交给第三方公司开发。

事实：实际上正如你在管理项目中会遇到困难一样，外包公司也不一定比你高明多少！在合同谈判中有多少虚假的承诺，也许连外包公司自己都不知道。如果开发团队不了解如何在内部管理和控制项目，那么将无一例外地在外包项目中遇到困难。

2、客户神话

项目的客户可能是隔壁的某个人、楼下的一个技术团队、市场／销售部门或者签订软件合同的某个外部公司。多数情况下，客户之所以相信所谓的项目神话，是因为项目经理和项目人员没有及时纠正他们的错误信息。项目神话导致客户错误的期望，最终导致对开发者的不满。

神话4：有了对项目目标的大概了解，便足以开始项目工作，可以在之后的项目开发过程中逐步充实细节。

事实：虽然通常很难得到综合全面且稳定不变的需求描述，但是对项目目标模糊不清的描述将为项目实施带来灾难。要得到清晰的需求描述，经常是需要逐步变得清晰的，但这有一个前提那就是客户（需求提供方）和项目团队应该保持良好的沟通和互动，否则所谓的渐进明细是猜出来的。

神话5：虽然软件项目需求不断变更，但是因为软件是弹性的，因此可以很容易地适应变更。

事实： 软件需求的确在随时变更，但随着变更引入的时机不同，变更所造成的影响也不同。如果需求变更提出得较早（比如在设计或者代码开发之前），则对费用的影响较小；但是，随着时间的推移，变更的代价也迅速增加——因为资源已经被分配，设计框架已经建立，而变更可能会引起的剧变，需要添加额外的资源或者修改主要设计。

3、工程师的神话

在多年的不正确的文化滋养下，工程师深信着各种各样的神话，并以此作为真理。

神话6：当我们完成技术工作并将其交付使用之后，我们的任务就完成了：

事实：根据拖延症的规律，我们可以推导出一个匪夷所思的现象：工作开始得越早，耗费的时间就越长。业界的一些数据显示，60%~80%的工作耗费在工作首次交付顾客使用之后。

神话7：直到工作结果在实际中使用或运行，才能评估其质量。

事实：最有效的质量保证机制之一就是技术评审，可以从项目启动就开始实行。技术评审作为“质量过滤器”，已经证明其可以比测试更为有效地发现多种类型的产品缺陷。现代质量管理更进一步的认为质量是设计出来的，而不是检查出来的。质量工作开始的越早，越节约成本，效果越明显。

神话8：对于一个成功的项目，只有交付最终的可交付成果就可以了。

事实：项目配置管理包括很多内容，可交付成果只是其中之一。各种工作产品（如模型、文档、计划）是成功实施项目工作的基础，更重要的是，为产品技术支持提供了指导。没有永远不出问题的产品，假设你交付客户的是一个信息系统网络集成项目，出现了运行故障，当你当到达现场时发现，没有网络拓扑图。我想此时的心情一定是飞过一万头羊驼。

神话9：项目工作将导致我们产生大量无用文档，并因此降低工作效率。

事实：项目工作并非以创建文档为目的，而是为了保证项目结果的开发质量。好的质量可以减少返工，从而加快交付时间。开发人员都恨自己写文档，都恨别人不写文档，最恨看别人的设计，也许就是这种神话产生的土壤吧！

目前，随着项目管理知识的普及，大多数项目从业人员已经认识到项目神话的谬误。对于项目中真实情况的正确理解是系统解决实际问题的第一步。但是项目管理知识的传播与实践，仍然任重而道远。