不論專案大小或產業類型，每個專案都會經歷相同的四個階段：規劃（Planning）、建構（Build-up）、執行（Implementation）、收尾（Closeout）。這些階段雖各有特性，卻會互相重疊——例如你會在規劃時先給出粗估的預算與完工日，到了建構與執行階段才把細節定下來，並依新資訊回頭修正原先的估算。

各階段對照表#

規劃：如何鋪陳一個專案#

人們提到專案規劃常立刻想到排時程，但排時程其實要等到建構階段。規劃真正要做的是釐清三件事：要解決什麼問題、誰會參與、要做什麼。

找出真正要解的問題#

開工前先停下來，確認這個專案到底要解決什麼。問題往往不像表面那麼明顯。

看到「我們資料拉不夠快」「我得查四份報告才能看到客戶最近活動」這類症狀，要繼續往下挖，找出組織真正想解決的根本問題，否則做出來的方案可能太簡化、太複雜、太晚，或根本不是使用者要的。

識別利害關係人#

利害關係人（stakeholders）是會被專案結果影響、會出資源、或會使用產出的人或單位。要做的是：

• 列出所有利害關係人
• 讓他們簽字確認對專案結束時的期望以及自己願意投入的資源
• 中途若有人換手，務必同步通知所有人並重新對齊

老闆或客戶常會「天馬行空」（blue-sky view），用不切實際的時程或不足的資源要求你達成奇蹟。專案經理的職責是讓需求與資源彼此匹配，否則一開始就注定失敗。

定義專案目標#

最具挑戰的工作之一是把不同利害關係人的期望熔合成一組可管理的目標。目標愈清楚明確，後續對「是否達成」的爭執就愈少。設定目標時用 SMART 原則：

• Specific（具體）
• Measurable（可衡量）
• Action-oriented（行動導向）
• Realistic（務實）
• Time-limited（有時限）

定義目標時，再把以下因素納入：

• 品質（Quality）：訂出品質標準與衡量方式
• 組織（Organization）：依手上人手與資源校正目標
• 溝通（Communication）：每位利害關係人需要什麼資訊？以什麼方式遞送？

決定範疇、資源與主要任務#

許多專案失敗，要不是因為承擔過頭、低估時間與金錢，就是漏掉一大塊重要工作。工作分解結構（Work Breakdown Structure, WBS） 是常用工具，把複雜活動拆分成最小可管理的單位。

建立 WBS 的方法：

• 不斷問「為了完成 X，必須做哪些事？」直到拆到不能再拆
• 估算每個小任務需要的工時與成本
• 一般 WBS 有三到六層，超大專案才會超過十層，最多不應超過 20 層

在規劃階段先別煩惱任務的先後順序，那是建構階段的事。WBS 只是先建好骨架，等到清楚人手、預算、時間後再往裡填。為降低風險而**保留緩衝（padding）**是可接受的，但要公開告知利害關係人理由。

為取捨做準備#

時間、成本、品質這三者通常彼此牽動：

品質 = 時間 + 成本

任何一者改變，結果就會改變。例如資料庫專案的時程突然砍半，要嘛多請一倍人力，要嘛接受成品功能縮水。關鍵在於設定一個能滿足利害關係人需求的品質水準，並隨時透明地溝通取捨後果。

從一開始就掌握每位利害關係人最在意哪一項變數，會讓你之後做調整時更游刃有餘。

建構：如何讓專案動起來#

進入建構階段，團隊開始集結，估算化為具體的時程與預算，承諾也在此階段彼此交付。

組成團隊#

從 WBS 推回來看，這個專案需要哪些技能？哪些人手？必要時引入臨時人員或內部其他單位的同仁。訓練的時間與費用也要編入預算，補上能力缺口。

規劃指派#

如果是自己組的團隊或熟悉的成員，通常可以直接分派。若團隊全是新面孔：

• 列出團隊成員、列出所需技能
• 與每位成員聊聊各自的能力與興趣
• 再做配對

