摘抄自：與熊共舞-軟件項目風險管理（Tom DeMarco、Timothy Lister著，熊節、馬姍姍 譯）
一般來說，這三個步驟應該在同一次會議上進行。但是，每個步驟的技巧是獨立的，所以值得挨個詳細的介紹它們：
- 災難頭腦風暴（指有計劃的集體想象活動）：
- #記錄所有的意見，一定不要讓主持人來負責記錄，因爲風暴是猛烈而且迅速的，必須認真記錄。
- 以噩夢的形式指明問題：這種做法在某種程度上也有助於消除不成文的規定的影響。詢問所有人，對於這個項目，他們最擔心的是什麼。如果他們會滿頭大汗的從夢中驚醒，夢中的情景會是什麼？
- 使用水晶球：如果突然你在能預見未來的水晶球中看到了項目的失敗，或者看到你的項目在未來成爲最白癡的項目，問問自己：怎麼會變成這樣那，是什麼導致的項目失敗？
- 轉化角度：請大家描述他們對項目最美好的夢想，然後將這些美夢全都反過來，然後大家討論“是什麼讓美夢不能成真”，
- 尋找不能被責備的災難：如果沒有誰做錯事情，項目因爲什麼而失敗？
- 尋找應該被責備的失敗：詢問每一個人，“項目會因爲什麼而變得面目全非？”。那些可能的原因是我們的責任？那些是用戶的責任？那些是管理層的責任？那些是你本人的責任？（只有當所有人都在場，這一花招纔有效。）
- 設想部分失敗：考慮是否有這種可能：項目整體上獲得成功，但是某一方特別不滿甚至是憤怒。
- 情景構造：
- 面對每個災難，想想它可能在那種或者哪幾種情況下出現。
- 有必要--至少是試探性地--估算每種情景出現的可能性。顯然，出現可能性極小的情景沒有什麼價值。但是對於被發現爲可能性很低的情景，仍然需要保持警惕：既然有人提出來，那麼它--至少對於提出它的人來說--或許並不是微不足道的。
- 可以不必再會議上進行，而是由一小組人在稍後進行，這樣可以更多的參考經驗數據，以判斷某個情景是否值得擔心。
- 根源分析：
- 現在，可能引發災難的情景已經擺在你們面前，大家可以一起來找出誘發這些情景的根源了。當這些情景還沒有真正出現時，這項工作會容易的多。如果所有這些情景都還只是想像--只是一些可能發生的蠢事--人們就可以大膽地推想他們的原因，並毫不顧忌地用指責的語氣說：“我無法想像這種事情發生，除非是哪個白癡在到處放火”，如果災難還沒有發生，這些話會比較容易說出口---哪怕可能成爲白癡的人也在同一個房間裏。
- 對於可能引發災難性後果的情景，它們的根源就是你需要管理的風險。
- 根據分析並不像乍看上去那麼輕鬆。這不僅因爲不成文規定的影響，更因爲“根源”本來就是一個複雜的概念（到哪裏纔算是找到根源了？）。這個過程最好是由一組人一起進行。
雙贏的選擇：
- 按照雙贏理論，項目應該預先找出所有參與者，並要求每個參與者描述所謂的“贏狀態”--在他/她看來項目成功的標誌。在這種方法論中，項目的需求是以一系列的“贏狀態”來描述的。如果一件事沒有成功爲任何人“贏狀態”的一部分，它就不是一向需求。有時--特別是在參與者較多時候--“贏狀態”之間會有所衝突，一方的“贏狀態”可能給別人的“贏狀態”帶來了困難，甚至使後者根本無法實現。按照雙贏理論，一對彼此衝突或彼此鉗制的“贏狀態”就代表一項風險。利用這個技巧，你也許會發現用其他方法發現不了的風險。