專案管理指引

目錄

  1. 專案管理概述
  2. 專案生命週期與階段管理
  3. 專案啟動階段
  4. 專案規劃階段
  5. 專案執行階段
  6. 專案監控階段
  7. 專案收尾階段
  8. 風險管理
  9. 溝通與會議管理
  10. 文件與報告管理
  11. 品質管理
  12. 採購與供應商管理
  13. 人力資源管理
  14. 利害關係人管理
  15. 專案整合管理
  16. 敏捷專案管理
  17. 專案管理成熟度
  18. 附錄：範例與模板

1. 專案管理概述

1.1 專案管理定義

專案管理是運用知識、技能、工具與技術於專案活動，以滿足專案需求的管理過程。對於金融 IT 專案而言，更需要嚴格遵循 SSDLC（安全軟體開發生命週期）規範。

1.2 專案管理核心原則

  • 明確的目標設定：每個專案都必須有清楚、可衡量的目標
  • 時程與資源控管：有效管理時間、人力、預算等資源
  • 品質保證：確保交付成果符合既定標準
  • 風險管控：主動識別、評估與應對專案風險
  • 持續溝通：建立有效的溝通機制與管道

1.3 專案管理五大流程群組

  1. 啟動（Initiating）：定義專案範圍與目標
  2. 規劃（Planning）：制定詳細執行計畫
  3. 執行（Executing）：實際進行專案工作
  4. 監控（Monitoring & Controlling）：追蹤進度並進行調整
  5. 收尾（Closing）：完成專案並進行經驗傳承

1.4 金融 IT 專案特色

  • 高度安全性要求（須符合金管會、國際標準）
  • 嚴格的法規遵循（如個資法、洗錢防制法）
  • 複雜的系統整合需求
  • 24/7 營運環境的穩定性要求
  • 大量的測試與驗證程序

實務案例

某銀行數位帳戶開發專案，專案經理運用 Agile 方法論，將 12 個月的專案分為 6 個 Sprint，每個 Sprint 2 個月。透過每日站立會議、Sprint 回顧會議等機制，成功在預定時程內上線，並獲得客戶滿意度 95% 的佳績。

2. 專案生命週期與階段管理

2.1 專案生命週期概述

專案生命週期是從專案啟動到結束的完整過程，每個階段都有特定的目標、活動與交付成果。

2.2 階段劃分方式

傳統瀑布式（Waterfall）

適用於需求明確、變更較少的專案

  • 需求分析 → 系統設計 → 程式開發 → 測試 → 部署 → 維護

敏捷式（Agile）

適用於需求可能變更、需要快速回應的專案

  • 迭代式開發，每個 Sprint 包含完整的開發週期

混合式（Hybrid）

結合瀑布式與敏捷式的優點

  • 前期採瀑布式進行需求與設計
  • 開發階段採敏捷式迭代

2.3 階段管控機制

階段檢核點（Stage Gate）

每個階段結束前必須通過檢核點才能進入下一階段：

  • 交付成果是否完成
  • 品質標準是否達成
  • 預算與時程是否符合預期
  • 風險是否在可控範圍內

里程碑管理（Milestone Management）

設定關鍵里程碑作為專案進度指標：

  • 需求確認完成
  • 系統設計評審通過
  • 開發階段完成
  • 使用者驗收測試通過
  • 系統正式上線

2.4 階段交付成果

每個階段都應該有明確的交付成果（Deliverable）：

階段主要交付成果
啟動專案章程、利害關係人名冊
規劃專案管理計畫、WBS、時程表
執行系統功能、測試報告
監控進度報告、變更申請
收尾驗收文件、經驗分享報告

實務案例

某保險公司理賠系統升級專案，專案經理採用階段檢核點機制。在系統設計階段結束時，發現原始需求有重大遺漏，立即召開變更控制委員會會議，重新評估專案範圍與時程，避免了後續更大的損失。

3. 專案啟動階段

3.1 專案啟動目標

專案啟動階段的主要目標是正式授權專案開始，並建立專案的基本框架。

3.2 關鍵活動清單

3.2.1 專案發起與評估

  • 商業需求分析：了解專案的商業價值與必要性
  • 可行性評估：技術、財務、時程可行性分析
  • 效益評估：量化專案預期效益（ROI、NPV 等）
  • 替代方案評估：比較不同解決方案的優缺點

3.2.2 專案章程制定

專案章程是專案的正式授權文件，包含：

  • 專案目標與成功標準
  • 高階需求與假設條件
  • 專案範圍邊界
  • 預算與時程概估
  • 專案經理授權範圍
  • 主要風險與限制條件

3.2.3 利害關係人識別

識別所有可能影響或受專案影響的人員：

  • 內部利害關係人：專案團隊、高階主管、使用者部門
  • 外部利害關係人：客戶、供應商、主管機關
  • 利害關係人分析：影響力與利益關係矩陣分析

3.3 專案啟動檢核清單

  • 專案章程已獲得高階主管核准
  • 專案經理已正式指派
  • 主要利害關係人已識別
  • 初始風險已識別並記錄
  • 專案成功標準已明確定義
  • 預算與資源已初步確認

3.4 啟動階段常見陷阱

避免事項

  • 範圍模糊：專案目標與範圍定義不清楚
  • 利害關係人遺漏：未完整識別所有相關人員
  • 期望管理不當：對專案成果的期望過高或不切實際
  • 資源評估不足：低估所需人力、時間或預算

最佳實務

  • 舉辦專案啟動會議（Project Kick-off Meeting）
  • 建立專案團隊溝通群組
  • 制定專案溝通計畫
  • 設立專案工作區域與工具

實務案例

某證券公司電子交易平台開發專案，在啟動階段發現業務單位對系統功能期望與 IT 部門的技術評估有很大落差。專案經理立即安排需求澄清會議，重新調整專案範圍，並修正專案章程，避免了後續執行階段的重大衝突。

4. 專案規劃階段

4.1 專案規劃目標

專案規劃階段的主要目標是制定詳細的專案執行計畫，為專案執行提供明確的指引。

4.2 工作分解結構（WBS）

4.2.1 WBS 建立原則

  • 階層化分解：將專案工作逐層分解至可管理的工作包
  • 100% 規則：子項目總和等於上層項目
  • 互斥性：各工作包之間不重疊
  • 可衡量性：每個工作包都有明確的完成標準

4.2.2 WBS 範例（金融系統開發）

1. 專案管理
   1.1 專案啟動
   1.2 專案規劃
   1.3 專案執行管控
   1.4 專案收尾

2. 需求分析
   2.1 業務需求收集
   2.2 功能需求分析
   2.3 非功能需求分析
   2.4 需求文件撰寫

3. 系統設計
   3.1 系統架構設計
   3.2 資料庫設計
   3.3 介面設計
   3.4 安全設計

4. 系統開發
   4.1 前端開發
   4.2 後端開發
   4.3 資料庫建置
   4.4 整合測試

5. 系統測試
   5.1 單元測試
   5.2 整合測試
   5.3 系統測試
   5.4 使用者驗收測試

6. 系統上線
   6.1 上線準備
   6.2 系統部署
   6.3 監控與調校
   6.4 使用者教育訓練

4.3 時程規劃

4.3.1 活動排序與相依性

  • 前置關係：識別活動間的邏輯關係
  • 關鍵路徑法（CPM）：找出專案的關鍵路徑
  • 緩衝時間管理：為高風險活動預留時間緩衝

4.3.2 工期估算技巧

  • 三點估算法：樂觀值、悲觀值、最可能值
  • 專家判斷法：諮詢領域專家經驗
  • 類比估算法：參考類似專案的歷史數據
  • 參數估算法：運用統計模型進行估算

4.4 資源規劃

4.4.1 人力資源規劃

  • 技能需求分析：識別所需技能與經驗
  • 角色與職責定義：明確團隊成員職責
  • 組織架構圖：建立專案組織架構
  • 人力取得計畫：規劃人員招募與訓練

4.4.2 預算規劃

  • 成本估算：直接成本、間接成本、管理成本
  • 預算分配：按階段或工作包分配預算
  • 應急準備金：預留風險應對資金
  • 成本基準：建立成本績效衡量基準

4.5 風險規劃

4.5.1 風險識別

  • 腦力激盪法：團隊共同識別潛在風險
  • 檢核表法：使用風險檢核清單
  • 專家訪談法：諮詢領域專家意見
  • 歷史資料分析：參考過去專案的風險經驗

4.5.2 風險評估

  • 機率影響矩陣：評估風險發生機率與影響程度
  • 風險優先順序排列：依據風險評分排定處理優先順序
  • 定性與定量分析：全面評估風險影響

4.6 規劃階段檢核清單

  • WBS 已完成並經確認
  • 專案時程已建立並合理
  • 資源需求已明確定義
  • 預算已編列並獲核准
  • 風險登錄表已建立
  • 品質管理計畫已制定
  • 溝通管理計畫已建立
  • 採購管理計畫已制定

實務案例

某銀行核心系統改版專案，專案經理在規劃階段發現原估算的開發時程過於樂觀。透過重新進行三點估算，並加入 20% 的時程緩衝，最終專案按時完成，避免了延期的風險。

5. 專案執行階段

5.1 專案執行目標

專案執行階段的主要目標是按照專案管理計畫執行專案工作，並管理團隊以完成專案交付成果。

5.2 團隊管理

5.2.1 團隊建立

  • 團隊組建：確定團隊成員並建立工作關係
  • 團隊發展：協助團隊渡過形成期、風暴期、規範期到執行期
  • 團隊激勵：運用各種激勵方式提升團隊士氣
  • 衝突管理：主動處理團隊內部衝突

5.2.2 團隊發展階段

  1. 形成期（Forming）：團隊成員剛組成，彼此了解有限
  2. 風暴期（Storming）：開始出現意見分歧與衝突
  3. 規範期（Norming）：建立共同工作規範與默契
  4. 執行期（Performing）：團隊運作順暢，高效執行任務
  5. 結束期（Adjourning）：專案完成，團隊解散

5.2.3 團隊管理技巧

  • 委派管理：適當分配工作並給予權限
  • 定期檢視：定期與團隊成員進行一對一會談
  • 認可激勵：及時認可團隊成員的貢獻
  • 技能發展：提供訓練機會提升團隊能力

5.3 工作執行管理

5.3.1 工作分派與追蹤

  • 任務指派：明確指派工作給具備適當技能的成員
  • 進度追蹤：定期檢查工作進度與品質
  • 問題解決：及時處理執行過程中遇到的問題
  • 資源協調：確保團隊有足夠資源完成工作

5.3.2 品質管理

  • 品質保證（QA）：確保工作過程符合既定標準
  • 品質控制（QC）：檢驗工作成果是否達到品質要求
  • 持續改善：根據回饋持續改善工作流程
  • 最佳實務分享：在團隊內分享成功經驗

5.4 變更管理

5.4.1 變更控制流程

  1. 變更申請：正式提出變更需求
  2. 影響評估：評估變更對專案的影響
  3. 變更審查：變更控制委員會進行審查
  4. 決策執行：核准或拒絕變更申請
  5. 變更實施：執行已核准的變更

5.4.2 變更管理最佳實務

  • 建立變更控制委員會：由關鍵利害關係人組成
  • 制定變更評估標準：明確變更評估的準則
  • 記錄所有變更：完整記錄變更歷程
  • 溝通變更影響：及時向所有相關人員溝通變更

5.5 執行階段常見挑戰

5.5.1 範圍蔓延（Scope Creep）

  • 成因：需求不明確、利害關係人期望管理不當
  • 應對：嚴格執行變更控制流程、定期確認專案範圍

