预警仪一键升级工具安装失败_如何预警失败的项目

　　（沈建苗编译）项目的成败往往在于能不能发觉表明项目出问题的关键迹象。本文简要介绍了表明项目某些地方出问题的一些早期症状，并且给出了相应的办法。　　IT项目失败时，管理人员通常是最后一个知情的。就像一条鱼在冰箱里搁了太久那样，异味终究会暴露的。要是到了这种地步，惟一的办法就是把鱼从冰箱里取出来，再用小苏打除去异味。

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

　　项目不是注定失败的

　　评估IT项目最常用的指标就是TheStandishGroupInternational的问题报告（ChaosReport）。这项报告每两年发布一次，它基于对几千家大中型公司开展的全球性调查。

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

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

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

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

　　4．里程碑没有达到

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

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

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

　　5．范围变更

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

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