整個項目管理過程中，風險一直是與之相伴的，而我們需要研究的風險管理就是其可能帶給項目的負面影響。雖然一直說項目風險屬于“意外”一類，但我們要知道很多時候發生都還是有一定前提因素存在的。

　　就是說，當有不少項目管理的不當行為發生時，那么也應該同時可以分析這些可能帶來怎樣的風險。下面就介紹下致使風險產生的因素又哪些。

　　一、需求目標未明確，開始匆忙

　　為了市場競爭或內部管理決策的需要，業務部門提出的需求往往要求的時間比較緊迫，需求的提出大多停留在幾張紙或口頭的傳達上，沒有形成正式的業務需求文檔。大多數從事IT的技術人員也深有體會，在沒有明確的需求范圍的情況下，為了迎合業務部門的口味匆匆開工，過程中用戶不斷地提出新的想法，技術人員開始疲于奔命和應付，很難保證項目的進度和質量，也難以取得業務部門的認可。

　　所以，在項目的前期一定要采取相應的手段或措施，與業務部門共同明確項目目標、需求范圍，充分考慮現有的時間和資源約束，將需求排定優先級，對于關鍵的需求優先實現，其他輔助性的根據過程中的具體情況進行滾動式計劃，并取得業務部門的書面確認。在此過程中要注重挖掘用戶的隱性需求，可以通過引導、系統原型等手段讓用戶在前期充分暴露自己的想法和需求。

　　二、新需求不斷增加，管控不嚴

　　在有了明確的目標和需求范圍情況下，需求的變更還是不可能避免。業務部門在看到具體的系統的真實雛形之后，源源不斷地要求、新想法隨之產生，如果不對此加以控制，新的需求的加入通常會影響已實現的需求，并且對項目進度和成本產生很大的影響。

　　項目經理針對這種情況一定要采取嚴格的變更控制流程，不能礙于臉面，否則最終的結果往往是出力不討好。針對用戶提出的新需求，按照正式流程提出變更申請，組織相關團隊成員進行分析及影響評估作為是否實施的依據。變更控制委員會根據分析結果判斷是否批準，如果批準，那項目組可以安排實施;否則，正式拒絕用戶的請求，當然實際情況下可以采取一些軟的措施緩和矛盾。

　　三、前期質量品控不嚴，反工風險

　　項目工作返工是項目組最不愿意看到的，既浪費人力、物力和財力，又影響團隊積極性。需求不明確或范圍沒有有效控制都可能造成返工，另外造成返工的原因是質量沒有達到用戶要求。

　　往往有這樣一種情況，每個團隊成員按照項目計劃報告進度都是100%完成;但一到最后系統集成的時候就會發現一大堆問題，不得不花費很大精力回頭排查、修改程序，造成這種情況的主要原因是過程中質量保證沒有做到位，把大部分問題留在了后面。

　　這就需要在項目實施過程中采取有效的措施來規避返工的風險，通常的做法有同行評審，比如概要設計完成之后，邀請其他項目組的技術專家進行技術評審以發現架構設計問題;管理評審，通過組織級的質量審計看產品以及實施過程是否滿足質量要求;代碼走查，在編碼過程中加入2-3次的代碼走查，排查不符合規范或性能要求的代碼，走查通常能夠發現50%-70%的錯誤;每日構建，這是一種非常有效的方法，可以避免把各部分的集成問題拖到最后，并且能夠及時發現相應的錯誤，日構建一般在項目的中后期開始，每天自動從版本服務器上獲取源代碼進行自動編譯和測試。

　　四、成員專業能力欠缺，外包成本

　　項目實施過程中由于人員技能欠缺造成的進度延后和軟件質量問題并不少見，一個熟練的技術人員完成同樣一個任務需要3天，但一個生手可能就需要7-10天。項目經理應該在前期就分析清楚項目所要采用的技術以及相應的人員技能要求，針對不同的角色，及時采取相應的技能培訓，以保證項目的順利實施。

　　如果對于項目中某些部分專業性特別強或新技術，短期內又不能快速建立技能的情況，可以考慮將該塊任務外包，借鑒合作廠商的力量降低實施風險，當然要進行外購人力成本與自建人力成本的效益分析。

　　五、團隊協作融合不夠，缺少配合

　　軟件項目實施屬于知識型，要發揮團隊成員的創造力，不同于制造業計件生產，各模塊最終要集成在一起形成一個有機的整體。這就需要各小組之間的密切配合，界定清楚工作界面及接口關系，并在實施過程中持續地溝通交流和共享。首先團隊要融為一體，那產出的軟件才能融為一體。

　　不論是風險還是機遇，都是最能體現項目經理項目管理能力的關鍵點。因此，只要抓住源頭，了解發生的原因，盡量規避，那么就會降低項目風險的不良影響。