5.5.2 資源衝突

  • 成因：多專案資源競爭、資源技能不匹配
  • 應對：建立資源協調機制、提前進行資源規劃

5.5.3 溝通問題

  • 成因：溝通管道不暢、資訊傳遞失真
  • 應對：建立正式溝通機制、定期檢視溝通效果

實務案例

某保險公司新商品系統開發專案，在執行階段發現開發團隊與測試團隊對需求理解不一致。專案經理立即安排需求釐清會議，並建立每日同步機制，確保所有團隊成員對需求有一致的理解。

6. 專案監控階段

6.1 專案監控目標

專案監控階段的主要目標是追蹤、檢視和調節專案進度和績效，以確保專案目標能夠達成。

6.2 績效監控指標

6.2.1 進度績效指標

  • 計畫完成百分比：實際完成工作與計畫工作的比較
  • 里程碑達成率：按時達成里程碑的比例
  • 關鍵路徑監控：關鍵路徑上活動的進度狀況
  • 工期績效指數（SPI）：掙值管理中的進度指標

6.2.2 成本績效指標

  • 預算執行率：實際支出與預算的比較
  • 成本績效指數（CPI）：掙值管理中的成本指標
  • 完工估算（EAC）：專案完成時的預估總成本
  • 剩餘工作成本：完成剩餘工作所需的成本

6.2.3 品質績效指標

  • 缺陷率：發現的缺陷數量與總工作量的比例
  • 返工率：需要重新執行的工作比例
  • 客戶滿意度：利害關係人對專案的滿意程度
  • 測試通過率：測試案例的通過比例

6.3 掙值管理（EVM）

6.3.1 掙值管理三要素

  • 計畫價值（PV）：按計畫應該完成的工作預算
  • 掙值（EV）：實際完成工作的預算價值
  • 實際成本（AC）：實際完成工作所花費的成本

6.3.2 關鍵績效指標

  • 成本變異（CV）= EV - AC
    • CV > 0：成本節省
    • CV < 0：成本超支
  • 進度變異（SV）= EV - PV
    • SV > 0：進度超前
    • SV < 0：進度落後
  • 成本績效指數（CPI）= EV / AC
  • 進度績效指數（SPI）= EV / PV

6.4 進度監控工具

6.4.1 甘特圖（Gantt Chart）

  • 視覺化時程：清楚顯示專案時程與進度
  • 相依關係：顯示活動間的邏輯關係
  • 關鍵路徑：標示影響專案完成日期的關鍵活動
  • 進度更新：定期更新實際進度

6.4.2 燃盡圖（Burndown Chart）

  • 剩餘工作量：顯示剩餘工作量隨時間的變化
  • 進度趨勢：預測專案完成時間
  • 敏捷專案適用：特別適用於 Agile 專案管理

6.5 定期檢視會議

6.5.1 每日站立會議（Daily Standup）

  • 時間：每日固定時間，15 分鐘內
  • 參與者：專案團隊核心成員
  • 討論內容：
    • 昨天完成了什麼？
    • 今天計畫做什麼？
    • 遇到什麼障礙？

6.5.2 週度進度會議

  • 時間：每週固定時間，30-60 分鐘
  • 參與者：專案團隊與主要利害關係人
  • 討論內容：
    • 本週進度報告
    • 下週工作計畫
    • 風險與問題討論
    • 資源需求協調

6.5.3 月度指導委員會

  • 時間：每月固定時間，60-90 分鐘
  • 參與者：高階主管與專案經理
  • 討論內容：
    • 專案整體狀況報告
    • 重大議題與決策
    • 預算與資源檢視
    • 下月工作重點

6.6 問題與風險管控

6.6.1 問題管理流程

  1. 問題識別：發現並記錄問題
  2. 問題分析：分析問題原因與影響
  3. 解決方案：制定問題解決方案
  4. 執行追蹤：執行解決方案並追蹤結果
  5. 結案確認：確認問題已解決並結案

6.6.2 風險監控機制

  • 風險登錄表更新：定期更新風險狀況
  • 風險指標監控：監控風險預警指標
  • 應變計畫啟動：必要時啟動應變計畫
  • 新風險識別：持續識別新的專案風險

實務案例

某金融科技公司支付系統專案，專案經理運用掙值管理發現專案成本績效指數（CPI）降至 0.8，立即召開緊急會議分析原因，發現是第三方 API 整合比預期複雜。透過重新分配資源並調整工作優先順序，最終將 CPI 拉回到 0.95，專案成功在預算內完成。

7. 專案收尾階段

7.1 專案收尾目標

專案收尾階段的主要目標是正式結束專案，確保所有工作完成，並進行經驗總結與知識移轉。

7.2 收尾活動清單

7.2.1 交付成果驗收

  • 功能驗收：確認所有功能符合需求規格
  • 效能驗收：驗證系統效能達到預期標準
  • 安全驗收：確認安全機制符合資安要求
  • 使用者驗收：取得最終使用者的正式認可

7.2.2 文件整理與歸檔

  • 專案文件整理：整理所有專案相關文件
  • 技術文件完善：完成系統操作手冊、維護手冊
  • 知識庫建立：將專案經驗納入組織知識庫
  • 文件歸檔：按照組織標準進行文件歸檔

7.2.3 系統移交

  • 維運移交：將系統移交給維運團隊
  • 知識移轉：進行技術知識與經驗移轉
  • 支援安排：安排專案團隊提供初期支援
  • 監控機制：建立系統上線後的監控機制

7.3 合約結案

7.3.1 供應商合約結案

  • 交付驗收：確認供應商交付成果符合合約要求
  • 付款結算：完成所有款項結算
  • 保固安排：確認保固期與保固範圍
  • 合約歸檔：完成合約文件歸檔

7.3.2 內部資源釋放

  • 人員釋放：釋放專案團隊成員回到原部門
  • 設備歸還：歸還借用的設備與資源
  • 預算結案：完成專案預算的最終結算
  • 空間釋放：歸還專案使用的辦公空間

7.4 專案評估與總結

7.4.1 專案成功度評估

  • 目標達成度：評估專案目標的達成情況
  • 時程績效：分析專案時程執行狀況
  • 成本績效：評估專案成本控制效果
  • 品質績效：檢視專案交付成果品質

7.4.2 利害關係人滿意度調查

  • 滿意度問卷：設計並發放滿意度調查問卷
  • 訪談回饋：與關鍵利害關係人進行深度訪談
  • 改善建議：收集未來改善的建議
  • 滿意度報告：撰寫滿意度調查報告

7.5 經驗學習與分享

7.5.1 專案回顧會議（Retrospective）

  • 成功經驗分享：總結專案成功的關鍵因素
  • 問題分析討論：分析專案過程中遇到的問題
  • 改善建議提出：提出未來專案的改善建議
  • 最佳實務萃取：萃取可複製的最佳實務

7.5.2 經驗學習文件

  • 專案總結報告：撰寫完整的專案總結報告
  • 經驗學習清單：列出具體的經驗學習事項
  • 最佳實務文件：記錄可供參考的最佳實務
  • 問題解決案例：記錄典型問題的解決方案

7.6 慶祝與認可

7.6.1 團隊慶祝活動

  • 專案慶祝會：舉辦專案完成慶祝活動
  • 成果展示：展示專案成果與團隊貢獻
  • 感謝表達：向團隊成員表達感謝
  • 紀念品發送：製作專案紀念品

7.6.2 個人認可與獎勵

  • 績效評估：進行團隊成員績效評估
  • 獎勵發放：根據貢獻程度給予適當獎勵
  • 推薦表揚：向上級推薦表現優異的成員
  • 職涯發展：協助優秀成員的職涯發展

7.7 收尾階段檢核清單

  • 所有交付成果已完成並通過驗收
  • 專案文件已整理完成並歸檔
  • 合約已結案並完成付款
  • 專案團隊已解散並釋放資源
  • 專案評估報告已完成
  • 經驗學習已記錄並分享
  • 利害關係人滿意度調查已完成
  • 後續支援安排已確認

實務案例

某銀行數位轉型專案完成後，專案經理舉辦為期兩天的專案回顧工作坊。透過世界咖啡館的方式，讓所有團隊成員分享專案經驗，最終產出 30 項最佳實務和 15 項改善建議，成為後續專案的重要參考資料。

8. 風險管理

8.1 風險管理目標

風險管理的主要目標是增加正面事件的機率與影響，減少負面事件的機率與影響，確保專案能在可控的風險範圍內達成目標。

8.2 風險管理流程

8.2.1 風險管理規劃

  • 風險管理策略：定義風險管理的方法與標準
  • 風險類別定義：建立專案風險分類架構
  • 風險容忍度：設定組織可接受的風險程度
  • 角色與職責：明確風險管理的角色分工

8.2.2 風險識別

  • 腦力激盪：召集團隊進行風險識別會議
  • 德爾菲技術：透過專家匿名意見收集風險
  • SWOT 分析：分析優勢、劣勢、機會、威脅
  • 檢核表法：使用歷史風險清單進行檢核

8.2.3 風險分析

定性風險分析
  • 機率評估：評估風險發生的可能性
  • 影響評估：評估風險對專案目標的影響程度
  • 機率影響矩陣：將風險按機率和影響分類排序
影響/機率很低(0.1)低(0.3)中(0.5)高(0.7)很高(0.9)
很高(0.8)0.080.240.400.560.72
高(0.6)0.060.180.300.420.54
中(0.4)0.040.120.200.280.36
低(0.2)0.020.060.100.140.18
很低(0.1)0.010.030.050.070.09
定量風險分析
  • 期望貨幣值（EMV）：計算風險的期望損失
  • 決策樹分析：分析不同決策路徑的風險
  • 蒙地卡羅模擬：進行風險的機率分析
  • 敏感度分析：分析變數對專案的影響程度

8.3 風險應對策略

8.3.1 負面風險應對策略

  • 迴避（Avoid）：改變專案計畫以消除風險
  • 轉移（Transfer）：將風險轉移給第三方（如保險、外包）
  • 減輕（Mitigate）：降低風險發生機率或影響程度
  • 接受（Accept）：承認風險存在但不採取主動應對

8.3.2 正面風險應對策略

  • 開拓（Exploit）：確保機會一定會實現
  • 分享（Share）：與第三方分享機會的好處
  • 提升（Enhance）：增加機會發生的機率或影響
  • 接受（Accept）：承認機會但不主動追求

8.3.3 應變計畫

  • 觸發條件：明確定義啟動應變計畫的條件
  • 應變行動：詳細描述應變措施與步驟
  • 責任分工：指派應變計畫的執行責任
  • 資源需求：準備應變計畫所需的資源

8.4 常見風險類型

8.4.1 技術風險

  • 技術可行性：新技術的成熟度與穩定性
  • 技術整合：系統間整合的複雜性
  • 效能風險：系統效能無法達到要求
  • 安全風險：資訊安全漏洞與威脅

8.4.2 專案管理風險

  • 範圍變更：需求變更導致範圍擴大
  • 時程延誤：工作進度落後預定計畫
  • 資源不足：人力、設備、預算不足
  • 溝通問題：資訊傳遞不當或失真

8.4.3 組織風險

  • 關鍵人員異動：重要成員離職或調動
  • 政策變更：組織政策或策略改變
  • 優先順序衝突：與其他專案的資源競爭
  • 利害關係人衝突：不同利害關係人期望衝突

8.4.4 外部風險

  • 法規變更：相關法規或標準變更
  • 供應商問題：供應商無法履行合約
  • 市場變化：市場環境或競爭狀況改變
  • 天災人禍：不可抗力因素影響

