|
1.1 死亡之旅的定义项目管理者联盟
非常简单，死亡之旅项目就是“项目参数”超标50%以上的项目。对绝大多数项目而言，这意味着下列限制条件的一个或多个被强加于项目之上：项目管理者联盟
与用合理估算方法得出的数值相比，进度被压缩了一半以上;因此，对于一个在正常情况下可望用12个月时间完成的项目，现在要求只用6个月或更短。由于当前全球市场上的商业竞争压力日益增加，这种形式的死亡之旅项目最为常见。项目管理者联盟
与正常情况下这种规模项目所需人员的数目相比，员工数被压缩了一半以上;因此，对于需要10个人的项目，项目经理只能得到5个人。这种情况的出现，很可能是因为某些人过于天真：他们相信某种新的编程语言或应用程序开发环境能够将团队的生产率魔术般地提高两倍，尽管团队从未接受过相应培训，而且从未就使用这种技术与他们进行过磋商。但不幸的是，由于持续的经济衰退及其引起的IT预算缩减，在2003年春天我撰写这个版本的《死亡之旅》时，这种现象的出现正在日益普遍。
预算及相关资源被削减了一半以上。与上面相同，这也经常源自于精简裁员以及其他削减支出的行为，但它也很可能是对固定总价合同进行竞标的结果——这种情况下，市场部门常常会这样通知项目经理：“好消息是我们赢得了合同;但坏消息是为了打败竞争对手，我们必须削减你一半的项目预算。”这类限制通常会对你能雇佣的人员数目产生立竿见影的影响，但有时，这种影响表面上看不明显，例如放弃雇佣价格昂贵但却经验丰富的人员而雇佣相对廉价、但却欠缺经验的新手。不止如此，它还会营造出一种压倒性的节俭氛围，在这种环境里，即使项目团队要花费整个周末在办公室加班，项目经理也很难花钱为团队买一只比萨饼。项目管理者联盟
与正常情况相比，项目被要求给出两倍的功能、特性、性能或其他技术要求。例如，项目团队很可能被要求在固定大小的内存或磁盘空间内压缩进至少两倍于竞争对手的功能特性;或者被要求系统的事务处理速度必须比所有其他系统高两倍以上。尽管性能限制条件不一定会导致死亡之旅项目，但我们总是可以利用更加便宜和快速的硬件，而且可以寻找更精巧的算法和设计方法来达到更高的性能。但是，将功能(例如可用特性)加倍通常意味着必须完成两倍的工作量;而这肯定会导致一个死亡之旅项目的产生。项目管理者联盟
在很多组织中，以上这些限制条件所产生的直接影响通常是：与正常项目相比，项目团队要么每周付出两倍的工作时间，要么付出加倍的努力。因此，如果正常情况是一周工作40小时，死亡之旅项目往往要求每天工作13到14小时，而且每周工作至少6天。由于在这种环境下紧张和压力会自然而然地升级，死亡之旅团队看起来就像是一直在使用兴奋剂一样。项目管理者联盟
描述此类项目的另一种方法如下：blog.mypm.net
如果公正客观的风险评估(应包括对技术、个人、合法性、政治等各方面的风险评估)所得出的结果是项目失败概率大于50%，那么这就是一个死亡之旅项目。项目管理者联盟
当然，即使没有以上这些关于进度、人员、预算和功能方面的限制，项目也有很大的可能性以失败告终。例如，在IT部门与用户之间充满敌意。但更常见的情况往往是：高风险的评估结果往往是上述限制条件综合作用的结果。项目管理者联盟
1.2 死亡之旅项目的分类项目管理者联盟
死亡之旅项目多种多样，各有特点。它们不仅包括进度、人员、预算和功能限制条件的不同组合，而且还具有不同的规模、范围和特色。training.mypm.net
根据我的经验，规模是区分死亡之旅项目的最重要因素。考虑以下4种不同规模的项目：项目管理者联盟
小规模项目——团队包含3到6人，目标是努力在3到6个月内完成不可能完成的任务。项目管理培训
中等规模项目——团队由20到30人组成，涉及的项目预计历时1到2年。club.mypm.net
大规模项目——团队由100到300人组成，预计项目历时大约3到5年。项目管理者联盟
难以置信的超大规模项目——团队由1 000到2 000人组成，有时人数甚至会更多(在很多情况下，将包括项目顾问和分包商)，项目预计历时7到10年。PgMp.mypm.net
由于多种原因，在我所访问过的组织中，小规模死亡之旅项目最为常见;但幸运的是，这类项目成功的概率也最大。因为由3到6人所组成的团队更有可能紧密团结在一起，如果他们再知道充满高强度工作的漫漫长夜、损失的周末以及被推迟的假期在几个月后都会得到补偿，那么这种被高度激励的团队更有可能自愿为项目牺牲3到6个月的个人生活(而且还有他们的健康!)。项目管理者联盟
相比而言，中等规模死亡之旅项目的成功率明显下降，而大规模死亡之旅项目的成功率几乎为零。随着所涉及人员数量的增多，不但凝聚的团队精神更加难于维持，而且人员流失、出现意外以及发生各种现代社会危险的几率也在迅速地增加。在这种情况下，至关重要的因素不仅包含所涉及人员的数目，而且还包括持续时间的长短：在6个月中每周工作80个小时也许还可以忍受，但如果这种情况持续2年很可能就将导致严重的问题。club.mypm.net
至于超大规模的死亡之旅项目，人们甚至很奇怪它们为何会存在。也许与1969年NASA登月项目相关的系统开发项目可以被看做是这类死亡之旅项目的一个成功范例，但绝大多数此种类型的项目一开始就注定将会以失败而告终。值得庆幸的是，绝大多数高级管理层都认识到了这一点，而且几乎所有的大型组织(一开始也只有它们才可能做得起这种项目)都严格防止启动这类项目。但是，唉，政府组织仍然会时不时启动这种项目;除了为处理这种“超级”项目而基本毫无限制的预算，对爱国想法(例如，后9·11时代的国家安全)的狂热足以蒙蔽高级管理层的双眼，使他们没有认识到注定失败的结果。项目管理者联盟
除了项目的规模，使用类似“涉及组织的数量”这样的标准来表示死亡之旅项目的等级也很有帮助。即便是只需要使单个用户或一组来自同一部门的同类用户感到满意，项目团队的工作就已经十分困难。而企业范围项目的难度往往要增加几个量级，原因很简单：任何跨职能的活动都包含着政治和沟通问题。因此，与商务重组项目相关的系统开发项目往往会堕落成为一场死亡之旅。在这种情况下，即使开发中所使用的硬件和软件都十分先进，但政治斗争也很可能会导致组织瘫痪，让项目团队受到无穷无尽的挫折。项目管理者联盟
最后，我们可以找到极其困难的项目与那些根本不可能的项目之间的差异。《Crunch Mode》一书的作者John Boddie指出：项目管理者联盟
具有优秀的技术人员、卓越的管理人员、突出的设计人员和聪明、忠诚的客户并不足以保证处于危急关头的项目得以成功。的确存在根本不可能实现的项目，而且这种项目每天都在启动。绝大多数这种类型的项目都可以在开发周期中被识别出来。这种项目看起来有两大类型：“理解欠佳的系统”和“异常复杂的系统”。项目管理者联盟
到此为止，我们仍旧没有回答为何理智的组织会启动这样的项目以及为何理智的项目经理和技术人员会同意参与其中。我们将在下面的章节中讨论这些问题。项目管理者联盟
1.3 为何会出现死亡之旅项目项目管理者联盟
|
