项目预算超支有哪些原因，如何让项目成本超支率下降

（一）六大原因，导致项目预算超支的

00 引言
大部分项目很少都能够在设定的预算范围内完成，尽管说正确的规划是项目成功的关键，但通常也有超出规划的一些问题，其中之一就是预算超支。的确，通过正确的规划能够避免一些问题，但你永远无法预测，一旦你开始一个项目，最终会发生什么。
下面是通过一些项目的经验来得出的导致预算超支的原因，了解这些原因可以帮助你避免预算超支的风险：

01 资金不足
导致预算超支的一个主要原因是资金不足，一个项目在刚开始如果预算分配不足，就会明显的导致成本超支，如果你想要一个项目取得成功，没有足够的预算那简直就是痴心妄想。
如何避免：对于出现项目预算超支的情况，要提前给项目赞助商进行解释，建议可以通过追加预算或减少项目交付范围来进行处理。

02 不可行的成本估算
项目管理中一个重要的工作就是做成本估计，而大多数项目中出现预算超支的一个共同原因就是对于成本估计不足。如果一个项目成本的估算是凭感觉或者是通过不合格人员的经验得出来的，那么这个项目该项目被意外地将要面对的预算超支，如果在项目的早期阶段还可以进行调整，但实际上往往都发生在很难调整的后期。
如何避免：寻求专家的工作人员和题材的专业人士的帮助，而制作项目的成本估算。分解工作为较小的部分，然后进行估计。您可以通过使用成本估算技术，如参数化建模，3点估算，储备分析，自下而上的分析，仿真等进行综合测算。

03 低估了项目的复杂性
越大的项目预算超支的风险越高，因为这种类型的项目，在执行的过程中交互产生的复杂程度会大大影响项目的预算，项目复杂程度越大，其产生的很多有形的、无形的成本就会不断增加，而这类成本往往在项目的规划阶段很难被考虑到的。
如何避免：将项目进行逐层分解，可以分解成若干个小的项目，在项目的一开始就应该预留出充分的变化空间和足够延迟的计划来避免预算超支这种情况的出现。

04 延长项目进度
如果该项目是按照计划来进行的，这并不一定意味着该项目预算也能够被满足。另一方面，如果项目进度被延长，那毫无疑问的项目需要投入更多的时间和金钱，而项目延期也意味着项目人员或项目资源也需要更多的时间。
如何避免：一个项目的关键阶段就是规划阶段，在最初分配给项目的时间和成本时，任何偏差都会大大影响到后面的所有阶段。如果你被要求延长项目的杀害，你需要和你的赞助商进行澄清，这可能会超过原计划的预算，因为更多的时间就意味着需要更多的资源。

05 缺乏备份计划
如果你没有为可能出现的所有问题制定一个备份的计划，那么往往一个小小的延迟，都有可能导致你项目的预算超支。如果不能为所有的问题制定备案，那么对于可能出现的重大问题，制定应急预案是必不可少的，否则，往往就不仅仅是预算超支，甚至可能是导致项目失败。
如何避免：凡事总有万一，对任何问题都要有一定的应急措施。在项目制定预算的初期，应该估算出项目备份计划中可能需要的成本，这样当项目进度或范围发生了一些意想不到的变化时，项目的预算计划有应变的空间。

06 缺乏资源规划
就算是预算充足，如果项目经理不能有效的按照计划提供资源，也会导致预算超支。很多时候，项目经理错误的估计了资源的使用情况，如专家资源没有按照进度被有效的使用，或者错误的估计了问题的严重性，人员的不合理安排等等。
如何避免：这可以通过适当的规划计划的范围、估计的成本和时间来避免，然后相应地将预算按需分配到所有部门。提前规划一切的前提是，你需要了解所有的的资源和设备，避免出现错误放置的情况出现。


（二）项目管理不好，容易出现预算超支问题


项目管理不好，容易出现预算超支问题。预算超支的原因可能是项目范围管理不好有关。另外，有时候客户需求变更管理的好坏，也会影响到项目预算。下面是一些项目管理不好，容易出现超支问题的一些情况类型总结。

有的项目严重超支，是由于没有进行良好的项目变更管理造成的;而有一些项目严重超支，是由于在开始的时候就没有明确的项目范围说明书和进度计划从而使管理失去了基准而形同虚设。以上两种情况，都会造成项目范围的无限制增加或改变、项目进度的无限制拖延，从而导致项目资源、人员的过量投入。

有时候项目管理的不错，但是根据公司相关规定还是会归为预算超支，例如：某个项目经理同意客户需求，根据变更控制管理规定，客户根据相关的变更而支付了相关的费用。项目也顺利完成了。问题出在：当这部分费用收到的时候，公司管理层并没有把此费用追加给项目组。因此，项目组被认为项目严重超支。

