打從出道(退伍)以來，過去將近二十年的職涯我所從事的都是業務性質的工作。
作為一位長年在第一線跑客戶的業務，我一直以為專案管理是工程師或是PM 的事，離我很遙遠。
因為業務的戰場始終是在電子郵件、電話、餐桌與會議室。我們該做的就是談條件、拿訂單、然後用業績來說話。
直到一次跟主管的面談，他期許我能加強專案管理的技能；我才開始認真思考什麼叫專案管理？
進一步檢視團隊日常工作後，我發現業務工作每天面對的其實就是一連串或大或小的專案(Project work)，只是一直以來我都習慣用經驗與臨場反應在解決每次的任務(Task)。
我並沒有一套制度化讓工作可控、可追蹤、可交付的方法。
如果是這樣子的話，我就無法讓團隊壯大，永遠都只是散兵遊勇又或者是獨善其身；無形之中也限制了個人的發展。
而這篇推薦文，就讓我用沒有正式受過專案管理訓練的業務的角度，跟大家分享我為什麼真心覺得這門課值得去上。
業務的日常，其實充滿專案(Project work)但我們常把它當營運 (Operational work)
過去的我，把很多事情歸類為日常營運：像是新產品說明會、區域試乘活動、季度促銷、重要客戶會議、跨部門上架流程……在腦中它們都是一條條待辦事項清單。
但老師第一個砲彈丟出來：專案工作（Project Work）跟營運工作（Operational Work）有本質上不同。
專案有明確目標 (Goal)、有起訖 (Duration)、有獨特交付物 (Deliverable)；營運工作則比較像是例行性公事，是用來維持工作效率與穩定輸出。
如果以我們公司的工作來舉例的話，辦一場新品試乘會就是專案，因為它有明確的時間與目標。
而例行性客戶拜訪、每天的訂單處理則偏向營運。
這個看似簡單的切分，卻像是把霧氣吹散。
因為一旦確認了某項工作是專案，那麼我就能用專案的邏輯來管理：先界定交付物，再倒推資源與限制，最後訂進度與責任。
反之，把專案當營運，就會出現典型業務的痛：臨時加碼、責任不清、進度失控、最後一週瘋狂救火。
這堂課教我的第一個轉念，就是把該用專案管理的場景挑出來。
自已依照上課的筆記與網路資料所整理的表格
從想法(Idea)到成果(Outcome)：專案管理能力就是規劃力(Planning)+執行力(Excution)
我相信在職場中，大家都會遇到類似的情況。
那就是老闆突然丟一個目標出來又或是客戶給了一些不是很明確的需求。
然後團隊各說各話，有各自的解讀。
最後的結果就是：大家都很努力，有做到，但是不夠好。
也就是台語中常聽到的：棚頂做甲流汗，棚跤嫌甲流瀾 (Pênn-tíng tsò kah lâu-kuānn, pênn-kha hiâm kah lâu-nuā)。
所以在一切的專案開始前，我們首先都要先確認我們為何而戰？
也就是確認何謂專案目標(Objective/Goal)？
專案目標就是用來衡量專案成敗的條件與專案規劃的起點。
唯有掌握目標後，我們才能釐清管理重點與判斷優先順序。
要如何掌握目標呢？
具體來說，就是不斷的與利害關係人(Stakeholder)也就是會直接受專案成敗影響的人或是組織。
通常來說，在職場就是老闆或是客戶啦。
在日常生活來說，有可能就是你的老婆、女友之類的。
從想法(Idea)到成果(Outcome)：專案管理能力就是規劃力(Planning)+執行力(Excution)
那麼，究竟什麼是專案管理呢？
面對這個難題，老師用一個四段式架構把我敲醒，並用最簡單的方式讓大家了解什麼是專案管理？
自已依照上課的筆記與網路資料所整理的表格
簡言之，專案管理就是把利害關係人(Stakeholder)的想法(Idea)與期待(Concept)給具體化，變成做法(Methodology)，再把做法拆成可以實踐(Execution)的任務(Task)，最後交付有標準可驗收的成果(Deliverables Outcome)。
身為業務，我尤其有感的是第一段：那就是與利害關係人（Stakeholder）溝通。對我來說，最常見的利害關係人(Stakeholder)就是我的直屬主管。
在公司服務多年，我與許多不同類型的利害關係人a.k.a.主管打過交道。
有些主管只有想法，但是沒有做法。
有些主管沒有想法，也沒有做法，他只有一個很高大上的目標，然後問你怎麼達成。
有些主管好一些，他有想法，有時候也會給你做法。
但是大多數的主管都是只有想法而沒有做法，因為想出做法並執行是我的工作。
以前都覺得先做、再調整，但課上反覆提醒：不把 Stakeholder 要什麼問清楚，後面 90% 的努力都會打折。
包括：結果怎麼衡量（KPI)？交付物與成果要什麼？有那些限制（包括人力、時間、預算、技能、法規等）？
以上這些問題如果專案開始前就能問到位，那麼上司對你的工作表現會安心。
客戶對於你所的提供的成果會滿意度上升。
最後老闆放心，客戶開心，你也加薪！(嗯~不一定啦)
兩個專案管理實用工具：運用工作分解結構(WBS=Work Breakdown Structure) 與 專案管理儀表板(PM's Big Table/Dashboard)，讓專案看得見、管得動
- WBS（Work Breakdown Structure）是這堂課的明星工具，因為它是用來翻譯需求、溝通需求與成果管理的工具。
過去我總以為 WBS 是工程師在用，但老師用生活化的例子再透過小組討論（如何辦一場公司烤肉活動）讓我立刻理解：WBS 的重點不是把事情寫滿，而是把工作範疇(Scope)切到能分派、能驗收、且 100% 覆蓋(儘可能的仔細)。
它要求你用「名詞」定義交付物，不要寫動詞與形容詞像是做行銷、加宣傳這種空話；要具體到需要兩款海報設計、三篇社群文、試乘流程指示牌、場地動線圖等。
對業務來說，這意味著你不用再在會議上浪費時間討論到底要做到什麼程度，因為 WBS 把期待寫成看得見的事物。
舉例來說，辨烤肉活動要買肉，但是要買什麼肉？
你自已喜歡吃牛肉，但是沒有考慮到其他人可能不吃牛，那麼結果一定無法皆大歡喜。
所以具體的寫下來，你要買什麼肉？
也就是把利害關係人的期待轉換成看得見的事物這點也非常重要。
而WBS 另一個好處就是三個字：可分派。
一旦每個工作包(Work packages)被定義清楚，就能貼上負責人(Responsible Person)與期限(deadline)，責任不再漂浮，也就是我們在工作上經常在說的當責(Accountability)！
這對業務團隊尤其重要，因為我們的成員常同時處理多個案子，WBS 能把專案切成方塊，讓每個人知道自己拿到的是哪一塊；這樣才有利於後續的追蹤。
WBS的範例很多，我自已簡單作了一個，作為公司內部分享用。紅字的例子就是不好的例子，因為不夠具體、明確。
- 專案管理儀表板(PM's Big Table/Dashboard)：則是可以全部的工作、任務、資源、進度、成本、風險等放在同一張表單，讓專案管理者可以一窺全貌並掌握動態。
透過這張把任務、起迄日期、負責人、狀態、相依關係、計畫 vs. 實際（包含成本與工時）、風險與議題，全部拉在一起的表單。
我們可以立即判斷專案進行的情況，而它的好處如下：
- 專案健康度一眼可見：延遲、超支、卡點在哪，你不用翻閱許多文件。
- 變更管理有依據：當資源有限（人、時、錢），你能提出調整方案(Planning)而不是情緒化的抱怨。
- 跨部門透明：行銷、供應、財務看到同一張表，溝通成本直線下降。
老師也分享了史上最複雜專案管理者-美國第34任總統，也是諾曼地登陸行動的最高指揮官-艾森豪 將軍的名言與學員分享。
Plan is nothing, planning is everything!
這句話的白話文是計畫是一堆廢紙，而規劃才是王道，但它背後的涵義則是：計畫本身（Plan）只是個文件，容易變動且死板，但制定計畫的過程（Planning），包含思考、溝通與動態調整的能力，才是成功與應對變化的關鍵，這過程能帶來前瞻性與應變力。
我想，這才是身為專案管理者所應該具備的能力。
依照場景來選擇合適的專案管理工具
老師也提醒不同場景的工具選擇，但是起手式都是WBS。
- 在面對人少且組員治力強的專案時，用 WBS 搭簡單追蹤就夠。
- 至於可能需要跨部門溝通而且變更也許更頻繁時，就需要使用 WBS + Dashboard
- 如果是更複雜的情況，例如不同專案間彼此聯動時，那麼則需要更專業的工具例如 Microsoft Project、Planner 等工具一起上。
我認為在實際的運作上，需要有工具輕重分級的概念：畢竟我們是以場景來決定工具，不是工具決定場景。
心態的換檔：先定範疇與目標，再算時間與限制
而課程最後的心法對我幫助非常大。
業務總是習慣先衝刺，但老師要我們學會練習三件事：
- 那就是用 WBS 釐清範疇（Scope）與交付物：把模糊的需求變成具體的清單。
- 確認每個任務的時間（Time）：排起迄、估工時、看相依。
- 評估資源與限制（Constraints）：人力是否足夠、預算是否到位、法規或流程有無阻礙。
這三步做完，專案就有了骨架，討論與執行起來也就會有了方向。
將老師二十多年的功力內化成以下圖表。
理論與實踐
我會將上課所學應用在日後三種工作場景上。
場景一：新品試乘活動
以前我們辦試乘，多靠群組訊息與 Excel 倉促協調，結果現場常出現「指示牌不夠、動線混亂、試乘車不齊」的狀況。
日後這次我會指示專案負責人做 WBS：場地、動線、宣傳物、車輛清單、保險與安全、志工分工、社群預告與媒體邀請、現場流程（報到→試乘→回收→問卷）……每一項都具體到可交付名詞。
再把任務搬進大表，貼起迄、負責人、相依。
希望在最終驗收時，活動不但順、滿意度也高，再在檢討會一看，延遲的點和超支的地方一清清楚楚，下一場立刻有對策。
我也可以透過這個作法，來作為人員的考評。
場景二：季度促銷企劃
促銷案最怕喊了大目標，落地沒細節。
這次我在啟動會上先確認目標：目標是銷售成長多少、要拉哪幾個品類、預算上限、可用的人力、不可碰的條件（例如既定的品牌形象）。
把這些寫進 WBS 的頂層，再往下拆成「促銷機制設計、素材製作、通路溝通、庫存與補貨計畫、行前教育、成效追蹤」。
透過每周用大表檢視，出現庫存不足的風險時，立刻調整通路配比與檔期節點，最後可以明確的了解促銷案的投入與成果回報。實獲值評估法(Earned Value Method)
場景三：關鍵客戶導入作業
面對關鍵客戶的導入流程，過去容易被對方的節奏牽著走。
我們可以試著透過WBS 把導入分成「技術規格確認、測試樣品、價格與合約、交期與物流、售後服務、教育訓練」等交付物，再用大表把對方節點與我方準備串起來。
當對方臨時調整測試規格時，我直接用「影響矩陣」在大表標註：影響的是交期與成本哪一段，提出多套替代方案讓對方選。
期望能將結果談判從拉扯變成共同解題，時間線也安全落地。
最後我認為這門課對業務的三個直接價值在於把溝通的方式從感覺/感性拉回定義/理性。
透過WBS 來說清楚交付物，並使用大表把進度、責任、影響給透明化看見。
這讓會議不再是你說我猜，而是拿清單與時程討論。
最後：推薦的理由
為什麼我會推薦給沒有受過專案管理訓練的人呢？
因為它把專案管理的「骨架」一次搭好： 先把專案與營運分清楚，讓你知道什麼該用專案邏輯。
再教你用 WBS 把需求變成交付物清單，避免做到很多卻不對。
最後用 PM 大表讓進度、成本、風險透明，變更管理有章法。 夠簡單、夠實作、不講空話。
對第一次進門專案管理領域的新手來說，不會被名詞淹死，反而能拿來就用。
而且講師豐富的實務經驗更是讓人獲益頗豐。
如果你跟我一樣，過去沒受過正式的專案管理訓練，卻每天在不同的專案中打滾；如果你厭倦了臨時救火、會議越開越忙卻成果不成形；如果你想把努力變成可複製與驗證的成果——那就去上一天，把這套方法學起來。
最後用我自己的結語收尾：
計畫會改，目標不改；資源有限，解法要在。
這門課，教的不只是做事的方法，更讓你在面對變動時多武器在變動世界裡的定心骨。
如果我能把它練成肌肉記憶，下一次面對專案，我將不會再害怕改變，而是會主動把改變成為我的槓桿並勇於接受挑戰！
