簡短回答： 專案開始前，可假設計劃未能達成目標，讓成員先獨立寫下可能原因，再選出值得驗證的薄弱點，指定預防、監察和應變工作。失敗推演用來改善準備，不能當成找出誰會犯錯的遊戲。
先界定要保護的目標
說明專案需達成甚麼、何時完成、哪些結果不能接受，並提供目前已知資料。若連成功條件都不清楚，成員寫出的專案風險便很難比較。主持人可用中性問題開場：「假設交付未能使用，有哪些條件可能造成這個結果？」
英國財政部的風險管理指引把風險管理連繫到目標、假設及不確定性。以下失敗推演是編輯整理的工作練習，不是能準確預測事故或保證成功的測驗。
先各自寫，再共同整理
讓不同職能先按自己接觸的資訊列出原因，避免第一位發言者決定全場方向。每項描述包括條件、可能事件及影響，例如「若供應資料延遲，測試無法完成」，而不是「某組一定拖延」。主管也應參與，但可以較後分享自己的推測。
假設情境：團隊準備推出新服務，有人擔心宣傳無效，有人指出客戶登入根本未完成測試。兩者都可保留，再比較會阻礙哪個目標、是否已有證據，以及現在能做甚麼。涉及標準分歧，可參閱討論不同工作標準。
從長清單選出值得驗證的薄弱點
合併同一原因的不同描述，分清已發生問題與仍是假設的風險。對未知之處明說不知道，毋須硬填精準機率。先處理後果大、依賴多、目前資訊不足且仍有時間改變的項目；正式安全與合規風險仍按專業程序評估。
每項選中的風險安排一個下一步：取得供應確認、安排代表性測試、準備替代入口，或指定觀察訊號。可參閱共同活動的例外情境演練，把想像接回實際操作。
如何避免被視為唱反調？
主持人應先確認提出疑慮的工作價值，再問可驗證依據，不要求發言者一併包辦解決。對方沒有完整方案，也可能提供了重要現場資訊；但只有籠統悲觀時，可以請他描述具體條件。
結束時留下風險、負責人、驗證日期及仍未處理的限制。之後按新資訊更新團隊判斷，別把事前清單當成已完成風險管理，更不要事後拿來責怪「早知道還會出錯」的人。
