馬克總是能一語道破職場的辛酸血淚，身為公司的小小職員，任務完成時間通常被層層壓縮，基本上這種交辦型態不健康的。一般而言，專案估算時程的時候，為避免風險發生而延遲交付，會預留一段緩衝時間，作為應變之用。然而，這個浮時的估算，必須在底層估算完成後，才能疊加上去，目的是避免由下到上被不斷膨脹，導致結案日變得遙不可及。成本概念也是一樣，專案經合理估價後，才加上應變準備金以備不時之需。
反之，由上而下交辦工作時，如果不能統籌管理，很容易就會發生馬克遭遇的悲慘事件，因為完工時程並不是在最後階段才加上浮時，而是每個階層都被偷走了。
家裡有小小孩的家長想必對救援小隊Poli並不陌生，Poli是來自韓國的卡通，主角們是布姆鎮一群專職救援的成員，包括警車Poli、消防車羅伊、救護車安寶、直升機赫利，以及負責接聽求救電話的琴。
救援小隊的形象清新，使命必達，不僅在小朋友界獲得廣大的支持，如果專案內有這麼一組專司救援任務的成員，那該有多好!
Team Work ! Team Work ! 團隊合作，是我們經常聽到的一句話，而它，看似簡單，卻是十分複雜的議題。何以說十分複雜? 如果團隊合作指的是把同一個專案工作，切分給團隊成員，各自做好被分配的工作，那麼很可能忽略了"人"本身的影響，太過於物象化了。工作如何切分? 誰多誰寡? 如何整合? A工作會不會影響B工作? 有人勤奮做多一些，有人偷懶有交付就好，品質該如何維持? 太多太多的問題盤根錯節，都是影響團隊戰力的可能因素。
一個具有凝聚力的團隊要建立並不容易，特別是當主管與成員分別來自不同領域，各自已有了自己的舒適圈，怎麼打破那無形的隔閡，讓團隊每個人發揮最高的效率? 專案經理或許能借重時程管理、資源管理、溝通管理等技巧，讓專案"看起來"順利運作，也算是達成被交付的責任。只是，專案經理通常也是主管級人物，若總是只完成交辦任務，而沒有創造更高的價值，也無法對上級交代。在專案不鍍金(註1)的前提下，專案經理應該投入更多精神在"人資管理"，所謂人資管理包含團隊形成、團隊建立、團隊解散等階段，每個環節都有數不清的人為因素影響，因此團隊成立時的基本規則是否建立? 成員間的衝突是否被解決? 成員的技能如何發揮? 需求是否被滿足? 就顯得十分重要。
一個團隊中若有位眾所期待的英雄人物，究竟是好或不好!? 英雄之所以為英雄，是因為他擁有過人的才華與天份，當專案運作順利，英雄能為組織帶來實質的貢獻，甚至還能創造更多的附加價值。然而，如果團隊過度依賴英雄，長期處在舒適的環境中，久而久之，便容易失去危機處理能力，甚至連基本功都有可能退化。
不可否認，我們都喜歡英雄，因為英雄能創造話題，英雄讓我們能投射情感在其身上，讓我們有了期望。只是，當專案團隊中出現英雄時，卻是PM該頭痛的時候了。PM頭痛的是，如何善用英雄的才能，讓他發揮最高的戰力，卻有同時讓團隊成員保有持續前進的動力。
專案的定義是"一個有限時間內，完成特定目標的工作"，因此商店的營運並不屬於專案的範疇，但若是將創業開店這件事視為一個階段性任務，那就能導入專案管理的知識來協助運作。以開設一家特色書店為例，如果你是一位新手，該從何開始?
我們試著從專案管理的生命週期來簡單說明:
若將正式拍攝前的準備工作以時序圖呈現，可以概略區分為資料準備、軟硬體準備兩大類，在資料部分，包括決定播報範圍、收集圖資、撰稿、內容分析、校稿等工作，軟硬體則包括攝影器材、燈光、音效、服裝儀容等。部分工作有其先後次序，當然也有能並行處理的項目，例如在確定播報內容並收集相關圖資後，便可同步進行撰稿及圖檔編修的工作，最後再統一進行場景套疊，因此，下圖(請略開始與結束日期)中黃色區塊就成為所謂的要徑。一般來說，這種簡單的區分法通常團隊成員已駕輕就熟，專案經理不需要過度干預，但是當專案的完工期限被提前時，要徑上的工作就有延遲的風險，普遍的應變作法是要求團隊成員壓縮時間每個工作包的時間，而我們知道，專案中有三個彼此相關的限制(註1)，要不得增加人力，要不就必須犧牲部分品質。另一種變通的方式是，將每個工作包再拆分成更小的工作包，例如圖資內容可以區分國際事件、國內事件，或依時間劃分成一周預報、明日預報，每完成一部分的圖資，隨即進入撰稿與美術設計階段，如此一來，當圖資收集的工作全部完成時，撰稿也幾乎完成了大部份工作，若每個工作包之間都能如此進行，整體的時程就能有效壓縮。
當然，實務的經驗告訴我們，將工作包拆分是有風險的，尤其常發生在最後整合階段，一旦風險發生，造成的後果可能比延遲更為嚴重。因此，一開始就必須明確鑑別被拆分的項目之間的關聯性，關聯性越小者越適合拆分，此外，專案經理也得緊盯每項工作包的運作狀態，留意是否有偏差的徵兆出現。簡單來說，當預知使用的管理方法有潛在風險時，就必須提高監控的頻率。
氣象播報是一門跨領域的學問，至少包含氣象與傳播兩種專業行為的表現，若是將範疇稍微做一些延伸，涵蓋美術設計、文字、導播、後製到影片的輸出，便像是一個專案的周期。若以一分鐘報氣象來當案例說明，PM並非螢光幕前大家所喜愛的氣質美女主播，而是躲藏在幕後的策劃人員，通常也可能是導播的角色。
首先，在影片拍攝前，必須決定播報內容，也就是專案產品的範疇，是一周氣象、國際概況，還是明日的天氣小叮嚀?有了明確的定義後，主播及氣象團隊便可針對範疇進行細節的分析，接著寫稿、校稿、繪圖、美編、燈光、攝影、排演到實況，PM拆解WBS並依前後相依關係組成工作時間序列圖，每一個步驟環環相扣，有的固定先後順序，有的則同步進行，每個不同的小組或成員各司其職，專案才得以順利進行。
在專案規畫階段，即使大部分專案管理的文書作業都忽略不看，WBS或甘特圖通常還是很重要的一項，因為有了初階的工作計畫，PM才有辦法進行後續的追蹤。既然WBS是規劃的產出，那麼勢必要有參考或估算的基準，也因為估算難免與實際狀況會有些許落差，因此才需要不斷進行監控與改善。我們常說WBS是將專案工作拆解到足以掌控的大小(例如以80小時工作量為一個工作包之單位)，但如何拆解成工作包又是一門學問。雖然專案管理知識告訴我們，進行工作包拆解的過程暫不需考量時間、成本(有其先後順序與相關性)，但實務上這些東西都是環環相扣，往往PM能估算的時間有限(今天被接收到專案，過幾天就必須提報規畫初稿)，因此PM只能快速、綜合性評估，所以我們在拆解WBS時，也常引用了成本管理中裡常用的類比估算法，也就是拿過去相似的經驗來套用，或是再加上部分的變異參數(例如兩個專案的人員程度不同)，快速初估工作項目、時程後，再同樣類比推估出所需的成本。
CMMI(能力成熟度模型)中提供了軟體開發專案的另一種估算方式，叫做功能點數，簡單來說，功能點數是將預定開發的軟體系統，依據系統開發範疇(邊界)，將功能區分為外部輸入(External Input File，簡稱EI，例如新增、刪除)、外部輸出(External Output File，簡稱EO，例如訊息輸出)、外部查詢(External Inquire File，簡稱EQ)、外部介面檔案(External Logical File，簡稱EIF，例如與其系統外的資料庫進行介接)，以及內部邏輯檔案(Internal Logical File，簡稱ILF，也就是在系統內部自行判斷的邏輯程序)，如下圖。透過點數估算出來的專案規模，再引入組織內部的人力產值，即可估出相對應的時間、人力成本。
升上管理職後，許多人一定會感覺文書作業變多了，週報、月報、季報、年報，填不完的表單、簽不完的文件，尤其技術出身的主管往往很難適應這樣的轉變，所花的過渡期就會拉長。因此，有人會疑問，專案管理不是號稱80%的時間在溝通嗎?為什麼反而Paper Work的時間佔了大部分? 又是理論和現實的差異嗎? 從字面意義來看，溝通是「彼此間的意見交流，或訊息的傳遞」，原本就不單指言語對談，舉凡會議、電子郵件、電話、簡訊、報告、新聞稿，乃至標記重點的紙條，都屬於溝通的範疇，因為這些動作都是在傳遞訊息，也因此，所謂80%的時間在溝通，當然也就包含了這些繁瑣的Paper Work。
在經驗學習&避免過多的Paper Work中曾談到過多Paper Work的壞處，今天要說的則是它的好處。適量的文書工作絕對是必須的，文件的形成主要來自於規範的訂定，要使身處不同地方的團隊成員有效溝通，就是得讓成員們遵循相同的規則，用相同的語言交流，這也是為何文件數量往往和專案大小成正比的關係，因為隨著專案人數增加，若彼此間的溝通方式不一，很容易造成時間的浪費。通常我們用n*(n-1)/2這個簡單的數學算式來表達溝通的數量(參考下圖)，當一個五人專案擴增為七人時，溝通管道會由10個暴增至21個，稍有不留意，訊息很容易就會出現誤解。
有了專案管理知識後，是不是就真能讓專案更有效率達成任務呢?理論上是的，但實際上專案的執行除了專案本身的時程控管外，還常常必須應付公司緊急交辦的事項，可能是其他專案，也可能是瑣碎的雜事。個別專案可以仰賴專案經理掌控，但在稍具規模的組織裡，每個專案間的資源如何調配?人力是否足夠或工作量是否超載?哪個專案工作較急迫?就不是單一專案經理有權限處理的，因此，PMO(Project Management Office，專案管理辦公室)這個團隊便應運而生。
PMO的建立，其目的是希望能有效地掌握、整合及運用企業內部資源，並提升專案績效以圓滿達成最後的專案任務，但實際執行時常需考慮到組織的架構、資源的整合、專案的特性、系統的使用，及績效評估等等眾多因素，也因此同一套標準並不適用於每間公司。
範疇管理到底有多重要?我想從馬克的圖已經很清楚表達，而這也是很多上班族共同的心聲 : 客戶到底還要改幾次!
專案管理中有一項很重要的精神 : 不鍍金，也就是不輕易承諾、完成超出專案範疇的工作，因為有了第一次，客戶便會一而再再而三提出越來越不合理的要求。然而，在台灣這個講究人情的社會，以及大部分老闆業務至上的觀念壟罩下，要有立即性的改善並不容易，因此，只好從一些PM能夠掌控的事情下手，以下以軟體專案而言分享一些經驗:
在溝通管理中，所謂溝通是必須經過雙向的互動，確認彼此理解對方想表達的意思。這指的是在客觀條件下，彼此理性、有邏輯的溝通，但在現實情況，我們很難跳脫情緒掌控，所以才會讓互動的過程中出現雜訊。雜訊如何影響溝通結果? 我們用目前最熱的新聞議題來做說明，但開始之前，必須請大家先摒棄對這個事件的任何成見，僅以理性的態度進行學術探討。
事件是這樣的:
車流崩潰(breakdown)意思是在沒有交流道、道路縮減及其他影響的情況下，單純因為車輛過多、變換車道，或部分車輛怠速所造成的塞車現象。在沒有任何瓶頸下，高速公路的車輛密度大約在80台車/公里，前後車距約12.5公尺，此為臨界密度，當超過臨界密度後，因車輛彼此距離太近，前方車輛做出一些反應時(如煞車)，後方車會比前方車反應還大，並一輛一輛往後傳，這個現象在大家平常等紅綠燈時就可以明顯感受到，當前方車輛煞車再加速時(例如從紅燈轉為綠燈)，後方的車通常在前方車已經確定往前後才會開始加速，因此越後面的車會發現綠燈已經亮了一段時間，自己卻還沒辦法前進。
在車輛增多、車距逐漸縮小時，我們便可以預知breakdown現象可能即將發生，因此若能適時做出應變，就能舒緩塞車的情形，這與專案管理中監控風險、風險回應的流程是相符的，PM必須在專案執行過程不斷由相關的徵兆來預知風險是否將發生。若事先做好風險回應對策之擬定，便可以適時做出規避、承擔、轉移、減輕等回應。
開會的目的是什麼? 關係到這個會議是否能有具體結論。會議就如同一場小型專案，一開始的章程不明確、範疇太廣，過程便容易失焦，被錯誤引導的議題也訂下了錯誤的決策。
回顧2013年世界棒球經典賽，雖然輸了兩場有機會贏球而未贏的比賽，國內討論的聲浪不斷，有鼓勵也有批評，但無論如何，那都屬於茶餘飯後的閒話。真正具有經驗傳承意義，當屬決策單位的檢討會議，若運作得當，能從中找出成敗的關鍵因子，並在下一次的比賽中想辦法改善。
勇者鬥惡龍曾經是陪伴許多宅男們度過無數個夜晚的經典RPG遊戲，勇者為了拯救世界，在魔法師、戰士等夥伴的協助下，歷經無數次與惡龍的對決(註1)，從2D到3D，從小孩到大人，還在持續不斷演進中。而現實生活中，PM也為了達成專案的目標不斷戰鬥，和潛在風險、和利害關係人，甚至和sponsor進行資源的爭奪戰。
身為剷除惡龍的專案經理，勇者羅德有明確的章程及時程網圖(註2)，對於專案目標、何時該於何地完成什麼任務都有清楚的指示，因此，勇者著重的焦點工作便是獲得專案團隊、發展專案團隊，以及確保品質良好。
老闆不是神，專案經理也絕對不是，既然如此，也就不用強求自己同時掌管許多專案還能事必躬親。適當的委任與授權，不但能讓團隊其他成員有機會學習，也能舒緩自己的工作量，可謂一舉數得。然而，什麼事該放手，什麼事該授權，可以依循抓大放小的原則來進行，也就是先挑出大的、重要的事項，由於這類的工作影響層面較廣，因此必須謹慎處理，其它工作再依屬性委任給適合的團隊成員。很多時候團隊成員若只是一個口令一個動作，很難從中學習成長，自然也無法發揮創意，長久下來，專案經理便成為時時要前線的救火隊。反之，一旦團隊成員被委派相當程度的工作，無形中也會比較謹慎看待。
抓大放小的原則在很多地方都很受用，例如WBS的制定、時程規畫等，雖然WBS號稱應該拆解為80小時以內的工作包，也就是最容易被掌控的工作量，但除非公司很重視專案管理工作，否則在實務上其實很難做到，因此，為顧全大局，挑出重要的工作優先處理是絕對必要的!
拿掉名片後，你還剩什麼?
當我們工作一段時間後，累積的經驗、技術可能讓我們得以在某個領域當上小小的leader，但，當這些頭銜不再，或重新轉換了跑道，是不是還能保有一樣的競爭力?如果我們不是該領域的佼佼者，如果我們沒有廣大的人脈，我們的經驗、我們的態度也許是
所為「要徑」，白話一點來說，可以視為專案工作執行的最重要工作路徑。之所以稱最重要，是因為該路徑一旦Delay，就會導致整個專案延遲。在專案執行的期間，會有許許多都的工作包等著處哩，如果管理者不能有效判定要徑所在，很可能會讓專案團隊同時背負太多工作，產生連鎖的負面效應。
