林佳熹 | 專案筆記 | AI

【新手PM必懂】專案鐵三角與專案基線，到底差在哪？ 【新手PM必懂】專案鐵三角與專案基線，到底差在哪？ 作者:林佳熹 | 發布日期:2026年8月10日 簡單說: 鐵三角是一種 思維 ，在開案前想「這個專案該怎麼權衡」時最有用。基線則是一個 工具/標準 ，一旦 kick off 之後開始執行，就是靠它幫全部人對焦、確認有沒有走偏。一個用在「想」的階段，一個用在「做」的階段，時間點不一樣，用法也不一樣。 新手PM最常卡住的兩個詞 如果你剛入門專案管理，考證照或看書的時候，一定會同時遇到「鐵三角」跟「基線」這兩個詞。更麻煩的是，這兩個詞剛好都圍繞著同樣三個東西：範疇、時間、成本。於是很多新手看完書，腦子裡只留下一團模糊的印象： 好像都是在講範疇時間成本，那到底差在哪？ 這個困惑很正常，因為這兩個概念確實高度相關，但 它們回答的是完全不同的問題 。搞懂這個差異，不只是應付考試，更會直接影響你日後在職場上，怎麼處理變更、怎麼跟老闆報告進度。 先講鐵三角:開案前，幫你想清楚怎麼權衡的思維 專案鐵三角（Iron Triangle），講的是 範疇（Scope）、時間（Time）、成本（Cost）三者之間互相牽制的關係 。這三個角，中間常常會加上「品質」放在三角形正中間，代表品質是這三者互動下的結果。 這個工具最有用的時機，是在 專案還沒開始、你在跟老闆或客戶討論「這個專案到底做不做得到」的階段 。老闆想要範疇加大（多做一個功能），如果時間不能延，那就得加錢加人；如果錢不能加，那就得延長時間。鐵三角本身 沒有具體數字 ，它是一個幫你在開案前想清楚「這個提案合不合理、要拿什麼去換什麼」的思考架構。 要補充一點： 鐵三角不是開案前用完就收起來的工具。 執行階段一旦有人提出變更需求，你還是會用鐵三角的邏輯去判斷「這個變更會牽動時間還是成本」，只是這時候它不是單獨使用，而是 跟基線搭配著用 ：基線給你「現在的數字」，鐵三角給你「牽動的邏輯」，兩者一起才能算出一個變更申請到底合不合理。 再講基線:kick off 之後，幫大家對焦的工具與標準 專案基線（Baseline），指的是...

PMBOK 六版、七版、八版到底差在哪？看穿專案管理的「內功」與「招式」 作者:林佳熹 | 發布日期:2025年11月16日 | 更新日期:2026年8月10日 曾被問過：「PMBOK 都出到第八版了，還學那套流程幹嘛？是不是過時了？」 我的答案是：不，而且問這個問題的時間點特別諷刺，因為 連 PMI 自己都在第八版，把七版拿掉的流程重新加回來了 。這不是巧合，這是市場用行動證明：原則（內功）可以進化，但招式（流程）從來沒有真的過時，PMI 自己打了七版一個耳光，用八版承認了這件事。 重點快覽: PMBOK 六版靠 49 個流程建立「招式」，七版轉向 12 條原則、拿掉流程只講「內功」，結果實務工作者反彈太大，八版索性把原則精簡成 6 條，同時重新加回 40 個流程，等於承認「只講內功、沒有招式」在真實職場行不通。不管你手上是哪一版，流程思維(招式)都是能不能真正落地執行的關鍵，這也是為什麼 AI 自動化時代，懂流程的人反而更有優勢。 1. 三個版本，其實是同一套內功心法的三次進化 要看懂這場「內功」與「招式」的辯論，得先搞懂三個版本各自在做什麼： PMBOK 六版（招式導向）： 用 5 大流程組、10 大知識領域、49 個流程 建構起完整的操作手冊，每一步該輸入什麼、用什麼工具、產出什麼，寫得清清楚楚。優點是可複製、可稽核；缺點是容易讓人誤以為「填完文件表格就是管理」，在混合式或敏捷專案裡顯得僵化。 PMBOK 七版（內功導向）： 大膽把 49 個流程整個拿掉，改成 12 條原則、8 大績效領域 ，訴求「不管你用哪種開發方式，這些原則都適用」。立意很好，但很多實務工作者反映： 原則講得很對，卻不知道具體該怎麼做 ，變成「知道要交付價值，但不知道怎麼交付」的空談。 PMBOK 八版（內功招式合體）： PMI 聽進了市場的反彈，把 12 條原則精簡合併成 6 條 （例如把「管理職責」與「領導力」合併成「當一個負責任的領導者」，把「系統思維」與「複雜度管理」合併成「用整體視角看待」），同時 重新加回 40 個非強制性流程 ，分佈在 7 大績效領域 裡（治理、範疇、時程、財務、利害關係人、資源、風險）。 這就是專案管理的演進賽局： 傳統執行型 PM： 死背流程組，以為把文件填滿就是管理（容易在變動中僵化）。...