针对上述例子中遇到项目超支问题。某网友的看法：如果你选择做某个公司的员工，就一定要支持公司的总体目标并支持公司管理层的战略措施。在此事的处理上，首先要把自己的想法坦诚地和公司相关管理层进行沟通，让他们明了你的看法。如果我们不去沟通，我们就不能主观断定别人肯定明白我们的想法。之后，也把我们对管理层做法的不解说出来，希望管理层能告诉我们他们这样做的初衷。在沟通之后，我相信管理层通常会认可我们的工作，而不会把一个本来不亏损的项目算为亏损的项目。但是，如果管理层确实由于整体战略需要这么做，需要我们作出一些贡献的话，我自己认为我们应该在理解的基础上服从。


（三）如何让项目失败和成本超支率大幅下降

有关项目失败率的 CHAOS 统计数据，经常被敏捷或其他过程改造方法的推崇者引用。因此，这些数据的真实性就非常重要。今年 8 月，《ACM 通讯》（Communications of the ACM，CACM）发表了Robert Glass 的一篇文章，影响很大。于是，InfoQ 采访了项目失败系列研究报告“CHAOS Chronicles”的创立人 Jim Johnson，咱们来听他说说是如何整理出这些数据的。

在采访后的一系列讨论中，有个关键问题仍然没弄明白：对于成本超支率从 1994 年的 189% 剧降至 1998 年的 69%，Standish Group 是如何解释的？互联网的其他很多地方对这个问题也有提及。Robert Glass 文章认为，可能是因为 Standish 在这几年改变了研究方法，只不过没有在报告中说明。如果真是这样的话，那么比较 1994 到 1998 年的 CHAOS 数据的就毫无意义了。

Standish 创始人 Jim Johnson 对 1994 到 1996 年间的研究结果差异也非常重视，甚至 1996 年的数据从未单独公开。在本文中，他将和大家一起分析 CHAOS 数据背后隐藏的 90 年代中期软件开发领域的重大变化。

文章引自 CHAOS 大学简报 2006 年 11 月刊，作者为Standish Group创始人兼现任负责人 Jim Johnson。

近来，不少人希望我能解释项目成本超支率从 1994 年的 189% 剧降至 1998 年 69% 的原因。其实，我们已经在很多场合很多会议上做过说明，比如我最近的文章《CHAOS Chronicles 3.0》和著作《My Life is Failure》。今天再和大家讨论一下，当然，不会有什么新东西。 

如果说这种进步是我们的研究报告促使大家努力改进工作而取得的，显然是夸大其词、过于自恋了，我们不会贪天之功。不过，报告首发以后，我们的确发现在我们关注的很多团队和组织中，用户参与度提高、管理层支持加强、大家对业务目标的认识更为清楚，很多公司开始重视其项目经理的 PMI 认证。所有这些，显然都产生了积极作用，但我们觉得这或许可以让 1994 年的 189% 下降到 1996 年的 142%，而说成是上面问题的主要原因，仍然站不住脚。

在本月的调查问卷中，我们要求SURF参与者反映他们对项目时间和成本的评估水平。有不到 10% 的人认为他们水平已经很高，而几乎三分之二的人仍然认为他们还在起步至中等层次。 

项目时间和成本评估能力的高低，对项目的时间和成本超支率有直接影响。1998 年春季，我们曾就是否已经改进项目评估问题对很多团队做过调查。结果显示，绝大多数人认为自己到那时为止仍然习惯于先大致评估，然后在考虑不可控因素基础上增加一个误差范围的传统方法。从 1998 年开始，大多数团队开始修正原来的老办法，以期实现最优评估，这和我们在上图中看到的 1994 到 1998 年发展趋势是吻合的。然而我们认为，这仍然不是超支率从 189% 猛降到 69% 的主要原因。因此，在你阅读下面段落之前，我希望你能回忆 1994 到 1998 年发生过的事情。闭上你的眼睛，遥想在那几年里，我们的 IT 产业和计算机应用领域究竟发生了什么样的巨大变化。

现在睁开眼睛，你想到了什么？我先提供一个线索！我们 1996 年的报告显示约有 40% 的项目失败了。这年的情况是如此混乱，以致于我们没有提供正式的 1996 年版 CHAOS 报告。不过，如果找到包含所有年份的 CHAOS 报告，你将会看到如下结果： 

是什么原因导致 1996 年如此之高的失败率？答案是互联网。我们从传统的 C/S 转变到互联网开发模式。C/S 应用的开发和实施比互联网应用复杂得多，总是莫名其妙出现很多问题，你永远不知道用户的 PC 上会出现什么样的软件冲突。于是，所有组织迫不及待地将 C/S 模式像垃圾一样丢掉。互联网应用使项目变得更小、更简单、实施更快、更容易管理。而其中基于浏览器的无客户端模式则是主力军。于是，从 1998 年开始，我们看到项目失败率稳定下降。仅从这点，我们就能学到很多东西，特别是必须努力让我们的思想进步，学会选择最优的软件开发方法。