第九章 軟體專案風險管理
軟體專案中的風險
不斷變換的需求
低劣的計劃和估算
不可信賴的承包人
欠缺的管理經驗
人員問題
技術失敗
政策的變化
……
本章內容要點
風險管理概述
風險規劃
風險識別
風險評估
風險應對
風險監控
軟體專案風險管理案例分析
第一節 風險管理概述
- 風險是遭受損失的一種可能性。
- 這個定義包含兩層含義：
第一，風險會造成損失。如產品質量的降低，費用的增加或進度的推遲等。
第二，風險的發生是一種不確定性隨機現象，可用概率表示其發生的可能程度。
- 風險發生的概率越高，造成的損失越大，就越是高風險，否則就是中等風險或低風險。
風險的屬性
- 一般來說，風險具有以下屬性：
風險事件
風險發生的原因
風險發生的概率
風險的影響
風險發生的頻率
與其它風險相比較的重要程度
風險防範策略和應對策略
風險責任人
風險分類
常用的風險分類方法包括：
按風險的後果劃分：純粹風險、投機風險；
按風險的來源劃分：技術風險、行為風險、經濟風險、組織風險；
按風險是否可管理劃分：可管理風險、不可管理風險；
按風險影響範圍劃分：區域性風險、總體風險；
按風險的可預測性劃分：已知風險、可預測風險、不可預測風險；
按風險後果的承擔者劃分：專案業主風險、承包方風險、投資方風險、設計單位風險、監理單位風險、擔保方風險、政府風險等。
- 人們在大量的軟體專案實踐中，還總結出了以下最常見的、對專案目標影響最大的軟體專案風險類別：
- 1.需求風險：軟體專案在初期確定的需求往往都是模糊的、不確定的，而且隨著專案的進展，需求還可能不斷變化，這些問題如果沒有得到及時的解決，就會對專案的成功造成巨大的潛在威脅。常見的與需求相關的風險有：需求不夠明確、不準確；缺少有效的需求變更管理措施；使用者對產品的需求無限制地膨脹；使用者不能經常性地參加需求分析和階段性評審；使用者與專案團隊之間沒有建立直接、快速的通訊渠道。等等。
- 2.過程和標準方面的風險。規範的軟體過程和軟體工程標準是取得軟體專案成功的重要保障。常見的有關過程和標準的風險有：組織沒有建立適用於本組織的軟體過程規範或標準；沒有管理機制保證專案團隊按照軟體工程標準來工作；流程的重組和標準的改變使開發人員不適應，甚至有抵觸情緒；沒有采用配置管理來跟蹤和控制軟體工程中的各種變更，等等。
- 3.組織和人員管理風險。IT行業的人員流動性大，個性較強，難於管理。一旦專案組織和人員發生變動，往往會關係到整個專案的成敗。組織和人員管理方面的常見風險有：採用了不符合專案特徵的組織結構和管理模式；人員離職或因特殊原因而不能參加專案工作；人員之間的溝通和協調產生障礙；人員之間產生衝突；因績效評估、獎懲等方面的不當措施而挫傷員工的工作積極性；將專案的一部分外包給其他開發商，但與承包商之間缺乏良好的合作和溝通，等等。
- 4.技術風險。軟體專案所涉及的技術往往十分複雜，同時由於軟體技術飛速發展，在專案中經常需要適當採用一些新技術，以更好地實現專案的目標。因此軟體專案中經常隱含著技術風險，例如：團隊對專案中的技術和工具缺少充分理解；缺少應用領域的經驗和背景知識；採用了錯誤的技術和方法；需要對技術進行更新，但對新技術不熟悉；所採用的新技術不夠成熟，等等。
風險的基本性質
- 客觀性：首先表現在風險的存在是不以人的意志為轉移的。不管風險主體是否意識到風險的存在，在一定條件下風險都可能變為現實。其次，風險的客觀性還表現在它無時不有、無所不在，它潛在於各種活動之中。
- 不確定性：風險何時何地有可能變為現實是不能確定的。由於人們對客觀世界的認識受到各種條件的限制，不可能準確預測風險的發生。
- 不利性：風險一旦發生，就會給風險主體帶來挫折、失敗和損失，對風險主體不利。
- 可變性：在一定條件下風險可以轉化，風險可以轉化為非風險，非風險的事件也可轉化為風險事件。
- 相對性：對於相同的風險，不同的風險主體的承受能力不同，不同的組織和個人往往對風險有著不同的容忍限度。
- 風險和利益的對稱性：風險和利益總是同時存在的，風險是利益的代價，利益是風險的報酬。
風險管理
- 風險管理是指專案管理組織對專案可能遇到的風險進行規劃、識別、估計、評價、應對、監控的動態過程，是以科學的管理方法實現最大安全保障的實踐活動的總稱。
- 風險管理用來處理專案中的各種不確定性。風險管理策略可以分為4個層次：
危機管理：風險已經造成麻煩後才著手處理。
風險緩解：事先制定好風險發生後的補救措施，但不制定任何防範措施。
著力預防：將風險防範作為專案的一部分加以規劃和執行。
消滅根源：識別和消滅可能產生風險的根源。
- 應採取主動的風險管理策略，即著力預防和消滅根源的管理策略。這一策略在專案計劃階段就啟動了：識別出潛在的風險、評估它們出現的概率和潛在的影響、按照重要性進行排序，然後制定一個計劃來管理風險。
- 風險管理應貫穿於專案始終，在專案早期要識別出風險並確定有效的應對措施，在隨後的專案執行過程中，還要持續地關注和反覆評估風險。
- 軟體專案風險管理包括風險規劃、風險識別、風險評估、風險應對和風險監控5個活動。
（1）風險規劃：對風險管理進行系統規劃和頂層設計，制定專案風險管理計劃。
（2）風險識別：識別出項目中的風險，並對其進行描述和分類。
（3）風險評估：採用定性或定量的方法對風險發生的概率和產生的影響進行分析和評估。
（4）風險應對：確定應對風險的方案和措施。
（5）風險監控：在整個專案生命週期中跟蹤已識別的風險，監測殘餘風險、識別新風險、實施風險應對方案並對其有效性進行評估。
第二節 風險規劃
- 風險規劃（Risk Planning）就是制定專案風險管理的一整套計劃，主要包括定義專案組及其成員風險管理的行動方案和方式，選擇適合的風險管理方法，確定風險判斷的依據，指定風險管理的角色和職責，概括風險識別和評估的結果並制定相應的風險應對策略等。
- 風險規劃的結果就是正式的“風險管理計劃”（Risk Management Plan，RMP）。
風險規劃的依據
（1）專案計劃中所包含或涉及的有關內容，如專案目標、專案規模、專案利益相關者情況、專案複雜程度、所需資源、專案進度、約束條件及假設前提等。
（2）專案組織及個人的風險管理經驗及實踐。
（3）決策者、責任方及授權情況。
（4）專案干係人對專案風險的敏感程度及可承受能力。
（5）可獲取的資料及管理系統情況：豐富的資料和執行良好的計算機輔助管理系統，將有助於風險識別、評估、定量化及對應策略的制定。
風險管理計劃
- 風險管理計劃是針對整個專案生命週期而制定的如何組織和進行風險識別、風險評估、風險應對、風險監控的計劃。風險管理計劃一般應該包括以下內容：
（1）方法：確定風險管理使用的方法、工具和資料資源，這些內容可隨專案階段及風險評估情況做適當的調整。
（2）角色與職責劃分：明確專案中進行風險管理活動的角色定位、任務分工和相關責任人。
（3）風險承受程度：即風險承受限度標準。不同的專案團隊對於風險所持的態度也不相同，這將影響其對風險認知的準確性，也將影響其應對風險的方式。應當為專案制定適合的風險承受標準，對風險的態度也應當明確地表述出來。
（4）專案風險管理時間與頻率：界定專案生命週期中實施風險管理活動的各個階段，以及風險管理過程的評價、控制和變更的次數或頻率等，並把風險管理活動納入到軟體專案進度計劃中去。
（5）預算：風險管理活動必然要發生一些成本，佔用一些資源，因此應對風險管理進行成本預算。
（6）風險類別：風險類別清單可以保證對專案進行風險識別的系統性和一致性，並能保證識別的效率和質量，還可以為其它的風險管理活動提供一個統一的框架。
（7）基準：明確定義由誰在何時以何種方式採取風險應對行動。
（8）彙報形式：規定風險管理各過程中應彙報和溝通的內容、範圍、渠道及方式、格式等。
（9）跟蹤和資料記錄：確定如何以文件的方式記錄專案進行過程中的風險和風險管理活動。
（10）風險概率和影響的定性等級：為了按照統一的標準管理專案中的風險，需要定義風險發生概率與影響程度的定性等級。
（11）專案的主要風險及其特性：識別出的專案的主要風險及其特性描述，包括風險事件、發生概率、影響、原因、應對措施等。這一部分內容也可寫在一份單獨的“風險規避計劃”中。
第三節 風險識別
風險識別的輸入包括風險管理計劃、專案計劃、WBS、歷史專案資料、專案約束和假設、公司目標等。
- 風險識別通常至少需要確定風險的三個相互關聯的要素：
第一，風險來源，如進度、成本、技術、人員等；
第二，風險事件，即給專案帶來消極影響的事件；
第三，風險徵兆，即風險事件的外在表現，如苗頭和前兆等。
風險識別方法
核對表法
德爾菲方法
頭腦風暴法
SWOT分析法
其他方法
核對表法
- 在風險檢查表中列出專案中常見的風險的檢查條目。
- 專案相關人員通過核對風險檢查表，判斷哪些風險會出現在專案中。
- 可根據專案經驗對風險檢查表進行修訂和補充。
- 該方法可以使管理者集中識別常見型別的風險。
有研究表明：IT專案常常存在一些共同的風險。
如：人員缺乏、不現實的人員和成本估計、晚期需求變化、外購構件缺陷等。
1. 基於關鍵域的檢查表
2. 基於三層結構的檢查表
3. 基於生存期的檢查表
1.基於關鍵域的檢查表
- 風險檢查表中的風險條目屬於以下幾個關鍵域：專案規模、商業影響、專案範圍、客戶特性、過程定義、技術要求、開發環境、人員數目及其經驗。其中每一關鍵域都包含很多風險檢查條目。專案管理者將主要精力放在這些關鍵域方面來關注風險，通過對每個關鍵域中的風險檢查條目的回答，可以識別專案可能存在的風險。
基於關鍵域的檢查表（舉例）
- 專案規模風險檢查表：
對於估算出的產品規模的信任程度如何？
產品規模與以前產品的規模的平均值的偏差百分比是多少？
產品建立或使用的資料庫大小如何？
產品的使用者數有多少？
產品的需求改變有多少？交付之前有多少？交付之後有多少？
複用的軟體有多少？
2. 基於三層結構的檢查表
- 用類（class）、元素（Element）、屬性（Attribute）三個層次描述風險列表。
- 每個類下包含若干元素，每個元素下又包含若干屬性。
- 通過屬性值來識別、評估風險。
三層結構的風險檢查表
Product Engineering
- Requirements
Stability
Completeness
Clarity
Validity
Feasibility
Precedent
Scale
- Design
Functionality
Difficulty
Interfaces
Performance
Testability
Hardware Constraints
Non Developmental software
- Code and Unit test
Feasibility
Testing
Coding/Implementation
- Integration and Test
Environment
Product
System
- Engineering Specialties
Maintainability
Reliability
Safety
Security
Human Factors
Specification
Development Environment
- Development process
Formality
Suitability
Process Control
Familiarity
Product control
- Development System
Capacity
Suitability
Usability
Familiarity
Reliability
System Support
Deliverability
- Management Process
Planning
Project Organization
Management Experience
Program Interfaces
- Management Methods
Monitoring
Personnel Management
Quality Assurance
Configuration Management
- Work Environment
Quality Attitude
Cooperation
Communication
Morale
Program Constraints
- Resources
Schedule
Staff
Budget
Facilities
- Contract
Type of Contract
Restriction
Dependence
- Program Interfaces
Customer
Associate Contractors
Subcontractors
Prime Contractor
Corporate Management
Vendors
Politics
3. 基於生存期的檢查表
- 初始階段
專案範圍不明確
使用者參與少或與使用者溝通少，。。。。。
- 設計階段
專案隊伍缺乏經驗
漏項，。。。。。。
- 實施階段
程式設計師開發能力差
專案範圍改變，。。。。
- 收尾階段
質量差
客戶不滿意，。。。。。
- 使用檢查表法進行風險識別的優點是快速而簡單，可以用來對照專案的實際情況，逐項排查，從而幫助識別風險。但由於每個專案都有其特殊性，檢查表法很難做到全面周到。
- 在軟體專案的收尾過程中，應通過總結專案經驗，對風險核對表進行檢查和改進。
德爾菲（Delphi）方法
- 德爾菲方法又稱專家調查法，本質上是一種匿名反饋的函詢法。它起源於20世紀40年代末，最初由美國蘭德公司應用於技術預測。
- 把需要做風險識別的軟體專案的情況分別匿名徵求若干專家的意見，然後把這些意見進行綜合、歸納和統計，再匿名反饋給各位專家，再次徵求意見，再集中，再反饋，直至各專家的意見趨向一致，作為最後的結論。
- 要使用好該方法需要注意它的三個主要特點：
（1）德爾菲法中徵求意見是匿名進行的，這有助於排除若干非技術性的干擾因素。
（2）德爾菲法要反覆進行多輪的諮詢、反饋，這有助於逐步去偽存真，得到穩定的結果。
（3）工作小組要對每輪的專家諮詢結果進行統計、歸納，這樣可以綜合不同專家的意見，不斷求精，最後形成統一的結論。
頭腦風暴法
- 頭腦風暴（Brain Storm）法簡單來說就是團隊的全體成員自由地提出自己的主張和想法，它是解決問題時常用的一種方法。
- 頭腦風暴法可以充分發揮集體智慧，保證群體決策的創造性，提高決策質量。
- 利用頭腦風暴法識別專案風險時，要將專案主要參與人員代表召集到一起，然後他們利用自己對專案不同部分的認識，識別專案可能出現的問題。一個有益的做法是詢問不同人員所擔心的內容。
頭腦風暴法的具體做法
- 參加會議的人員輪流發言，無條件接納任何意見，不加以評論。
- 由一個記錄人員記錄提出的每一條意見，並寫在白板上，可被所有參會人員看到。
- 在輪流發言過程中，任何一個成員都可以先不發表意見而跳過。
- 這一過程迴圈進行，直到所有人員都沒有新的意見或限定時間到。
頭腦風暴法的特點
- 應用頭腦風暴法時要遵循的重要原則是：不進行討論，沒有任何判斷性評論。對各種意見、觀點的評判要放到事後進行，否則會影響會議的自由氣氛。要認真對待任何一種意見，而不管其是否正確。
- 頭腦風暴法的優點是善於發揮相關專家和分析人員的創造性思維，可對專案風險進行全面的識別。
SWOT分析法
- SWOT是英文的Strength（優勢）、Weakness（劣勢）、Opportunity（機遇）和Threat（挑戰）的簡寫。
- SWOT分析法的基準點是對企業內部環境之優劣勢的分析，在瞭解企業自身特點的基礎之上，判明企業外部的機會和威脅，然後對環境做出準確的判斷，做出合理決策。
SWOT分析法的道斯矩陣表
SWOT分析的步驟
- 列出專案的優勢和劣勢，可能的外部機會與威脅，填入道斯矩陣表的Ⅰ、Ⅱ、Ⅲ、Ⅳ區；
- 將內部優勢與外部機會相組合，形成SO策略，制定抓住機會、發揮優勢的戰略，填入道斯矩陣表的Ⅴ區；
- 將內部劣勢與外部機會相組合，形成WO策略，制定利用機會克服弱點的戰略，填入道斯矩陣表的Ⅵ區；
- 將內部優勢與外部威脅相組合，形成ST策略，制定利用優勢減少威脅戰略，填入道斯矩陣表Ⅶ區；
- 將內部劣勢與外部挑戰相組合，形成WT策略，制定彌補缺點、規避威脅的戰略，填入道斯矩陣表的Ⅷ區。
- 由於SWOT分析法明確了專案的優勢和劣勢，以及機會和威脅，因此可以多角度地、合理地分析識別專案的風險。
其他風險識別方法
- 文件評審：對軟體專案的計劃、方案等文件和每個專案階段的工作過程及其成果進行評審，可識別出項目的許多風險。
- 掙值分析：將計劃的工作與已完成的工作進行比較，確定專案是否符合計劃的費用和進度要求，如果偏差較大，則需要進一步進行專案的風險識別、評估和量化。
- 環境分析：對專案的環境（包括客戶、競爭者、合作者、政府管理者等）進行分析，從而識別出項目風險，並重點考慮它們相互聯絡的特徵和穩定性。
- 情景分析：通過有關資料和圖表等，對專案未來的某個狀態或某種情況進行詳細的描繪和分析，從而識別引起專案風險的關鍵因素及風險的影響程度。它注重說明某些事件引發風險的條件和因素，並且還要說明當某些因素髮生變化時，又會出現什麼樣的風險，會產生什麼樣的後果。
- 面談：與軟體專案的團隊成員、有經驗的專案干係人、有關專家和有類似專案經驗的人進行有關風險的面談，將有助於識別那些在常規方法中未被識別的風險。
第四節 風險評估
- 風險評估就是對風險發生概率的估計和評價，專案風險後果嚴重程度的估計和評價，專案風險影響範圍的分析和評價，以及對於專案風險發生時間的估計和評價。
- 定性評估是確定風險發生的概率和發生後產生的影響程度，並按照風險的潛在危險性大小對其進行優先順序排序；定量評估是針對那些對專案有潛在重大影響而排序在前的風險進行量化分析，從而為風險應對和專案管理決策提供依據。
風險概率和影響程度評估
- 風險概率和影響程度評估是根據軟體專案風險管理計劃中定義的標準，評估專案中每一個風險發生的可能性和它對專案目標（時間、成本、質量等）所造成的影響。
- 在軟體專案風險管理計劃中應該為風險發生的概率和影響程度制定一個統一的分級標準。
風險概率評估
風險影響程度評估
風險概率和影響程度評估方式
- 可以組織包括軟體專案團隊成員、專案干係人和專案外部的專業人士等在內的人員，採用召開會議或進行訪談等方式，對風險發生概率和影響程度進行分析。
- 每項風險的發生概率和影響程度值可由每個人定性地估計，然後彙總平均，得到一個有代表性的值。
風險值及風險排序
- 可採用下式為每個風險計算出一個“風險值”。
風險值 = 風險發生概率×風險影響程度
- 風險值代表了風險的危險程度，可根據風險值的大小對風險進行排序，風險值較大的排在前面。
- 風險排序可為風險應對措施提供指導，排在前面的高風險需要重點關注，並採取積極的應對策略，而排在後面的低風險，只需將之放入待觀察風險清單，不需要採取任何積極的管理措施。
決策樹分析
- 決策樹是一種形象化的圖形分析方法，它把專案所有可供選擇的方案、方案之間的關係、方案的後果及發生的概率用樹狀的圖形表示出來，為決策者提供選擇最佳方案的依據。
決策樹的結構
—— 決策節點。從它引出的分支叫方案分支，分支數量與方案數相同。決策節點表明從它引出的方案要進行分析和決策，在分支上要註明方案的名稱。
—— 狀態節點。從它引出的分支叫狀態分支或概率分支，分支數量等於狀態數量，在每一分支上註明狀態名稱及其出現的概率。
△—— 結果節點。將不同方案在各種狀態下所取得的結果標註在結果節點的右端。
期望損益值
- 每一個分支都採用期望損益值（Expected Monetary Value, EMV）作為其度量指標。決策者可根據各分支的期望損益值中最大者（如求最小，則為最小者）作為選擇的依據。期望損益值等於損益值與事件發生的概率的乘積，即：
EMV=損益值×發生概率
- 例如：某行動方案成功的概率是50%，收益是10 萬，則EMV=10*50%=5萬。
決策樹分析示例
- 某軟體公司有一款辦公軟體，現在需要決定是否研發該辦公軟體的新版本。據分析測算，如果市場需求量大，只銷售老版本的軟體可獲利50萬元，開發出新版本軟體並銷售可獲利100萬元。如果市場需求量小，只銷售老版本軟體仍可獲利20萬元，開發和銷售新版本軟體將虧損10萬元（以上損益值均指一年的情況）。另據市場分析可知，市場需求量大的概率為0.8，需求量小的概率為0.2。試分析和確定是否應該研發該辦公軟體的新版本。
- 第一步：繪製出決策樹。
- 第二步，計算各節點的期望損益值，計算順序是從右向左進行。
-節點2：100×0.8+(-10)×0.2=78（萬元）
-節點3：50×0.8+20×0.2=44（萬元）
-決策點1的期望損益值為：max{78, 44}=78（萬元）
- 第三步，剪枝。決策點的剪枝從左向右進行，因為決策點的期望損益值為78萬元，是“研發新版本”這一方案的期望損益值，因此剪掉“不研發新版本”這一分支，保留“研發新版本”這一分支。因此根據年度獲利最多這一評價準則，合理的決策是開發新版本辦公軟體。
模擬分析法
- 模擬分析法是運用概率論及數理統計的方法來預測和研究各種不確定因素對軟體專案的影響，分析系統的預期行為和績效的一種定量分析方法。大多數模擬都以某種形式的蒙特卡洛分析為基礎。
- 蒙特卡洛模擬法是一種最經常使用的模擬分析方法，它是隨機地從每個不確定因素中抽取樣本，對整個軟體專案進行一次計算，重複進行很多次，模擬各式各樣的不確定性組合，獲得各種組合下的很多個結果。通過統計和處理這些結果資料，找出專案變化的規律。
風險評估結果
第五節 風險應對
- 風險應對就是針對風險分析的結果，制定風險應對策略和處置辦法的過程，其目標是應對、減少、以至於消滅風險事件。
- 風險應對的主要策略：
迴避風險
轉移風險
減小風險
接受風險
風險預留
迴避風險
- 迴避風險是指當專案風險發生的可能性太大，不利後果也很嚴重，又無其他策略可用時，主動放棄或改變會導致風險的行動方案。
- 迴避風險包括主動預防風險和完全放棄兩種。
- 通過分析找出發生風險的根源，通過消除這些根源來避免相應風險的發生，這就是通過主動預防來回避風險。
- 迴避風險的另一種策略是完全放棄可能導致風險的方案。是最徹底的風險迴避方法，可把風險發生的概率降為零，但也是一種消極的應對手段，在放棄的同時也可能會失去發展的機遇。
- 注意事項：
必須要對風險有充分的認識，對威脅出現的可能性和後果的嚴重性有足夠的把握。
另外，採取迴避策略，最好在行動方案尚未實施時，若放棄或改變正在執行的方案，一般都要付出較高的代價。
轉移風險
- 轉移風險又叫合夥分擔風險，其目的是借用合同或協議，在風險事故一旦發生時將損失的全部或一部分轉移到專案以外的有能力承受或控制風險的個人或組織。
- 這種策略要遵循兩個原則：第一，必須讓承擔風險者得到相應的回報；第二，對於各具體風險，誰最有能力管理則讓誰分擔。
- 當專案的資源有限、不能實行減輕和預防策略，或風險發生頻率不高、但潛在損失或損害很大時可採用此策略。
轉移風險主要有四種方式：出售、外包、開脫責任合同、保險與擔保。
- 出售：通過買賣契約將風險轉移給其他組織。這種方法在出售專案所有權的同時也就把與之有關的風險轉移給了其他組織。
- 外包：向本專案組織之外分包產品的開發，從而把風險轉移出去。
- 開脫責任合同：在合同中列入開脫責任條款，要求甲方（客戶）在風險事故發生時，不令乙方（專案承擔者）承擔責任。
- 保險與擔保：保險是轉移風險最常用的一種方法。專案承擔者只要向保險公司交納一定數額的保險費，當風險事故發生時就能獲得保險公司的補償，從而將風險轉移給保險公司。所謂擔保，指為他人的債務、違約或失誤負間接責任的一種承諾。在專案管理上是指銀行、保險公司或其他非銀行機構為專案風險負間接責任的一種承諾。
減小風險
- 在風險發生之前採取一些措施降低風險發生的可能性或減少風險可能造成的損失。
- 例如，為了防止人員流失，提高人員待遇，改善工作環境；為防止程式或資料丟失而進行備份等。
- 減輕風險策略的有效性與風險的可預測性密切相關。對於那些發生概率高，後果也可預測的風險，專案管理者可以在很大程度上加以控制，可以動用專案現有資源降低風險的嚴重性後果和風險發生的概率。而對於那些發生概率和後果很難預測的風險，專案管理者很難控制，對於這類風險，必須進行深入細緻的調查研究，降低其不確定性。
接受風險
- 專案團隊有意識地選擇由自己來承擔風險後果。
- 當專案團隊認為自己可以承擔風險發生後造成的損失，或採取其它風險應對方案的成本超過風險發生後所造成的損失時，可採取接受風險的策略。
- 主動接受：在風險識別、分析階段已對風險有了充分準備，當風險發生時馬上執行應急計劃。
- 被動接受：風險發生時再去應對。在風險事件造成的損失數額不大，不對軟體專案的整體目標造成較大影響時，專案團隊將風險的損失當做軟體專案的一種成本來對待。
風險預留
- 風險預留是指事先為專案風險預留一部分後備資源，一旦風險發生，就啟動這些資源以應對風險。
- 風險預留一般應用在大型專案中。
- 專案的風險預留主要有風險成本預留、風險進度預留和技術後備措施三種。
風險成本預留
- 預留的風險成本是在專案經費預算中事先準備的一筆資金，用於補償差錯、疏漏及其它不確定性對專案費用估計精確性的影響。
- 風險成本預留在專案預算中要單獨列出，不能分散到具體費用專案下，否則專案管理組很容易失去對支出的控制。
- 專案團隊在進行風險成本預留時要根據風險評估的結果來進行，不可盲目地在各個具體費用中預留成本。
- 風險成本預留又可分為實施應急費和經濟應急費兩類。實施應急費用於補償估價和實施過程中的不確定性，經濟應急費用於應付通貨膨脹、價格或匯率等的波動。
風險進度預留
- 風險進度預留就是在關鍵路徑上設定一段時差或機動時間。當專案進行過程中出現了一些不利事件引起進度拖延時，專案管理者可以用這些機動時間或者時間差去補償進度的延遲，從而在總體上保證專案的整體進度。
- 可以通過壓縮關鍵路徑上活動的持續時間或者改變活動之間的關係來預留專案的進度，比如趕工法、快速跟進法等。
技術後備措施
- 技術後備措施專門用於應對專案的技術風險，它是預留的一段時間或一筆資金。只有當技術風險發生，並需要採取補救行動時，才動用這段時間或這筆資金。
風險應對示例
- 人員的頻繁流動是一項風險，基於過去的歷史和管理經驗，人員頻繁流動可能性的估計值為70%，會造成開發時間增加15%，總成本增加12%。對於這一風險，專案經理採取了以下風險應對策略：
- 與現有人員討論人員流動的原因。
- 專案啟動時，做好會出現人員流動的準備，採取一些技術以確保人員的一旦離開後，專案仍然能繼續。
- 建立良好的專案組織和通訊渠道，以使大家能夠了解每個有關的開發活動的資訊。
- 指定文件標準並建立相應的機制，以保證文件能夠及時建立。
- 對所有工作組織細緻的評審，使大多數人能夠按計劃進度完成自己的工作。
風險分析表
第六節 風險監控
實施和跟蹤風險管理計劃
確保風險策略正在合理使用
監視剩餘的風險和識別新的風險
收集可用於將來的風險分析資訊
風險監控
- 風險監控包括對風險發生的監控和對風險管理的監控。
- 對風險發生的監控是對已識別的風險源進行監督和控制，以便及早發現風險事件的徵兆，從而將風險事件消滅在萌芽中或採取緊急應急措施以儘量減小損失；
- 對風險管理的監控是在專案實施中監督人們認真執行風險管理的組織措施和技術措施，以消除風險發生的人為誘因。
風險預警
- 風險預警，是指對於專案管理過程中有可能出現的風險，採用超前或預先防範的管理方式，一旦有發生風險的徵兆，就及時發現併發出預警訊號，以便採取矯正行動，從而最大限度地控制不利後果的發生。
- 風險監控的一個良好開端和有效措施是建立一個預警系統，及時覺察計劃的偏離。
- 例如，計劃進度與實際進度之間的區別就是系統會探測到的一個偏差，可作為進度風險的預警。
- 另一個關於進度計劃的預警是活動浮動時間（詳見第4章）的減少，專案中浮動越少，風險產生影響的可能性就越大，因此活動的浮動時間越少，活動就越應該被關注。
- 預算與實際支出之間的差別是成本風險監控的預警。
- 通過風險預警，可從“救火式”風險監控向“消防式”風險監控發展，從注重風險應對向風險事前控制發展。
風險監控方法
- 常用的風險監控方法包括階段性評審與過程審查、風險再評估、掙值分析、技術績效衡量。
階段性評審與過程審查
- 階段性評審與過程審查是通過評審活動來評估、確認前一個階段的工作及其交付物，評價軟體過程的有效性，並提出補充修正措施，調整下一階段工作的內容和方法。
- 階段評審和過程審查可以讓風險的徵兆儘早被發現，從而可以儘早地預防和應對。
- 階段評審和過程審查可以有效地檢驗工作方法和工作成果，並通過一步步地確認和修正中間過程的結果來保證專案過程的工作質量和最終交付物的質量，從而大幅度地降低了軟體專案的風險。
風險再評估
- 風險監控過程通常要使用本章前面介紹的方法對已經評估的風險進行重新評估，檢查其優先次序、發生概率、影響範圍和程度等是否發生了變化，如果發生了變化，要考慮怎樣調整其應對措施。
- 應該安排定期進行專案風險再評估，每次重新評估的內容和詳細程度可根據軟體專案的具體情況而定。
掙值分析
- 掙值分析不僅可以用於風險識別，也可用於風險監控，因為掙值分析的結果反映了軟體專案在當前檢查點上的進度和成本等指標與專案計劃的差距。
- 如果存在偏差，則可以對原因和影響進行分析，這有助於對進度和成本風險進行監控。
技術績效衡量
- 該方法將專案執行期間的技術成果與專案計劃中預期的技術成果進行比較，如果出現偏差，則可能會導致風險發生。
- 例如在某里程碑處未實現計劃規定的功能，有可能意味著專案範圍的實現存在著風險。
風險管理案例分析
- 案例描述
在編制早期計劃書時，市場部李工不斷提出新的需求，而張工“來者不拒”，不停地更改專案計劃。
在工程的機房裝置平面設計中，張工組織人員自行設計，將大部分機架式的小型機集中擺放在一片較小區域內。
本期工程正式完全割接上線前，舊系統仍然需保持執行。保證系統穩定執行是專案團隊的第一要務，在系統割接期間，確保7天×24小時的業務連續平穩執行。
- 問題：該工程中有哪些風險？應採取怎樣的應對策略？
- 分析
在該專案中，專案經理張工對市場部李工不斷提出的新需求採取了“來者不拒”的態度，這是不恰當的，因為這會使專案計劃不斷變動，導致專案範圍無法確定，工期和成本不可控制，
團隊成員工作目標也不明確，因此出現了非常嚴重的需求風險。
為了應對這一風險，張工應該與李工積極地溝通和談判，使他明白工程的重要意義，並承諾工程不是交鑰匙專案，可為系統升級和擴容留有擴充套件介面，將來新的需求能夠通過後續工程逐步實現，從而使需求趨於穩定。
在工程的機房裝置平面設計中，將大部分機架式的小型機集中擺放在一片較小區域內，從表面上看，提高了機房平面空間的使用率，但是由於未充分考慮到裝置散熱因素，容易造成該區域
機器過熱而宕機。因此團隊的機房設計技術經驗不足給專案帶來了系統執行不穩定的風險。
可採取風險轉移策略來應對這一風險。張工可聘請具有通訊設計資質的專家來負責機房裝置平面設計，從機房空調、電源、佈線、承重、消防等各個方面進行詳細的勘察和設計，從而保證裝置執行的可靠性，實現工程設計風險的良性轉移。
在系統割接期間，新舊系統要順利交接，這給系統業務的7天×24小時連續平穩執行帶來了風險，
因此專案組必須制定詳盡可行的系統割接方案、新舊系統並執行方案和故障應急處理方案。
- 《軟體缺陷管理和度量系統》專案風險管理
本章小結
1.理解風險和風險管理的概念，瞭解風險分類。2.風險規劃：瞭解風險規劃的依據，理解風險管理計劃的作用，瞭解其內容。
3.風險識別：理解檢查表法、德爾菲方法，瞭解頭腦風暴法、SWOT分析法和其他方法。
4.風險評估：掌握風險概率和影響程度的定性評估方法和決策樹分析法，瞭解模擬分析法。
5.風險應對：理解迴避風險、轉移風險、減小風險、接受風險、風險預留的指導思想。
6.風險監控：理解風險預警、階段性評審與過程審查的作用，瞭解風險再評估、掙值分析、技術績效衡量在風險監控中的作用。