利害關係人溝通三層階梯：專案經理的實戰溝通術（含步驟、範例、FAQ） 利害關係人溝通三層階梯：專案經理的實戰溝通術 作者:林佳熹 | 發布日期:2025年8月27日 「陳經理，這禮拜要交的報告能再修一下你覺得呢？」小美在會議中低聲問道。她心裡很清楚，這項專案的時程被安排得非常緊湊，更重要的是，利害關係人分成五六個派系，支持的聲音從來不整齊。這種情況在台灣職場非常常見：如果沒有足夠的溝通技巧， 專案管理 就會困難重重。 重點快覽: 專案溝通卡關，多半不是工具不夠，而是把不同層次的議題混在一起講。溝通三層階梯的順序是：先事實層（同口徑數據對齊認知），再情感層（把顧慮登錄成風險項並指派 Owner），最後才是未來展望層（用決策三案對齊方向）。順序顛倒，衝突就會一直重演。 目錄 為何專案溝通會卡關？台灣企業常見情境 溝通三層階梯模型：事實層／情感層／未來展望層 會議腳本與實戰話術：你可以這樣說 如何量化溝通成效：指標與儀表板 常見錯誤與修正：避免三大溝通陷阱 案例：阿明如何在瀑布型專案救回共識 FAQ：常見問題快速解 行動清單：今天就能用的 10 個動作 一、為何專案溝通會卡關？台灣企業常見情境 多方利害關係人、權責交疊： 部門 KPI 不一致，會議易流於各說各話。 時間壓力大、資訊不對稱： 決策被催促，資料卻零散；風險無法被客觀討論。 情緒累積、信任薄弱： 一次溝通不順，後續就以「預設立場」看彼此。 只談活動，不談成果： 討論「做了什麼」而非「達成了什麼」，共識難形成。 核心問題不是工具不足，而是層次錯置。 把不同層次的議題混在同一個對話裡，溝通必然失焦。 二、溝通三層階梯模型：由下而上建立共識 （1）事實層：用同一套數據對齊認知 事實層是地基。先確認大家看的指標、基線與計算口徑一致，才能避免「你說你的、我說我的」。 ...

