没有业务案例==项目失败

商业案例介于软件项目的明智构想和软件项目的创建之间。

• 拥有一个项目的想法诞生了
• Tcheck –正式或非正式商业案例
• Tstart –项目启动
• 趋向–项目成功完成或被放弃

并非所有软件项目创意都有意义。 在上面的黄色区域中，在构想和启动项目之间，应该对项目构想进行一些尽职调查 。 即使只是非正式地在餐巾纸的背面，也可以在这里进行业务处理。

在业务案例中，您可以暂停并估计该项目是否值得，即与不执行该项目相比 ， 该项目会使您的生活更好 。 对于那些想要精确定义的人，项目应为NPV + ve。 用外行的话来说，该项目应该使组织更好地了解自己的底线，或者至少提高技能水平，以便使其他项目更好。

没有提高技能或底线的项目是失败的。

在10个软件项目中（请参阅了解机会 ）：

• 3个成功
• 4面临挑战，即成本过高，预算超支或功能少得多
• 3将失败，即被放弃

这意味着，任何软件项目的成功基准率只有10分之3。然而，即使项目团队可能知道从第1天开始该项目就会失败，但高管们仍会例行执行不会失败的项目。

商业案例使高管有机会在开始之前停止可疑项目。 （请参阅“ 愚蠢”就是“愚蠢” ）了解业务案例需要多么正式才能归结为不确定性 。 每个项目都有三个主要的不确定因素：

• 需求不确定性
• 技术不确定性
• 技能不确定

当这三个领域中的任何一个领域存在适度的不确定性时，则需要准备一个具有现金流量和风险的正式商业案例。

需求不确定性

需求不确定性是导致范围变化 （范围蠕变）的原因。

项目失败的概率与项目开始时未知需求的数量成正比（请参阅Shift Happens ）。

对于两个特定项目，需求不确定性很低：

1. 重新设计需求不变的项目
2. 软件项目的下一个次要版本。

对于所有其他软件项目，需求不确定性中等，应准备正式的业务案例。

您不熟悉的新项目具有很高的需求不确定性。

技术不确定性

当不清楚是否可以使用所选技术在项目所需的性能水平上实现所有要求时，存在技术不确定性。 只有对需求和实施技术有深刻的了解，技术不确定性才会很低。 不确定性和风险是两种不同的动物（请参阅软件开发中的不确定性特朗普风险 ）

如果对需求或实现技术只有一个中等的了解，那么您将遇到以下问题：

• 在项目后期澄清的要求，实施技术将不支持
• 增强对实现技术的了解后将无法实现的要求

因此，当您第一次执行项目时，技术不确定性很高，而需求不确定性也很高。 当您使用新技术时，即从Java转向.NET或更改GUI技术，技术不确定性很高。

采用新技术的项目具有中等到高度的不确定性。

技能不确定

技能不确定性来自使用不熟悉要求或实施技术的资源。 技能的不确定性是一个知识问题 。

只有当资源了解当前的要求和实施技术时，技能的不确定性才会很低。

当需求没有很好地编写时，不熟悉需求的资源通常会以次优的方式实现需求。 这将涉及返工； 对要求的理解越差，就需要进行更多的返工。

由于不熟悉实现库的原理，不熟悉实现技术的资源会在选择实现方法时出错。 通常，在项目完成之后，资源将了解应该使用不同的实施策略。

正式或非正式的业务案例？

只有在需求，技术和技能不确定性较低的情况下，非正式的业务案例才有可能。 这仅在以下几种情况下发生：

• 更换需求相同且实施技术已被团队充分理解的系统
• 软件系统的下一个次要版本

每个其他项目都需要一个正式的业务案例，该案例将量化项目中存在何种不确定性和不确定性程度。 至少，面对中度到高度不确定性的项目经理应被激励去推动业务案例（请参阅Stupid与Stupid一样 ）。

以下是在没有任何实际商业案例来量化不确定性的情况下可能会被接受的项目列表：

• 实施技术的变更
  • 如果不使用面向对象的技术
• 非软件公司的软件项目
• 使用通才来实施技术解决方案
• 用不熟悉的资源替换系统
  • 外包经常发生

中度到高风险且没有业务案例的项目注定要失败。

相关文章

• 无需经验！
  • 令人惊讶的是，多年的经验与生产力之间没有关联。
• 停下来！ 不，真的停下来！
  • 软件组织通常需要立即停止的5种最差实践

参考： 无业务案例==我们的JCG合作伙伴 Dalip Mahal在Accelerated Development博客上的项目失败 。

翻译自: https://www.javacodegeeks.com/2014/02/no-business-case-project-failure.html