8.5 風險監控與控制

8.5.1 風險監控指標

  • 風險趨勢：追蹤風險數量與嚴重程度變化
  • 風險觸發指標：監控可能引發風險的預警信號
  • 應對措施執行狀況：追蹤風險應對計畫的執行進度
  • 剩餘風險評估：評估應對措施後的剩餘風險

8.5.2 風險報告

  • 風險狀況摘要：定期報告整體風險狀況
  • 新增風險報告：報告新識別的風險
  • 風險變更報告：報告風險狀況的變化
  • 風險結案報告：報告已解決或過期的風險

8.6 風險登錄表範例

風險ID風險描述風險類別機率影響風險評分應對策略負責人狀態
R001關鍵開發人員離職組織風險中高0.30減輕專案經理進行中
R002第三方API異常技術風險低高0.21轉移技術主管已解決
R003法規要求變更外部風險高中0.35接受法務主管監控中

實務案例

某電商平台重構專案中，專案經理識別出「關鍵技術人員可能在專案中期離職」的高風險。採用減輕策略，提前安排知識移轉、交叉訓練，並準備外部技術顧問作為後備。當該風險真的發生時，專案只延誤了 1 週，大大降低了原本可能造成 2 個月延誤的衝擊。

9. 溝通與會議管理

9.1 溝通管理目標

溝通管理的主要目標是確保專案資訊能及時、準確地產生、收集、分發、儲存和處置，讓所有利害關係人都能獲得必要的專案資訊。

9.2 溝通管理規劃

9.2.1 利害關係人溝通需求分析

  • 溝通需求：分析各利害關係人的資訊需求
  • 溝通偏好：了解偏好的溝通方式與頻率
  • 溝通權限：確定不同層級可接收的資訊範圍
  • 語言與文化：考慮多元文化的溝通需求

9.2.2 溝通方法選擇

  • 同步溝通：會議、電話會議、視訊會議
  • 非同步溝通：電子郵件、專案平台、文件分享
  • 正式溝通：正式報告、會議紀錄、官方公告
  • 非正式溝通：走廊談話、咖啡時間、即時通訊

9.2.3 溝通管道建立

  • 專案入口網站：建立專案資訊集中平台
  • 通訊軟體群組：建立即時溝通管道
  • 定期報告機制：建立固定的報告流程
  • 緊急溝通程序：建立緊急情況的溝通流程

9.3 會議管理

9.3.1 會議類型與目的

專案啟動會議（Kick-off Meeting）
  • 目的：正式啟動專案，建立團隊共識
  • 參與者：所有專案團隊成員與主要利害關係人
  • 內容：專案目標、範圍、角色職責、溝通方式
  • 時間：專案啟動階段，半天到一天
每日站立會議（Daily Standup）
  • 目的：同步進度、識別障礙、協調工作
  • 參與者：專案核心團隊成員
  • 內容：昨天完成、今天計畫、遇到障礙
  • 時間：每日 15 分鐘
週度進度會議
  • 目的：檢視週度進度、討論問題、協調資源
  • 參與者：專案團隊與相關利害關係人
  • 內容：進度報告、問題討論、下週計畫
  • 時間：每週 60-90 分鐘
月度指導委員會
  • 目的：高層決策、重大議題討論、方向確認
  • 參與者：高階主管、專案經理、關鍵利害關係人
  • 內容：專案狀況報告、重大決策、預算檢視
  • 時間：每月 60-120 分鐘

9.3.2 高效會議技巧

會議前準備
  • 議程設定：提前發送詳細議程
  • 資料準備：準備相關資料與簡報
  • 參與者通知：確認參與者出席狀況
  • 設備檢查：確認會議室與設備正常
會議進行管控
  • 時間控制：嚴格控制會議時間
  • 議程執行：按議程順序進行討論
  • 參與鼓勵：鼓勵所有成員參與討論
  • 決議記錄：即時記錄決議與行動項目
會議後追蹤
  • 會議紀錄：24 小時內發送會議紀錄
  • 行動項目追蹤：明確行動項目的負責人與期限
  • 決議執行：追蹤決議的執行狀況
  • 回饋收集：收集參與者對會議的回饋

9.4 溝通工具與平台

9.4.1 專案管理工具

  • Microsoft Project：甘特圖、資源管理、進度追蹤
  • Jira：敏捷專案管理、問題追蹤、看板管理
  • Trello：看板式任務管理、簡單易用
  • Asana：團隊協作、任務分派、進度可視化

9.4.2 溝通協作工具

  • Microsoft Teams：視訊會議、即時通訊、檔案共享
  • Slack：團隊溝通、頻道管理、整合應用
  • Zoom：視訊會議、螢幕分享、會議錄影
  • Discord：語音通話、即時聊天、社群管理

9.4.3 文件協作工具

  • SharePoint：文件管理、版本控制、權限管理
  • Google Workspace：即時協作、雲端儲存、線上編輯
  • Confluence：知識管理、文件協作、團隊空間
  • OneDrive：檔案同步、版本歷程、離線存取

9.5 溝通挑戰與解決方案

9.5.1 常見溝通問題

資訊過載
  • 問題：接收過多不相關的資訊
  • 解決：建立資訊分層機制，按需發送
資訊滯後
  • 問題：重要資訊無法及時傳達
  • 解決：建立緊急溝通機制，設定資訊即時通知
理解偏差
  • 問題：接收者對資訊理解有誤
  • 解決：要求回饋確認，使用多種溝通方式
文化差異
  • 問題：跨文化團隊溝通障礙
  • 解決：提供文化敏感度訓練，使用共通語言

9.5.2 虛擬團隊溝通

時區差異管理
  • 輪流會議時間：輪流安排對不同時區友善的會議時間
  • 非同步溝通：善用非同步溝通工具減少即時溝通需求
  • 會議錄影：錄製重要會議供無法參與者觀看
文化融合
  • 虛擬咖啡時間：安排非正式的線上聚會
  • 文化分享：鼓勵團隊成員分享各自文化背景
  • 共同規範：建立團隊共同的工作規範與溝通準則

9.6 溝通效果評估

9.6.1 溝通效果指標

  • 資訊到達率：重要資訊的接收確認比例
  • 回應時間：對緊急訊息的平均回應時間
  • 理解準確度：資訊理解的正確性評估
  • 滿意度調查：利害關係人對溝通的滿意程度

9.6.2 持續改善機制

  • 定期回顧：定期檢視溝通效果與問題
  • 流程優化：根據回饋改善溝通流程
  • 工具更新：評估並更新溝通工具
  • 訓練加強：針對溝通問題提供額外訓練

實務案例

某跨國金融專案團隊分布在台北、新加坡、倫敦三地。專案經理建立了三時區輪流主持的每日站立會議制度，並使用 Slack 進行非同步溝通。透過建立共同的工作時間窗口（亞洲下午 = 歐洲上午），大大提升了跨時區協作效率，專案溝通滿意度從 65% 提升到 90%。

10. 文件與報告管理

10.1 文件管理目標

文件管理的主要目標是建立有效的文件控制機制，確保專案文件的完整性、準確性、可追溯性和可取得性。

10.2 文件管理框架

10.2.1 文件分類架構

管理類文件
  • 專案章程：專案授權與目標文件
  • 專案管理計畫：整體專案執行計畫
  • 工作分解結構（WBS）：專案工作分解
  • 時程表：專案時程與里程碑
需求類文件
  • 商業需求文件（BRD）：商業需求與目標
  • 功能需求規格（FRS）：詳細功能需求
  • 系統分析文件（SAD）：系統分析結果
  • 使用者故事：敏捷開發需求描述
設計類文件
  • 系統架構文件：整體系統架構設計
  • 詳細設計文件：模組詳細設計規格
  • 資料庫設計文件：資料模型與 Schema 設計
  • 介面設計文件：使用者介面與 API 設計
開發類文件
  • 程式碼文件：程式碼註釋與說明
  • 開發指南：開發標準與規範
  • 部署指南：系統部署與安裝說明
  • 設定檔說明：系統設定參數說明
測試類文件
  • 測試計畫：測試策略與範圍
  • 測試案例：詳細測試步驟與預期結果
  • 測試報告：測試執行結果與缺陷報告
  • 驗收測試文件：使用者驗收測試規格
維運類文件
  • 操作手冊：系統日常操作指南
  • 維護手冊：系統維護與疑難排解
  • 監控指南：系統監控與警報設定
  • 備份復原程序：資料備份與災難復原

10.2.2 文件版本控制

版本編號規則
  • 主版本號：重大變更時遞增（1.0, 2.0, 3.0）
  • 次版本號：功能增加時遞增（1.1, 1.2, 1.3）
  • 修訂版本號：錯誤修正時遞增（1.1.1, 1.1.2）
  • 狀態標識：Draft（草稿）、Review（審查）、Final（正式）
版本控制流程
  1. 文件創建：建立初始版本（0.1 Draft）
  2. 內部審查：團隊內部審查與修正
  3. 正式審查：利害關係人正式審查
  4. 核准發布：正式核准並發布（1.0 Final）
  5. 變更管理：後續變更依流程進行

10.3 專案報告體系

10.3.1 進度報告

週度進度報告
  • 報告期間：本週工作週期
  • 主要內容：
    • 本週完成工作摘要
    • 下週計畫工作項目
    • 目前面臨問題與風險
    • 需要的支援與資源
  • 收件者：專案團隊與相關利害關係人
  • 發送頻率：每週五發送
月度進度報告
  • 報告期間：當月完整工作週期
  • 主要內容：
    • 專案整體進度狀況
    • 重要里程碑達成情況
    • 預算執行與成本分析
    • 風險管控與問題處理
    • 下月工作重點規劃
  • 收件者：高階主管與指導委員會
  • 發送頻率：每月最後一個工作日

10.3.2 狀況報告

專案儀表板（Dashboard）
  • 綠燈：專案進行順利，無重大問題
  • 黃燈：專案有輕微問題，但在控制範圍內
  • 紅燈：專案有重大問題，需要立即處理
例外報告
  • 觸發條件：
    • 進度延誤超過 10%
    • 預算超支超過 5%
    • 發生高風險事件
    • 重大變更需求
  • 報告內容：問題描述、影響分析、應對措施、需要支援

10.3.3 專案完成報告

專案總結報告
  • 專案概述：專案背景、目標、範圍
  • 成果摘要：主要交付成果與達成情況
  • 績效分析：時程、成本、品質績效分析
  • 經驗學習：成功經驗與改善建議
  • 後續建議：維運建議與未來發展方向

10.4 文件品質管控

10.4.1 文件審查機制

同儕審查（Peer Review）
  • 審查範圍：技術文件、設計文件
  • 審查人員：同職級團隊成員
  • 審查重點：技術正確性、完整性、一致性
正式審查（Formal Review）
  • 審查範圍：重要管理文件、對外文件
  • 審查人員：專案經理、部門主管、利害關係人
  • 審查重點：內容正確性、符合需求、合規性

10.4.2 文件品質標準

內容品質
  • 正確性：資訊內容準確無誤
  • 完整性：涵蓋所有必要資訊
  • 一致性：用詞與格式一致
  • 時效性：資訊保持最新狀態
格式品質
  • 標準化：遵循組織文件標準
  • 可讀性：結構清楚、易於理解
  • 可搜尋：適當的標題與關鍵字
  • 可維護：易於更新與修改

10.5 文件儲存與取得

10.5.1 文件庫管理

集中式文件庫
  • 專案資料夾結構：
