摘抄自：與熊共舞-軟件項目風險管理（Tom DeMarco、Timothy Lister著，熊節、馬姍姍 譯）
- 通過風險發現過程調查出項目面臨的風險。
- 確認軟件項目所有的核心風險都已經出現在你的調查結果中。
- 針對每項風險，完成下列”家庭作業“：
- 爲風險命名，並提供一個唯一的編號。
- 通過頭腦風暴找出這項風險的轉化指標----風險具現的所有徵兆中最早出現的那個。
- 估算風險一旦發生可能對成本和進度造成的影響。
- 估算風險具現的可能性。
- 計算風險的日程和預算暴露值。
- 判斷如果風險開始轉化，需要採取哪些應急措施。
- 判斷需要在風險轉化之前採取哪些緩解措施才能保證應急措施不至於失效。
- 將緩解措施列入項目的總體計劃。
- 將所有細節記入一個模板（如圖一）。
- 指出項目的致命風險，將它們列爲項目假定。執行風險移交儀式，將它們轉交給上級。
- 假設沒有任何風險具現，進行第一次日程估算。換句話說，估算的第一個步驟是要找出極小概率點N--第一個讓你不能有絕對把握地說“不可能在那天完成”的日期。與業界常見的做法不同，我們建議你將N點作爲進度規劃的輸入條件，而不是輸出結果。使用你的參數化估算工具，並將所有參數設置爲最樂觀的情況，就能夠得到N的值。
- 下載RISKOLOGY(http://www.systemsguild.com/riskology), 並將項目參數輸入主工作表，然後，輸入你所能找到的所有自定義因素（來自企業對過去項目的記錄數據）。儘可能的覆蓋模擬器中關於核心風險的業界數據，將它們替換爲來自你的環境的更可靠的數據。爲你要跟蹤的每項非核心風險創建自定義的工作表。最後，運行模擬器，使其繪出項目的風險曲線，曲線與水平軸的交點爲N.
- 從此時起，用風險圖來描述所有承諾，明確指出每項預計日期和預算所涉及的不確定性。客戶對於風險圖的概念通常知之甚少，但你不必費力向他們解釋，把他們解釋爲模擬器對項目進行500次模擬結果好了----這裏有所有可能的結果，以及每種結果的相對可能性。
- 創建一個工作細分結構，用於展示完成項目所需的所有任務，估算每項任務所需的工作量。我們將以一種略顯與衆不同的方式使用這些估算結果：只關心任務工作量的相對權重，而不考慮他們的絕對值。這些相對權重將作爲輸入條件，用於計算EVR（淨值運行）度量值。
- 在項目開始時，必須要求參與各方確定產品的淨輸入/淨輸出數據流。在整個項目日程安排的前12%~15%時間裏，你應該能夠得到所有淨輸入/淨輸出數據流的完整定義（精確到數據元素的級別）。項目各方簽字認可這些數據流，這應該被設爲一個重要的里程碑。如果沒有完成這個里程碑，切勿貿然進行後續的任務。請謹記：這項重要的工作--淨數據流的簽字認可--如果沒有完成，意味着項目有全軍覆沒的危險。
- 在實現任何功能之前，首先進行詳盡的設計劃分。將設計劃分的結果作爲輸入條件，創建增量式交付計劃。
- 設計劃分完成之後，回到工作細分結構，重新估算任務的權重，並以在剩下工作中所佔用的百分比的形式描述每項任務。
- 估算項目的價值，精度應該與成本估算的精度相當。
- 將項目規約中包含的需求細分到元素級別，按照各需求元素的優先級順序爲它們編號。在評定優先級時，對於用戶的淨價值和技術風險是兩個重要的因素。
- 創建增量式交付計劃，在其中將整個產品細分爲多個版本（版本應該足夠多，以保證至少每週發佈一個新版本）。所有需求元素都必須分配給某個版本，優先級越高的需求應該在越早的版本中實現。計劃每個版本的EVR（淨值運行），將結果記入增量式交付計劃。增量式交付計劃應該是項目的重要產品之一。
- 爲整個產品創建最終的總體驗收測試，然後將其分爲多個VAT(版本驗收測試)，每個版本都應該有一個對應的VAT.
- 根據各版本的預期交付日期爲它們分配EVR（淨值運行）。每當一個版本通過VAT時，在同一副圖中畫上實際的EVR（淨值運行）值。
- 從項目開始到結束，密切監視所有風險的具現情況或終止情況，一旦風險具現，立即執行應急措計劃。監視EVR（淨值運行）的滑行路線及其與預期路線的吻合度。如果實際路線與預期路線發生偏差，很可能是有風險出現了。
- 從項目開始到結束，持續進行風險發現過程，隨時發現後續出現的風險。
圖一：風險模板
