IT項目管理中的風(fēng)險

1、1.功能無限蔓延；2.需求鍍金或者開發(fā)人員鍍金；3.質(zhì)里不疋；4.計劃過于樂觀；5.設(shè)計欠佳；6.銀彈綜合癥；7.研發(fā)導(dǎo)向的開發(fā)；8.人員薄弱；9.簽約商失敗;10.研發(fā)人員和客戶的摩擦;1計劃編制風(fēng)險：1.1計劃、資源和產(chǎn)品定義完全靠客戶或者上層領(lǐng)導(dǎo)的口頭命令，并且不完全一致；1.2計劃是優(yōu)化的，但是是不現(xiàn)實的；1.3計劃忽略了必要的任務(wù)；1.4計劃基于使用特定的小組成員，而那個小組成員基本上指望不上；1.5在限定時間內(nèi)無法建立成已定規(guī)模的產(chǎn)品；1.6產(chǎn)品規(guī)模比估計的大；1.7進度已經(jīng)拖延的項目在重新評估時過于優(yōu)化和忽略項目歷史；1.8過度的進度壓力造成生產(chǎn)率下降；1.9目標(biāo)日期提前，沒有相

2、應(yīng)調(diào)整產(chǎn)品范圍和可用資源；1.10 一個任務(wù)的拖延導(dǎo)致相關(guān)任務(wù)的連鎖反應(yīng)；1.11涉足不熟悉的產(chǎn)品領(lǐng)域，花費在設(shè)計和實現(xiàn)上的時間比預(yù)期的要多；2組織和管理：2.1項目缺乏一個有凝聚力的最高領(lǐng)導(dǎo)人；2.2由于前期乏力，項目長時間擱置；2.3解雇和削減開支導(dǎo)致項目小組能力下降；2.4僅由管理層或市場人員來進行技術(shù)決策，導(dǎo)致計劃進度延長；2.5低效的項目組結(jié)構(gòu)降低生產(chǎn)率；2.6管理層審查/決策的周期比預(yù)期時間長；2.7預(yù)算削減打亂項目計劃；2.8管理層做出了打擊項目積極性的決定；2.9非技術(shù)的第三方工作比預(yù)期延長（預(yù)算批準(zhǔn)、設(shè)備采購批準(zhǔn)）2.10計劃性太差，無法適應(yīng)期望的開發(fā)速度；2.11項目計劃由

3、于壓力而放棄，導(dǎo)致開發(fā)混亂，低效；2.12管理層強調(diào)英雄主義，而忽略客觀確切的狀態(tài)報告，降低發(fā)現(xiàn)和改正問題的能力; 3開發(fā)環(huán)境：3.1設(shè)施沒有及時到位；3.2設(shè)施到位，但是不配套；3.3設(shè)施擁擠，雜亂或者破損；3.4開發(fā)工具沒有及時到位；3.5開發(fā)工具不如期望那樣有效，開發(fā)人員需要時間創(chuàng)建工作環(huán)境或者切換新的工具；3.6開發(fā)工具的選擇不是基于技術(shù)需求，不能提供計劃所需要的性能；3.7新開發(fā)工具的學(xué)習(xí)比預(yù)期的長，內(nèi)容多；4最終用戶：-14.1最終用戶堅持新的需求；4.2最終用戶對于最后交付產(chǎn)品不滿意，要求重新設(shè)計和重做；4.3最終用戶不買進項目產(chǎn)品，無法提供后續(xù)支持；4.4最終用戶的意見沒有被采

4、納，造成產(chǎn)品最終無法滿足用戶期望，而必須重做；5客戶：5.1客戶堅持新的需求；5.2客戶對規(guī)劃、原型和規(guī)格的審核/決策周期比預(yù)期要長；5.3客戶沒有或不能參加規(guī)劃、原型、規(guī)格階段的評審，導(dǎo)致需求不穩(wěn)定和耗時的變更；5.4客戶堅持技術(shù)決策導(dǎo)致進度計劃延長；5.5客戶對于開發(fā)進度管理過細，導(dǎo)致實際進度變慢；5.6客戶提供的組件無法和開發(fā)產(chǎn)品匹配，導(dǎo)致額外的設(shè)計和集成工作；5.7客戶提供的組件質(zhì)量欠佳，導(dǎo)致額外的測試、設(shè)計和集成工作，以及額外的客戶管理管 理工作；5.8客戶要求的支持工具和環(huán)境不兼容，性能差或者功能不完善，導(dǎo)致生產(chǎn)率下降；5.9客戶不接受交付的軟件，盡管已經(jīng)滿足了所有的規(guī)格；5.10