主動與成員溝通能力與興趣，會啟動團隊的溝通與向心力。專案經理一旦把工作交出去，就要放手讓團隊做事，但仍要記得：最終結果由你負責。

有效授權的小撇步#

• 認識並信任團隊成員的能力
• 聚焦結果，不過度介入「怎麼做」
• 把授權當作培養成員技能的機會
• 永遠把工作授權到能勝任的最低層級
• 清楚說明任務並提供足夠資源
• 拒絕「反向授權」（reverse delegation）：不要替成員作決定，而是和他一起想替代方案

建立時程#

理想上，計算出該做的事與資源後，可推算需要多少時間；現實是大多數專案的起訖日期都已被框死。要在固定範圍內建立可行時程，從死線（drop-dead deadlines）回推：

1. 從 WBS 列出活動，找出對成果有關鍵影響的任務
2. 為每個任務指派一項可交付物（deliverable），如「完成問卷草稿」
3. 用 deliverable 安排合理的截止日
4. 找出可能拖累時程的瓶頸
5. 想辦法移除瓶頸，或預留緩衝
6. 建立更新與溝通機制以便修訂時程
7. 持續讓所有利害關係人知道進度與時程變動

排程工具方面，會用到關鍵路徑法（Critical Path Method, CPM）、計畫評核術圖（Program Evaluation and Review Technique, PERT chart） 來決定任務順序，以及甘特圖（Gantt chart） 呈現時序與時長。後續章節會深入這些工具。

啟動會議#

選好成員、訂好時程後，立刻召開啟動會議（kickoff meeting）。會議中要：

• 詳細回顧計畫與目標
• 確認時程
• 釐清角色與職責
• 鼓勵成員指出可能的問題與改進空間

對於團隊成員比你更有經驗的領域，特別要把他們的建議放心上，並據此調整估算與計畫。

編列預算#

建立預算的核心問題是：「實際把工作做完，要花多少？」。把費用拆成下列類別：

• 人力（Personnel）：員工與外包，含經常性與臨時費用，通常占最大宗
• 差旅（Travel）：是否需要把人從別的地點調來
• 訓練（Training）：是否需差旅、是否需教導使用者
• 物料（Supplies）：除了一般電腦軟體外的特殊需求
• 空間（Space）：是否需搬遷？空間需求與維護費？
• 研究（Research）：要外購研究資料還是自己做？
• 資本支出（Capital expenditures）：是否需添購昂貴設備或升級？回收方式？
• 管理費（Overhead）：是否符合公司的標準比率？

把表格填完後，找一位信得過的同仁問問「你有沒有漏掉什麼？」。常被遺漏的項目包括保險、執照費、法律或會計支援。

預算終究只是「最佳猜測」，實際數字一定會跟原估有落差，要在時間、品質與總金額的限制內保留最大彈性。

執行：如何把計畫變成現實#

執行階段往往最有成就感（事情真的在動），但細節繁瑣也最容易令人窒息。

監控進度與預算#

• 維持全景視角，避免被細節吞沒
• 沒有一套方法適用所有專案：大型專案的制度套到小專案會被表單壓死；小專案的方法套到大專案則撐不住
• 對新資料快速反應、看出問題的早期跡象並採取矯正動作（corrective action）——若只看不動，那只是「監控」而非「控制」
• 收到問題的時效要清楚溝通給團隊（一般週報就足夠）
• 不要太快跳下去修，讓成員自己解決小問題
• 緊盯實際數字與預算的差距，並能解釋無可避免的超支（加班、顧問費、匯率等）

進度回報#

利害關係人通常希望定期收到狀態更新。和他們討論：頻率、格式、內容深度。

不要隱匿或淡化問題。若提早告知，利害關係人往往會成為解決問題的資源；若拖到最後才講，問題會升級為危機。

每週團隊會議#

陷入細節時很容易被旁支岔開。每週聚一次，定期問自己：「對這個專案的成功而言，現在什麼最關鍵？」會議規範：