專案名稱/
├── 01-管理文件/
│   ├── 專案章程
│   ├── 專案計畫
│   └── 會議紀錄
├── 02-需求文件/
│   ├── 商業需求
│   ├── 功能需求
│   └── 非功能需求
├── 03-設計文件/
│   ├── 系統架構
│   ├── 資料庫設計
│   └── 介面設計
├── 04-開發文件/
│   ├── 程式碼
│   ├── 開發指南
│   └── 部署文件
└── 05-測試文件/
    ├── 測試計畫
    ├── 測試案例
    └── 測試報告
權限管理
  • 讀取權限：依角色給予適當的文件讀取權限
  • 編輯權限：只有文件負責人可進行編輯
  • 核准權限：只有指定人員可核准文件發布
  • 存取記錄：記錄所有文件存取活動

10.5.2 文件分享機制

內部分享
  • 專案入口網站：建立專案文件入口網站
  • 雲端共享：使用雲端平台進行文件分享
  • 定期發送：定期發送重要文件更新通知
  • 搜尋功能：提供文件搜尋與索引功能
外部分享
  • 客戶入口：為客戶建立專用的文件存取入口
  • 供應商平台：與供應商建立文件交換平台
  • 安全控制：確保外部分享的安全性與權限控制
  • 版本追蹤：追蹤外部分享文件的版本與使用情況

10.6 文件管理工具

10.6.1 文件管理系統

  • SharePoint：企業文件管理平台
  • Confluence：團隊知識管理與協作
  • Google Drive：雲端文件儲存與協作
  • Box：企業級雲端文件管理

10.6.2 版本控制系統

  • Git：程式碼與文件版本控制
  • SVN：集中式版本控制系統
  • TFS：微軟整合開發平台
  • Perforce：企業級版本控制

10.7 文件管理檢核清單

  • 文件分類架構已建立
  • 版本控制機制已設定
  • 文件審查流程已定義
  • 文件庫權限已設定
  • 文件備份機制已建立
  • 文件保存期限已確定
  • 文件銷毀程序已制定
  • 文件管理訓練已完成

實務案例

某政府數位服務專案要求所有文件必須符合政府文件管理規範。專案經理建立了三層審查機制：技術審查、管理審查、合規審查。透過 SharePoint 平台建立文件庫，並設定自動化工作流程，確保所有文件都經過適當審查才能發布。最終專案文件通過政府稽核，獲得優等評價。

11. 品質管理

11.1 品質管理目標

品質管理的主要目標是確保專案交付成果符合既定的品質標準與利害關係人期望，並建立持續改善的機制。

11.2 品質管理三要素

11.2.1 品質規劃（Quality Planning）

  • 品質標準定義：建立明確的品質標準與驗收標準
  • 品質政策制定：制定專案品質政策與方針
  • 品質指標設定：建立可衡量的品質指標
  • 品質成本分析：分析品質相關的成本效益

11.2.2 品質保證（Quality Assurance）

  • 流程稽核：定期稽核專案執行流程
  • 標準遵循：確保遵循既定的品質標準
  • 預防性措施：建立預防缺陷的機制
  • 持續改善：建立品質持續改善流程

11.2.3 品質控制（Quality Control）

  • 交付成果檢驗：檢驗專案交付成果品質
  • 缺陷管理：建立缺陷追蹤與修正機制
  • 統計品質控制：運用統計方法控制品質
  • 驗收測試：執行系統性的驗收測試

11.3 品質管理工具與技術

11.3.1 品質規劃工具

  • 標竿比較（Benchmarking）：與業界最佳實務比較
  • 實驗設計（Design of Experiments）：科學化的實驗設計
  • 品質功能展開（QFD）：將客戶需求轉化為技術規格
  • 品質成本分析：分析預防、評估、失敗成本

11.3.2 品質保證工具

  • 品質稽核：系統性的品質稽核
  • 流程分析：分析與改善工作流程
  • 品質管理系統：建立品質管理體系
  • 訓練與認證：提供品質相關訓練

11.3.3 品質控制工具

七大品質工具（7 QC Tools）
  1. 查檢表（Check Sheet）：收集與分析數據
  2. 直方圖（Histogram）：顯示數據分布狀況
  3. 柏拉圖（Pareto Chart）：識別主要問題
  4. 魚骨圖（Fishbone Diagram）：分析問題根本原因
  5. 散布圖（Scatter Diagram）：分析變數間關係
  6. 控制圖（Control Chart）：監控過程穩定性
  7. 層別法（Stratification）：將數據分層分析
新七大品質工具（7 Management Tools）
  1. 親和圖法（Affinity Diagram）：將相關想法分組
  2. 關聯圖法（Relations Diagram）：分析因果關係
  3. 系統圖法（Tree Diagram）：系統化分解問題
  4. 矩陣圖法（Matrix Diagram）：分析要素間關係
  5. 箭頭圖法（Arrow Diagram）：網路圖排程分析
  6. PDPC法（Process Decision Program Chart）：預防性問題分析
  7. 矩陣數據解析法（Matrix Data Analysis）：量化分析矩陣數據

11.4 軟體品質管理

11.4.1 軟體品質特性（ISO 25010）

  • 功能性（Functionality）：功能完整性、正確性、適切性
  • 效能（Performance）：時間行為、資源利用、容量
  • 相容性（Compatibility）：共存性、互通性
  • 易用性（Usability）：易認知、易學習、易操作
  • 可靠性（Reliability）：成熟性、可用性、容錯性、可復原性
  • 安全性（Security）：機密性、完整性、不可否認性、可歸責性、真實性
  • 維護性（Maintainability）：模組化、可重用、可分析、可修改、可測試
  • 可攜性（Portability）：適應性、可安裝、可替換

11.4.2 軟體測試策略

測試層級
  • 單元測試（Unit Testing）：測試個別程式模組
  • 整合測試（Integration Testing）：測試模組間的整合
  • 系統測試（System Testing）：測試完整系統功能
  • 驗收測試（Acceptance Testing）：使用者驗收測試
測試類型
  • 功能測試：驗證系統功能是否符合需求
  • 效能測試：驗證系統效能是否達標
  • 安全測試：驗證系統安全性
  • 易用性測試：驗證系統易用性

11.5 品質指標與度量

11.5.1 過程品質指標

  • 缺陷密度：每千行程式碼的缺陷數量
  • 缺陷發現率：單位時間內發現的缺陷數量
  • 缺陷修正時間：從發現到修正缺陷的平均時間
  • 測試覆蓋率：測試案例涵蓋程式碼的比例

11.5.2 產品品質指標

  • 客戶滿意度：客戶對產品的滿意程度
  • 可用性：系統正常運作的時間比例
  • 效能指標：回應時間、處理量等效能指標
  • 安全指標：安全事件數量、修正時間等

11.6 品質管理最佳實務

11.6.1 建立品質文化

  • 高階主管承諾：獲得高階主管對品質的支持
  • 全員參與：讓所有團隊成員參與品質管理
  • 持續改善：建立持續改善的文化
  • 客戶導向：以客戶需求為品質標準

11.6.2 品質管理系統

  • ISO 9001 品質管理系統：建立標準化的品質管理系統
  • CMMI（能力成熟度模型）：提升組織的過程成熟度
  • Six Sigma：運用統計方法追求近乎完美的品質
  • TQM（全面品質管理）：全組織的品質管理方法

實務案例

某電商平台改版專案，專案經理建立了三階段品質閘門機制：設計審查、程式碼審查、測試審查。每個階段都設定明確的品質標準與退場機制。透過自動化測試工具提升測試效率，最終將缺陷率從 15% 降至 2%，客戶滿意度提升至 98%。

12. 採購與供應商管理

12.1 採購管理目標

採購管理的主要目標是從專案外部取得所需的產品、服務或成果，並建立有效的供應商關係管理機制。

12.2 採購管理流程

12.2.1 採購規劃

  • 採購需求分析：分析專案所需的外部採購項目
  • 自製或外購決策：評估自製與外購的成本效益
  • 採購策略制定：制定採購的整體策略
  • 合約類型選擇：選擇適當的合約類型

12.2.2 採購執行

  • 供應商來源尋找：尋找合適的供應商來源
  • 招標文件準備：準備招標文件與評選標準
  • 供應商評選：執行供應商評選與比較
  • 合約談判：進行合約條件談判

12.2.3 採購控制

  • 合約管理：管理與監控合約執行
  • 供應商績效管理：監控供應商績效
  • 變更管理：管理採購範圍與合約變更
  • 爭議解決：處理採購相關爭議

12.2.4 採購結案

  • 交付驗收：驗收供應商交付成果
  • 合約結案：完成合約行政結案
  • 績效評估：評估供應商績效
  • 經驗學習：記錄採購經驗與教訓

12.3 合約類型

12.3.1 固定總價合約（Fixed Price）

  • 總價固定合約（FFP）：價格完全固定
  • 總價加獎勵費合約（FPIF）：基本價格加績效獎勵
  • 總價加經濟調整合約（FPEPA）：允許通膨等經濟調整

優點：成本可預測、供應商承擔風險 缺點：供應商可能抬高價格、變更成本高 適用：需求明確、風險可控的專案

12.3.2 成本償還合約（Cost Reimbursable）

  • 成本加固定費用合約（CPFF）：實際成本加固定管理費
  • 成本加獎勵費合約（CPIF）：實際成本加績效獎勵費
  • 成本加成本百分比合約（CPPC）：實際成本加比例管理費

優點：適合高風險、需求不確定專案 缺點：成本難預測、需要嚴格監控 適用：研發專案、需求經常變更的專案

12.3.3 工時材料合約（Time & Material）

  • 單純工時材料合約：按實際工時與材料計費
  • 工時材料加上限合約：設定總費用上限

優點：彈性高、適合範圍不確定專案 缺點：成本控制困難、需要密切監控 適用：維護服務、顧問服務、緊急專案

12.4 供應商管理

12.4.1 供應商評選

評選標準
  • 技術能力：技術實力、過往經驗、團隊素質
  • 財務狀況：財務穩健度、營運狀況
  • 管理能力：專案管理能力、品質管理系統
  • 商業條件：價格競爭力、付款條件、交期
評選方法
  • 加權評分法：設定各項標準權重進行評分
  • 最低評選標準：設定最低門檻，合格者進行價格評比
  • 技術商務分離：先評技術，合格者再評商務
  • 最有利標：綜合考量技術與商務因素

12.4.2 供應商績效管理

績效指標（KPI）
  • 品質指標：交付品質、缺陷率、返工率
  • 時程指標：準時交付率、里程碑達成率
  • 成本指標：預算控制、變更成本
  • 服務指標：回應時間、客戶滿意度
績效評估方法
  • 平衡計分卡：從多面向評估供應商績效
  • 供應商計分卡：定期評估供應商表現
  • 績效審查會議：定期召開績效檢討會議
  • 改善計畫：針對績效落差制定改善計畫

12.5 風險管理

12.5.1 採購風險類型

  • 供應商風險：供應商財務問題、能力不足
  • 技術風險：技術可行性、整合風險
  • 商業風險：價格波動、匯率風險
  • 法律風險：合約爭議、智慧財產權
  • 交期風險：延遲交付、品質不符

12.5.2 風險應對策略

  • 供應商分散：避免過度依賴單一供應商
  • 保證金制度：要求供應商提供履約保證
  • SLA 設定：設定明確的服務水準協議
  • 定期稽核：定期稽核供應商狀況
  • 備援計畫：準備替代供應商方案

12.6 國際採購管理

12.6.1 跨國採購考量

  • 文化差異：了解不同國家的商業文化
  • 法律法規：遵循各國相關法規要求
  • 匯率風險：管理匯率波動風險
  • 時差問題：協調不同時區的工作時間
  • 語言溝通：克服語言溝通障礙

