写点什么

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

  • 2007 年 9 月 20 日
  • 本文字数:1573 字

    阅读完需:约 5 分钟

有关项目失败率的 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 年开始,我们看到项目失败率稳定下降。仅从这点,我们就能学到很多东西,特别是必须努力让我们的思想进步,学会选择最优的软件开发方法。

查看英文原文: Standish: Why were Project Failures Up and Cost Overruns Down in 1998?

2007 年 9 月 20 日 01:572463
用户头像

发布了 26 篇内容, 共 70046 次阅读, 收获喜欢 2 次。

关注

评论

发布
暂无评论
发现更多内容

第一章学习笔记

博博

架构师 01 期,第五周课后作业

子文

架构师训练营第 1 期 -- 第五周作业

发酵的死神

极客大学架构师训练营

架构师训练营week1-食堂就餐卡系统设计

花果山

技术选型(一)

wing

极客大学架构师训练营

架构师训练营 - 第 5 周学习总结(1 期)

阿甘

第五周 作业第二题

sean

第一周作业

tothegump

极客大学架构师训练营

极客时间架构 1 期:第 5 周 技术选型(一) - 命题作业

Null

第一周

宇文青

训练营第五周作业 2

仲夏

极客大学架构师训练营

Week 1 :架构的方法(学习总结)

shuyaxx

架构师训练营 1 期 -- 第五周笔记

曾彪彪

极客大学架构师训练营

架构师训练营 - 第 5 周课后作业(1 期)

阿甘

第一周学习总结

晴空万里

极客大学架构师训练营

食堂就餐卡设计

博博

Week 1 :架构的方法(作业一)

shuyaxx

架构师训练营第五周作业

月殇

极客大学架构师训练营

架构师训练营 1 期 - 第五周总结(vaik)

行之

极客大学架构师训练营

架构师训练营week05作业(hash算法)

FG佳

架构师一期

Week 5 总结

黄立

总结

架构设计-UML案例

极客时间架构 1 期:第5周 技术选型(一) - 学习总结

Null

分布式架构技术选型总结(一)

天天向上

极客大学架构师训练营

架构师训练营week05总结

FG佳

架构师一期

极客时间-架构训练营 第一周总结-做架构的姿势

架构师训练营 Week5 技术选型 - 缓存/消息队列/负载均衡

负载均衡 缓存 消息中间件

训练营第五周作业 1

仲夏

极客大学架构师训练营

架构师训练营第 2 期 第一周作业1

月下独酌

极客大学架构师训练营

第五周 作业一 第一题

sean

第一周学习总结

tothegump

极客大学架构师训练营

如何让项目失败和成本超支率大幅下降-InfoQ