5、客戶期望的開發(fā)速度是開發(fā)人員無法達到的；6承包商：6.1承包商沒有按承諾交付組件；6.2承包商遞交的組件質(zhì)量低下無法接收，必須花費時間改進質(zhì)量；6.3承包商沒有買進項目開發(fā)所需要的公舉，進而無法提供需要的性能水平；7需求：7.1需求已經(jīng)成為項目的基準(zhǔn)，但是變化還在繼續(xù)；7.2需求定義欠佳，而進一步的定義會擴展項目范疇；7.3添加額外的需求；7.4產(chǎn)品定義含糊的部分比預(yù)期需要更多時間；8產(chǎn)品：8.1錯誤發(fā)生幾率高的模塊需要比預(yù)期更多的測試，設(shè)計和實現(xiàn)工作；8.2校正質(zhì)量低下不可接受的產(chǎn)品，需要比預(yù)期更多的測試，設(shè)計和實現(xiàn)工作；8.3在一個或多個新興領(lǐng)域推廣計算機技術(shù)使得計劃進度的延長不可預(yù)期；8

6、.4由于軟件功能的錯誤，需要重新設(shè)計和實現(xiàn)；8.5開發(fā)額外不需要的功能，延長了計劃進度；8.6要滿足產(chǎn)品規(guī)模和進度要求，需要比預(yù)期更多的事件，包括重新設(shè)計和實現(xiàn)工作；8.7嚴格要求與現(xiàn)有系統(tǒng)兼容，需要進行比預(yù)期更多的事件進行測試，設(shè)計和實現(xiàn)工作；8.8要求在不同操作系統(tǒng)下運行將花費比預(yù)期更長的時間；8.9在不熟悉或沒有經(jīng)驗的軟件環(huán)境中運行產(chǎn)生沒有預(yù)料的問題；8.10在不熟悉或者沒有經(jīng)驗的硬件環(huán)境中運行產(chǎn)生沒有預(yù)料的問題；8.11開發(fā)一種對組織全新的模塊將比預(yù)期花費更長的時間；8.12依賴于正在開發(fā)中的技術(shù)將延長計劃進度；9外部環(huán)境：9.1產(chǎn)品依賴于政府規(guī)章，而規(guī)章的改變是不可避免的；9.2產(chǎn)品

7、依賴于草擬中的技術(shù)標(biāo)準(zhǔn)，而最后的標(biāo)準(zhǔn)是不可預(yù)期的； 10人員:10.1招聘人員所花費時間比預(yù)期長；10.2做為先決條件的任務(wù)不能萬丞，比如培訓(xùn)，其他項目的萬丞，工作許可證；10.3開發(fā)人員和管理層關(guān)系不佳導(dǎo)致決策緩慢，影響全局；10.4項目組乘員沒有全身心投入項目，進而無法達到需要的產(chǎn)品性能水平；10.5缺乏激勵機制，士氣低下，降低了生產(chǎn)能力；10.6缺乏必要的規(guī)范，增加了工作失誤和重復(fù)工作；10.7某些人需要更多時間適應(yīng)不熟悉的軟件工具和環(huán)境；10.8某些人需要更多時間適應(yīng)不熟悉的硬件工具和環(huán)境；10.9某些人需要更多時間適應(yīng)不熟悉的編程語言；10.10項目結(jié)束前，合冋制人員離開團隊；10.

8、11項目結(jié)束前，雇員辭職；10.12項目后期加入新的開發(fā)人員，額外的培訓(xùn)和溝通降低現(xiàn)有成員的效率；10.13項目組成員不能有效地一起工作；10.14由于項目組成員的沖突，導(dǎo)致溝通不暢，設(shè)計欠佳，接口錯誤和額外的重復(fù)工作；10.15有問題的成員沒有調(diào)離項目組，損害了項目組其他成員的積極性；二10.16項目組的最佳人員沒有加入項目組；10.17項目組的最佳人員已經(jīng)加入項目組，但是因為政治或其他原因沒有合理使用；10.18關(guān)鍵人員只能兼職參與；10.19項目人員不足；10.20人員工作的進展比預(yù)期的慢；10.21任務(wù)的分配合人員技能不匹配；10.22項目管理人員的怠工導(dǎo)致計劃和進度失控；10.23技

