在启动一个新的软件项目时，寻求一名在软件开发领域具有丰富经验并且可以在项目计划的早期阶段提供协助的主题专家的帮助。这一策略已经被证实可以极大提升项目的成果，然而在项目结束时你还是只能眼睁睁的看着失败发生。为什么会这样呢?
项目失败可分为成本超支、交付延期、质量不合格和/或产品未被应用等一种或几种情况。无论是否曾经参与到项目计划阶段，通常情况下，软件开发人员都会首当其冲承担失败的责任;无论怎样，他们是真正构建这个应用的人。然而，对项目更进一步的审查表明并非所有失败的项目都应归咎于开发人员能力不足。
当对这些失败的项目进行评估时，其中一些项目与行业趋势相比完成的“还算不错”，然而却被其所在组织认定为失败项目。其原因在于绝大多数的问题都与项目之初有缺陷的评估或错误的商务决策联系紧密。为了避免这种情况发生，整个组织首先必须要使用标准的评估术语集合。我们经常会发现个人和组织大量地互换使用关键术语，而实际上他们各自都有独特的含义。
目标 - 我们想要完成或达成的目标 约束 - 在我们所能完成的工作上的一些内部或外部的限制 估算 - 在范围、成本、日程、人员和可能性确定的情况下，对我们所能完成的工作的技术性计算。 承诺 – 通过选择一个评估场景并分配合适的资源，在一系列的限制条件下达成目标的商务决策。 计划 – 一系列项目任务和活动的集合，让我们可以在确定的范围、预算、日程以及人员的情况下，有一定的概率可以履行某一承诺。
这些概念的清晰定义可以确保项目拥有一个良好的开端——实际的目标和对项目所受限制的理解。若非如此，下面这些因素很有可能导致项目在一开始就踏上死亡的征程。
1. 在没有实质的数据和分析的情况下，就接受一个强制的日程安排或完成日期/里程碑日期。
组织中的某个人公开推测项目将在某一特定日期完成，这样在无意中整个团队都会致力于这一期限。也许你的预算周期显示分配给这一项目的资金必须花费到今年年底或者下一个版本不会得到资金支持。也许项目的利益相干人希望项目能在圣诞节前完成，知道项目已经结束他/她就可以安静地享受假期。或者干脆就是因为利益相干人特别喜欢整数，希望项目能够在该月一号发布。为什么一个开发团队会被设定一个主观的项目完成日期的原因五花八门。过于狂热的计划经常导致项目人员配备过度的不幸现实是为什么软件项目失败的另一原因。
2. 添加过多的人员以实现不切实际的日程压缩。
项目经理如何处理过度乐观的项目计划?一个常见的反应就是增加项目组成员，增加的成员经常会比完成项目所需的成员更多。这样不仅会大幅增加项目的成本，还会降低项目质量。让更多的人参与到项目中会增加错误传达的可能性，也会让不同部分的代码整合更具挑战。此外，Frederick Brooks (1975) 的主张“在延期项目中增加人手只会让项目更加滞后”是有一些道理的。这些人员通常是从其他项目中调派而来。这会让其他项目的项目计划更加滞后并且还要求新的成员能够赶上资深成员，这样整体来说生产力是下降的。
3. 未能考虑和调整需求的增长或变化并据此对计划和预算预期进行必要的调整。
“如果……不是更好么?”这种话有时候是最可怕的，特别是在项目组建的过程中道听途说而来时。当然，确实需要时间和场所进行头脑风暴，这些活动应该在第一阶段和第二阶段开展。实际上，这两个阶段的目的就是要决定一个项目是否可行，以及应用应该具备哪些功能特性。你可以如此考虑这个问题，第二阶段帮助你确定所要构建的内容，第三阶段则开始构建在第二阶段所确定的内容。在这两个高级阶段之间存在一定的重叠，当处于阶段三时，对于一个产品发布版本来说，应该已经有了一个清晰的必要功能列表。如果在没有增加开发时间和预算的前提下就增加功能，需求的增长就会成为问题。实际上，这是在要求在更短的时间内完成更多的工作，这种手段早已被证明无效。取决于其特性和时点，已有需求的变更也有可能成为问题。只要变更发生在某一特定迭代的构建之前，使用敏捷开发方法的项目就可以处理这些明细需求的变更。不过，对于任何会导致代码返工的软件架构方面的需求变更几乎必然会对项目的计划和预算产生影响。
4. 忽略事实和统计数据的情绪化或”全凭直觉的“利益干系人谈判。
或早或晚，我们都会与某个我们参与的具体项目紧密联系并在该项目的产出之上投入情感。对于许多人来说，该项目可能关乎自己的声望;项目太大经不起失败，而这经常会让我们被我们的情感所控制。当软件项目的成功或失败悬而未决导致个人的事业处于危险之中时，任何相关的业务决策很有可能都会受到影响。压力可以让人思维混乱，特别是在赌注巨大之时。为了给客户留下深刻的印象，某个利益相干人可能会要求一个12个月的项目计划安排，而完全不顾之前类似规模的项目报告均显示了15个月的生命周期。利益相干人很可能会忽略项目成员的建议，并声称他“感觉”项目团队可以渡过难关。在这种情况下，凭直觉可能是相当不利的并且有可能直接导致项目的失败。