根据Standish商业研究公司的一份报告，将近三分之一的信息系统项目在最终完成之前都被取消了。另外，在所有的项目中几乎有一半左右会超出其预算。

　　令人惊讶的是，项目失败的原因很少同技术有关。大多数项目管理咨询项目都是因为技术以外的其他原因而招致失败的。可是，既然不是技术原因造成的项目失败，那么又该是什么原因令这些项目失败的呢？答案是项目所牵扯的人和工作过程。具有讽刺意味的是，普通开发人员在处理技术问题的时候应对有道但他们在同其他人以及工作流程打交道的时候却不是这样。

　　问题 # 1 ：缺乏有意义的商务案例

　　真的叫人很吃惊，有些项目从一开始就找不出有意义的商务案例来支持它们。商务案例很重要，因为它为项目提供了基础。商务案例应该能提出效益分析，同时还能考虑到商业风险和项目之外事件的影响。机构会采用商务案例把它们有限的资源划分出优先级别从而为其提供最大回报。这样说来，在没有商务案例的情况之下，一个项目该如何起步呢？这也是可能的，因为项目的商业属主也许仅仅是需要实现什么特定的目标，而且有能力达到自己需要实现的目标。另外还有一种可能性，那就是IT机构认为商业单位需要它因此它们自己先创建出来再说。

　　最近两年，因为许多人相信他们必须开发某些思摩特咨询项目来维持竞争力，所以好多同Web关联的项目在不存在商务案例的情况下就纷纷上马了。那争先恐后的样子就好象不奋力一搏就赶不上趟似的，“.com”的崩溃意味着商务实践回归原来的基础，这其中自然也包括商务案例。

　　对策：探询你目前着手的项目是否受到了商务案例的支持。找一份商务案例来仔细阅读它。你所在项目的商业动力是什么？这一商务案例符合逻辑而且可理解吗？该商务案例存在怎样的前天条件？其风险是什么？什么外部因素会影响商务案例？如果你无法为自己的项目找到可理解、有意义的商务案例，那么你得知道为什么没有开发出有关的商务案例。

　　问题 #2 ：没有获得同意的需求或系统规范

　　缺乏需求确实是一件非常危险的事情。在Standish的报告里，挑战项目正常运行的三个最常见因素都和系统需求有关。系统需求能给出将要创建的系统的大小和结构。它们定义了系统应该和不应该实现的任务。

　　需求管理就是在整个项目周期之内定义、记录、追踪以及管理需求的过程。需求管理保证了最终的解决方案能够满足用户的需要。

　　对策：密切注意你的需求管理过程。如果看起来没人负责管理系统的需求，或系统的需求老是在变，那么你可能会遇到麻烦了。

　　问题 #3 ：缺乏项目计划

　　有些项目竟然会在没有项目计划的情况下运做。这简直就是不用图纸造房子。每个项目都是一个事业，都应当具备相应的项目计划。项目计划对那些项目决策人来说是非常必要的交流手段，项目计划为南京PMP项目的进展以及确定需要进一步完成的其他工作提供了指导。有一种说法称不需要告诉有关开发人员具体的计划内容；他们只需要知道做什么就可以。这种看法对只有一个人的项目队伍来说管用，但要做大事就站不住脚了。开发人员确实需要接受计划的指导。他们想要知道什么任务排在前面。他们不想猜测哪些东西是最重要的。

　　仅仅有了一个计划还是不够的：计划必须跟随项目的发展保持最新状态。举个例子吧，有些项目刚开始的时候房间里贴满了五花八门的甘特图和波特图，结果几个月乃至数年过去了这些图表还是老样子放在那里，没有任何变化。这可不是一个当前计划。为了让计划与时俱进，项目计划就必须反映实际完成的工作，同时还要预计将要完成的工作。计划更新的频率倒不至于达到每周一次的程度，但也不能低于每两周一次。计划应该准确地反映完成项目的时间和开销。只有在这样的情况下才可以说计划保持在最新的状态。过于频繁变更的计划同过期的计划一样令人恐惧。我曾经见过这样的项目计划，该项目计划每周都要修改，结果把项目的阶段终止日期超出了一周的范围。计划每周都在更新，但项目工程仍然失去了控制。

　　对策：如果没有公开的项目管理咨询项目计划你无论如何得赶快弄出一个来。如果你被告知，因为信息的机密性你不能查阅项目计划，那么，你不妨把这一事件看做一个严重的警示迹象。除非你在开发新一代的原子弹，否则秘密项目计划根本没有存在的道理。保持信息的隐秘通常意味着管理层知道项目出了问题，他们正试着把问题掩盖起来。一定要保证计划常新而且还得具有合理的更新间隔。它不该是个不断变动的目标，但它一定得是最新的。如果你不能保证项目计划的最新状态，那么项目会出问题的。

　　项目快完蛋了，我该怎么办？

　　你发现自己的项目已经出现了以上一个或者多个预警信号吗？对这个问题的回答取决于你的个人状况。如果你感到你能采取行动改变现状，那么你一定要立即行动。同项目经理、顾客或你队伍中的其他成员对话。用一种就事论事、不具威胁性的方式讨论你所关心的问题。试着尽可能提出正面意见。看看你能否给项目带来转机。如果项目濒于失败而且你发现自己没有办法控制事态的发展，那么你最好想办法离开现在的项目。你也许能在同一家机构内找到一个好一些的项目，要不你干脆离开现在的单位算了。反正走为上策。到这份儿上已经不是告诉某人该如何运做项目的时候了。

　　如果你粘在项目上了，或者正等着走人，那你也不妨换个看问题的角度。就当你在长经验吧。比方说，你能从现状中获得什么？如果得到授权你将采取什么行动改变现状？将来你该如何避免撞上这样的项目？从当前南京PMP项目进展中学到的知识和掌握的经验必定能在你着手的将来项目上给你带来莫大的帮助。 仅仅是个开始

　　以上的3个问题主要牵扯到业务和计划方面，但是，项目遇险的迹象还并不止于这些。接下来，我们将继续讨论在失败的项目中涉及到用户和项目主管人员的4个因素，讨论下这些因素是如何给你提出项目遇险警告的。