9、術(shù)人員怠工導(dǎo)致工作遺漏或質(zhì)量低下，工作需要重做；11設(shè)計和實現(xiàn)：11.1設(shè)計過于簡單，無法確定主要事件，并導(dǎo)致重新設(shè)計和實現(xiàn)；11.2設(shè)計過于復(fù)雜，導(dǎo)致一些不必要工作，并影響效率；11.3設(shè)計質(zhì)量低下，導(dǎo)致重復(fù)設(shè)計和實現(xiàn)；11.4采用不熟悉的方法，導(dǎo)致額外的培訓(xùn)時間，并重犯以前的錯誤；11.5產(chǎn)品采用低級語言來實現(xiàn)，導(dǎo)致生產(chǎn)率比預(yù)期低；11.6 一些必要的功能無法是用現(xiàn)有的代碼和庫實現(xiàn)，開發(fā)人員必需使用新的庫或者自行開 發(fā)所需要的功能；=11.7代碼和庫質(zhì)量低下，導(dǎo)致需要額外的測試，錯誤修正或重做；11.8過高估計增強型工具對項目進度的節(jié)省量；11.9分別開發(fā)的模塊無法有效集成，需要重新設(shè)計或

10、者重做；12過程12.1大量紙面工作導(dǎo)致進展比預(yù)期慢；12.2進度跟蹤不準(zhǔn)確，導(dǎo)致無法預(yù)知項目是否已經(jīng)落后計劃進度；12.3前期的質(zhì)量保證行為不真實，導(dǎo)致后期的重復(fù)工作；12.4質(zhì)量跟蹤不準(zhǔn)確，導(dǎo)致無法得知影響進度的質(zhì)量問題；在IT項目管理中時常會遇到風(fēng)險，包括技術(shù)風(fēng)險、管理風(fēng)險等等對項目產(chǎn)生影響的不 確定因素。項目風(fēng)險的控制直接影響項目的成敗，是貫穿項目生命周期始終的一個重要組成部分。本文就IT的一個實際項目：數(shù)據(jù)移植來討論風(fēng)險控制的步驟。1. 風(fēng)險識別數(shù)據(jù)移植是把數(shù)據(jù)從一個系統(tǒng)批量地移植到另一個系統(tǒng)的過程，通常用在更換系統(tǒng)或系統(tǒng)升級的時候。在做數(shù)據(jù)移植之前， 首先要進行風(fēng)險識別， 就是標(biāo)識

11、出整個數(shù)據(jù)移植的過程 中可能出現(xiàn)的對項目產(chǎn)生影響的風(fēng)險。風(fēng)險識別有以下幾種方法：頭腦風(fēng)暴。有關(guān)數(shù)據(jù)移植的項目成員、專家、客戶等各方人員組成小組，一起討論所有可能的風(fēng)險；專家訪談。向數(shù)據(jù)移植領(lǐng)域的專家或有經(jīng)驗人員了解項目中會遇到哪些困難。歷史資料。通過查閱數(shù)據(jù)移植項目的歷史資料了解可能出現(xiàn)的問題。檢查表。將可能出現(xiàn)的問題列出清單，可以對照檢查潛在的風(fēng)險。評估表。根據(jù)歷史經(jīng)驗進行總結(jié)，通過調(diào)查問卷方式判別項目的整體風(fēng)險和風(fēng)險類型。就數(shù)據(jù)移植而言，風(fēng)險可以分成以下幾類：技術(shù)風(fēng)險。數(shù)據(jù)移植涉及到的字段匹配因數(shù)據(jù)源的數(shù)據(jù)質(zhì)量問題或目標(biāo)系統(tǒng)的接口變 化而產(chǎn)生潛在風(fēng)險。管理風(fēng)險。數(shù)據(jù)移植的計劃草率，項目進度

