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