如何預(yù)警失敗的項目

申請免費(fèi)試用、咨詢電話：400-8352-114

項目的成敗往往在于能不能發(fā)覺表明項目出問題的關(guān)鍵跡象。本文簡要介紹了表明項目某些地方出問題的一些早期癥狀，并且給出了相應(yīng)的辦法。

IT項目失敗時，管理人員通常是最后一個知情的。就像一條魚在冰箱里擱了太久那樣，異味終究會暴露的。要是到了這種地步，惟一的辦法就是把魚從冰箱里取出來，再用小蘇打除去異味。

如今，項目管理在日益改進(jìn)，成功的項目更多了，完全失敗的項目更少了，而且項目帶來的投資回報更大了。不過，完全成功的項目大概只占1/3。

項目不是注定失敗的

評估IT項目最常用的指標(biāo)就是The Standish Group International的問題報告（Chaos Report）。這項報告每兩年發(fā)布一次，它基于對幾千家大中型公司開展的全球性調(diào)查。

最初的那項調(diào)查結(jié)果讓人震驚。研究人員在1994年發(fā)現(xiàn): 31%的IT項目完全失敗，也就是說，這些項目還未完成就被拋棄，毫無成效; 只有大約16%的項目才完全成功——按時、按預(yù)算交付應(yīng)用軟件，而且提供了最初規(guī)定的所有特性和功能。

Standish Group主席Jim Johnson說: “到2006年，項目完全失敗的比例降到了19%; 成功率上升到了35%?！笔Ｏ碌?6%是Standish Group認(rèn)為的“有缺陷的項目”: 這些項目并不符合完全成功的標(biāo)準(zhǔn)，但交付了有用的產(chǎn)品。

Jim Johnson說: “情況之所以好轉(zhuǎn)是因為，項目管理方面的整套體系變得更像是一門職業(yè): 我們更清楚項目管理方法; 表述能力更強(qiáng)的用戶能夠更準(zhǔn)確地描述需求; 我們還有一些非常好的工具可以幫助用戶，如統(tǒng)一建模語言（UML）?！?/FONT>

AtTask是生產(chǎn)項目管理工具的公司，該公司CIO Scott Johnson說，“互聯(lián)網(wǎng)也起到了作用，可以迅速進(jìn)行溝通，沒必要等召開狀況報告會議時才發(fā)現(xiàn)問題，也不存在中間溝通環(huán)節(jié)的延遲?！?/FONT>

Scott Johnson認(rèn)為，與幾年前相比，新的項目管理工具更容易使用。而且，它們還包括了像復(fù)雜的趨勢分析這些功能，從而能夠及早發(fā)現(xiàn)有問題的項目。

Jim與Scott都堅定不移地?fù)碜o(hù)敏捷項目管理，這種管理方式側(cè)重于把項目分成多個小部分，然后迅速交付部分成果，以便用戶反饋。

尋找失敗的無形跡象

Chaos Report顯示，近1/5的IT項目還是完全失敗的，2/5以上的項目局部失敗。更加讓人擔(dān)憂的是: 項目規(guī)模越大，問題越嚴(yán)重。Jim Johnson說: “人力成本不到75萬美元的項目中，有73%是成功的; 但人力成本超過1000萬美元的項目中只有3%是成功的。我敢說，這3%的項目之所以會成功，是因為過高估計了預(yù)算，而不是因為管理有方?！?/FONT>

導(dǎo)致IT項目失敗的常見原因包括: 缺少管理人員的支持和目標(biāo)不明確。而失敗的警告跡象要具體得多，與項目的日常運(yùn)作有密切關(guān)系。

最重要的早期警告跡象都是無形的，Jim Johnson說，其中最重要的兩個跡象就是對項目沒有興趣以及溝通不暢。

1．沒有興趣

對項目沒有興趣往往是由于得不到管理人員的認(rèn)可，實(shí)施者可能迫于壓力或者勸說之后批準(zhǔn)項目，其實(shí)并非真正同意。其他跡象包括不參加會議、不關(guān)注或者根本不發(fā)表任何意見?！耙_保每個人真正同意項目要完成的任務(wù); 確保即使日程表相互沖突，每個人也都有同樣的目標(biāo)。”Jim Johnson說，“積極良好的環(huán)境有助于項目順利開展?！辈坏椖繄F(tuán)隊要有興趣，用戶也要有興趣。正如Jim Johnson所言: “你希望看到積極的參與、積極的反饋以及積極的用戶群體。要不然，項目成功的可能性就很小。”

2．溝通不暢

缺少溝通（正式和非正式的）是另一個早期警告跡象。要是從團(tuán)隊成員到用戶的各利益相關(guān)方?jīng)]有彼此溝通，就有問題了。在理想的狀況下，項目評審會議不該有任何讓人驚訝的地方，因為大家都知道，至少大體上知道項目的進(jìn)展情況。

3．缺乏速度

