以总是时间紧迫，不合情理。
有意思的是，“两难境地”的提出是在1987年，“死亡行军”的提出是在1997年，两者相隔10年；而我们再反观又过了10年后的今天，2008年，20年过去了，可似乎我们身处的软件行业、软件项目管理并没有出现太明显的改善。虽然真正“失控”的项目只是极少数，而且也并不是所有的死亡行军项目都会失败，但我们可以发现自己要么处于“两难境地”，要么正在“死亡行军”，总是难以逃脱。
托尔斯泰说过，“幸福的家庭都相似,不幸的家庭各有各的不幸”，但IT项目刚好相反——成功的项目可能各有各的原因，但“失控”的项目，却总是有些相似的问题。
在本书中，作者引用了KPMG在1989年和1995年进行的两次调查的报告，而两份调查报告的核心，是对英国250家软件企业的“失控”项目进行的统计、分析和“失控根源”分类。根据KPMG的报告，这些项目最终“失控”的原因，归咎于没有指定完整的项目目标（特别是需求）、拙劣的计划和评估、采用新技术、缺乏或根本不具备项目管理方法、团队中缺少资深人士、硬件/软件供应商的低劣表现；而本书的作者在最后又附加了一条“系统无法满足性能和可靠性要求”。下面就对这7大根源先做一个整理。
1. 没有指定完整的项目目标
在KPMG的报告中，有51%的项目失控被认为与“没有指定完整的项目目标”，而核心又是我们在IT项目中最常见的一个问题——需求。作者也列出了几个常见的需求问题，包括：
1）需求过多，系统过于庞大：似乎注定了越庞大的项目需求就越复杂，也越容易失败；
2）需求不稳定，用户无法决定他们真正想要解决的问题；
3）需求模棱两可
4）需求不完整
作者在书中也用占整本书1/3的篇幅讲述了2个很典型的案例，来说明需求突然发生重大变更和项目目标定位过高导致的“失控”案例。可如何做好需求管理，控制好需求变更，这在今天仍然是一个难题。
2. 拙劣的计划和评估
在这一节里，作者提到的关键，是对项目的难度和工作量评估不准确，导致项目的进度永远达不到schedule的要求，并且被无限期的拖延下去。这的确是我们在IT项目中遇到的第二个难题，似乎所有的项目的完成时间都要比预定计划推后一些，虽然不能说一定是计划和评估做的差导致的——因为项目经理还要承担着监控和控制项目进度的职责——但在我们身边的很多项目中，的确存在对项目难度和工作量估计不足，或缺少科学的度量方法的问题；而这又最终导致我们在项目的初期就已经处于“两难境地”，并逐渐进入“死亡行军”的状态。
3. 采用新技术
新的技术、框架、平台、方法论、解决方案、术语缩写的推出，相对于10年前（本书第一次出版的时候）越来越频繁，而且貌似这些新东西更新换代的速度越来越快，生命周期越来越短。曾经有做开发的朋友说自己很羡慕那些做C或者C++的人，因为可以“沉下去”，不受外界这些“新东西”的干扰，积累下真正的技术和经验；相对来说，软件测试也占有类似的优势，毕竟我们现在所使用的方法和技术，大多也都是20年前或者10年前发明并流传下来的——当然，那些沉迷于自动化框架开发或者尝试各种新工具的人会不同意我的看法。
新技术的采用，有时的确可以极大的提高生产率，并解决一些棘手的问题，帮助项目最终成功。但是技术的选型就成了最大的问题，因为新东西推出的太快，而我们的IT行业中真正的技术专家、资深人士又总是少数，大多数ITer或者说开发人员，要么只有2-3年的开发经验，对核心技术和行业应用的把握能力有限；要么迫于项目
项目经理胜任力免费测评PMQ上线啦！快来测测你排多少名吧~
http://www.leadge.com/pmqhd/index.html
