這個頁面
為什麼大多數專案在開始前就已失敗
事後回顧時,專案失敗很少令人意外。根本原因幾乎總是已經出現在原始計畫中 - 或是根本沒有計畫。只有日期而沒有範疇聲明的任務清單。在了解相依關係之前便建立的時程。團隊分散承擔權責,卻沒有 RACI 將其明確化。曾在啟動會議中討論過一次、之後再也沒有記錄下來的風險。這些不是執行失敗,而是規劃失敗,最後只能由執行來承擔。
針對專案失敗的研究一再指出相同原因:不明確的範疇讓需求得以無限擴張;未理解完整工作內容便制定不切實際的時程;權責不明造成缺口與重複;以及原本可以預見卻未採取緩解措施的風險。這些都是規劃問題,而非執行問題 - 只要在開始時套用正確的框架,每一項都可以預防。
Paul - KissMySkills 的專案管理 agent - 會在一次資訊蒐集工作階段中套用這套框架。輸出內容是一份完整的專案計畫,建立於資深專案經理所採用的方法論之上:包含明確排除項目的範疇聲明、工作分解結構、位於關鍵路徑上的里程碑時程、RACI 矩陣、附有緩解措施的風險登錄表,以及利害關係人溝通計畫。在專案開始時建立,早於任何單一任務啟動之前。
Paul 會建立範疇聲明、工作分解結構、RACI 矩陣、關鍵路徑時程及風險登錄表 - 一次工作階段完成完整的專案計畫。
查看 Paul →完整的專案計畫實際包含哪些內容
大多數稱為「專案計畫」的文件,其實只是附有日期、頂端寫著一個名稱的任務清單。完整的專案計畫包含六個部分,而任務清單式做法會省略這些部分 - 每個部分都針對不同的失敗模式。
一份範疇聲明,定義哪些內容屬於範疇內,同樣重要的是,明確定義哪些內容不在範疇內。若沒有明確的排除項目,範疇就會在利害關係人要求的推動下,不斷擴張到填滿可用的時間與預算;這些要求個別看來都合理,合在一起卻會摧毀時程。
一個工作分解結構,將專案交付成果拆解為工作流,再進一步拆解為任務,直到每項工作都完成指派並估算規模。WBS 是用來揭示那些總是被低估的工作,因為它們存在於主要里程碑之間 - 整合測試、簽核流程、文件製作、培訓及轉換活動。
一份根據關鍵路徑建立的里程碑時間表 - 關鍵路徑是任何延遲都會推遲專案結束日期的任務序列。大多數專案時間表都是從期望的結束日期倒推建立,卻沒有辨識出工作流程中真正關鍵的路徑。非關鍵任務延遲時,這是一個問題;關鍵路徑任務延遲時,整個專案都會延遲。
一份RACI 矩陣,為每項重要交付成果指派負責執行、當責、諮詢和知會角色。這項工具會在執行開始前明確劃分責任,而不是到了第四週才發現兩個人都以為對方負責某項沒有人完成的交付成果。
一份風險登錄表,記錄已識別的風險、評估其發生可能性和影響、指派緩解行動,並為整個專案期間每項風險的監控指定負責人。
一份利害關係人溝通計畫,明確規定誰以何種頻率收到哪些更新 - 確保利害關係人永遠不會對專案狀態感到意外,而專案經理也永遠不會在重要會議前措手不及,沒有準備好的更新內容。
先定義範疇,再排定時間表:專案管理中最常被違反的規則
在沒有明確範疇的情況下建立的時間表,不是真正的時間表 - 而是帶有虛假精確度的估算。專案錯過截止期限最常見的原因,不是團隊執行不力,而是時間表在完整了解範疇之前建立,或在確認所有相依性之前建立,或在有人提出那些能揭示初始需求中未出現工作內容的問題之前建立。
Paul 在建立任何時間表之前,會先詢問交付成果、相依性、限制條件和明確排除項目。範疇說明是第一項產出 - 在設定任何里程碑日期之前,先確認並取得共識。範疇蔓延在發生之前,遠比開始之後再管理容易預防,而範疇說明中的明確排除項目,讓專案經理在收到新要求時有權說「那不在範疇內」。如果沒有記錄排除項目,每次「聽起來很簡單,我們可以加上嗎」的對話都會變成一場協商。
RACI:防止責任分散的工具
責任分散是專案管理中旁觀者效應的對應現象:當多個人都與某項交付成果有關,卻沒有明確的負責人時,每個人都會以為其他人正在處理。結果是,這項交付成果在成為所有人的問題之前,沒有人把它當成自己的問題 - 直到問題被晚發現、倉促處理,並歸咎於團隊。
RACI 矩陣會在執行開始前明確界定責任歸屬,從而避免這種情況。Responsible 是實際執行工作的人。Accountable 是對結果負責的唯一指定人員 - 只能有一人。Consulted 是需要提供意見的人員。Informed 是需要了解狀態的人員。Paul 會為專案每個工作流中的每項重要交付成果建立 RACI,涵蓋所有擔任角色的利害關係人。
RACI 的設計目的是在專案啟動會議中逐項討論 - 不是寄出文件供非同步審閱,而是由團隊共同討論,讓每個人確認自己的角色、了解自身的責任,並在專案開始前有機會提出疑慮。在啟動會議發現的 RACI 衝突只需五分鐘即可解決。在專案進行中才發現的衝突則需要數週。
在風險實際發生前建立風險登錄表
建立風險登錄表的最佳時機是在專案啟動時,此時團隊的注意力著眼於未來,選項也仍然開放。開端識別出的風險可以獲得緩解。在風險已經實際發生時才識別,只能進行管理 - 選項更少、成本更高,對時程的影響也更糟。
Paul 會產出風險登錄表,其中包含已識別的風險、可能性與影響評級(高/中/低)、每項風險的具體緩解措施,以及負責在整個專案生命週期中監控每項風險的指定負責人。識別出的風險包括明顯風險 - 關鍵資源的可用性、第三方相依性延遲 - 以及根據經驗,這類專案最常見的類別特定風險。
已陷入困境的專案
Paul 也能診斷並挽救陷入困境的專案 - 不只是規劃新專案。對於進度落後、超出預算,或遭受範圍失控擴張的專案,初始問題會找出根本原因:原始範圍不明確、不切實際的時間表、責任歸屬模糊,或未制定緩解計畫便已發生的風險。復原計畫會處理實際原因,而不只是壓縮剩餘時程 - 因為對根本有缺陷的計畫進行時程壓縮,只會產生同一失敗的另一種版本。
如何開始使用 Paul 進行專案規劃工作階段
將 Paul 技能檔案載入 Claude Projects。貼上啟用 prompt。Paul 會詢問有關專案的初始問題:目標、交付成果、截止期限、團隊組成、已知相依性和限制。請具體回答 - 提供的實際專案細節越多,計畫就越精準。完整工作階段會在 30 分鐘內產出完整的專案計畫。Paul 可與 Claude、ChatGPT,或任何接受系統 prompt 的 AI 聊天工具搭配使用。