IT项目失败时，管理人员通常是最后一个知情的。就像一条鱼在冰箱里搁了太久那样，异味终究会暴露的。要是到了这种地步，惟一的办法就是把鱼从冰箱里取出来，再用小苏打除去异味。

　　如今，项目管理在日益改进，成功的项目更多了，完全失败的项目更少了，而且项目带来的投资回报更大了。不过，完全成功的项目大概只占1/3。

　　项目不是注定失败的

　　评估IT项目最常用的指标就是The Standish Group International的问题报告(Chaos Report)。这项报告每两年发布一次，它基于对几千家大中型公司开展的全球性调查。

　　最初的那项调查结果让人震惊。研究人员在1994年发现: 31%的IT项目完全失败，也就是说，这些项目还未完成就被抛弃，毫无成效; 只有大约16%的项目才完全成功——按时、按预算交付应用软件，而且提供了最初规定的所有特性和功能。

　　Standish Group主席Jim Johnson说: “到2006年，项目完全失败的比例降到了19%; 成功率上升到了35%。”剩下的46%是Standish Group认为的“有缺陷的项目”: 这些项目并不符合完全成功的标准，但交付了有用的产品。

　　Jim Johnson说: “情况之所以好转是因为，项目管理方面的整套体系变得更像是一门职业: 我们更清楚项目管理方法; 表述能力更强的用户能够更准确地描述需求; 我们还有一些非常好的工具可以帮助用户，如统一建模语言(UML)。”

　　AtTask是生产项目管理工具的公司，该公司CIO Scott Johnson说，“互联网也起到了作用，可以迅速进行沟通，没必要等召开状况报告会议时才发现问题，也不存在中间沟通环节的延迟。”

　　Scott Johnson认为，与几年前相比，新的项目管理工具更容易使用。而且，它们还包括了像复杂的趋势分析这些功能，从而能够及早发现有问题的项目。

　　Jim与Scott都坚定不移地拥护敏捷项目管理，这种管理方式侧重于把项目分成多个小部分，然后迅速交付部分成果，以便用户反馈。

　　寻找失败的无形迹象

　　Chaos Report显示，近1/5的IT项目还是完全失败的，2/5以上的项目局部失败。更加让人担忧的是: 项目规模越大，问题越严重。Jim Johnson说: “人力成本不到75万美元的项目中，有73%是成功的; 但人力成本超过1000万美元的项目中只有3%是成功的。我敢说，这3%的项目之所以会成功，是因为过高估计了预算，而不是因为管理有方。”

　　导致IT项目失败的常见原因包括: 缺少管理人员的支持和目标不明确。而失败的警告迹象要具体得多，与项目的日常运作有密切关系。

　　最重要的早期警告迹象都是无形的，Jim Johnson说，其中最重要的两个迹象就是对项目没有兴趣以及沟通不畅。

　　1.没有兴趣

　　对项目没有兴趣往往是由于得不到管理人员的认可，实施者可能迫于压力或者劝说之后批准项目，其实并非真正同意。其他迹象包括不参加会议、不关注或者根本不发表任何意见。

　　“要确保每个人真正同意项目要完成的任务; 确保即使日程表相互冲突，每个人也都有同样的目标。”Jim Johnson说，“积极良好的环境有助于项目顺利开展。”

　　不但项目团队要有兴趣，用户也要有兴趣。正如Jim Johnson所言: “你希望看到积极的参与、积极的反馈以及积极的用户群体。要不然，项目成功的可能性就很小。”

　　2.沟通不畅

　　缺少沟通(正式和非正式的)是另一个早期警告迹象。要是从团队成员到用户的各利益相关方没有彼此沟通，就有问题了。在理想的状况下，项目评审会议不该有任何让人惊讶的地方，因为大家都知道，至少大体上知道项目的进展情况。

　　3.缺乏速度

　　对于拥护敏捷项目管理的人来说，“速度”是个关键概念，这通常意味着经常拿出许多小的交付成果。速度快不仅更容易跟踪项目进度，还有助于提升情绪。它让人感到成功带来的喜悦，提升团队士气。

