大型it項目管理的六大風險管理
it項目的不確定性非常大，因此風險的發生可能性就大起來了。而對於大型it項目管理來說，風險管理就更應該引起註意。由於項目規模大，人員多，技術難度大，因此，面臨的不確定會更大。那麽，該如何去應對大型it項目管理的風險，對其做好管理呢?下文會從大型it項目管理的六大風險管理出發，介紹一些解決方法，主要是以銀行核心系統升級項目來為例。
項目的成功離不開項目組所有成員的拼搏努力，同時也離不開成功的項目管理，尤其是風險管理。從項目啟動階段，制定了定性的風險計劃，識別出風險級別最高的幾個風險。為了減輕技術風險的影響，在項目計劃階段，所有開發小組都對上一代系統認真進行了梳理，分析出系統升級的影響，制定了相應的應對方案。同時，在項目執行過程中，高層管理人員也很註意對風險的監控，確保在風險變成問題時能有效應對，並指示PMO認真做好所有問題記錄工作。在項目中被識別的主要風險有：技術風險;溝通風險;需求變更風險;進度風險;數據遷移風險;人力資源風險。
(1)技術風險。核心系統升級引入了外包廠商的最新產品，使用了很多新技術，行內研發人員熟悉這些技術需要一定的時間，而在項目過程中卻不可避免地會遇到一些技術問題。如何能快速解決這些棘手的技術問題?項目部具體做法是：第一，指定行內外包廠商接頭人，由接頭人負責和外包廠商的技術人員進行溝通，同時該接頭人也是行內對廠商產品最熟悉的人，一般性的小問題基本上此人就可以解決，比較復雜的問題才提交給廠商解決，這樣比起全部問題都去找廠商解決，節省了時間。第二，購買廠商的人力進行技術支持，請廠商的研發人員來到開發現場和我們一塊研發。第三，預約廠商在系統上線期間到現場待命，以應對緊急問題發生，對可能出現的問題進行第一時間的響應。
(2)溝通風險。參與項目的外包廠商有多個，溝通渠道多，溝通成本大，而且容易出現理解不一致的情況。所以，項目組成立了專門的PMO，負責制定相應的溝通計劃，為每個廠商指定行內的接頭人，對內部人員實行分級管理，組織定期例會解決項目過程中出現的問題，防範由於對需求理解不一致造成的項目延誤，充分利用已有的郵件、會議、電話和短信等溝通工具，並推廣使用某即時通訊工具以作為主要的工作溝通工具。
(3)需求變更風險。針對IT軟件項目中不可避免的需求變更活動，在項目開始後，項目部就停止了除政策性需求以外的所有規模超過20人/天的新業務需求，同時制定了需求變更流程：所有業務需求的變更必須由業務方的代表統一提出，變更必須有書面記錄，開發人員仔細評估是否接受，最後由總管變更的領導(CCB)復審，總管領導具有一票否決權，從而精簡了一些不合理的需求變更。在項目中期引入了IBM的配置管理工具CCCQ來管理代碼和缺陷，所有Bug都進行了分類，並錄入CQ系統，防止重復修改和修改後無記錄等情況的發生。遷移演練之後的缺陷都由各個系統的負責人統一對缺陷進行分析評審，消除Bug修復可能導致的系統關聯問題。
(4)進度風險。項目進行核心升級，引起了客戶面數據結構和一些外部接口的變化，同時前端業務平臺也做了很大的調整，如開發了新的權限系統、遷移主機老權限系統上的權限數據到微機、替換傳輸協議XML為JSON、改造微機調用主機框架等。主機平臺和開放平臺開發工作量巨大，需要留有足夠的ST、UAT測試時間，項目開發時間有限，為了應對可能造成的進度延誤，項目部采用了以下應對方法：一是制定詳細的進度計劃，明確每個人的任務，各項目組每周定期檢視項目進度，如出現偏差及時糾正;二是與外包公司合作，引入外包人力，為項目臨時增派了多名生力軍;三是強制加班;四是並行化詳細設計和編碼同時加強代碼評審，在加快進度的同時減少返工。
(5)數據遷移風險。項目涉及的系統多達上百個，系統集成環境復雜，需要遷移的數據量龐大，而且數據遷移對數據的準確性和完整性有著很高的要求。項目制定了分階段集成和多次遷移演練的策略：將遷移工作進行提前預演，模擬真實上線遷移場景。經過多次演練以後，問題大大減少，減輕了系統上線的數據遷移風險。
(6)人力資源風險。項目建設周期長，歷時兩年，大範圍人員流動可能會造成項目延誤。針對這一風險，應對的方法是：做兩手準備，盡力挽留要走的人員，曉之以理，動之以情，請求公司人力資源部提升員工待遇;同時加緊社會招聘，在重要的崗位上安排備份，防止由於成員生病、離職等意外造成的減員。最終這個風險沒有成為問題。
上訴的對大型it項目管理的六大風險管理的處理方式，可以給一些參考意見。但是在具體的項目管理中，需要結合具體的實際情況、行業背景和幹系人特點，靈活采用相應的對策才行，切記不可行盲目照搬。
本文轉載自拓源優課：www.toyoke.com
大型it項目管理的六大風險管理