12、和人員配置不合理組織風(fēng)險。高層對項目不重視、數(shù)據(jù)移植資金不足或與其他項目有資源沖突。外部風(fēng)險。數(shù)據(jù)移植涉及到的目標(biāo)系統(tǒng)的的負責(zé)方發(fā)生變化。2. 風(fēng)險分析在進行風(fēng)險識別并分類之后， 必須就各項風(fēng)險發(fā)生的概率和對項目的影響力做一些分析 和評價。風(fēng)險分析的方法非常多，一般采用統(tǒng)計學(xué)范疇內(nèi)的概率、分布頻率、平均數(shù)眾數(shù)等方法。風(fēng)險造成的后果是風(fēng)險發(fā)生的概率和產(chǎn)生的影響力的乘積。如果風(fēng)險發(fā)生的概率很高，但產(chǎn)生的影響并不嚴重，則最終的后果可能是中等。反之，如果風(fēng)險產(chǎn)生的影響極其惡劣，但發(fā)生的概率非常低，則最終的后果可能是低等級。風(fēng)險分析比較實用的兩種方法是：定性評估：將風(fēng)險發(fā)生概率和影響力分成低、中、高、極

13、高等幾個等級，通過相互比 較確定每個事件的等級。例如在數(shù)據(jù)移植項目中，數(shù)據(jù)質(zhì)量問題發(fā)生的概率比較高，但影響可能只是局部的，則數(shù)據(jù)質(zhì)量風(fēng)險的等級是低級或中級。定量評估：將發(fā)生概率和影響力用01之間的一個數(shù)字描述，然后找出那些“概率子跋熗A背嘶蟮氖錄 繚謔菀浦蠶钅恐校钅拷紉蠛芙簦？但關(guān)鍵的人員卻還在別的項目中，這個事件的發(fā)生概率大概為 0.5 ,卻影響整個項目的成敗， 影響力為0.8 , 則整個事件的定量評估值為 0.5*0.8= 0.4.3. 風(fēng)險應(yīng)對策略風(fēng)險應(yīng)對策略主要有以下四種。規(guī)避。通過變更項目計劃消除風(fēng)險或風(fēng)險的觸發(fā)條件，使目標(biāo)免受影響。 這是一種事前的風(fēng)險應(yīng)對策略。 例如，在數(shù)據(jù)移植的

14、過程中澄清不明確的需求、明確資源的需求量和時間、加強與各參與方的溝通，確保項目資金等。轉(zhuǎn)移。不消除風(fēng)險，而是將項目風(fēng)險的結(jié)果連同應(yīng)對的權(quán)力轉(zhuǎn)移給第三方。這也是一種事前的應(yīng)對策略，例如，將數(shù)據(jù)移植項目的成敗交給監(jiān)理方控制或與用戶簽定補償性合同。弱化。將風(fēng)險事件的概率或影響力降低到一個可以接受的程度。例如，在正式的數(shù)據(jù)移植之前在測試系統(tǒng)上多次演練，增加備份設(shè)計等。接受。不改變項目計劃，而考慮發(fā)生后如何應(yīng)對。例如當(dāng)數(shù)據(jù)移植出現(xiàn)問題時按事先 制定好的應(yīng)急計劃或退卻計劃執(zhí)行。4. 風(fēng)險監(jiān)控風(fēng)險監(jiān)控的目的是：監(jiān)視風(fēng)險的狀況，確定風(fēng)險是已經(jīng)發(fā)生、仍然存在還是已經(jīng)消失；檢查風(fēng)險的對策是否有效，監(jiān)控機制是否在運

15、行；不斷識別新的風(fēng)險并制定對策。無論項目進展的情況如何，都必須將風(fēng)險管理的計劃和行動結(jié)果整理匯總進行分析，形成風(fēng)險管理報告。采取書面或口頭、不定期的或階段性的等多種方式，為項目的實施、控制、管理、決策提供信息基礎(chǔ)。風(fēng)險總是和效益并存的。只有正確地識別風(fēng)險、分析風(fēng)險、應(yīng)對風(fēng)險，才能確保每一個 項目的順利實施和成功完成，才能給企業(yè)帶來更多的效益。IT項目風(fēng)險管理案例和應(yīng)對之道2011-3-28 來源：網(wǎng)絡(luò)IT項目管理從某個意義上來說，就是風(fēng)險管理。從理論上講風(fēng)險管理可以分為三個部分：風(fēng)險識別、風(fēng)險分析和風(fēng)險解決。傳統(tǒng)的風(fēng)險管理系統(tǒng)只能幫我們較正規(guī)地統(tǒng)計和管理風(fēng)險，這些系統(tǒng)本身是不能規(guī)避或解決任何風(fēng)

