這篇文章闡述了3個同業(yè)務有關的預警信號，希望它們能有助于你看清項目是否在走向崩潰。雖然這些總結(jié)并不太具備科學意義上的準確性，但是，這些跡象能為你提供一些早期警告。而且，盡管你無法拯救項目但你或許能通過這些警示拯救你自己。在文章的末尾還提出了一些建議性的應對措施，這樣一來，萬一你發(fā)現(xiàn)自己正身陷項目失敗的泥沼，那么你好歹可以采取相應的合理行動自救。
在你的職業(yè)生涯里，總有些時候需要你當機立斷地終結(jié)一個失敗的開發(fā)項目。當然，那是我們最希望避免出現(xiàn)的結(jié)果。從好的方面看失敗會令人沮喪，從壞的方面看項目的完蛋或許會威脅到你的職業(yè)安全性了。如果你能采取行動拯救一個項目，那么你就可能有機會影響項目的成敗。然而，除非你是項目經(jīng)理，否則你只能束手無策。不過，你倒可以想法了解迫近的問題以便尋找機會逃跑。
概述
針對成功的IT項目的統(tǒng)計報告不具備太大的意義。根據(jù)Standish商業(yè)研究公司的一份報告，將近三分之一的信息系統(tǒng)項目在最終完成之前都被取消了。另外，在所有的項目中幾乎有一半左右會超出其預算。
令人驚訝的是，項目失敗的原因很少同技術有關。在軟件管理手冊Peopleware: Productive Projects and Team一書中，作者之一Tom Demarco提醒讀者注意，大多數(shù)項目都是因為技術以外的其他原因而招致失敗的?？墒?，既然不是技術原因造成的項目失敗，那么又該是什么原因令這些項目失敗的呢？答案是項目所牽扯的人和工作過程。具有諷刺意味的是，普通開發(fā)人員在處理技術問題的時候應對有道但他們在同其他人以及工作流程打交道的時候卻不是這樣。
問題 # 1 ：缺乏有意義的商務案例
真的叫人很吃驚，有些項目從一開始就找不出有意義的商務案例來支持它們。商務案例很重要，因為它為項目提供了基礎。商務案例應該能提出效益分析，同時還能考慮到商業(yè)風險和項目之外事件的影響。機構會采用商務案例把它們有限的資源劃分出優(yōu)先級別從而為其提供最大回報。
這樣說來，在沒有商務案例的情況之下，一個項目該如何起步呢？這也是可能的，因為項目的商業(yè)屬主也許僅僅是需要實現(xiàn)什么特定的目標，而且有能力達到自己需要實現(xiàn)的目標。另外還有一種可能性，那就是IT機構認為商業(yè)單位需要它因此它們自己先創(chuàng)建出來再說。
最近兩年，因為許多人相信他們必須開發(fā)某些項目來維持競爭力，所以好多同Web關聯(lián)的項目在不存在商務案例的情況下就紛紛上馬了。那爭先恐后的樣子就好象不奮力一搏就趕不上趟似的，“.com”的崩潰意味著商務實踐回歸原來的基礎，這其中自然也包括商務案例。
對策：探詢你目前著手的項目是否受到了商務案例的支持。找一份商務案例來仔細閱讀它。你所在項目的商業(yè)動力是什么？這一商務案例符合邏輯而且可理解嗎？該商務案例存在怎樣的前天條件？其風險是什么？什么外部因素會影響商務案例？如果你無法為自己的項目找到可理解、有意義的商務案例，那么你得知道為什么沒有開發(fā)出有關的商務案例。
問題 #2 ：沒有獲得同意的需求或系統(tǒng)規(guī)范
缺乏需求確實是一件非常危險的事情。在Standish的報告里，挑戰(zhàn)項目正常運行的三個最常見因素都和系統(tǒng)需求有關。系統(tǒng)需求能給出將要創(chuàng)建的系統(tǒng)的大小和結(jié)構。它們定義了系統(tǒng)應該和不應該實現(xiàn)的任務。
需求管理就是在整個項目周期之內(nèi)定義、記錄、追蹤以及管理需求的過程。需求管理保證了最終的解決方案能夠滿足用戶的需要。
對策：密切注意你的需求管理過程。如果看起來沒人負責管理系統(tǒng)的需求，或系統(tǒng)的需求老是在變，那么你可能會遇到麻煩了。
問題 #3 ：缺乏項目計劃
有些項目竟然會在沒有項目計劃的情況下運做。這簡直就是不用圖