項目風險是一種不確定事件或狀況，一旦發生，會對至少一個項目目標，如進度、成本、範圍或質量目標產生積極或消極影響。那麼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項目中的重要性，正因爲對風險管理足夠重視，提前制定了風險應對計劃，我們才得以如庖丁解牛般化解項目中遇到的各種風險，並最終取得了上線的勝利。任何項目都不能迴避風險問題，風險的存在導致幾乎每個項目都不可能順風順水地完成項目目標，良好的風險管理技能將幫助項目經理處理好項目中的不確定因素，保證項目的順利進行。
