專案風險是一種不確定事件或狀況，一旦發生，會對至少一個專案目標，如進度、成本、範圍或質量目標產生積極或消極影響。那麼IT專案管理的風險有哪些呢？一起來了解下吧：
(1)技術風險。
核心系統升級引入了外包廠商的最新產品，使用了很多新技術，行內研發人員熟悉這些技術需要一定的時間，而在專案過程中卻不可避免地會遇到一些技術問題。如何能快速解決這些棘手的技術問題?我們的做法是：第一，指定行內外包廠商接頭人，由接頭人負責和外包廠商的技術人員進行溝通，同時該接頭人也是行內對廠商產品最熟悉的人，一般性的小問題基本上此人就可以解決，比較複雜的問題才提交給廠商解決，這樣比起全部問題都去找廠商解決，節省了時間。第二，購買廠商的人力進行技術支援，請廠商的研發人員來到開發現場和我們一塊研發。第三，預約廠商在系統上線期間到現場待命，以應對緊急問題發生，對可能出現的問題進行第一時間的響應。
(2)溝通風險。
參與專案的外包廠商有多個，溝通渠道多，溝通成本大，而且容易出現理解不一致的情況。所以，專案組成立了專門的PMO，負責制定相應的溝通計劃，為每個廠商指定行內的接頭人，對內部人員實行分級管理，組織定期例會解決專案過程中出現的問題，防範由於對需求理解不一致造成的專案延誤，充分利用已有的郵件、會議、電話和簡訊等溝通工具，並推廣使用某即時通訊工具以作為主要的工作溝通工具。
(3)需求變更風險。
針對IT軟體專案中不可避免的需求變更活動，在專案開始後，我部就停止了除政策性需求以外的所有規模超過20人/天的新業務需求，同時制定了需求變更流程：所有業務需求的變更必須由業務方的代表統一提出，變更必須有書面記錄，開發人員仔細評估是否接受，最後由總管變更的領導(CCB)複審，總管領導具有一票否決權，從而精簡了一些不合理的需求變更。在專案中期引入了IBM的.配置管理工具CCCQ來管理程式碼和缺陷，所有Bug都進行了分類，並錄入CQ系統，防止重複修改和修改後無記錄等情況的發生。遷移演練之後的缺陷都由各個系統的負責人統一對缺陷進行分析評審，消除Bug修復可能導致的系統關聯問題。
(4)進度風險。
專案進行核心升級，引起了客戶面資料結構和一些外部介面的變化，同時前端業務平臺也做了很大的調整，如開發了新的許可權系統、遷移主機老許可權系統上的許可權資料到微機、替換傳輸協議XML為JSON、改造微機呼叫主機框架等。主機平臺和開放平臺開發工作量巨大，需要留有足夠的ST、UAT測試時間，專案開發時間有限，為了應對可能造成的進度延誤，我們採用了以下應對方法：一是制定詳細的進度計劃，明確每個人的任務，各專案組每週定期檢視專案進度，如出現偏差及時糾正;二是與外包公司合作，引入外包人力，為專案臨時增派了多名生力軍;三是強制加班;四是並行化詳細設計和編碼同時加強程式碼評審，在加快進度的同時減少返工。
(5)資料遷移風險。
專案涉及的系統多達上百個，系統整合環境複雜，需要遷移的資料量龐大，而且資料遷移對資料的準確性和完整性有著很高的要求。專案制定了分階段整合和多次遷移演練的策略：將遷移工作進行提前預演，模擬真實上線遷移場景。經過多次演練以後，問題大大減少，減輕了系統上線的資料遷移風險。
(6)人力資源風險。
專案建設週期長，歷時兩年，大範圍人員流動可能會造成專案延誤。針對這一風險，應對的方法是：做兩手準備，盡力挽留要走的人員，曉之以理，動之以情，請求公司人力資源部提升員工待遇;同時加緊社會招聘，在重要的崗位上安排備份，防止由於成員生病、離職等意外造成的減員。最終這個風險沒有成為問題。
在專案升級專案中，我負責兩個子系統的開放部分，由於高層對風險管理的重視，我在執行的時候也特別重視對風險的控制。專案組有四個人，溝通成本比較低，所以我們每隔一週進行一次程式碼評審，解決遇到的一些技術難題和編碼規範問題，在實際開發中使用Checkstyle進行程式碼規範檢視，及早扼殺了可能出現的Bug和不規範的程式碼;制定組員每週報告進度制度，防範進度偏差;面對前端最可能出現的需求變更——UI變更，我嘗試在設計初期使用原型方法和業務進行有效溝通，大大減少了後期UAT階段UI變更需求。回想剛進公司時我做過的某個專案，由於沒有考慮到UI類需求變更風險，前期沒有進行UI設計的交流，導致UAT階段大量返工，使專案延誤了一個多月，並且浪費了不少人力資源。設想如果當時識別了這類風險，在早期就把風險發生的概率降低，那麼專案可能會順利得多。
由於前期風險控制得當，一直到遷移演練前我負責的專案都很順利，但是在遷移演練過程中出現了一些問題，其中一個問題是導庫程式不能正常執行，並多次發生。我和同事花了很多時間研究問題，最後找到的原因是某個配置引數的問題，研發人員使用了錯誤的配置引數，ST、UAT期間導庫的資料量比真實演練期間的資料量小太多，所以沒有被發現，修改配置後再演練環境導庫成功。還有一些問題是沒有有效溝通導致的。例如，在演練的時候使用者反映某個查詢交易很慢，經排查，後臺人員說前臺調錯了交易，前臺人員提出異議：為什麼ST環境查詢很快?原來後臺人員寫了多個查詢交易，新交易確實能提升查詢速度，但是沒有在正式的文件上註明前臺應使用新交易替換老交易，也沒有通過別的途徑告知前臺，這樣前臺呼叫的還是老交易，導致了查詢效能問題。由於ST、UAT環境和生產環境的差異性，上述兩類問題很難暴露，試想如果沒有進行遷移演練，這個問題恐怕要在生產上出現了。遷移演練提前暴露了ST、UAT所不能測出的系統缺陷，使得研發人員能有充分的時間去排查問題和修復缺陷，有效降低了系統上線風險。
經過這次核心升級專案的洗禮，我深深認識到風險管理在IT專案中的重要性，正因為對風險管理足夠重視，提前制定了風險應對計劃，我們才得以如庖丁解牛般化解專案中遇到的各種風險，並最終取得了上線的勝利。任何專案都不能迴避風險問題，風險的存在導致幾乎每個專案都不可能順風順水地完成專案目標，良好的風險管理技能將幫助專案經理處理好專案中的不確定因素，保證專案的順利進行。