　　Scott Johnson说: “很难让IT项目运作很长一段时间，你需要比较小的项目里程碑，它们经常带来一些小回报。”

　　“你需要迅速推动项目，需要迅速交付成果，这是真正的关键所在。”Jim Johnson认为，表明项目出问题的典型迹象之一就是没有进展。

　　4.没有坏消息

　　Raj Kapur是一家软件项目管理咨询及培训公司执行副总裁，他说: “这是非常棘手的企业文化问题，每个人对坏消息都非常反感，因而，往往会形成这样一种文化: 坏消息迟迟没有传达到公司上层，管理人员因此得不到关键的信息。”

　　Kapur说: “你一定要营造接受坏消息的环境，这很关键。而且，这不是项目团队成员的工作，而是领导人的工作，同样也是CIO的工作。”

　　具体迹象

　　Kapur主张使用仪表盘工具，让管理人员及其他人只要点击鼠标，就能了解项目。Kapur说: “这可以防止起先一直亮绿灯、到最后一刻却亮红灯的情况。”

　　1.经常加班

　　项目超进度的一个早期迹象就是团队经常加班加点。这个指标特别重要，因为指定或者鼓励加班是项目经理惯用的最快速的补救办法，但也是最少有人注意的办法。一般而言，按进度开发的项目几乎不需要什么加班。实际上，敏捷开发过程就明确不赞成加班。

　　正如Scott Johnson开玩笑所说: “表明项目出问题的一个迹象就是，参与项目的每个员工健康状况下降。这是由于经常加班导致摄入太多的咖啡因、熬了太多的夜、吃了太多的垃圾食品。”

　　2.资源挪用

　　把分配给某个项目的资源(通常是人)挪作他用，这可能因为另一个项目出了问题，需要救火队临时救急，也可能因为要做一些“份外”工作。

　　如果你已经为项目合理编制了预算，这些挪用就会积少成多。这里占几个小时，那里占几个小时，似乎没什么大不了，但很快就会积少成多。Scott Johnson警告说: “这最终会影响到项目团队本该完成的任务。”因而，准确跟踪转移到其他项目的人员和资金很重要。

　　3.比率问题

　　比率是一种标准的财务管理衡量尺度，现在刚开始出现在IT项目管理领域。据Scott Johnson介绍，两个重要的项目管理衡量尺度是成本比率和进度比率，譬如: 预算时间与实际所花时间的比率、预算资金与实际所用资金的比率。

　　Scott Johnson说: “这些比率让你知道到目前为止的实际成本及进度，以及应当出现的成本及进度。在为期两年的项目中，你到第二周就能知道哪个环节在耗用成本或者人力。”

　　一般的衡量尺度对确保项目顺利进展至关重要。Kapur警告说: “要是没有明确的衡量尺度，你只好依靠与项目经理及其他人的沟通。但那样会碰到麻烦，因为你往往很晚才发觉出了问题。”

　　4.里程碑没有达到

　　Scott Johnson建议，最好是能不断地获得里程碑，譬如几周，而不是几个月或者几个季度。要完成一小部分就交到用户手里，然后开始获得反馈。

　　每个里程碑都用可度量的方式来明确定义，并且有实实在在的交付成果。Jim Johnson更喜欢用“垫脚石”这个词语，而不是里程碑。“每踏上一块垫脚石，你就获得了具体的结果。”

　　“软性”里程碑(如全面完工的百分比)比较麻烦，因为很难确定是否已达到。更糟糕的是，基于所付努力而不是实际结果的里程碑，典型的例子就是从编写的代码来评估进度。

　　5.范围变更

　　试图挽救问题项目的常见办法就是变更项目范围，项目经理或者参与人员可能会减少或者放弃一些特性功能。这通常是从放宽需求(譬如响应时间)入手，竭力减少开发工作量。

　　需求变更本身无可厚非，也不是什么坏事。实际上，它们大量地运用于敏捷开发的方法中，这是由于开发过程中不断带来用户反馈。问题在于变更哪些需求、为什么。这些答案可以让你深入了解项目的运作状况。