PMP 的核心價值：為什麼在 AI 時代，你反而更需要這套不變的管理底層邏輯？ 【長青思維】PMP 的核心價值：為什麼在 AI 時代，你反而更需要這套不變的管理底層邏輯？ 作者:林佳熹 | 發布日期:2025年8月24日 重點快覽: AI 能快速產出排程與計畫草稿，但缺乏專案管理底層知識的人，無從判斷這些自動化建議是否符合真實的資源與範疇限制，容易被「AI 幻覺」帶偏方向。PMP 提供的五大流程組與十大知識領域，不是要取代 AI，而是讓你有能力審查 AI，這正是 AI 時代裡，反而更凸顯價值的長青底層邏輯。 一、高壓會議下的數位工具省思 在專案經理參與的一場跨部門對齊會議中，主管語氣堅定地提醒全體成員：「這禮拜要交最終方案喔。」這句話在會議室裡迴盪，帶來的推進壓力宛如一座大山。PM 看著手中那份由系統生成的時程排程，心中暗忖： 「雖然 AI 幫忙拉出的甘特圖草稿很漂亮，但沒有對齊真實團隊的資源限制，這個估算方式在真實職場環境中，還是需要人來介入處理調整。」 面對時間緊迫、資源有限與範疇不斷變動的複雜專案，許多 PM 開始意識到，單靠零散的自動化工具並不足以穩住大局。在技術大爆炸的AI年，不論你是否要成為專職 PM，或是考取國際 PMP（Project Management Professional） 證照，這套淬鍊了數十年的專案管理（Project Management）底層邏輯，都已經成為現代上班族必備的長青管理基礎。 二、數位轉型時代的真實挑戰：警惕 AI 幻覺與底層知識的真空 在自動化工具全面普及的今天，許多人產生了技術安全感的錯覺，誤以為只要把需求倒給大語言模型（LLM），正確的專案路徑就會自動誕生。然而，這正是最致命的盲點： 「如果你缺乏專案管理的底層知識，你將無從判定 AI 给出的時程與風險建議是否內含『AI 幻覺（Hallucination）』。缺乏框架思維，更容易被似是而非的自動化草稿帶偏方向，在跨部門協作中付出巨大代價。」 優秀的管理者深知，真實的職場專案是由一連串複雜的利益鏈與變動交織而成： 範疇不斷蔓延（Scope...

硬底子才是王道：專案管理就像打副本 硬底子才是王道： 專案管理 就像打副本 玩過線上遊戲的人都知道，表面上大家能聊天、換裝備、跑地圖，氣氛很熱鬧；但真正決定一個隊伍能不能打贏大魔王的，是分工與基本功。沒有輸出（DPS），王打不掉；沒有坦（Tank），隊伍一下就全滅；沒有補師（Healer），大家撐不到最後。再炫彩的時裝、再活躍的公會頻道，關鍵時刻都救不了你。 一句話重點： 遊戲靠分工， 專案管理 也一樣；真正撐起專案的，是可重複、可追溯、可驗證的「硬底子」。 專案裡的「硬角色」：把戰場穩住，輸出打滿 職場上，口才好、會激勵、緣分廣，像是遊戲裡的聊天頻道與表情動作，讓旅程更舒服。但能撐住副本節奏、確保通關的，永遠是以下這些「硬角色」： 遊戲分工 職場對應 在 專案管理 中的硬任務 沒有它會發生什麼？ Tank（坦） PMO 架構 治理與節奏控場：里程碑設計、基準線管理、風險門檻與升級路徑 決策混亂、優先級飄移、會議多而無結論 Healer（補） SOP／作業規範 把最佳做法文檔化、版本化、可追溯；交付驗收清單化 同樣錯誤重複發生、交付品質不穩、交接即失憶 DPS（輸出） Waterfall 基礎流程 WBS 分解、關鍵路徑、依賴管理、變更控制（CR→CCB） 專案斷點不明、估時失真、遇變更全隊重工 小叮嚀： 敏捷很重要，但要跑得快，先得站得穩。建議學習曲線採「先打好 Waterfall 基礎 → 再引入敏捷元素」，讓節奏與治理不打架。 軟技巧是 Buff，但不是核心輸出 溝通、激勵、領導、跨部門協作，這些都是「Buff」：能把隊伍的輸出加成、補血更有效率、容錯更高。...