12.6.2 貿易條件（Incoterms）

  • EXW（工廠交貨）：最小責任條件
  • FOB（船上交貨）：海運常用條件
  • CIF（成本保險費）：賣方負責運費保險
  • DDP（完稅後交貨）：最大責任條件

實務案例

某銀行核心系統採購專案，專案經理採用技術商務分離的評選方式。先進行技術評審，淘汰不符技術要求的廠商，再針對合格廠商進行商務評比。設定了嚴格的 SLA 與罰則機制，並要求供應商提供履約保證金。最終成功降低採購風險，專案按時完成且品質達標。

13. 人力資源管理

13.1 人力資源管理目標

人力資源管理的主要目標是有效運用組織內外的人力資源，建立高效能的專案團隊，並促進團隊成員的專業發展。

13.2 人力資源規劃

13.2.1 人力需求分析

  • 技能需求評估：分析專案所需的技能組合
  • 人力數量估算：估算各階段所需人力數量
  • 角色與職責定義：明確定義各角色職責
  • 組織架構設計：設計專案組織架構

13.2.2 人力資源獲取

內部資源獲取
  • 內部調派：從組織內部調派合適人員
  • 兼任安排：安排人員兼任專案工作
  • 技能培訓：提供必要的技能培訓
  • 職涯發展：將專案視為職涯發展機會
外部資源獲取
  • 招募新人：招募具備所需技能的新進人員
  • 外包服務：將部分工作外包給專業廠商
  • 顧問諮詢：聘請外部顧問提供專業服務
  • 派遣人員：使用派遣人員補充人力

13.3 團隊建立與發展

13.3.1 團隊建立策略

團隊組成原則
  • 技能互補：確保團隊技能組合完整
  • 經驗平衡：新手與資深人員適當搭配
  • 文化融合：考慮團隊成員文化背景
  • 規模適中：控制團隊規模在有效範圍內
團隊建立活動
  • 團隊啟動會議：正式介紹團隊成員與專案目標
  • 團隊建立活動：透過活動增進團隊默契
  • 技能工作坊：提供必要的技能培訓
  • 團隊章程制定：共同制定團隊工作章程

13.3.2 團隊發展階段管理

Tuckman 團隊發展模型

  1. 形成期（Forming）

    • 特徵：成員互相認識、了解專案目標
    • 管理重點：建立信任、明確期望、提供指導

  2. 風暴期（Storming）

    • 特徵：出現衝突、角色競爭、權力鬥爭
    • 管理重點：調解衝突、釐清角色、建立規範

  3. 規範期（Norming）

    • 特徵：建立工作規範、形成團隊認同
    • 管理重點：強化規範、促進合作、建立文化

  4. 執行期（Performing）

    • 特徵：高效協作、自主管理、創新表現
    • 管理重點：授權決策、支援資源、持續激勵

  5. 結束期（Adjourning）

    • 特徵：專案結束、團隊解散、情感依戀
    • 管理重點：慶祝成果、評估績效、規劃轉換

13.4 團隊激勵與管理

13.4.1 激勵理論應用

Maslow 需求層次理論
  • 生理需求：提供合理薪酬與工作環境
  • 安全需求：確保工作穩定與職業安全
  • 社交需求：促進團隊互動與歸屬感
  • 尊重需求：給予認可肯定與職業尊嚴
  • 自我實現：提供挑戰性工作與成長機會
Herzberg 雙因子理論
保健因子（避免不滿）
  • 薪資福利、工作環境、公司政策、管理制度
激勵因子（提升滿意）
  • 成就感、認可肯定、工作本身、責任感、升遷機會

13.4.2 激勵策略與方法

物質激勵
  • 績效獎金：根據專案成果給予獎勵
  • 加薪升遷：提供職涯發展機會
  • 福利優惠：提供額外福利與優惠
  • 股票選擇權：讓員工分享公司成長
精神激勵
  • 公開表揚：在公開場合表揚優秀表現
  • 專業認證：支持員工取得專業認證
  • 學習機會：提供教育訓練與會議參與
  • 工作彈性：提供彈性工作安排

13.5 績效管理

13.5.1 績效管理循環

  1. 績效規劃

    • 設定績效目標與標準
    • 制定績效衡量指標
    • 確認績效期望與資源

  2. 績效監控

    • 定期檢視績效表現
    • 提供即時回饋與指導
    • 記錄績效相關事件

  3. 績效評估

    • 客觀評估績效成果
    • 分析績效差距原因
    • 提供建設性回饋

  4. 績效發展

    • 制定績效改善計畫
    • 提供必要支援與資源
    • 規劃職涯發展路徑

13.5.2 績效評估方法

目標管理法（MBO）
  • 設定具體可衡量目標
  • 定期檢視目標達成狀況
  • 評估目標完成品質
關鍵績效指標（KPI）
  • 量化績效衡量標準
  • 設定績效基準與目標
  • 追蹤績效趨勢變化
360 度回饋
  • 收集多方回饋意見
  • 包含上司、同事、部屬、客戶
  • 提供全面性績效觀點

13.6 衝突管理

13.6.1 衝突來源

  • 資源競爭：對有限資源的競爭
  • 角色模糊：職責不清造成的衝突
  • 目標差異：不同目標優先順序的衝突
  • 溝通問題：資訊傳遞錯誤或不足
  • 個性差異：工作風格與價值觀差異

13.6.2 衝突處理策略

Thomas-Kilmann 衝突處理模型

  1. 競爭（Competing）

    • 高度關注自己，低度關注他人
    • 適用：緊急決策、不妥協原則

  2. 協作（Collaborating）

    • 高度關注自己，高度關注他人
    • 適用：重要議題、雙贏解決方案

  3. 妥協（Compromising）

    • 中度關注自己，中度關注他人
    • 適用：時間壓力、暫時解決方案

  4. 迴避（Avoiding）

    • 低度關注自己，低度關注他人
    • 適用：微不足道議題、冷卻情緒

  5. 遷就（Accommodating）

    • 低度關注自己，高度關注他人
    • 適用：維持關係、學習機會

13.7 虛擬團隊管理

13.7.1 虛擬團隊挑戰

  • 溝通困難：缺乏面對面溝通
  • 信任建立：難以建立深度信任
  • 文化差異：跨文化協作挑戰
  • 時區問題：不同時區協調困難
  • 技術依賴：高度依賴通訊技術

13.7.2 虛擬團隊管理策略

  • 明確溝通協議：建立清楚的溝通規範
  • 定期面對面會議：安排定期實體聚會
  • 文化敏感度訓練：提供跨文化協作訓練
  • 技術平台統一：使用統一的協作平台
  • 信任建立活動：安排信任建立活動

實務案例

某跨國軟體開發專案，團隊分布在台北、上海、班加羅爾三地。專案經理建立了時區輪轉的每日站立會議制度，每週安排全球團隊視訊會議，並透過文化交流活動增進團隊認同。運用 Scrum 方法論與數位看板工具，成功管理 50 人的虛擬團隊，專案按時交付且團隊滿意度達 92%。

14. 利害關係人管理

14.1 利害關係人管理目標

利害關係人管理的主要目標是識別、分析、規劃和管理所有可能影響或受專案影響的個人、團體或組織，確保專案獲得充分支持並降低阻力。

14.2 利害關係人識別

14.2.1 利害關係人類型

內部利害關係人
  • 專案贊助者：提供資源與權威支持
  • 專案經理：負責專案執行與管理
  • 專案團隊：實際執行專案工作的成員
  • 功能經理：提供功能性資源的部門主管
  • 高階主管：影響專案方向與資源分配
  • 使用者：實際使用專案成果的人員
外部利害關係人
  • 客戶：專案成果的直接受益者
  • 供應商：提供產品或服務的外部組織
  • 監管機關：相關法規的監督單位
  • 合作夥伴：策略合作的組織
  • 社會大眾：可能受專案影響的一般民眾
  • 媒體：可能報導專案的媒體組織

14.2.2 利害關係人識別技術

  • 腦力激盪：團隊共同識別利害關係人
  • 專家判斷：諮詢經驗豐富的專家意見
  • 檢核清單：使用標準化的檢核清單
  • 利害關係人登錄表：系統化記錄利害關係人

14.3 利害關係人分析

14.3.1 權力利益網格分析

根據利害關係人的權力大小與利益相關程度進行分類：

分類權力利益管理策略
管理密切（Manage Closely）高高密切合作、定期溝通
令其滿意（Keep Satisfied）高低保持滿意、避免不滿
隨時通知（Keep Informed）低高提供資訊、滿足需求
最低監督（Monitor）低低最低程度的監督

14.3.2 影響力方向分析

  • 支持者（Supporters）：積極支持專案的利害關係人
  • 中立者（Neutral）：對專案持中立態度
  • 反對者（Opponents）：可能反對或阻礙專案進行

14.3.3 參與程度分析

  • 不知情（Unaware）：不知道專案存在
  • 抗拒（Resistant）：知道專案但抗拒變化
  • 中立（Neutral）：知道專案但不積極參與
  • 支持（Supportive）：知道專案並給予支持
  • 領導（Leading）：積極參與並影響他人支持

14.4 利害關係人參與規劃

14.4.1 參與策略制定

高權力高利益（管理密切）
  • 策略：密切合作、共同決策
  • 活動：定期會議、深度參與、意見諮詢
  • 頻率：高頻率溝通與互動
高權力低利益（令其滿意）
  • 策略：保持滿意、避免不滿
  • 活動：重要資訊通報、禮貌性諮詢
  • 頻率：適度溝通、重要時點通知
低權力高利益（隨時通知）
  • 策略：充分告知、滿足期望
  • 活動：詳細資訊提供、進度報告
  • 頻率：定期更新、主動通知
低權力低利益（最低監督）
  • 策略：最低程度監督
  • 活動：一般性通知、被動回應
  • 頻率：低頻率、必要時聯絡

14.4.2 溝通計畫制定

  • 溝通內容：針對不同利害關係人客製化資訊
  • 溝通方式：選擇適當的溝通管道與方法
  • 溝通頻率：設定合適的溝通頻率
  • 責任分工：明確溝通責任與分工

14.5 利害關係人參與管理

14.5.1 參與活動執行

資訊提供
  • 專案簡報：定期提供專案進度簡報
  • 進度報告：書面進度報告與狀況更新
  • 成果展示：階段性成果展示與說明
  • 網站平台：建立專案資訊網站
意見收集
  • 焦點團體：組織焦點團體收集意見
  • 問卷調查：設計問卷收集回饋
  • 個別訪談：進行深度個別訪談
  • 公聽會：舉辦公開說明會
決策參與
  • 諮詢會議：邀請參與重要決策討論
  • 工作小組：組成跨功能工作小組
  • 審查委員會：成立專案審查委員會
  • 共同設計：邀請參與解決方案設計

14.5.2 關係維護

  • 信任建立：透過誠實溝通建立信任
  • 期望管理：適當管理利害關係人期望
  • 衝突解決：主動處理利害關係人衝突
  • 關係強化：持續強化正面關係

14.6 利害關係人監控

14.6.1 參與度監控

  • 參與度評估：定期評估利害關係人參與程度
  • 態度變化：監控利害關係人態度變化
  • 影響力變化：追蹤利害關係人影響力變化
  • 新利害關係人：識別新出現的利害關係人

14.6.2 參與效果評估

  • 滿意度調查：定期進行滿意度調查
  • 回饋分析：分析利害關係人回饋內容
  • 參與品質：評估參與活動的品質
  • 目標達成：評估參與目標的達成度

