IT項目管理從某個意義上來說，是風險管理。從理論上講風險管理可以分為三個部分：風險識別、風險分析和風險解決。 傳統(tǒng)的風險管理系統(tǒng)只能幫我們較正規(guī)地統(tǒng)計和管理風險，這些系統(tǒng)本身是不能規(guī)避或解決任何風險的。在實際操作上，由于可能發(fā)生風險的種類很多，處理起來所耗費的人力物力也相當可觀。在下列的案例中，我們建議的不是一套昂貴而且全面的風險管理系統(tǒng)，而是一套扼住關鍵部位，高效且低成本，適合于千萬中小企業(yè)的小型解決方案。
一個案例
在2009年某家在北京海淀區(qū)的嵌入式產品公司跟我們討論項目管理時，該公司的王總監(jiān)跟我們做了以下溝通。他們項目風險種類可以概略分為四類：
（1） 需求風險 ——對需求理解不夠透徹或需求變更頻繁；
（2） 人員風險 ——人員生病或離職，一時無法找到替代者；
（3） 技術風險 ——某個關鍵的技術問題無法快速攻克；
（4） 管理風險 ——管理人員協(xié)調能力和執(zhí)行力能力不足，計劃偏差，流程更改和溝通不良等。
這些風險的發(fā)生導致的結果是項目延期和成本大幅攀升。無法有效處理這些風險的兩個大問題在于：
（1）對風險的反應遲鈍 ——常常是太晚發(fā)現(xiàn)問題，以至于無法彌補或是彌補成本太大；
（2） 對過程難以掌控 ——雖已有既定的流程，但由于人員變動、流程變動、系統(tǒng)出錯等問題，很難照著走。
為了讓我們更理解，王總監(jiān)很生動的解釋了以上兩個問題。對風險反應遲鈍的問題，他說，在做項目計劃時為求實際，總會多估個20%到40%的時間。如果項目需求清晰，或是團隊做過類似項目，用20%或多些；如果是新項目，或風險因素多便用30%到40%。所以，當某些風險（如，需求變更或人員變動）發(fā)生了，一般也未必馬上造成項目延期。可是，如果風險發(fā)生量繼續(xù)增加，或是某一兩個風險產生較嚴重的沖擊，在某個時刻會過了臨界點。難的地方是項目大人員多，是連項目經(jīng)理也是見樹不見林。
對過程難以掌控的問題，王總監(jiān)舉了個例子。公司的研發(fā)制度里規(guī)定，為保證需求的準確性，一個需求的變更要經(jīng)過（1）該項目經(jīng)理，（2）一位程序員，和（3）該產品經(jīng)理，等三個關鍵人審核后才可以進行更改。王總監(jiān)說：需求變更的過程在邏輯上看似簡單，但在實際操作時卻不斷地發(fā)生問題。舉例來說，內部溝通主要是以郵件通知的方式進行，需求變更的文檔寄來寄去，版本很多，而且郵件總是遺失。另有一次更嚴重，產品經(jīng)理因為休假，沒能及時查郵件。在等了兩天后，因怕誤了工期，項目經(jīng)理便越權要求程序員把代碼寫了。不巧，產品經(jīng)理對這需求的更改有他強烈的意見。當他看到在沒得到他的同意下把代碼寫了，火冒三丈，直接在會議中和項目經(jīng)理吵了起來。
兩個控制風險的原則
雖然風險總是發(fā)生，但如同大多數(shù)的公司一樣，該公司也不愿意花費太多的精力和時間在這風險管控上，所以在尋求一個低成本又高效的管控方法。王總監(jiān)和我們在研討后，使用工具DevSuite基于下列兩個原則做了處理。（為避免篇幅太大，以下我們僅把精彩的點列出來。）
（1） 提高項目的可視性
不論是哪一種風險，其后沖擊的基本上是項目本身，延期是常見的結果。如果是對可能發(fā)生的風險都一一進行管控，成本必然很高，而且還可能有疏漏。使用燃盡圖（Burn Down Chart）可能是針對項目延期有效的解決辦法，因為它很大程度地提高了項目的可視性。在實際操作時，我們讓團隊成員每天對其參與的每一任務都鍵入下列兩項數(shù)字：1）該任務花費時間，和2）該任務所剩時間。結果會生了類似如下的燃盡圖。