對于擁護(hù)敏捷項目管理的人來說，“速度”是個關(guān)鍵概念，這通常意味著經(jīng)常拿出許多小的交付成果。速度快不僅更容易跟蹤項目進(jìn)度，還有助于提升情緒。它讓人感到成功帶來的喜悅，提升團(tuán)隊士氣。Scott Johnson說: “很難讓IT項目運(yùn)作很長一段時間，你需要比較小的項目里程碑，它們經(jīng)常帶來一些小回報。”“你需要迅速推動項目，需要迅速交付成果，這是真正的關(guān)鍵所在。”Jim Johnson認(rèn)為，表明項目出問題的典型跡象之一就是沒有進(jìn)展。

4．沒有壞消息

Raj Kapur是一家軟件項目管理咨詢及培訓(xùn)公司執(zhí)行副總裁，他說: “這是非常棘手的企業(yè)文化問題，每個人對壞消息都非常反感，因而，往往會形成這樣一種文化: 壞消息遲遲沒有傳達(dá)到公司上層，管理人員因此得不到關(guān)鍵的信息?！盞apur說: “你一定要營造接受壞消息的環(huán)境，這很關(guān)鍵。而且，這不是項目團(tuán)隊成員的工作，而是領(lǐng)導(dǎo)人的工作，同樣也是CIO的工作?！?/FONT>

具體跡象

Kapur主張使用儀表盤工具，讓管理人員及其他人只要點(diǎn)擊鼠標(biāo)，就能了解項目。Kapur說: “這可以防止起先一直亮綠燈、到最后一刻卻亮紅燈的情況?！?/FONT>

1．經(jīng)常加班

項目超進(jìn)度的一個早期跡象就是團(tuán)隊經(jīng)常加班加點(diǎn)。這個指標(biāo)特別重要，因為指定或者鼓勵加班是項目經(jīng)理慣用的最快速的補(bǔ)救辦法，但也是最少有人注意的辦法。一般而言，按進(jìn)度開發(fā)的項目幾乎不需要什么加班。實(shí)際上，敏捷開發(fā)過程就明確不贊成加班。正如Scott Johnson開玩笑所說: “表明項目出問題的一個跡象就是，參與項目的每個員工健康狀況下降。這是由于經(jīng)常加班導(dǎo)致攝入太多的咖啡因、熬了太多的夜、吃了太多的垃圾食品。”

2．資源挪用

把分配給某個項目的資源（通常是人）挪作他用，這可能因為另一個項目出了問題，需要救火隊臨時救急，也可能因為要做一些“份外”工作。如果你已經(jīng)為項目合理編制了預(yù)算，這些挪用就會積少成多。這里占幾個小時，那里占幾個小時，似乎沒什么大不了，但很快就會積少成多。Scott Johnson警告說: “這最終會影響到項目團(tuán)隊本該完成的任務(wù)?！币蚨瑴?zhǔn)確跟蹤轉(zhuǎn)移到其他項目的人員和資金很重要。

3．比率問題

比率是一種標(biāo)準(zhǔn)的財務(wù)管理衡量尺度，現(xiàn)在剛開始出現(xiàn)在IT項目管理領(lǐng)域。據(jù)Scott Johnson介紹，兩個重要的項目管理衡量尺度是成本比率和進(jìn)度比率，譬如: 預(yù)算時間與實(shí)際所花時間的比率、預(yù)算資金與實(shí)際所用資金的比率。

Scott Johnson說: “這些比率讓你知道到目前為止的實(shí)際成本及進(jìn)度，以及應(yīng)當(dāng)出現(xiàn)的成本及進(jìn)度。在為期兩年的項目中，你到第二周就能知道哪個環(huán)節(jié)在耗用成本或者人力?！币话愕暮饬砍叨葘Υ_保項目順利進(jìn)展至關(guān)重要。Kapur警告說: “要是沒有明確的衡量尺度，你只好依靠與項目經(jīng)理及其他人的溝通。但那樣會碰到麻煩，因為你往往很晚才發(fā)覺出了問題?！?/FONT>

4．里程碑沒有達(dá)到

Scott Johnson建議，最好是能不斷地獲得里程碑，譬如幾周，而不是幾個月或者幾個季度。要完成一小部分就交到用戶手里，然后開始獲得反饋。每個里程碑都用可度量的方式來明確定義，并且有實(shí)實(shí)在在的交付成果。Jim Johnson更喜歡用“墊腳石”這個詞語，而不是里程碑?！懊刻ど弦粔K墊腳石，你就獲得了具體的結(jié)果?！薄败浶浴崩锍瘫ㄈ缛嫱旯さ陌俜直龋┍容^麻煩，因為很難確定是否已達(dá)到。更糟糕的是，基于所付努力而不是實(shí)際結(jié)果的里程碑，典型的例子就是從編寫的代碼來評估進(jìn)度。

5．范圍變更

試圖挽救問題項目的常見辦法就是變更項目范圍，項目經(jīng)理或者參與人員可能會減少或者放棄一些特性功能。這通常是從放寬需求（譬如響應(yīng)時間）入手，竭力減少開發(fā)工作量。需求變更本身無可厚非，也不是什么壞事。實(shí)際上，它們大量地運(yùn)用于敏捷開發(fā)的方法中，這是由于開發(fā)過程中不斷帶來用戶反饋。問題在于變更哪些需求、為什么。這些答案可以讓你深入了解項目的運(yùn)作狀況。