14.7 困難利害關係人管理

14.7.1 困難利害關係人類型

  • 權力型反對者：具有高權力但反對專案
  • 情緒型反對者：因情緒因素反對專案
  • 利益衝突者：專案可能損害其既得利益
  • 資訊不足者：因缺乏資訊而產生誤解
  • 完美主義者：對專案要求過度完美

14.7.2 應對策略

權力型反對者
  • 尋找共同利益：找出雙方共同關心的議題
  • 建立聯盟：與其他利害關係人建立聯盟
  • 階段性妥協：適度妥協以換取支持
  • 展示價值：清楚展示專案對其的價值
情緒型反對者
  • 同理傾聽：耐心傾聽並表示理解
  • 情緒疏導：協助處理負面情緒
  • 建立關係：投資時間建立個人關係
  • 漸進說服：循序漸進地改變其觀點

14.8 利害關係人管理工具

14.8.1 利害關係人登錄表

姓名組織角色權力利益態度參與策略溝通方式負責人
張總經理總公司決策者高中支持令其滿意月報告PM

14.8.2 利害關係人分析矩陣

高權力 │ 令其滿意        │ 管理密切
      │ (Keep Satisfied) │ (Manage Closely)
      │─────────────────│─────────────────
低權力 │ 最低監督        │ 隨時通知
      │ (Monitor)        │ (Keep Informed)
      └─────────────────┴─────────────────
       低利益            高利益

實務案例

某市政府智慧城市專案涉及多個局處與民間組織。專案經理透過利害關係人分析，識別出 45 個利害關係人，包括 8 個局處、15 個民間組織、12 個社區代表等。針對高權力高利益的局處長官，建立每月例會機制；對於關心專案的市民代表，設立專案網站與意見信箱。透過系統化的利害關係人管理，成功化解反對聲浪，專案獲得全面支持。

15. 專案整合管理

15.1 專案整合管理目標

專案整合管理的主要目標是統一協調專案管理的各個過程群組與知識領域，確保專案各部分有效整合並達成專案目標。

15.2 專案整合管理過程

15.2.1 制定專案章程

  • 專案授權：正式授權專案開始執行
  • 專案經理指派：指派專案經理並明確職權
  • 高階需求定義：記錄高階專案需求
  • 專案成功標準：建立專案成功評估標準

15.2.2 制定專案管理計畫

  • 整合各領域計畫：整合範圍、時程、成本等計畫
  • 建立基準線：建立範圍、時程、成本基準
  • 定義管理程序：定義各種管理程序與流程
  • 設定變更程序：建立變更控制程序

15.2.3 指導與管理專案工作

  • 執行計畫活動：按計畫執行專案工作
  • 協調資源：協調人力、物力、財力資源
  • 管理團隊：管理專案團隊績效
  • 溝通協調：促進利害關係人溝通

15.2.4 管理專案知識

  • 知識獲取：從內外部來源獲取知識
  • 知識分享：在團隊間分享知識經驗
  • 知識創造：透過經驗創造新知識
  • 知識保存：建立組織知識庫

15.2.5 監控專案工作

  • 追蹤績效：監控專案績效與進度
  • 識別變異：識別計畫與實際的變異
  • 分析趨勢：分析專案績效趨勢
  • 預測結果：預測專案完成狀況

15.2.6 實施整體變更控制

  • 變更申請審查：審查所有變更申請
  • 影響評估：評估變更對專案的影響
  • 變更決策：決定變更的核准或拒絕
  • 變更實施：管理變更的實施過程

15.2.7 結束專案或階段

  • 交付驗收：完成所有交付成果驗收
  • 合約結案：結束所有採購合約
  • 資源釋放：釋放專案資源
  • 經驗總結：總結專案經驗教訓

15.3 專案管理計畫整合

15.3.1 子計畫整合

管理計畫
  • 範圍管理計畫：如何管理專案範圍
  • 需求管理計畫：如何管理專案需求
  • 時程管理計畫：如何管理專案時程
  • 成本管理計畫：如何管理專案成本
  • 品質管理計畫：如何管理專案品質
  • 資源管理計畫：如何管理專案資源
  • 溝通管理計畫：如何管理專案溝通
  • 風險管理計畫：如何管理專案風險
  • 採購管理計畫：如何管理專案採購
  • 利害關係人參與計畫：如何管理利害關係人
基準線
  • 範圍基準：專案範圍的核准版本
  • 時程基準：專案時程的核准版本
  • 成本基準：專案預算的核准版本

15.3.2 整合考量因素

  • 相互依賴性：各計畫間的相互依賴關係
  • 資源衝突：不同活動間的資源競爭
  • 優先順序：不同目標間的優先順序
  • 風險相關性：不同風險間的相關性
  • 變更影響：變更對多個領域的影響

15.4 變更控制系統

15.4.1 變更控制委員會（CCB）

組成成員
  • 專案贊助者：提供高層決策權威
  • 專案經理：提供專案管理觀點
  • 技術專家：提供技術評估意見
  • 業務代表：提供業務需求觀點
  • 品質代表：提供品質影響評估
職責範圍
  • 變更評估：評估變更的必要性與影響
  • 決策權限：決定變更的核准或拒絕
  • 優先順序：決定變更實施的優先順序
  • 資源分配：核准變更所需的資源

15.4.2 變更控制流程

  1. 變更識別

    • 發現需要變更的情況
    • 記錄變更需求來源

  2. 變更申請

    • 填寫變更申請單
    • 提供變更詳細說明

  3. 初步評估

    • 專案經理進行初步評估
    • 決定是否進入正式流程

  4. 詳細分析

    • 技術影響分析
    • 成本時程影響分析
    • 風險影響分析

  5. CCB 審查

    • 提交 CCB 正式審查
    • 進行決策投票

  6. 變更實施

    • 更新專案文件
    • 執行變更活動
    • 驗證變更結果

  7. 變更結案

    • 確認變更完成
    • 更新專案記錄

15.5 專案知識管理

15.5.1 知識管理活動

知識獲取
  • 專家諮詢：諮詢領域專家
  • 最佳實務研究：研究業界最佳實務
  • 供應商知識：獲取供應商專業知識
  • 客戶回饋：收集客戶使用回饋
知識分享
  • 經驗分享會：定期舉辦經驗分享
  • 知識庫建立：建立組織知識庫
  • 導師制度：建立知識傳承機制
  • 社群平台：建立知識分享平台
知識創造
  • 創新工作坊：舉辦創新思考活動
  • 實驗專案：進行創新實驗
  • 跨域合作：促進跨領域合作
  • 研發投資：投資研發新知識
知識保存
  • 文件化：將知識系統化文件化
  • 知識地圖：建立組織知識地圖
  • 專家網路：建立內部專家網路
  • 接班計畫：建立知識接班機制

15.6 專案組合管理整合

15.6.1 專案組合與專案關係

  • 策略對齊：確保專案符合組織策略
  • 資源協調：協調多專案間的資源分配
  • 優先順序：建立專案優先順序機制
  • 綜效創造：創造專案間的綜效

15.6.2 多專案管理

PMO（專案管理辦公室）功能
  • 標準化：建立專案管理標準
  • 方法論：提供專案管理方法論
  • 工具平台：提供專案管理工具
  • 績效監控：監控專案組合績效
  • 資源協調：協調跨專案資源
  • 能力建設：提升專案管理能力

15.7 整合管理工具

15.7.1 專案管理資訊系統（PMIS）

  • 計畫整合：整合各種專案計畫
  • 進度追蹤：即時追蹤專案進度
  • 資源管理：管理專案資源分配
  • 文件管理：集中管理專案文件
  • 報告產生：自動產生管理報告

15.7.2 專案儀表板

  • 關鍵指標：顯示關鍵績效指標
  • 狀態燈號：用顏色表示專案狀態
  • 趨勢圖表：顯示績效趨勢變化
  • 例外報告：突顯需要關注的問題

實務案例

某跨國企業 ERP 系統導入專案，涉及 15 個國家、30 個子專案。專案經理建立了三層整合管理架構：全球整合委員會、區域協調委員會、國家執行委員會。透過統一的 PMIS 系統整合所有子專案資訊，每月召開全球整合會議檢視整體進度。成功協調跨時區、跨文化的複雜專案，在 18 個月內完成全球 ERP 系統統一。

16. 敏捷專案管理

16.1 敏捷專案管理概述

敏捷專案管理是一種以人為本、迭代式的專案管理方法，強調快速回應變化、持續交付價值、團隊協作與客戶合作。

16.2 敏捷宣言與原則

16.2.1 敏捷宣言四大價值

  1. 個人與互動 重於 流程與工具
  2. 可用的軟體 重於 詳盡的文件
  3. 客戶合作 重於 合約談判
  4. 回應變化 重於 遵循計畫

16.2.2 敏捷十二原則

  1. 透過持續及早交付有價值的軟體來滿足客戶
  2. 欣然面對需求的變化，發揮敏捷流程的優勢
  3. 經常交付可用的軟體，頻率從數週到數月
  4. 業務人員與開發人員必須天天一起工作
  5. 以積極的個人來建立專案，給予所需環境與支援
  6. 面對面的溝通是最有效率且效果的溝通方式
  7. 可用的軟體是衡量進度的主要指標
  8. 敏捷流程提倡可持續發展的步調
  9. 持續關注技術優越性及良好設計以增進敏捷性
  10. 簡潔是必要的，減少不必要的工作
  11. 最佳的架構、需求與設計來自自組織團隊
  12. 團隊定期反思如何更有效率，並調整行為

16.3 敏捷框架與方法

16.3.1 Scrum 框架

Scrum 角色

  • 產品負責人（Product Owner）

    • 負責產品待辦清單管理
    • 定義使用者故事與驗收標準
    • 決定功能優先順序
    • 與利害關係人溝通

  • Scrum Master

    • 確保團隊遵循 Scrum 流程
    • 移除團隊工作障礙
    • 促進團隊協作與溝通
    • 指導團隊持續改善

  • 開發團隊（Development Team）

    • 跨功能自組織團隊
    • 負責交付產品增量
    • 估算工作量與計畫衝刺
    • 持續改善開發流程
Scrum 事件

  • 衝刺（Sprint）

    • 時間長度：1-4 週固定週期
    • 目標：交付可用的產品增量
    • 特性：時間盒限制、目標不變

  • 衝刺規劃（Sprint Planning）

    • 時間：衝刺長度 8 小時為上限
    • 目標：規劃衝刺工作內容
    • 輸出：衝刺目標與衝刺待辦清單

  • 每日站立會議（Daily Scrum）

    • 時間：每日 15 分鐘
    • 目標：同步進度與規劃當日工作
    • 內容：昨天完成、今天計畫、遇到障礙

  • 衝刺檢視（Sprint Review）

    • 時間：衝刺長度 4 小時為上限
    • 目標：檢視衝刺成果
    • 參與者：整個 Scrum 團隊與利害關係人

  • 衝刺回顧（Sprint Retrospective）

    • 時間：衝刺長度 3 小時為上限
    • 目標：反思改善團隊運作方式
    • 輸出：改善行動計畫
Scrum 產出物

  • 產品待辦清單（Product Backlog）

    • 所有產品功能需求的優先順序清單
    • 持續維護與優化
    • 包含使用者故事、驗收標準、優先順序

  • 衝刺待辦清單（Sprint Backlog）

    • 從產品待辦清單選取的項目
    • 加上交付這些項目的計畫
    • 開發團隊的工作預測

  • 產品增量（Increment）

    • 衝刺期間完成的產品待辦清單項目總和
    • 必須符合完成定義（Definition of Done）
    • 可使用且可能發布的產品版本

