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

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

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

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

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

項(xiàng)目不是注定失敗的

評(píng)估IT項(xiàng)目最常用的指標(biāo)就是The Standish Group International的問題報(bào)告（Chaos Report）。這項(xiàng)報(bào)告每?jī)赡臧l(fā)布一次，它基于對(duì)幾千家大中型公司開展的全球性調(diào)查。

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

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

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

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

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

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

尋找失敗的無形跡象

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

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

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

1．沒有興趣

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

2．溝通不暢

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

3．缺乏速度

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

4．沒有壞消息

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

具體跡象

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

1．經(jīng)常加班

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

2．資源挪用

把分配給某個(gè)項(xiàng)目的資源（通常是人）挪作他用，這可能因?yàn)榱硪粋€(gè)項(xiàng)目出了問題，需要救火隊(duì)臨時(shí)救急，也可能因?yàn)橐鲆恍胺萃狻惫ぷ?。如果你已?jīng)為項(xiàng)目合理編制了預(yù)算，這些挪用就會(huì)積少成多。這里占幾個(gè)小時(shí)，那里占幾個(gè)小時(shí)，似乎沒什么大不了，但很快就會(huì)積少成多。Scott Johnson警告說: “這最終會(huì)影響到項(xiàng)目團(tuán)隊(duì)本該完成的任務(wù)。”因而，準(zhǔn)確跟蹤轉(zhuǎn)移到其他項(xiàng)目的人員和資金很重要。

3．比率問題

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

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

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

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

5．范圍變更

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