專案風險評估是在風險發生前，系統性分析其發生機率與潛在影響的過程。這篇文章帶你走過完整的四步驟實戰流程，從風險識別到回應策略選擇，讓你的專案不再被「意外」打亂節奏。
什麼是專案風險評估？與風險管理的關係
專案風險評估，是指在專案執行過程中，針對尚未發生的不確定事件，系統性地評估其發生機率與對專案目標的潛在影響。它是風險管理流程中的核心環節——但不是全部。
很多人會把「風險」和「問題」搞混。風險是未來可能發生的不確定事件，問題是已經發生、正在影響專案的事件。當你在週會上說「伺服器掛了」，那是問題；當你在專案啟動時說「促銷當天伺服器可能撐不住流量」，那才是風險。
風險管理的完整流程包含五個階段：識別、評估、優先排序、應對、監控。風險評估位於流程的第二和第三步，負責把識別出來的風險「量化」並「排序」，讓團隊知道該先處理哪些。
台灣中小型專案團隊最常見的誤區，是把「風險登記」等同於「風險評估」。PM 在專案啟動會議上列了一張風險清單，覺得任務完成了——但那只是識別，還沒有評估每個風險的嚴重程度，更沒有排出優先順序。
舉個真實情境：一家台灣電商公司在年度雙 11 促銷前，技術團隊列出了「系統可能無法承受流量」這個風險，但沒有進一步評估機率和影響——沒做壓力測試、沒估算流量峰值。結果當天系統崩潰 4 小時，損失超過 NT$500 萬營收。如果當初花兩天做完整的風險評估，這個損失完全可以避免。
5 種台灣專案最常見的風險類型
在進入評估流程之前，你需要先知道風險長什麼樣子。以下是我們在台灣專案中最常遇到的五種風險類型，每種都附上在地情境和早期預警訊號，讓你能立即對照自己的專案。
| 風險類型 | 常見情境 | 早期預警訊號 |
|---|---|---|
| 範疇蔓延風險 | 客戶在軟體開發中持續追加功能需求，設計專案反覆修改方向 | 需求變更單數量持續上升；每次會議都有「再加一個小功能」 |
| 資源風險 | 核心工程師離職、跨部門資源借調被拒、外包廠商人力不足 | 團隊成員開始頻繁請假或抱怨工作量；關鍵人員更新履歷 |
| 時程風險 | 供應商交貨延遲、政府標案法規審查時間不確定、第三方 API 整合卡關 | 里程碑完成率低於 80%；上游交付物持續延遲 |
| 預算風險 | 進口設備因匯率波動漲價、原物料成本上升、追加需求導致工時超支 | 實際花費超過預算 10% 以上；採購單價持續上調 |
| 技術風險 | 新技術導入學習曲線過長、系統整合失敗、資料遷移出錯 | 技術 POC 進度落後；開發團隊頻繁反映「比預期複雜」 |
範疇蔓延風險在台灣軟體開發專案中特別高發。我們團隊曾經手一個電商後台改版專案，客戶在開發中期追加了 12 項原本不在範疇內的功能，導致時程延後 6 週。如果你發現每次會議都有人說「順便加一個」，那就是範疇蔓延的早期訊號。
資源風險是台灣中小企業的痛點。團隊規模小，一個人離職可能影響整個專案。特別是在農曆年前後，人員異動率最高，這段時間的專案更需要提前做好資源風險評估。
把這五種風險類型當作檢查清單，在每次風險識別時逐一掃過，能大幅降低遺漏的機率。如果你的團隊還在用紙本或口頭方式追蹤這些風險，建議先用流程圖把風險識別流程視覺化，再搭配數位工具管理。
專案風險評估的最佳時機
風險評估不是「專案啟動時做一次就好」。這是我們見過最多團隊犯的錯——在 Kickoff 會議上花了兩小時做風險評估，然後那份文件就再也沒人打開過。
風險是動態的。專案進行到一半，原本低機率的風險可能因為環境變化變成高機率。以下是五個你應該觸發風險評估的關鍵時間點：
1. 專案章程核准後、正式啟動前 這是最基本的時間點。在專案正式開跑前，團隊應該完成第一輪完整的風險識別與評估。這份初始風險登記表會成為後續所有更新的基準線。撰寫企劃書時就應該把風險評估納入其中一個章節。
2. 每個里程碑完成後 Sprint Review、階段審查、或任何重要交付完成後，都應該重新檢視風險清單。有些風險可能已經過期（不再適用），有些新風險可能浮現。
3. 重大範疇變更發生時 當客戶要求追加功能、專案目標調整、或交付範圍改變時，必須立即重新評估。範疇變了，風險圖譜一定跟著變。
4. 關鍵資源異動時 核心成員離職、預算被削減、關鍵供應商更換——這些都是觸發風險重新評估的訊號。
5. 外部環境重大變化時 法規修訂、市場劇變、技術標準更新。這類風險通常超出專案團隊的控制範圍，但影響可能很大。
舉個實際案例：一個政府 IT 標案團隊在專案中期完成第二個里程碑後，按照慣例做了風險重新評估。在這次評估中，他們發現一項即將生效的個資法修訂條文會影響系統的資料處理架構。因為及時發現，團隊有三個月的緩衝時間調整交付範圍，避免了驗收不過的風險。如果他們只在啟動時做過一次評估，這個法規變化很可能到驗收前才被發現。
專案風險評估四步驟實戰流程
這是整篇文章的核心。以下四個步驟是我們團隊實際在用的風險評估框架，適用於 3 人小組到 50 人大型專案。
步驟一：風險識別——找出所有潛在威脅
風險識別的目標很簡單：盡可能找出所有可能影響專案的不確定事件。遺漏比誤判更危險——你無法評估一個你不知道存在的風險。
我們團隊常用的三種識別技法：
腦力激盪工作坊：把專案團隊、利害關係人、甚至客戶代表聚在一起，用 30-60 分鐘自由列舉所有想得到的風險。重點是「不批判」——任何人提出的風險都先記下來，分析留到下一步。我們通常會用 Miro 的白板功能來做線上腦力激盪，每個人用便利貼同時寫，避免團體迷思。
專家訪談：找有類似專案經驗的人一對一聊。問他們「上次做這種專案，最讓你意外的是什麼？」這個問題比「你覺得有什麼風險」更能挖出真正的洞見。
歷史專案覆盤（Lessons Learned）：翻出過去類似專案的結案報告，看看當時遇到了哪些問題。這些問題在新專案中很可能再次出現。
識別完成後，建議用 RAID 日誌來整理。RAID 代表 Risks（風險）、Assumptions（假設）、Issues（問題）、Dependencies（相依性）。把識別出來的項目分類放進這四個欄位，能幫你看清全貌。
一家台灣製造業在導入 ERP 系統時，用 RAID 日誌在啟動前識別出 23 個潛在風險，其中包括「現有資料格式不一致導致遷移失敗」和「工廠端使用者抗拒新系統」。這兩個風險後來都被證實是高影響項目，但因為提前識別，團隊有足夠時間準備應對方案。
步驟二：風險分析——量化機率與影響
識別出風險後，下一步是分析每個風險的「發生機率」和「對專案的影響程度」。這一步的目的是把模糊的擔憂轉化為可比較的數據。
定性分析：5×5 風險矩陣
對台灣大多數中小型專案來說，定性分析就夠用了。方法很直觀：用 1-5 分分別評估每個風險的機率和影響。
機率評分標準：
- 1 分（極低）：幾乎不可能發生（< 5%）
- 2 分（低）：不太可能，但有可能（5-20%）
- 3 分（中）：有合理的可能性（20-50%）
- 4 分（高）：很可能發生（50-80%）
- 5 分（極高）：幾乎確定會發生（> 80%）
影響評分標準：
- 1 分（極低）：對時程、預算、品質的影響可忽略
- 2 分（低）：輕微影響，不需要調整計劃
- 3 分（中）：需要調整部分計劃，但不影響整體目標
- 4 分（高）：嚴重影響，需要重新規劃部分交付
- 5 分（極高）：可能導致專案失敗或重大目標無法達成
定量分析：蒙地卡羅模擬
如果你的專案規模大（預算超過 NT$5,000 萬、團隊超過 30 人），可以考慮用蒙地卡羅模擬來做定量分析。這個方法透過數千次隨機模擬，計算出專案在不同風險情境下的時程和成本分布。常用工具如 @RISK（Palisade 出品的 Excel 外掛），能直接在試算表中建模並產出機率分布圖。不過對大多數台灣中小型專案來說，定性分析的 5×5 矩陣已經足夠，不需要為了「看起來專業」而過度複雜化。
這個步驟的關鍵是：評分要由團隊共同討論決定，不是 PM 一個人拍腦袋。不同角色對同一個風險的認知可能差很大——工程師覺得「技術整合失敗」機率很高，但 PM 可能低估了這個風險。透過討論取得共識，評分才有意義。
步驟三：風險優先排序——聚焦高影響項目
有了機率和影響的評分後，計算風險分數：風險分數 = 機率分數 × 影響分數。
分數範圍是 1-25 分。我們團隊的分類標準：
- 高優先（15-25 分）：立即處理，必須制定應對策略並指派負責人
- 中優先（8-14 分）：持續監控，準備應對方案但不一定立即執行
- 低優先（1-7 分）：接受風險，定期檢視即可
排序的目的是讓團隊把有限的精力集中在真正重要的風險上。一個專案可能識別出 30 個風險，但通常只有 5-8 個是高優先的。如果你試圖同時處理所有風險，結果就是一個都處理不好。
這跟艾森豪矩陣的邏輯一樣——先處理重要且緊急的，再處理重要但不緊急的。
一個 10 人軟體開發團隊的做法值得參考：他們用 Google Sheets 建立風險矩陣，每週 Sprint Review 時花 15 分鐘更新。PM 在表格中設定了條件格式——分數 15 以上自動標紅，8-14 標黃，7 以下標綠。這樣一眼就能看出哪些風險需要立即關注。整個流程不到 15 分鐘，但讓團隊對風險狀態始終保持清晰的認知。
步驟四：建立風險登記表（Risk Register）
風險登記表是風險評估的最終產出，也是後續監控的基礎。它不是一份「寫完就歸檔」的文件，而是一份需要持續更新的活文件。
風險登記表的 9 個必備欄位：
| 欄位 | 說明 | 範例 |
|---|---|---|
| 風險編號 | 唯一識別碼 | R-001 |
| 風險描述 | 具體描述風險事件 | 主要供應商因產能不足延遲交貨 |
| 風險類別 | 對應五大類型 | 時程風險 |
| 機率分數 | 1-5 分 | 4 |
| 影響分數 | 1-5 分 | 5 |
| 風險分數 | 機率 × 影響 | 20（高優先） |
| 觸發條件 | 什麼情況發生時啟動應對策略 | 供應商延遲超過 3 天 |
| 負責人 | 誰負責監控與應對 | 採購經理 王小明 |
| 應對策略 | 選擇的回應方式 | 減輕：提前 2 個月下單 + 備用供應商 |
| 狀態 | 目前狀態 | 監控中 |
「觸發條件」這個欄位非常關鍵——它定義了「什麼時候該從監控切換到行動」。沒有觸發條件，團隊只知道風險存在，卻不知道什麼時候該啟動應對策略。觸發條件的寫法要具體可觀測，例如「供應商延遲超過 3 天」比「供應商可能延遲」有用得多。這個欄位也會直接對應到後續持續監控章節中的自動化規則設定。
讓風險登記表成為「活文件」的三個關鍵做法：
- 指定更新頻率：至少每週一次，高風險專案每天更新
- 綁定會議議程：把「風險登記表更新」列為週會固定議程，不是「有空再看」
- 設定負責人：每個風險都有明確的負責人，不是「大家一起負責」（等於沒人負責）
實務上，你可以用 monday.com 的看板功能來建立風險登記表。我們團隊的做法是在 monday.com 上建一個「風險追蹤」看板，每個風險是一個項目，用狀態欄位標示優先等級，用自動化規則設定「當風險分數 ≥ 15 時自動通知 PM」。這比 Google Sheets 多了自動化和通知功能，特別適合 5 人以上的團隊。免費方案不需要信用卡，可以先試用看看是否符合需求。
風險回應策略：5 種應對方式與選擇邏輯
評估完風險、排好優先順序後，接下來要決定「怎麼應對」。PMI PMBOK 定義了五種風險回應策略，每種適用不同情境。
| 策略 | 適用情境 | 台灣案例 | 優點 | 缺點 |
|---|---|---|---|---|
| 迴避（Avoid） | 高機率 × 高影響，且可改變計劃 | 放棄使用未經驗證的新技術，改用成熟方案 | 徹底消除風險 | 可能犧牲創新或效率 |
| 轉移（Transfer） | 風險影響大，但可由第三方承擔 | 工程專案投保營造綜合險；SLA 合約約定供應商賠償條款 | 降低自身損失 | 有成本（保費、合約費用） |
| 減輕（Mitigate） | 最常用，適用大多數中高風險 | 提前招募備用人力；增加測試輪次降低技術風險 | 靈活性高 | 需要額外資源投入 |
| 接受（Accept） | 低風險，或無法改變的風險 | 接受匯率小幅波動的影響，不做避險 | 不消耗額外資源 | 風險發生時可能措手不及 |
| 升級（Escalate） | 超出專案範疇的組織層級風險 | 公司層級的法規合規風險，上報給法務部門處理 | 讓對的人處理對的問題 | 需要組織有明確的升級機制 |
接受策略有兩種形態需要區分：
- 主動接受：知道風險存在，並準備了應變計劃（Contingency Plan）。例如：「如果供應商延遲超過一週，啟動備用供應商」
- 被動接受：知道風險存在，但不做任何準備。這通常只適用於風險分數極低（1-4 分）的項目
升級策略是很多台灣團隊忽略的。當風險超出專案經理的權限範圍——例如涉及公司層級的法規合規、組織架構調整、或跨部門資源分配——應該上報給更高層級處理，而不是硬扛。這不是推卸責任，是讓對的人處理對的問題。培養這種判斷力，也是領導力的一部分。
如何選擇正確的回應策略？
選擇策略不是憑直覺，而是有判斷邏輯的。以下是我們團隊使用的決策框架：
舉個實際案例：一個行銷活動專案面對「關鍵 KOL 臨時取消合作」的風險（機率 3 分、影響 5 分、風險分數 15 分）。團隊選擇了組合策略：
- 轉移：在合約中加入違約金條款，降低財務損失
- 減輕：提前簽約 2 位備用 KOL，確保活動不會因一人取消而停擺
這種組合策略在實務中很常見。不一定只能選一種，關鍵是每種策略都要有明確的負責人和執行時間。
風險評估工具與範本推薦
工具的選擇取決於你的團隊規模和專案複雜度。以下是我們實際測試過的工具，按適用場景分類。
免費工具（適合小型團隊）
Google Sheets：最低門檻的選擇。用條件格式設定風險分數的顏色標示，加上資料驗證功能限制評分範圍（1-5），就能建出堪用的風險登記表。適合 5 人以下、專案數量少的團隊。
Notion：如果你的團隊已經在用 Notion 做專案追蹤，可以直接在同一個 workspace 建立風險資料庫。用資料庫的「看板視圖」按風險等級分欄，用「時間軸視圖」對照專案里程碑，遠端團隊特別好用。
Miro：最適合做風險識別階段的腦力激盪工作坊。用 Miro 的線上白板讓團隊同時貼便利貼，再用投票功能做初步的優先排序。我們團隊在遠端工作時，幾乎每次風險識別都用 Miro。
專業專案管理工具（含風險模組）
| 工具 | 適用規模 | 風險管理功能 | 起始價格 | 免費方案 |
|---|---|---|---|---|
| monday.com | 5-200 人 | 風險看板、自動化通知、儀表板視覺化、自訂欄位 | NT$390/人/月 | ✅ 最多 2 人 |
| ClickUp | 3-100 人 | 自訂狀態、優先等級標籤、時間追蹤、多視圖切換 | NT$230/人/月 | ✅ 功能限制版 |
| Notion | 1-50 人 | 資料庫、看板、時間軸、關聯資料表 | NT$270/人/月 | ✅ 個人免費 |
| 開始使用 | 免費試用 → | 免費試用 → | 免費試用 → | — |
你是哪種團隊？
- 5 人以下、剛開始接觸風險管理 → 先用 Google Sheets 或 Notion 免費版建立基本的風險登記表
- 5-15 人跨部門協作 → monday.com 是我們的首選，自動化通知功能在風險監控上特別實用
- 技術團隊跑 Scrum → ClickUp 的 Sprint 整合讓風險追蹤和開發流程無縫銜接
- 15 人以上的大型專案 → monday.com 企業方案，搭配儀表板做跨專案風險匯總
可直接使用的範本清單
以下四種範本涵蓋了風險評估的完整需求：
- 風險評估表（5×5 矩陣版）：適合所有專案規模，用於步驟二的機率與影響分析
- 風險登記表（含 9 個必備欄位）：適合 5 人以上團隊，用於步驟四的持續追蹤
- RAID 日誌範本：適合專案啟動階段，用於步驟一的全面識別
- 風險管理計畫範本：適合大型專案或政府標案，包含完整的風險管理策略與監控機制
這些範本在 Google Sheets 中都能建立。如果你的團隊已經在用 monday.com，可以直接用內建的專案模板，省去從零建立的時間。
持續監控：讓風險評估成為團隊習慣
做完一次風險評估只是起點。風險會隨專案進展動態變化——上個月的低風險可能因為一個人離職變成高風險；原本的高風險可能因為應對策略生效而降級。
「一次性評估」的最大陷阱是：團隊以為風險已經被「處理」了，於是放鬆警覺。但風險管理不是一個事件，是一個持續的過程。
建立風險監控節奏的 3 個實務做法
1. 每週站會加入「風險更新」固定議程（5 分鐘）
不需要長篇大論。每週站會最後 5 分鐘，PM 快速掃一遍高優先風險：「R-003 的狀態有變化嗎？」「上週新增了什麼風險？」這 5 分鐘的投資，能讓團隊對風險狀態保持即時的共識。
2. 每個里程碑做一次完整風險重新評估
里程碑完成意味著專案進入新階段，風險圖譜也會跟著改變。花 30-60 分鐘重新走一遍四步驟流程：有沒有新風險？現有風險的機率和影響有沒有變？應對策略是否需要調整？
3. 設定風險觸發條件（Trigger）
這就是風險登記表中「觸發條件」欄位發揮作用的地方。預先定義「當 X 發生時，自動升級為高優先風險」。例如：
- 當預算消耗率超過計劃的 120% → 預算風險自動升級
- 當核心成員提出離職 → 資源風險自動升級
- 當供應商延遲超過 3 天 → 時程風險自動升級
在 monday.com 中可以用自動化規則來實現這個功能：設定條件「當某欄位值超過閾值時，自動變更狀態並通知 PM」。我們團隊設定了一條規則：當任務延遲超過 2 天，自動通知負責人和 PM。這個設定在 6 個月內觸發了 23 次，每次都讓問題在擴大前被處理——以前要到週會才發現。
風險管理 KPI：如何衡量成效
如何知道你的風險管理是否有效？以下三個 KPI 可以量化衡量：
- 風險緩解率：已識別風險中被成功緩解的比例。目標值：> 70%
- 未預期問題比例：實際發生的問題中，有多少是事先未識別的風險。目標值：< 30%
- 應對行動完成率：已制定的應對策略中，按時執行完成的比例。目標值：> 85%
一個 15 人的產品開發團隊在導入這套監控機制後，每週 Sprint Review 花 10 分鐘更新風險登記表。三個月後，未預期問題從原本佔總問題的 60% 降到 20%——減少了將近 40%。這代表團隊的風險識別能力大幅提升，越來越少被「意外」打到。
持續的風險監控需要團隊養成習慣，而習慣的養成需要降低摩擦力。如果更新風險登記表需要打開三個不同的工具、填五張表單，沒有人會持續做。選一個團隊已經在用的工具，把風險追蹤整合進現有的工作流程，才是長久之計。想提升團隊的專注力和執行效率，也可以參考心流狀態的概念，幫助成員在風險監控任務中保持高效。
結論
專案風險評估不是一份「做完就歸檔」的文件，而是一套持續運作的管理機制。回顧本文的核心重點：
- 風險評估是風險管理的核心環節，負責把模糊的擔憂轉化為可量化、可排序的數據
- 五種常見風險類型（範疇蔓延、資源、時程、預算、技術）是你的識別檢查清單，搭配早期預警訊號能提前發現問題
- 四步驟實戰流程（識別→分析→排序→登記）是可立即套用的框架，5×5 風險矩陣對大多數台灣中小型專案已經足夠
- 五種回應策略（迴避、轉移、減輕、接受、升級）搭配決策樹使用，能幫你快速選出最適合的應對方式
- 持續監控才是風險管理成功的關鍵——每週 5 分鐘更新、里程碑完整重評、觸發條件自動升級
你的下一步行動：
- 用本文的 5×5 矩陣和 9 欄位風險登記表格式，為你目前的專案建立第一份風險評估
- 在下一次週會中加入 5 分鐘的「風險更新」議程
- 選一個適合你團隊規模的工具來管理風險——如果你還沒有專案管理工具，建議從 monday.com 的免費方案開始，用「專案追蹤模板」建立風險看板並設定自動化通知規則
（推薦試試 monday.com 的免費方案，不需要信用卡，我們團隊實際使用後風險追蹤效率提升明顯）
專案風險評估常見問題
風險評估表應該包含哪些欄位？
一份完整的風險評估表至少需要 9 個欄位：風險編號、風險描述、風險類別、機率分數（1-5）、影響分數（1-5）、風險分數（機率 × 影響）、觸發條件、負責人、應對策略、狀態。其中「觸發條件」欄位定義了何時該啟動應對策略，是連結風險評估與持續監控的關鍵。如果專案規模較大，可以再加上「預計應對時間」欄位，方便追蹤應對行動的時效性。
專案風險應該多久重新評估一次？
至少每個里程碑完成後做一次完整的重新評估。高風險專案（風險分數 15 分以上的項目超過 3 個）建議每週更新。日常監控可以在每週站會中用 5 分鐘快速掃過高優先風險的狀態變化。
小型團隊（5 人以下）也需要正式的風險評估嗎？
需要，但可以大幅簡化。一張 Google Sheets 風險登記表 + 每週 10 分鐘的更新就足夠。重點不是格式多完整，而是團隊有沒有「主動思考風險」的習慣。即使只列出 5 個風險並排好優先順序，都比完全不做好得多。
風險管理四大原則是什麼？
風險管理的四大核心原則是：識別（找出潛在風險）、評估（分析機率與影響）、應對（選擇回應策略）、監控（持續追蹤與更新）。這四個原則構成了一個循環——監控過程中可能識別出新風險，重新啟動整個流程。如果你想更系統性地學習專案管理的完整框架，建議從企劃書的撰寫開始，把風險評估納入專案規劃的標準流程中。