16.3.2 看板（Kanban）方法

看板核心實務
  1. 視覺化工作流程：將所有工作項目視覺化
  2. 限制在製品數量：限制同時進行的工作量
  3. 管理流程：測量與管理工作流程
  4. 建立明確政策：讓流程政策明確且可見
  5. 實施回饋循環：建立回饋與改善機制
  6. 協作改善：團隊協作進行改善
看板系統設計
待辦 │ 進行中 │ 測試中 │ 完成
     │ (限制3) │ (限制2) │
──────┼────────┼────────┼──────
故事A │ 故事B  │ 故事D  │ 故事F
故事E │ 故事C  │ 故事G  │ 故事H
     │ 故事I  │        │

16.3.3 其他敏捷方法

SAFe（Scaled Agile Framework）
  • 適用場景：大型組織敏捷轉型
  • 層級架構：Team、Program、Large Solution、Portfolio
  • 核心要素：精實-敏捷領導、團隊與技術敏捷性
DevOps
  • 目標：縮短系統開發生命週期
  • 原則：開發與維運協作
  • 工具：持續整合、持續部署、基礎設施即程式碼

16.4 敏捷專案規劃

16.4.1 發布規劃（Release Planning）

  • 發布目標設定：定義發布的業務目標
  • 功能優先順序：根據業務價值排定優先順序
  • 發布時程規劃：規劃多個衝刺的發布時程
  • 資源與能力評估：評估團隊交付能力

16.4.2 使用者故事撰寫

使用者故事格式
身為 [角色]
我想要 [功能]
以便於 [價值/目的]
驗收標準
  • Given-When-Then 格式
Given [前提條件]
When [執行動作]
Then [預期結果]
INVEST 原則
  • Independent（獨立）：故事間彼此獨立
  • Negotiable（可協商）：需求細節可協商
  • Valuable（有價值）：對用戶有明確價值
  • Estimable（可估算）：可以估算工作量
  • Small（小）：在一個衝刺內可完成
  • Testable（可測試）：有明確的測試標準

16.4.3 故事點估算

規劃撲克（Planning Poker）
  1. 每人拿到估算卡片（費氏數列：1,2,3,5,8,13,21…）
  2. 產品負責人說明使用者故事
  3. 團隊討論故事內容與複雜度
  4. 每人秘密選擇估算卡片
  5. 同時翻開所有卡片
  6. 討論差異較大的估算
  7. 重複估算直到達成共識

16.5 敏捷團隊管理

16.5.1 自組織團隊特質

  • 跨功能技能：團隊具備完成工作所需的所有技能
  • 自主決策：團隊能自主決定如何完成工作
  • 共同責任：團隊對交付成果共同負責
  • 持續學習：團隊持續學習與改善

16.5.2 團隊激勵機制

  • 自主性（Autonomy）：給予團隊決策自主權
  • 精通性（Mastery）：提供技能發展機會
  • 目的性（Purpose）：連結工作與更大的目的
  • 團隊認同：建立強烈的團隊認同感

16.6 敏捷度量與監控

16.6.1 敏捷度量指標

速率（Velocity）
  • 定義：團隊在一個衝刺中完成的故事點數
  • 用途：預測未來衝刺的交付能力
  • 趨勢：觀察速率的穩定性與趨勢
燃盡圖（Burndown Chart）
  • 衝刺燃盡圖：顯示衝刺期間剩餘工作量
  • 發布燃盡圖：顯示發布期間剩餘工作量
  • 用途：視覺化進度與預測完成時間
累積流量圖（Cumulative Flow Diagram）
  • 顯示內容：各階段工作項目數量隨時間變化
  • 用途：識別瓶頸與流程問題
  • 指標：週期時間、在製品數量

16.6.2 品質度量

  • 缺陷率：生產環境發現的缺陷數量
  • 技術債務：需要重構的程式碼量
  • 自動化覆蓋率：自動化測試的覆蓋範圍
  • 客戶滿意度：客戶對產品的滿意程度

16.7 敏捷轉型

16.7.1 轉型挑戰

  • 文化變革：從命令控制轉向協作信任
  • 角色調整：管理者角色從控制轉向服務
  • 流程重設：從階段式轉向迭代式流程
  • 技能提升：團隊需要學習新的工作方式

16.7.2 轉型策略

  • 高層支持：獲得高階主管的承諾與支持
  • 試點專案：選擇合適的試點專案開始
  • 教練輔導：引入敏捷教練指導轉型
  • 持續改善：建立持續改善的文化

實務案例

某金融科技新創公司採用 Scrum 開發行動支付 App。組成 7 人跨功能團隊，包含 PM、UI/UX、前端、後端、QA 角色。採用 2 週 Sprint，透過每日站立會議同步進度，每個 Sprint 結束都有可用的產品增量。透過持續的 Sprint 回顧改善流程，第 6 個月時團隊速率提升 40%，產品上線後獲得 4.8 星評價。

17. 專案管理成熟度

17.1 專案管理成熟度概述

專案管理成熟度是指組織在專案管理實務上的成熟程度，反映組織系統化管理專案的能力水準。

17.2 成熟度模型

17.2.1 CMMI（Capability Maturity Model Integration）

成熟度等級

  1. 初始級（Initial）

    • 特徵：臨時性、混亂、無標準流程
    • 結果：專案成功依賴個人英雄主義
    • 風險：高度不可預測性

  2. 管理級（Managed）

    • 特徵：專案層級的基本管理
    • 結果：專案有基本的計畫與追蹤
    • 重點：需求管理、專案規劃、專案監控

  3. 已定義級（Defined）

    • 特徵：組織層級的標準流程
    • 結果：流程一致性與可預測性
    • 重點：組織流程焦點、組織流程定義、訓練

  4. 量化管理級（Quantitatively Managed）

    • 特徵：統計管理與量化品質目標
    • 結果：可預測的品質與績效
    • 重點：組織流程績效、量化專案管理

  5. 最佳化級（Optimizing）

    • 特徵：持續流程改善與創新
    • 結果：持續改善的組織能力
    • 重點：組織創新與部署、原因分析與解決

17.2.2 OPM3（Organizational Project Management Maturity Model）

三個領域

  1. 專案管理（Project Management）

    • 單一專案的管理
    • PMI PMBOK 知識領域應用

  2. 方案管理（Program Management）

    • 相關專案的協調管理
    • 創造個別專案無法達成的效益

  3. 專案組合管理（Portfolio Management）

    • 專案與方案的選擇與優先順序
    • 與組織策略目標對齊
四個成熟度階段

  1. 標準化（Standardize）

    • 建立一致的流程與方法
    • 制定組織標準與政策

  2. 測量（Measure）

    • 建立度量與測量機制
    • 收集績效數據

  3. 控制（Control）

    • 運用數據進行管理決策
    • 建立控制機制

  4. 持續改善（Continuously Improve）

    • 基於數據持續改善
    • 創新與最佳化

17.3 成熟度評估

17.3.1 評估方法

自我評估
  • 問卷調查：使用標準化問卷
  • 訪談評估：深度訪談關鍵人員
  • 文件審查：檢視相關文件與記錄
  • 觀察評估：觀察實際工作流程
第三方評估
  • 正式評估：委託專業機構評估
  • 同儕評估：邀請同業進行評估
  • 顧問評估：聘請顧問進行診斷
  • 認證評估：進行正式認證評估

17.3.2 評估構面

流程成熟度
  • 流程存在性：是否有正式的流程
  • 流程一致性：流程是否一致執行
  • 流程有效性：流程是否達到預期效果
  • 流程改善：是否有持續改善機制
組織能力
  • 人員能力：專案管理人員的能力水準
  • 組織支持：組織對專案管理的支持度
  • 文化成熟度：專案管理文化的成熟程度
  • 工具應用：專案管理工具的應用程度

17.4 成熟度提升策略

17.4.1 成熟度提升路徑

階段性提升

  1. 建立基礎（Level 1→2）

    • 導入基本專案管理流程
    • 建立專案管理辦公室（PMO）
    • 提供基礎專案管理訓練

  2. 標準化（Level 2→3）

    • 建立組織級專案管理標準
    • 制定專案管理方法論
    • 建立專案管理知識庫

  3. 量化管理（Level 3→4）

    • 建立專案管理度量體系
    • 導入統計品質控制
    • 建立基準與目標管理

  4. 持續最佳化（Level 4→5）

    • 建立持續改善機制
    • 推動創新與變革
    • 追求卓越績效

17.4.2 關鍵成功因素

高階主管支持
  • 承諾與資源：提供必要的承諾與資源
  • 變革領導：領導組織變革
  • 政策支持：制定支持性政策
人員發展
  • 能力建設：建立專案管理能力
  • 認證制度：建立專業認證制度
  • 職涯發展：提供職涯發展路徑
文化變革
  • 價值觀：建立專案管理價值觀
  • 行為模式：改變工作行為模式
  • 學習文化：建立學習型組織

17.5 PMO（專案管理辦公室）

17.5.1 PMO 類型

支援型 PMO（Supportive）
  • 角色：提供支援與諮詢
  • 權力：低度控制權
  • 功能：提供模板、最佳實務、訓練
控制型 PMO（Controlling）
  • 角色：提供支援並要求遵循
  • 權力：中度控制權
  • 功能：制定標準、要求報告、執行審查
指導型 PMO（Directive）
  • 角色：直接控制專案
  • 權力：高度控制權
  • 功能：直接管理專案、分派專案經理

17.5.2 PMO 功能

治理功能
  • 標準制定：建立專案管理標準
  • 流程管理：管理專案管理流程
  • 合規監督：確保遵循組織政策
支援功能
  • 方法論：提供專案管理方法論
  • 工具平台：提供專案管理工具
  • 訓練發展：提供能力發展訓練
執行功能
  • 專案管理：直接管理重要專案
  • 資源協調：協調跨專案資源
  • 組合管理：管理專案組合

17.6 最佳實務與標竿學習

17.6.1 內部最佳實務

  • 成功案例：收集內部成功案例
  • 經驗萃取：萃取成功經驗要素
  • 知識分享：建立知識分享機制
  • 複製推廣：推廣最佳實務應用

17.6.2 外部標竿學習

  • 標竿企業：識別業界標竿企業
  • 最佳實務研究：研究外部最佳實務
  • 經驗交流：參與業界經驗交流
  • 創新應用：創新應用先進實務

17.7 數位化轉型

17.7.1 專案管理數位化

  • 雲端平台：運用雲端專案管理平台
  • AI 應用：運用人工智慧輔助決策
  • 自動化：自動化例行性專案管理工作
  • 大數據：運用大數據分析專案績效

17.7.2 數位化效益

  • 效率提升：提升專案管理效率
  • 透明度：增加專案透明度
  • 決策支援：提供即時決策支援
  • 協作強化：強化團隊協作能力

實務案例

某大型製造企業透過 5 年的專案管理成熟度提升計畫，從 CMMI Level 1 提升到 Level 4。首先建立 PMO 並導入基本專案管理流程；第二年制定組織專案管理標準與方法論；第三年建立度量體系並導入專案管理資訊系統；第四年達到量化管理水準；第五年建立持續改善機制。最終專案成功率從 60% 提升到 92%，專案延期率從 40% 降低到 8%。

18. 附錄：範例與模板

11.1 專案章程範本

# 專案章程

## 專案基本資訊
- **專案名稱**：[專案名稱]
- **專案經理**：[姓名]
- **專案贊助者**：[姓名]
- **建立日期**：[日期]
- **版本**：1.0

