1.1死亡之旅的定义
非常简单，死亡之旅项目就是“项目参数”超标50%以上的项目。对绝大多数项目而言，这意味着下列限制条件的一个或多个被强加于项目之上：
·与用合理估算方法得出的数值相比，进度被压缩了一半以上；；因此，对于一个在正常情况下可望用12个月时间完成的项目，现在要求只用6个月或更短。由于当前全球市场上的商业竞争压力日益增加，这种形式的死亡之旅项目最为常见。
·与正常情况下这种规模项目所需人员的数目相比，员工数被压缩了一半以上；因此，对于需要10个人的项目，项目经理只能得到5个人。这种情况的出现，很可能是因为某些人过于天真：他们相信某种新的编程语言或应用程序开发环境能够将团队的生产率魔术般地提高两倍，尽管团队从未接受过相应培训，而且从未就使用这种技术与他们进行过磋商。但不幸的是，由于持续的经济衰退及其引起的IT预算缩减，在2003年春天我撰写这个版本的《死亡之旅》时，这种现象的出现正在日益普遍。
·预算及相关资源被削减了一半以上；。与上面相同，这也经常源自于精简裁员以及其他削减支出的行为，但它也很可能是对固定总价合同进行竞标的结果——这种情况下，市场部门常常会这样通知项目经理：“好消息是我们赢得了合同；但坏消息是为了打败竞争对手，我们必须削减你一半的项目预算。”这类限制通常会对你能雇佣的人员数目产生立竿见影的影响，但有时，这种影响表面上看不明显，例如放弃雇佣价格昂贵但却经验丰富的人员而雇佣相对廉价、但却欠缺经验的新手。不止如此，它还会营造出一种压倒性的节俭氛围，在这种环境里，即使项目团队要花费整个周末在办公室加班，项目经理也很难花钱为团队买一只比萨饼。
·与正常情况相比，项目被要求给出两倍的功能、特性、性能或其他技术要求；。例如，项目团队很可能被要求在固定大小的内存或磁盘空间内压缩进至少两倍于竞争对手的功能特性；或者被要求系统的事务处理速度必须比所有其他系统高两倍以上。尽管性能限制条件不一定会导致死亡之旅项目，但我们总是可以利用更加便宜和快速的硬件，而且可以寻找更精巧的算法和设计方法来达到更高的性能。但是，将功能（例如可用特性）加倍通常意味着必须完成两倍的工作量；而这肯定会导致一个死亡之旅项目的产生。
在很多组织中，以上这些限制条件所产生的直接影响通常是：与正常项目相比，项目团队要么每周付出两倍的工作时间，要么付出加倍的努力。因此，如果正常情况是一周工作40小时，死亡之旅项目往往要求每天工作13到14小时，而且每周工作至少6天。由于在这种环境下紧张和压力会自然而然地升级，死亡之旅团队看起来就像是一直在使用兴奋剂一样。
描述此类项目的另一种方法如下：
如果公正客观的风险评估（应包括对技术、个人、合法性、政治等各方面的风险评估）所得出的结果是项目失败概率大于50%，那么这就是一个死亡之旅项目。
当然，即使没有以上这些关于进度、人员、预算和功能方面的限制，项目也有很大的可能性以失败告终。例如，在IT部门与用户之间充满敌意。但更常见的情况往往是：高风险的评估结果往往是上述限制条件综合作用的结果。
1.2 死亡之旅项目的分类
死亡之旅项目多种多样，各有特点。它们不仅包括进度、人员、预算和功能限制条件的不同组合，而且还具有不同的规模、范围和特色。
根据我的经验，规模是区分死亡之旅项目的最重要因素。考虑以下4种不同规模的项目：
·小规模项目——团队包含3到6人，目标是努力在3到6个月内完成不可能完成的任务。
·中等规模项目——团队由20到30人组成，涉及的项目预计历时1到2年。
·大规模项目——团队由100到300
项目经理胜任力免费测评PMQ上线啦！快来测测你排多少名吧~
http://www.leadge.com/pmqhd/index.html