【轉型賽局】驅動 AI 賦能專案升級：傳統組織如何在兩週內完成低成本防禦性轉型？ 【轉型賽局】驅動 AI 賦能專案升級：傳統組織如何在兩週內完成低成本防禦性轉型？ 在一家擁有30年歷史、底蘊深厚的台中製造企業裡，專案經理陳經理正遭遇著跨部門數位轉型的核心考驗。她剛接到一項十萬火急的任務：決策層拍板必須在兩週內，更新底層的生產流程系統並引入 AI 自動化技術，以優化產線的實質營運效率。面對這種技術高度密集、時程卻極度緊縮的指令，資深 PM 都明白，這背後隱藏著「需求範疇模糊」與「利害關係人期望錯配」的隱形專案風險。 一、技術變更背後的利害關係人利益博弈 在 2026 年的商務環境中，將大語言模型（LLM）與自動化工作流融入傳統產業，是推動流程優化、拉高市場競爭優勢的必然趨勢。然而，這種技術變更在落地時，本質上是一場「組織政治學」。它牽動了技術單位與第一線作業單位之間不對稱的利益鏈與習慣摩擦。面對高層叮嚀的迫切死局，不成熟的經理人常落入盲目跟風的盲點，最終導致工程團隊抗拒、專案進度癱瘓。 陳經理深知，AI 工具絕非一敷就靈的萬靈丹。專案風險控制的核心，在於能否在前期對「端到端（End-to-End）的業務邏輯」進行結構化拆解。她採取了 防禦性文件化 的手段，建立起清楚的責任邊界（RACI 矩陣），並利用同口徑數據對齊利害關係人的期望。在面對不合理的緊縮時程時，這成了她與團隊不可替代的免責護城河。 二、防禦性雙軌自救策略：最小可行性試點（MVR） 為了在急迫時程內同時兼顧「系統穩定性」與「技術創新度」，陳經理果斷拒絕了高風險的全面翻新，轉而推行成熟的 「雙軌控制策略」 ： 軌道一 - 最小可行性試點（MVR）： 劃定明確的範疇（Scope）邊界，僅在單一產線、特定功能模組內導入 AI 髒數據清洗與自動化預警。 軌道二 - 原有基線防護（Baseline Protection）： 堅守既有的瀑布流控制（Waterfall Control），確保核心核心生產流程不受新技術的意外扰動，用低成本進行實測風險分攤。 這種雙管齊...

【數位領航】AI 導入專案管理的盲點與新思維：AI 上班族如何用自動化工作流翻轉生存危機？ 【數位領航】AI 導入專案管理的盲點與新思維：AI 上班族如何用自動化工作流翻張生存危機？ 一、從會議室開始的思維革命：IT 工具人的消失與轉型 在某個忙碌的星期三上午，台北信義區某家跨國團隊內部，一場充滿張力的變更對齊會議正在進行。專案主管林經理望著投影幕上管理團隊提案的 AI 自動化架構，心中盤算著：「本週五天天下班前必須交付的跨部門方案內容龐大，如何讓新技術真正幫上忙？」然而，會議中利害關係人針對成本、數據合規與實質效益的爭論卻讓氣氛愈發緊繃。這場景象，正是 AI 年現代企業推動數位轉型與流程優化的關鍵縮影。 隨著大語言模型（LLM）全面接管了複製貼上、資料格式整理等重複性任務，過往只負責機械性抄錄數據的初階 IT 分析師（IT analyst）正逐步退出職場歷史舞台。這意味著，不論是專職 PM 還是普通上班族，都必須具備 將 AI 轉化為個人控制流與核心決策槓桿 的現代思維。正確導入，能大幅降低資訊不對稱；盲目跟風，則容易被技術反噬。 二、AI 導入時常被忽略的三大管理盲點 1) 資源配置與現有流程脫鉤 許多公司在引進自動化技術的初期，常犯下將技術與業務現況割裂的錯誤。林經理回憶起某個大型瀑布流專案：當時技術團隊設計了一套精妙的分析模型，但由於未能對齊一線團隊的真實需求與 SOP，導致系統上線後頻頻報錯。流程優化不能流於口號，忽略基線控制（Baseline Control）與組織習慣的盲目引入，是專案延誤的最大導火線。 2) 技術黑盒子導致的溝通落差 資訊透明度與期望管理，是決定變更成敗的關鍵。林經理曾在專案會議中看到：技術專家試圖用複雜的演算法術語來說服管理層，結果非技術背景的主管與業務完全無法對齊利益，導致決策卡關了整整兩個月。AI 專案的本質是 專案管理 中的利害關係人管理。如果不能把複雜技術翻譯成同口徑Fact的事實指標，再精準的工具也難以落地。 3) 資料治理框架的缺位 數據是驅動自動化的油田，但前提是這片油田必須經過嚴格的資料治理。林經理曾深陷於跨部門數...