• 議程要明確，圍繞產出量、收入目標或其他績效指標
• 從未達標、達標、超標的項目自然延伸出議題
• 每週追蹤待辦並把它們連回整體績效指標
• 慶祝小勝利——能在邁向長期目標的過程中持續點燃團隊熱情

處理進度落後的對策#

在認定「這次注定要延期」之前，先試試以下方法：

• 與利害關係人重新協商：增加預算或延後死線
• 用後續步驟補回時間：重看後段預算與時程能否補上
• 縮窄範疇：能否拿掉非必要元素以省時省錢
• 投入更多資源：加人、加設備（與成本權衡）
• 接受替代方案：用便宜或現貨的替代品
• 找替代來源：別處能否取得欠缺項目
• 接受部分交付：先收已備妥的部分，剩下的後補
• 提供激勵：用獎金或誘因促成準時交付
• 強制兌現：要求對方履約（小心使用，可能傷害關係）

處理問題#

四種常見的大問題：

1. 時間滑落（Time slippage）：專案最常見的問題。延誤難以完全避免，但通常可以改善——關鍵是先承認自己落後了
2. 範疇蔓延（Scope creep）：當利害關係人要求更動，必須清楚說明對成本、時間、品質的影響。別捲入既定範疇之外的問題，即使那個問題公司也很急
3. 品質問題（Quality issues）：別為趕進度而犧牲必要的品質檢查；用合適工具（檢視、檢核表、統計抽樣等）決定是否接受或退回交付
4. 人員問題（People problems）：通常最難處理。靠頻繁溝通預防——僅靠週會可能不夠，必要時每天溝通

注意小徵兆：成員緊繃易怒、失去熱情、無法決策。及早抓出問題核心並處理，別讓小事演變成災難。

收尾：如何處理結尾事務#

每個專案終究會結束。專案經理要決定：何時結束、怎麼結束。

評估專案績效#

結案前，團隊要不就達成目標，要不就與利害關係人共同確認「這些目標已不再適用」。把進度對照當初共識的範疇做比較，再與利害關係人對齊「完成度」。

結案#

收尾步驟取決於團隊是否自留產出、移交給組織、或必須中止整個專案。後續章節會詳細介紹這三種收尾方式。即使不順利（拖延、成果縮水、超支），仍要肯定團隊的努力與成就。

與團隊回顧#

務必排定後評估會議（post-evaluation）：debrief 並把流程記錄下來，讓「學到的教訓」（lessons learned）能被分享。

後評估是「探索的場合」，不是「批判與咎責的場合」。若成員擔心被秋後算帳，反而會藏起問題，無從學起。

產出後評估報告#

後評估報告對未來的專案經理也有用。報告應涵蓋：

• 團隊洞察：debrief 中識別出哪些教訓應在未來沿用？
• 未來狀態：專案結束後何去何從？是更大專案的一部分，還是一個自成體系的成果？
• 進行中關鍵任務的狀態：技術風險高、或由外部供應商承擔的任務目前狀況如何？
• 風險評估：是否曾出現或可能造成財務損失、專案失敗、其他責任？
• 稽核限制：後評估的可信度有沒有疑義？資訊是否齊全？是否有人不願提供細節？

專案管理辦公室（PMO）#

大型公司常設置專案管理辦公室（Project Management Office, PMO），可能負責下列工作的組合：

• 建立流程與範本，引導專案經理規劃與執行
• 為事業領導人、專案經理、團隊成員提供教練與協助
• 直接管理專案以達成目標（高度矩陣化的組織通常不會由 PMO 直接負責）

一個運作良好的 PMO 會幫每個專案團隊發展合適的計畫、合理估算風險、追蹤進度，同時保留偏離標準流程的彈性。

累積成資產#

專案結束後，你累積到的知識、技能與人脈都是可重用的資產。訣竅是：在下一個專案中繼續使用它們。

改寫自：Pocket Mentor: Managing Projects（product #1878），Harvard Business Review Press, 2006