project-management - “变更管理”从哪里结束，“项目失败”从哪里开始？

Question

我最近和我的老板就“项目失败”发生了小争执。三年后，我们将代码库迁移到新平台的项目（我参与了 1.5 年的项目，但我的团队领导只参与了几个月）上线了。他与我公司和客户的高级管理人员（我是您经常听到的那些可怕的顾问之一。我的参与是“应用程序外包”）宣布该项目是成功的。我不同意，指出我发现的旧演示文稿表明，与最初的时间表相比，部署延迟最好以月为单位来衡量，并且可能以年为单位来衡量。我解释了我对项目失败的了解，以及失败率背后的研究和统计数据。他回答说那都是学术界，他领导的项目没有失败，

也许这样的咨询与其他项目不同，但似乎这只是用一个更漂亮的名字包装的失败，以避免因未能按时交付、按预算交付或未提供完整功能的耻辱。他解释说，我的公司为了在最大预算内完成项目而免费提供数小时的工作，这一事实说明了很多。

所以我问你这个：

• 什么是变更管理，它如何应用于项目？
• “变更管理”从哪里结束，“项目失败”从哪里开始？

---

@shog9：
我不是在问与顾问的责备游戏，尤其是因为在这种情况下我代表顾问。我一直在寻找关于何时应将项目视为“失败”的意见，无论最终是否实现了所需的功能。
我正在寻找“这实际上比我们想象的要复杂一点，而且这将是另一周”之间的区别，我认为这有点典型，和“项目失败” - 但是你想定义失败。甚至有区别吗？这种轻微的进度延误是否构成统计上的“项目失败”？

Answer 1

我认为，大多数时候，我们开发人员忘记了我们所做的一切毕竟是关于业务的。

从这个角度来看，当客户愿意为此付费时，项目并不是失败的。这完全取决于客户，一些客户有更多的耐心，更了解软件开发的风险，另一些客户如果有很大的延迟就不会支付。

无论如何，关于你的问题。每当您发展一个项目时，都会涉及风险，也许您将项目安排在某个日期结束，但这比您预期的要长六个月。在这种情况下，你必须平衡你已经花费的东西和你必须获得的东西与你所承担的风险。实际上有一整门科学叫做“决策制定”，它在软件层面研究它，所以你的老板一点都没错。

让我们看一些问题，客户愿意等待项目吗？他愿意承担某些超额成本吗？即使他不这样做，是否值得承担额外的成本而不是扔掉所有已经完成的工作来完成项目？公司可以假设已经丢失的东西吗？

您的问题的真正答案在于这些问题。你不能建立一个观点，在这里，如果这个项目没有在这个时候完成，那么它就是一个失败。至于你的具体情况，谁知道呢？你的老板可能比你有更多的信息，所以你的工作是告诉他项目进展如何，需要多少费用以及需要多少费用（如果你愿意，以小时/人工计算）

Answer 2

除非在项目开始时明确说明目标，否则“成功”和“失败”之间没有明确的界限。通常，一个项目会有不同程度的成功/失败。

对一些人来说，仅仅在代码中获得一些概念就是成功，而另一些人则可能将成功衡量为收回所有投资并赚取利润。两种众所周知的失败模式是进度延误和质量下降，但在现实世界中，人们似乎不太关心它们。

推迟进度的简单方法是让经理随时提出请求（功能蠕变），让程序员编写他们认为正确的任何代码（牛仔编码）。变更管理流程，例如Scrum的sprint 计划和 XP 的计划游戏就是其中的一些例子。这些是管理层和开发人员按时交付可靠产品的一些尝试。如果任何一方对可靠或准时不感兴趣，那么变更管理就没有用处。

Answer 3

我想项目的成功程度取决于客户是谁。如果客户是公司董事并且他们很高兴，那么无论沿途失败如何，项目都是成功的。

Answer 4

Andy Rutledge写了一篇关于成功的非常有趣的文章。虽然标题是Pre-bid Discussions，但这篇文章定义了一个成功的项目，对于 Andy 来说，这意味着：

1. 是否允许我或我的团队将我们最好的作品带入最终结果？
2. 客户是否准备好适当地参与该项目？
3. 客户准备好开始这个项目了吗？
4. 客户是否准备好信任我或我的团队的想法？
5. 我或我的团队是否准备好满足或超过项目要求？

这篇文章是由成功的顾问 Obie Fernandez 在他关于咨询的Do the Hustle会议中指出的。

Answer 5

什么是变更管理，它如何应用于项目？

变更管理是关于在项目发生之前批准和传达对项目的变更。如果您项目中的某个人（用户、赞助商、团队成员……任何人）想要添加功能，则需要记录更改并分析其效果。对范围、预算和进度的任何变更都必须在进行变更之前获得批准。这些更改通常由您的发起人、指导委员会或客户批准。

一旦更改被批准并接受，这就是您的新计划。原始预算或时间表是什么并不重要。

项目的变更管理都是关于“没有惊喜”的原则。合适的人（您的变更控制委员会）需要在对范围、进度和预算的任何变更采取行动之前批准这些变更。

One thing to remember is that there may be certain explicit or implicit constraints and tolerances for change. You may be have to deliver your project by a certain date to meet government regulatory requirements. Or your organisation may have a threshold that once a project budget is 30% over the original budget it must go to a "C" level or the project is killed. Investigating and explicitly stating these thresholds and tolerances up front are a good way of having better successful projects.

Where does "change management" end, and "project failure" begin?

If a project delivers on the approved scope, schedule and budget then it is successful.

However it may be still viewed as a failure. Post Implementation Reviews are a good tool to qualify this with your stakeholders (not just your boss). Also Benefit Realisation would be worthwhile looking into to see outside the blackbox of the project and the impact on the business as a whole.