我最近与老板谈到了“项目失败”。三年后，我们将代码库迁移到一个新平台的项目（我已经工作了一年的项目已有1.5年，但我的团队领导工作只持续了几个月）才开始实施。他，以及我公司和客户的高级管理人员（我是你听到很多关于那些可怕的顾问之一。我的订婚是“应用外包”）宣称该项目是成功的。我不同意，指出我发现的旧陈述表明，与原始计划相比，部署的延迟最好用几个月来衡量，并且可能用数年来衡量。我解释了我所知道的项目失败，以及失败率背后的研究和统计数据。他回答说这是所有的学术界，由于变革/风险管理的奇迹，他所领导的项目都没有失败 - 这似乎归结为解释延迟并根据新数据重新评估时间表。
这样的咨询可能与其他项目有所不同，但看起来这只是一个更漂亮的名字，以避免因未能按时，按预算或完整功能而交付的耻辱。事实上，他解释说我的公司免费提供了数小时的工作，以便在最大限度的预算内完成项目说了很多。
所以我问你这个：
<小时/> @ shog9：
答案 0 :(得分：5)
我认为，大多数时候，我们开发人员忘了这一点，毕竟我们所做的一切都是关于商务。
从这个角度来看，一个项目并非失败，而客户愿意为此付出代价。这一切都取决于客户，一些客户有更多的耐心，更好地了解软件开发的风险，如果有实质性的延迟，其他客户就不会付钱。
无论如何，关于你的问题。无论何时进化项目都存在风险，也许您在某个日期安排项目结束，但需要比预期长6个月。在这种情况下，你必须平衡你已经花费的东西和你必须获得的东西与你正在承担的风险。实际上有一种称为“决策制定”的整个科学在软件层面进行研究，所以你的老板根本没有错。
让我们看看一些问题，客户是否愿意等待项目？他是否愿意承担某些超额成本？即使他不这样做，是否值得完成该项目，假设额外的成本而不是丢弃所有已经完成的工作？公司能否承担已经失去的东西？
问题的真正答案在于这些问题。你不能建立一个观点，并说，如果这个时候没有完成项目，那么它就是失败。至于你的具体情况，谁知道？你的老板可能有更多的信息，所以你的工作就是告诉他项目的进展情况，需要花多少钱以及花费多少（如果你愿意的话，以小时/人为单位）
答案 1 :(得分：1)
除非在项目开始时明确说明目标，否则“成功”和“失败”之间没有明确界限。通常，项目会有不同程度的成功/失败。
对于一些人来说，只需在代码中获取一些概念就可以获得成功，而其他概念则可以衡量成功，即恢复所有投资并获取利润。 两种众所周知的失败模式是时间表滑动和质量下降，但在现实世界中，人们似乎并不关心它们。
简单的方法是让管理人员随时提出请求（功能蠕变）并让程序员编写他们认为正确的任何代码（牛仔编码）。更改管理流程，例如scrum的sprint planning和XP的planning game都是一些例子。这些是管理层和开发人员按时交付可靠产品的一些尝试。如果任何一方对可靠或准时不感兴趣，那么变更管理将没有用处。
答案 2 :(得分：0)
我认为项目的成功取决于客户是谁。如果客户是公司董事并且他们很高兴，那么无论一路上的失败如何，该项目都是成功的。
答案 3 :(得分：0)
Andy Rutledge写了一篇关于成功的非常有趣的文章。虽然标题是Pre-bid Discussions，但文章定义了有一个成功的项目，这对Andy来说很重要：
成功的顾问Obie Fernandez在他的Do the Hustle咨询会议上指出了这篇文章。
答案 4 :(得分：0)
什么是变更管理，以及它如何应用于项目？
变更管理是指在项目发生之前批准和传达变更。如果您的项目中有人（用户，赞助商，团队成员......谁）想要添加功能，则需要记录变更并分析其效果。在进行更改之前，必须先批准对范围，预算和进度进行的任何更改。这些更改通常由您的赞助商，指导委员会或您的客户批准。
一旦更改得到批准并被接受，那就是您的新计划。原始预算或时间表是什么并不重要。
项目的变更管理完全是关于“没有惊喜”的原则。合适的人员（您的变更控制委员会）需要批准对范围，计划和预算的任何更改，然后才能采取行动。
要记住的一点是，可能存在某些明确或隐含的约束和变更容忍度。您可能必须在特定日期之前交付项目以满足政府监管要求。或者您的组织可能有一个阈值，一旦项目预算比原始预算高30％，它必须达到“C”级别或项目被杀死。预先调查并明确说明这些阈值和容差是获得更好的成功项目的好方法。
“变更管理”结束在哪里，“项目失败”开始了？
如果项目按批准的范围，进度和预算交付，则成功。
然而，它仍然可能被视为失败。实施后评估是一个很好的工具，可以与您的利益相关者（不仅仅是您的老板）进行合格。此外，还可以通过实现方式来了解项目黑盒外部以及对整个业务的影响。