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)險的。在實際操作上，由于可能發(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í)行力能力不足，計劃偏差，流程更改和溝通不良等。
這些風(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ā)生了，一般也未必馬上就造成項目延期。可是，如果風(fēng)險發(fā)生量繼續(xù)增加，或是某一兩個風(fēng)險產(chǎn)生較嚴(yá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)部溝通主要是以郵件通知的方式進行，需求變更的文檔寄來寄去，版本很多，而且郵件總是遺失。另有一次更嚴(yán)重，產(chǎn)品經(jīng)理因為休假，沒能及時查郵件。在等了兩天后，因怕誤了工期，項目經(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)險都一一進行管控，成本必然很高，而且還可能有疏漏。使用燃盡圖（Burn Down Chart）可能是針對項目延期最有效的解決辦法，因為它很大程度地提高了項目的可視