16、險的。在實際操作上，由于可能發(fā)生風(fēng)險的種類很多，處理起來所耗 費的人力物力也相當(dāng)可觀。在下列的案例中，我們建議的不是一套昂貴而且全面的風(fēng)險管理系統(tǒng)， 而是一套扼住最關(guān)鍵部位，高效且低成本，適合于千萬中小企業(yè)的小型解決方案。一個案例在2009年某家在北京海淀區(qū)的嵌入式產(chǎn)品公司跟我們討論項目管理時，該公司的王總監(jiān)跟我們做了以下溝通。他們項目風(fēng)險種類可以概略分為四類：（1）需求風(fēng)險對需求理解不夠透徹或需求變更頻繁；（2）人員風(fēng)險 一一人員生病或離職，一時無法找到替代者；（3）技術(shù)風(fēng)險一一某個關(guān)鍵的技術(shù)問題無法快速攻克；（4）管理風(fēng)險 一一管理人員協(xié)調(diào)能力和執(zhí)行力能力不足，計劃偏差，流程更改和溝通不良

17、 等。這些風(fēng)險的發(fā)生導(dǎo)致的結(jié)果就是項目延期和成本大幅攀升。無法有效處理這些風(fēng)險的兩個最大問題在于：（1）對風(fēng)險的反應(yīng)遲鈍一一常常是太晚發(fā)現(xiàn)問題，以至于無法彌補或是彌補成本太大；（2）對過程難以掌控 一一雖已有既定的流程，但由于人員變動、流程變動、系統(tǒng)岀錯等問 題，很難照著走。為了讓我們更理解，王總監(jiān)很生動的解釋了以上兩個問題。對風(fēng)險反應(yīng)遲鈍的問題，他說，在 做項目計劃時為求實際，總會多估個 20%到40%勺時間。如果項目需求清晰，或是團隊做過類似項目， 就用20%或多些；如果是新項目，或風(fēng)險因素多便用30%到40%所以，當(dāng)某些風(fēng)險（如，需求變更或人員變動）發(fā)生了，一般也未必馬上就造成項目延期。

18、可是，如果風(fēng)險發(fā)生量繼續(xù)增加，或是某一 兩個風(fēng)險產(chǎn)生較嚴重的沖擊，在某個時刻就會過了臨界點。難的地方就是項目大人員多，就是連項 目經(jīng)理也是見樹不見林。對過程難以掌控的問題，王總監(jiān)舉了個例子。公司的研發(fā)制度里規(guī)定，為保證需求的準(zhǔn)確性， 一個需求的變更要經(jīng)過（1）該項目經(jīng)理，（2）一位資深程序員，和（3）該產(chǎn)品經(jīng)理，等三個關(guān)鍵 人審核后才可以進行更改。王總監(jiān)說：需求變更的過程在邏輯上看似簡單，但在實際操作時卻不斷 地發(fā)生問題。舉例來說，內(nèi)部溝通主要是以郵件通知的方式進行，需求變更的文檔寄來寄去，版本 很多，而且郵件總是遺失。另有一次更嚴重，產(chǎn)品經(jīng)理因為休假，沒能及時查郵件。在等了兩天后， 因怕誤了

19、工期，項目經(jīng)理便越權(quán)要求程序員把代碼寫了。不巧，產(chǎn)品經(jīng)理對這需求的更改有他強烈 的意見。當(dāng)他看到在沒得到他的同意下就把代碼寫了，火冒三丈，直接在會議中就和項目經(jīng)理吵了 起來。兩個控制風(fēng)險的原則雖然風(fēng)險總是發(fā)生，但就如同大多數(shù)的公司一樣，該公司也不愿意花費太多的精力和時間在這風(fēng)險管控上，所以在尋求一個低成本又高效的管控方法。王總監(jiān)和我們在研討后，使用工具DevSuite基于下列兩個原則做了處理。（為避免篇幅太大，以下我們僅把最精彩的點列出來。）（1）提高項目的可視性不論是哪一種風(fēng)險，其最后沖擊的基本上就是項目本身，延期是最常見的結(jié)果。如果是對可能發(fā)生的風(fēng)險都一一進行管控，成本必然很高，而且還可能

