这本书展示了一些重大失控项目的经验与教训，它对这些失控项目进行了分类：
1、没有指定完整的项目目标（51%）
毫无疑问，项目需求是软件项目失控问题中最主要的原因。
需求问题发生在以下情形：
（1）需求过多：大型项目比小型项目更容易失败
（2）需求不稳定：用户无法决定他们真正想要解决的问题
（3）需求模棱两可：不可能确定需求的真实含义
（4）需求不完整：没有足够的信息来创建系统
2、拙劣的计划和评估（48%）
拙劣的评估是多数软件项目的灾难。往往仅仅由于评估过于乐观，而与实际执行的任务不符，项目经常发生进度问题。
"霍夫斯塔特（Hofstadter）定律"：开发软件的时间总比想象的时间要长，即使注意了霍夫斯塔特定律也是如此。
3、采用新技术（45%）
缺少经验的人使用不成熟的技术组合极为危险。
项目使用技术出现问题是由于：
（1）技术无法扩展（所有的新技术都有限制，在主要项目使用新技术之前完全了解新技术的限制很重要）
（2）技术是错误问题的解决方案（仅仅由于技术是新的，并不意味着它适用于你所试图解决的所有问题）
（3）技术不具有要求的功能性（新技术有时候无法解决用户问题的一些方面，有时不仅是现在不能，而且是永远不能）
4、缺乏或根本不具备项目管理方法（42%）
没有一个项目会仅仅由于一个原因而失控，可能存在技术障碍、拙劣的计划、需求发生变化，以及其他很多的原因，但其中最显著的是恶劣的项目管理。
不管怎样，有了合适的管理总可以避免很多技术障碍，能够改进计划或者稳定需求。历史上认为多数软件工程的失败是由拙劣的管理引起的，是很有依据的。
方法可以引入，但管理是负责软件项目所需的所有知识和技巧，它可能永远是一门艺术。没有一种蓝图、秘诀或者方法可以把一个拙劣的管理者变成一个好的管理者。
5、团队中缺少资深人员（42%）
过去几年进行的研究发现，单个软件工作人员的能力差距可以达到5：1到30：1，这个30：1的比例就可以使软件项目成功或者失败。
毫无疑问，缺少完成工作的合适人选，是导致项目失控的重要原因。
6、硬件/软件供应商的低劣表现（42%）
在到处都听到责备之声的地方，却没有多少指责说供应商是引起失败的主要原因。
7、其他——性能（效率）问题
有些开发出的软件就是无法快速地运行及时地满足用户的需求。这种问题称作"性能"问题。这些问题往往出现巨型系统中，巨型往往用来描述大型和复杂的系统，但也可能会牵扯到其他的因素，可以是很多相对简单的系统所访问的大型复杂数据库，或者可以是一个简单系统访问简单的数据库，但是用户数目极大。这些因素中的任何一个，都会导致性能成为问题。但是其中最重要的因素涉及到互动。计算机内部最慢的事就是与外部存储进行通信，例如数据集。当它们与人进行通信时就更慢了。当"巨型"牵扯到这些因素时，性能就很可能成为问题。
出现性能问题，往往说明其中许多人是被没有准备的时间关键问题所绊倒。
人在江湖：成功的项目都是一样的，不成功的项目各有各的原因。
书中也展示了一些软件失控项目的补救措施：
第一是风险管理
在计算机领域中越来越强烈地相信，驾驭项目失控最好的方法是从开始就管理项目的风险。
风险管理就是预测在项目中可能出现的最严重的问题（伤害和损失），以及采取必要的措施来处理。
第二是问题管理
风险是在项目开始工作之前预测到的问题，而这里的问题是指项目的过程中提出的问题。如果所有的问题可以提前辨明，就可以将其称之为风险。
但是，由于软件创建的复杂性，在项目进行过程中总要提出许多（意外的）问题。
第三是失控项目的补救措施
如下展示了一份调查结果：
（1）扩展进度表：85%
（2）更好的项目管理程序：54%
（3）更多的人：53%
（4）更多的资金：43%
（5）通过停止支付来给供应商施加压力：38%
（6）减小项目覆盖面：28%
（7）新的外来帮助：27%
（8）更好的开发方法：25%
（9）以提出诉讼威胁给供应商施加压力：20%
（10）改变项目中使用的技术：13%
（11）放弃项目：9%
（12）其他：9%
上面这些措施都只是权宜之计，不同的公司不同的项目应酌情处理，但这不是长久之计。
第四是为将来预留的补救措施
在项目紧张进行时，失控项目的补救措施会受到限制。任何补救措施都必须符合项目过程的框架。但是一旦项目结束，我们就应该把从失控项目中学到的教训整理出来，以备在以后的实践中使用。
不幸的是，软件领域的失败之一，就是很少学习那些教训。只有很少的例外，估计5根指头就能数得过来。
下面是从经历过失控项目的那些公司中学到的、关于未来计划的知识，这些有问题的公司提出了以下长期解决方案：
（1）改进项目管理：86%
（2）可行性研究：84%
（3）更多的用户参与：68%
（4）更多的外部建议：56%
（5）与以上无关：4%
人在江湖：我们不怕失败，怕的是重复失败。
你可以使用这个链接引用该篇文章 http://publishblog.blogchina.com/blog/tb.b?diaryID=675262