## 專案背景與目的
### 專案背景
[描述專案產生的背景與原因]

### 專案目的
[明確描述專案要達成的目的]

### 商業價值
[說明專案對組織的商業價值]

## 專案目標與成功標準
### 專案目標
1. [目標一]
2. [目標二]
3. [目標三]

### 成功標準
- **時程**：[完成期限]
- **預算**：[預算限制]
- **品質**：[品質標準]
- **範圍**：[交付範圍]

## 專案範圍
### 包含範圍
- [範圍項目一]
- [範圍項目二]

### 不包含範圍
- [排除項目一]
- [排除項目二]

## 高階需求
1. [需求一]
2. [需求二]
3. [需求三]

## 假設條件與限制
### 假設條件
- [假設一]
- [假設二]

### 限制條件
- [限制一]
- [限制二]

## 高階風險
1. [風險一]
2. [風險二]
3. [風險三]

## 專案預算與資源
### 預算估算
- [預算項目] : [金額]

### 人力資源
- [角色] : [人數]

## 專案時程
### 主要里程碑
- [里程碑一] : [日期]
- [里程碑二] : [日期]

## 專案組織
### 專案贊助者
[姓名與職責]

### 專案經理
[姓名與職責]

### 專案團隊
[核心成員與職責]

## 核准簽署
專案贊助者：________________  日期：________
專案經理：__________________  日期：________

11.2 風險登錄表範本

# 風險登錄表

| 風險ID | 風險描述 | 風險類別 | 機率 | 影響 | 風險評分 | 應對策略 | 應對措施 | 負責人 | 目標日期 | 狀態 | 備註 |
|--------|----------|----------|------|------|----------|----------|----------|--------|----------|------|------|
| R001 | [風險描述] | [技術/管理/組織/外部] | [很低/低/中/高/很高] | [很低/低/中/高/很高] | [0.00-1.00] | [迴避/轉移/減輕/接受] | [具體措施] | [負責人] | [YYYY-MM-DD] | [開放/進行中/已解決/已關閉] | [備註] |

## 風險評估準則

### 機率等級
- **很高 (0.9)**：90% 以上機率發生
- **高 (0.7)**：70-89% 機率發生
- **中 (0.5)**：30-69% 機率發生
- **低 (0.3)**：10-29% 機率發生
- **很低 (0.1)**：10% 以下機率發生

### 影響等級
- **很高 (0.8)**：嚴重影響專案目標
- **高 (0.6)**：顯著影響專案目標
- **中 (0.4)**：中度影響專案目標
- **低 (0.2)**：輕微影響專案目標
- **很低 (0.1)**：幾乎不影響專案目標

### 風險評分
風險評分 = 機率 × 影響

### 應對策略
- **迴避**：改變專案計畫以消除風險
- **轉移**：將風險轉移給第三方
- **減輕**：降低風險機率或影響
- **接受**：承認風險但不採取行動

11.3 專案狀況報告範本

# 專案狀況報告

## 基本資訊
- **專案名稱**：[專案名稱]
- **報告期間**：[開始日期] ~ [結束日期]
- **專案經理**：[姓名]
- **報告日期**：[日期]

## 專案整體狀況
### 專案健康度
- **進度狀況**：🟢/🟡/🔴
- **預算狀況**：🟢/🟡/🔴
- **品質狀況**：🟢/🟡/🔴
- **資源狀況**：🟢/🟡/🔴

### 狀況說明
[簡要說明專案整體狀況]

## 進度報告
### 本期完成工作
1. [完成工作一]
2. [完成工作二]
3. [完成工作三]

### 下期計畫工作
1. [計畫工作一]
2. [計畫工作二]
3. [計畫工作三]

### 里程碑狀況
| 里程碑 | 計畫日期 | 實際日期 | 狀況 | 備註 |
|--------|----------|----------|------|------|
| [里程碑一] | [日期] | [日期] | 已完成/進行中/延遲 | [備註] |

## 預算報告
### 預算執行狀況
- **核准預算**：[金額]
- **已使用預算**：[金額]
- **預算執行率**：[百分比]
- **預估完工成本**：[金額]

### 成本變異分析
[分析成本變異原因與影響]

## 問題與風險
### 目前問題
| 問題ID | 問題描述 | 影響程度 | 負責人 | 預計解決日期 | 狀況 |
|--------|----------|----------|--------|--------------|------|
| I001 | [問題描述] | 高/中/低 | [負責人] | [日期] | 開放/進行中/已解決 |

### 新增風險
| 風險ID | 風險描述 | 機率 | 影響 | 應對策略 | 負責人 |
|--------|----------|------|------|----------|--------|
| R001 | [風險描述] | 高/中/低 | 高/中/低 | [策略] | [負責人] |

## 資源狀況
### 人力資源
- **計畫人力**：[人數]
- **實際人力**：[人數]
- **人力缺口**：[人數]

### 關鍵資源需求
[說明關鍵資源需求與取得計畫]

## 下期重點工作
1. [重點工作一]
2. [重點工作二]
3. [重點工作三]

## 需要的支援
1. [支援需求一]
2. [支援需求二]
3. [支援需求三]

## 備註
[其他重要事項說明]

11.4 會議紀錄範本

# 會議紀錄

## 會議基本資訊
- **會議主題**：[會議主題]
- **會議日期**：[日期]
- **會議時間**：[開始時間] ~ [結束時間]
- **會議地點**：[地點/線上平台]
- **主持人**：[姓名]
- **記錄人**：[姓名]

## 出席人員
### 出席者
- [姓名] - [職稱/部門]
- [姓名] - [職稱/部門]

### 請假者
- [姓名] - [職稱/部門] - [請假原因]

## 會議議程
1. [議題一]
2. [議題二]
3. [議題三]

## 討論內容與決議

### 議題一：[議題標題]
**討論內容：**
[記錄主要討論內容]

**決議：**
[記錄會議決議]

**行動項目：**
- [行動項目] - 負責人：[姓名] - 完成期限：[日期]

### 議題二：[議題標題]
**討論內容：**
[記錄主要討論內容]

**決議：**
[記錄會議決議]

**行動項目：**
- [行動項目] - 負責人：[姓名] - 完成期限：[日期]

## 行動項目彙總
| 項次 | 行動項目 | 負責人 | 完成期限 | 狀態 |
|------|----------|--------|----------|------|
| 1 | [行動項目一] | [負責人] | [日期] | 待執行 |
| 2 | [行動項目二] | [負責人] | [日期] | 待執行 |

## 下次會議
- **會議時間**：[日期與時間]
- **會議地點**：[地點]
- **主要議題**：[預計討論議題]

## 備註
[其他重要事項]

---
**會議紀錄核准：**
主持人：________________  日期：________

11.5 變更申請單範本

# 變更申請單

## 變更基本資訊
- **變更編號**：[CR-YYYY-XXX]
- **申請日期**：[日期]
- **申請人**：[姓名]
- **申請部門**：[部門]
- **專案名稱**：[專案名稱]

## 變更內容
### 變更描述
[詳細描述變更內容]

### 變更原因
[說明提出變更的原因]

### 變更類型
- [ ] 範圍變更
- [ ] 時程變更
- [ ] 預算變更
- [ ] 品質變更
- [ ] 資源變更

## 影響分析
### 範圍影響
[分析對專案範圍的影響]

### 時程影響
- **預估延長時間**：[天數]
- **影響的里程碑**：[里程碑名稱]
- **關鍵路徑影響**：是/否

### 成本影響
- **額外成本**：[金額]
- **成本節省**：[金額]
- **淨成本影響**：[金額]

### 品質影響
[分析對專案品質的影響]

### 資源影響
[分析對專案資源的影響]

### 風險影響
[分析變更可能帶來的新風險]

## 建議方案
### 方案一
**描述**：[方案描述]
**優點**：[方案優點]
**缺點**：[方案缺點]
**成本**：[成本估算]

### 方案二
**描述**：[方案描述]
**優點**：[方案優點]
**缺點**：[方案缺點]
**成本**：[成本估算]

## 建議採用方案
[說明建議採用的方案與理由]

## 實施計畫
### 實施步驟
1. [步驟一]
2. [步驟二]
3. [步驟三]

### 實施時程
- **預計開始日期**：[日期]
- **預計完成日期**：[日期]

### 所需資源
- **人力資源**：[需求描述]
- **財務資源**：[需求金額]
- **其他資源**：[需求描述]

## 審查流程
### 技術審查
- **審查人**：________________  
- **審查意見**：[意見]
- **審查結果**：核准/不核准/需修正
- **審查日期**：________

### 管理審查
- **審查人**：________________  
- **審查意見**：[意見]
- **審查結果**：核准/不核准/需修正
- **審查日期**：________

### 最終決定
- **決定**：核准/不核准
- **核准人**：________________  
- **核准日期**：________
- **核准條件**：[特殊條件說明]

## 實施記錄
### 實施狀況
[記錄實際實施狀況]

### 完成確認
- **實施負責人**：________________  
- **完成日期**：________
- **確認人**：________________  
- **確認日期**：________

參考資料與延伸閱讀

專案管理標準與認證

  1. PMI（專案管理學會）

    • PMBOK Guide（專案管理知識體）
    • PMP（專案管理專業）認證
    • 網址：https://www.pmi.org

  2. PRINCE2（受控環境下的專案）

    • PRINCE2 方法論
    • PRINCE2 Foundation & Practitioner 認證
    • 網址：https://www.axelos.com/best-practice-solutions/prince2

  3. Agile Alliance

    • 敏捷軟體開發宣言
    • Scrum、Kanban 等敏捷方法
    • 網址：https://www.agilealliance.org

專案管理工具

  1. Microsoft Project

    • 傳統專案管理工具
    • 甘特圖、資源管理
    • 網址：https://www.microsoft.com/project

  2. Jira

    • 敏捷專案管理
    • 問題追蹤、看板管理
    • 網址：https://www.atlassian.com/software/jira

  3. Trello

    • 看板式任務管理
    • 簡單易用的協作工具
    • 網址：https://trello.com

金融業專案管理參考

  1. 金管會資訊安全規範

    • 金融機構資安防護基準
    • SSDLC 安全開發規範

  2. Basel III 風險管理

    • 銀行業風險管理標準
    • 資本適足性要求

  3. ISO 27001 資訊安全管理

    • 資訊安全管理系統標準
    • 風險評估與管理要求

延伸學習建議

  1. 基礎學習

    • 完成 PMP 或 PRINCE2 認證
    • 學習敏捷方法（Scrum、Kanban）
    • 熟悉專案管理工具操作

  2. 進階學習

    • 學習風險管理專業知識
    • 研讀金融業法規與標準
    • 培養領導與溝通技能

  3. 實務經驗

    • 參與實際專案執行
    • 尋找資深專案經理指導
    • 定期參與專案管理社群

文件資訊

  • 文件名稱：專案管理指引（完整版）
  • 版本：2.0
  • 建立日期：2025年8月13日
  • 更新日期：2025年8月29日
  • 建立者：GitHub Copilot
  • 適用範圍：金融 IT 專案管理與企業專案管理
  • 下次檢視：2026年8月29日

版本歷程

  • v1.0 (2025/08/13)：初版建立，包含基本專案管理流程
  • v2.0 (2025/08/29)：新增品質管理、採購管理、人力資源管理、利害關係人管理、專案整合管理、敏捷專案管理、專案管理成熟度等章節

免責聲明 本指引僅供參考，實際專案執行時應根據具體情況調整。建議結合組織政策、法規要求及專案特性進行客製化。