20、有疏漏。使用燃盡圖（Burn Down Chart ）可能是針對項目延期最有效的解決辦法，因為它很大程度地提高了項目的可視性。在實際操作時， 我們讓團隊成員每天對其參與的每一任務(wù)都鍵入下列兩項數(shù)字：1 ）該任務(wù)花費時間，和2）該任務(wù)所剩時間。結(jié)果就會生了類似如下的燃盡圖。Burndown Report如圖所示，起初這項目被估計是要3480小時完成。大致上來說，一般的研發(fā)團隊因著人員請假、 會議和其他突發(fā)事情，平均每人每天只能有六小時花在實際項目工作上?，F(xiàn)這項目有七個人參與， 估算出來大約需要四個月完成。（也就是從2009年11月29日到2010年3月 29日，圖中紅色直立線為起始線，藍色直立線

21、為終止線。）這圖里共有三條曲線。紅色號碼？/span表示到現(xiàn)在為止在該項目的總花費時間，紅色號碼？表示估算的項目剩余時間，紅色號碼？是到目前為止所花的時間與剩余時間之和的曲線。到了 2010年3月 21日就得到了上面的這個圖。到了這一天，我們發(fā)現(xiàn)原本估計的3480總小時數(shù)是低估了，更可能的是 ？所示的3740小時。以縱軸的性質(zhì)區(qū)分，燃盡圖可以分為兩大類，即縱軸可以是時間或是事件。以范圍區(qū)分，燃盡 圖至少可以分為三類：項目級的、任務(wù)級的和需求級的。透過燃盡圖，我們可以看到項目進行的情 況，項目需求是否按計劃進入開發(fā)流程，工作是否有延時，或者工作安排的飽和度是否適合。如上 圖所示，我們可以輕易地看

22、到，照著現(xiàn)在的進度，這項目最可能會延期6到7工作天。當(dāng)高層看到這圖時，就可以在資源上做調(diào)動，以避免延期產(chǎn)生的不良后果。我們刻意使用了這個較理想的圖做講解，為的是讓讀者更容易理解。它不是個典型的圖。在大 多情況，使用燃盡圖會是比較復(fù)雜的，因為它可能包含了需求搜集、編程、單元測試、集成測試和 缺陷修復(fù)，并且還可能有迭代。所以估算時間會較困難。這個燃盡圖的過程是比較穩(wěn)定的，結(jié)果是 比較理想的，其原因至少有二：（一）項目里單純地只有編程、單元測試和缺陷修復(fù)任務(wù)，全都由程 序員搞定；它里頭沒有需求搜集、集成測試或其他任務(wù)。（二）這個項目復(fù)雜度低，約一半的編碼任務(wù)是機械性的，所以估岀來的時間較為準(zhǔn)確。（2

23、）固化工作流以管控過程對于公司里既定的流程，我們在DevSuite里以圖形化的工作流將其固化。下圖就是以前面王總監(jiān)提到的需求變更流程設(shè)計岀來的。這工作流指明了，在一個變更事件被創(chuàng)建后，它需要經(jīng)過一個評審狀態(tài)。在評審階段里， 有三個人（A，B和C）要全部同意，才能到達通過狀態(tài)。有任何一人不同意，狀態(tài)就轉(zhuǎn)到拒絕當(dāng)一到達評審狀態(tài)，系統(tǒng)馬上促發(fā)郵件和手機通知，將信息寄給A, B和C。系統(tǒng)可以預(yù)先設(shè)定這三人有兩天的時間評審該變更。假如兩天過了，狀態(tài)仍為評審，那就是有人未及時處理該事件。這時候，系統(tǒng)會自動將事件升級，把狀態(tài)轉(zhuǎn)換為升級處理，系統(tǒng)馬上促發(fā)郵件，將信息寄給研發(fā)部王總監(jiān)。王總監(jiān)可以斟酌情況，做最妥善的處理。初始狀態(tài)提交變靈事件使用固化的工作流至少有四個優(yōu)點：1）提高通知效率？郵件和手機自動通知提高效率，溝通岀錯的機會減少了； 2）避免流程岀