危機管理這種模式類似於救火模式，其特點是聽任軟體風險的發生，及至軟體風險給軟體專案開發造成麻煩後才著手進行處理。例如，針對小劉要離開軟體專案組這一風險，軟體專案負責人知道這一軟體風險，但是沒有采取任何措施。在小劉離開專案組一個月之後，軟體專案組的其它成員需要與小劉所負責的子系統模組進行整合和測試時，才發現相關程式碼還沒編寫。顯然，此時這一風險已經嚴重影響了軟體專案組其他人員的工作，並將使軟體專案的進度滯後。在這種情況，軟體專案負責人才採取相應的措施來處理風險（如抽調其他人員來接替小劉的工作）。失敗處理在這種模式中，專案組人員和負責人察覺到了潛在的風險，但聽任軟體風險的發生和演化，只是在風險發生之後才採取應對措施。例如，針對小劉要離開專案組這一風險，專案組沒有采取任何的措施。在小劉離開專案組的第二天，專案組決定抽調其他人員來接替小劉的工作，但是此時已經無法和小劉進行面對面的專案交接。顯然，無論是危機管理模式還是失敗處理模式，它們對於風險的處理都是非常消極的，因而在軟體專案實施過程中不主張採用這兩種風險管理模式。風險緩解在風險緩解模式中，專案組人員和負責人在軟體開發過程中有意識地識別各種軟體風險，並且針對這些軟體風險事先制定好風險發生後的補救措施，但是不做任何防範措施。也就是說，專案組人員和負責人預先識別和分析哪些不好事件可能會發生，等它發生，並制定好這些事件發生後的應對措施。例如，專案組成員和負責人已經知道小劉要離開專案組，但是沒有采取任何措施來防止這一事件的發生，聽任其發展，不過他們制定了相應的措施，一旦小劉離開專案組，小張來接替小劉的工作。顯然，與危機管理和失敗管理模式相比較，風險緩解模式在處理和應對軟體風險方面變的較為積極。風險預防風險預防模式將風險識別和風險防範作為軟體專案的一部分加以規劃和執行。專案組人員和負責人預先識別和分析哪些不好事件可能會發生，制定好了萬一發生的應對措施，同時採取措施防止它發生。例如，專案組人員和負責人知道小劉要離開專案組，一方面和和小劉商量能否等到專案完成之後再離開，另一方面制定了相應的措施，一旦小劉離開專案組，就由小張來接替小劉的工作。消滅根源在該模式中，專案組人員和負責人不僅要識別軟體開發過程中各種潛在的軟體風險，而且還要分析導致這些軟體風險發生的主要因素，並採取積極的措施消除軟體風險產生的根源。也就是說，專案組人員和負責人預先識別哪些不好事件可能會發生，制定好了萬一發生的應對措施，同時採取措施消除軟體風險根源，杜絕軟體風險的發生。例如，針對小劉要離開專案組這一風險，專案組人員和負責人制定了相應的措施，一旦小劉離開專案組，就由小張來接替小劉的工作。同時，透過和小劉的交流發現，導致小劉離開專案組的主要原因是小劉認為公司給他的薪水太低，與他的技術水平以及給公司和軟體專案組所做的貢獻不匹配。針對這一因素，公司和軟體專案組考慮給小劉增加薪水和補貼，以打消小劉離開軟體專案組的念頭。顯然，後三種風險管理模式對於軟體風險的處理更加積極，他們能更為有效地降低軟體風險給軟體專案實施所帶來的消極影響，因而在軟體專案管理中應加以提倡。