【流程治理】AI Workflow 在專案管理的實戰應用：中階主管如何建立人機協作的增強決策系統？ 【流程治理】AI Workflow 在專案管理的實戰應用：中階主管如何建立人機協作的增強決策系統？ 一、序幕：資源不對稱下的流程優化希望 在台灣科技團隊的會議室裡，專案經理 Linda 正面臨一個極具挑戰性的死局。專案資源有限、前線開發團隊負荷沉重，而跨部門的利害關係人又不斷催促時程。在進度壓力瀕臨臨界點時，她深知光靠口頭協調或加班已無法根本解決問題。許多團隊在此時會盲目跟風採購花俏的工具，但 Linda 心裡十分冷靜： 「AI 工具本身不是萬能解藥，真正能為團隊拉出護城河的，是能否設計出一個可重複驗證、閉環運行的『AI Workflow』。」 她回想起上週的專案範疇對齊會議：當各部門主管聽到要推動自動化時，現場充滿了對技術黑盒子的疑惑與不確定感。甚至有第一線同仁坦言：「老實說，我不認為自動化工具能幫忙加快這禮拜要交的數據報告。」這讓 Linda 保持警覺，導入技術的本質從來不是單純的軟體安裝，而是一場 對齊組織利益與習慣的流程變革 。 二、AI Workflow 的三步走標準防禦戰略 為了建立起具備韌性的管理節奏，Linda 設計了嚴密的三步驟導入計畫，確保每一項自動化改造都有數據支持： 1) 需求評估：用結構化框架找到真實痛點 Linda 舉辦了一場跨職能小組工作坊，邀請各部門利害關係人列出日常溝通中最常遇到的資訊延遲卡點。經過同口徑的Facts梳理，她將繁雜的需求收斂為三大核心方向： 風險管理： 缺乏即時的數據觀測與事前防禦警示機制。 流程優化： 例行性的跨系統報表與週報製作耗費大量人工體力活。 溝通透明度： 單一事實來源（SSOT）缺位，常導致跨部門誤解。 2) 逐步整合：實施最小可行性試點（MVR） Linda 拒絕了一刀切的全面更替，而是挑選一個特定的試點專案。她的核心核心目標不是期待技術一次解決所有組織沉痾，而是精準找出「自動化能幫人類換取最大時間籌碼的槓桿節點」。例如： ...

任務分工到 AI Workflow：吳經理如何把關鍵專案做對 任務分工到 AI Workflow：吳經理如何把關鍵專案做對 在台北的一間明亮寬敞的會議室裡，吳經理這位中階管理者正面臨著一個棘手的專案。此專案對公司非常重要，卻同時面臨時間緊迫與資源有限的雙重壓力。他必須迅速組織團隊，制定可行的任務分工計畫，並把每一個細節落地執行。吳經理心想：要如何用最有效的方式，分配多樣化的任務、降低風險，並確保交付品質與進度同步達標？ 快速導讀： 核心框架： 透過 WBS 任務分解 與 RACI 權責矩陣 建立結構。 效能倍增： 識別 5 個高 CP 值的 AI Workflow 節點。 實戰工具： 內含 3 大管理矩陣範例與 10 項立即落地的行動清單。 成功的 專案管理 ，不是把工作丟出去而已；而是建立一套讓人與流程與工具彼此強化的系統。 一、由上而下對齊：專案目標、範圍與成功準則 任務分工之前，吳經理先把三個關鍵問題釐清： 我們要交付什麼？ 明確成果（Deliverables）與驗收標準（Definition of Done）。 何時交付？ 里程碑（Milestones）與關鍵路徑（Critical Path）。 如何判定成功？ 商業指標（如營收/成本/客戶滿意度）與營運指標（如故障率、交期符合率）。 他用一張一頁式的專案概覽（One-Page Project Brief）凝聚共識，成為後續所有分工與決策的依據。這一步看似花時間，卻能讓後續分工更精準，避免「邊做邊猜」帶來的反覆溝通成本。 二、建立結構：WBS 任務分解與價值優先 吳經理帶著團隊進行 WBS（Work Breakdown Structure）工作分解，把大型成果拆解成可管理的工作包（Work Packages），再依「價值 vs. 複雜度」進行分層...