本文件探讨了项目管理的基本理论，强调有效管理对项目成功的关键性，指出70%的项目失败源于管理不善。介绍了项目的基本定义与范围管理，强调沟通与责任意识是项目经理的重要素质，同时阐述了项目管理过程中的风险控制、时间与成本管理。总结了项目生命周期的重要特性，强调实时跟踪与调整是确保项目成功的关键。

1. 專案管理理論基礎 - 所有參與專案成員都必須知道的專案管理知識

2. 關於”專案” 70% 的專案失敗是因為管理不善引起的 , 而非技術原因 大約只有 10% 的項目能夠在預定的費用和定度計劃下交付 大部分專案經理會認為專案管理是一種” 意外的工作 ”

3. Definition: “ 專案”、”項目”、” Project” 專案是為完成某一 獨特的產品或服務 所做的 一次性 努力 目標導向，每個專案都是唯一的 非批次或日常活動 軟體專案 : 軟體開發規範 嚴謹度遠不及其他領域 ; “ 經驗”在軟體專案上仍起著極大的影響力 軟體仍未脫離手工開發模式，而人的管理是最麻煩的 軟體開發仍是最複雜的領域之一 軟體是純知識產品，其開發進度和質量很難估計和度量

4. 西天取經專案 專案發起人 – 如來佛 專案目的 – 西天取經、永傳東土 專案客戶 – 唐太宗 Functional Manager – 觀音菩薩…等 專案經理 – 唐三藏 專案成員 – 孫悟空等”技術人員”

5. 一般專案 vs 嵌入式系統專案 嵌入式專案包含所有軟體專案的特性，除了 : 對硬體性能的依賴 對硬體成本相當敏感 涉及生產相關事宜 產品品質要求 視最終市場定位而定

6. 專案管理 + 軟體工程 專案管理與軟體工程都關注達成目標前的過程，意圖歸納出最佳實踐 (best practices) 專案規劃 專案監控 專案實施 軟體開發 軟體開發 過程定義＆改善 軟體開發 品質保證＆監控 軟體工程 專案管理

7. 專案管理的迷思 PMI: PM 最重要的工作是溝通， PM 應該要有 90% 的時間花在溝通 事實上，台灣軟體開發團隊 PM 的工作性質卻是 ？ PMI: 專案的品質是規劃出來的 實際上，幾乎所有專案都是用”檢查”來保證品質

8. 專案經理 PM 最主要的一個特點是 : “ 責任大於權力” PM 責任 : 開發 專案計畫 組織 專案執行 專案控制 PM 應具備的能力 : 對專案目標有透徹的了解 了解專案需要什麼專長的成員 面向成果、注重實際、對專案有強烈的責任心 具備談判技巧 具成本意識 能應付挫折與失望、能忍受模糊不清的煎熬

9. 專案經理的角色變換 領導風格 獨裁 / 專制的 民主的 專案初期 專案末期 專案進行中 指示 (Directing) 指導 (Coaching) 協助 (Facilitating) 支援 (Supporting)

10. 專案管理基本概念 (1) 專案一開始面對的挑戰是 – “專案目標含糊，充滿衝突” 第二個挑戰是 – “專案關係人間缺乏溝通技巧與工具” 執行過程面臨最大的挑戰是 – “計畫的準確性低”

11. 專案管理基本概念 (2) PDCA

12. 專案管理基本概念 (3) Schedule Scope/ Quality 專案管理的鐵三角 – 質能守衡定律 Cost

13. 你的專案有這些”東西”嗎？ (1) SWOT 分析 專案授權書 (Project Charter) 規模管理 (Scope Management) 變更管制系統 (Change Control System) WBS (Work Breakdown Structure) 作業排序 (Activity Sequencing) 關鍵路徑 (Critical Path)

14. 你的專案有這些”東西”嗎？ (2) 挣值管理 (EVM – Earned Value Management) QA & QC 激勵理論 衝突管理 風險管理 – 定性分析、定量分析、風險監控 結案管理

15. 循專案生命週期 介紹 專案管理知識體系

16. PMP 簡介 PMP – Project Management Professional PMI – Project Management Institute PMBOK – Project Management Body of Knowledge PMP 知識体系並非閉門造車，而是世界成功專案經理的經驗累績 .

17. Copyright © 2007 FITPI. All rights reserved.

18. 專案管理五大步驟

19. 專案生命週期 專案 啟動 階段 專案 規劃 階段 Scope / Time / Cost / Quality plan Resource / Communication plan Risk plan Configuration plan 專案 執行 / 監控 階段 專案 結案 階段

20. 專案生命週期的特性 專案初期與末期成本與人力需求較低，中段最高 專案初期不確定高 (i.e. 風險高 ) 專案初期，專案關係人較能影響專案產出與成本 專案初期改變規格或修正錯誤的成本較低 專案各階段結束前為重要查核點

21. 專案啟動 (1) 專案可行性分析 專案授權書 (project charter) 明確說明專案目標與管理方向 明確對授權 PM 任何與專案有關的資訊 需求管理者 確定 需求分析 & Review 專案規模估算 專案風險分析 初略專案執行 計畫 & Review

22. 專案啟動 (2) 嵌入式系統專案啟動 確認產品規格 ( 成本 / 效能 / 品質… 需求 ) 確認產品限制 初步 確認將參與專案的公司與單位 確認開發模式 (S/W development life cycle) Waterfall model Prototype model ( 初期需求不明確 ) Spiral model (Waterfall + Prototype 的多次迭代 ) …

23. 專案結案階段 合約結案 專案結案 專案資料歸檔 技術資料歸檔 紀錄經驗，累積企業的專案資產 人員解散

24. 專案管理九大知識體系 整合 (Integration) 管理 範圍 (Scope) 管理 時間 / 時程 (Time) 管理 成本 (Cost) 管理 品質 (Quality) 管理 人力資源 (Human Resource) 管理 溝通 (Communication) 管理 風險 (Risk) 管理 採購 (Procurement) 管理

25. 專案範圍 (Scope) 管理 (1) 產品完成後發現一個需求上的缺陷 , 修改這個缺陷要比在專案初期發現這個缺陷 , 要多付出 68 倍的成本 ( 另有研究結果為 200 倍 ) 需求工程 需求開發 需求管理 變更管理 需求獲取 需求分析 需求規格 說明書 需求驗證 不可能一次 就把需求談清楚 要做好需求一定會 變動的心理準備

26. 專案範圍 (Scope) 管理 (2) WBS (Work Breakdown Structure) 工作分解，其他專案計畫 ( 成本、時間、人力… ) 最重要的依據 分解的標準 : 按 功能組成 分解 按 專案生命週期 (e.g. 規劃  設計  coding  測試… ) WBS 最底層的工作 (work package) 要非常具體，建議至少要拆分到約 1 周 or 40HRs 的工作量

28. WBS 實務 XXX project Sys Arch. System Feature MP5 Game Console DPF Portable TV Linux Porting Others DPF Product Spec. DPF tech. Transfer Photo API Host function Memory stick Optional UI Photo API design Photo API implement … … … …

29. WBS 注意事項 每項工作可再細分為許多子工作，直到可明確分配給某人或某小組 . 為 WBS 裡的每項工作進行 job description. WBS 最底層的每項工作都必須有明確的 schedule. 根據 WBS, 找出工作間的相依性 , 亦即找出可能的瓶頸所在 .

30. 專案範圍 (Scope) 管理 (3) 專案執行控制過程 專案計畫 專案追蹤 & 控制 變更 請求 變更控制 系統 計劃與實際 狀況比較 專案狀況 採集 偏差 採取 措施 ? 專案 資料庫 ( 公司資產 ) 外部變更 Y N N Y

31. 專案範圍 (Scope) 管理 (4) 需求變更管理 需求變更並不可怕，可怕的是對變更束手無策 PM 必須堅持 “絕不輕易答應需求的變更” ，應該要循變更管理控制流程決定是否接受變更 . 申請變更 變更評估 變更評估報告 CCB 作出決策 實施變更 ( 包含 修改計畫 ) 變更結案 取消變更 驗證 pass fail accept reject

32. 專案時程 (Time) 管理 (1) 時間為單向性、不可重複性、不可替代性，與其他資源特性不同 規劃 “進度計畫” 由 WBS 取得專案中所有的任務 (or 活動 activity) 確認各任務之間的關係 ( 需時長短、先後關係… ) 進度管理圖表 (Gantt/ 甘特圖 + 網路圖 ) A B A B A B A B

33. 專案時程 (Time) 管理 (2) 甘特圖 網路圖 Task1 S E Task2 Task4 Task3

34. 專案時程 (Time) 管理 (3) 關鍵路徑 (CPM) 網路圖中最長的路徑 惟有縮短關鍵路徑上各個工作的時間，對整個專案的結束時間才會有影響 專案管理軟體會自動從甘特圖中推出關鍵路徑 Task1 S E Task2 Task4 Task3 2 5 1 3 2 3

35. 專案時程 (Time) 管理 (4) Parkinson’s Law – 不論工作困難度與緊急程度，員工都傾向用完所有分配給他的時間 . 管理預留 為整個專案預留時間，而不是為各個工作預留時間 一般會預留 Critical Path 的 10~15% 另有一種說法是預留到 50%

36. 專案時程 (Time) 管理 (5) 進度管理 Schedule vs. Cost – 幾乎呈現反比關係 ( 加速 schedule 往往必須增加成本 , 反之亦然 ) WBS 分解成果的好壞，直接影響專案進度計畫 執行時期必須不斷檢查專案計畫與實際進度 , 是否存在偏差 ; 當發生第一次偏差 ( 甚至趨勢發生反轉 ) ， PM 就應該開始追蹤與處理

37. 專案成本 (Cost) 管理 (1) 軟體系統的專案成本預估，永遠 不會是 一門精確的科學 ; 只能依照以前的專案經驗或業界驗證過的共識來提高精度 . 基本嵌入式系統成本來源 : 管理成本 硬體 / 機構 設計成本 生產 & 材料成本 軟體開發成本 – Lines of code 、 Function Point 、人月… e.g. COCOMO 模型的參數 ( 評估 軟體開發案 的成本 ) a ( 乘數因子 ) b ( 指數因子 ) Organic (e.g 特定領域的應用程式 ) 2.4 1.05 Semidetached (e,g, compiler…) 3.0 1.12 Embedded system 3.6 1.2

38. 專案成本 (Cost) 管理 (2) 各階段 成本估算 的誤差 誤差的來源 基礎數據不足，或專案仍存在許多不確定因素 該專案成本對”需求”相當敏感 經驗不足、低劣的成本估算技術 簽約前後不連貫 (e.g. sales 用高規格低價格殺回來的專案 )

39. 專案成本 (Cost) 管理 (3) 軟體專案中人力成本是總成本最主要的部份；但嵌入式系統專案因為有硬體、機構與生產等成本，往往會忽略了人力成本所佔的比例。 COQ (Cost of Quality) – 品質管理也是要成本的

40. 專案成本 (Cost) 管理 (4) 你知道你的專案目前的完成度嗎 ? 你知道專案 進度 與 預算花費 的趨勢嗎 ? 挣值管理 (EVM) 成本管理 進度管理

41. 專案品質 (Quality) 管理 (1) 基本觀念 品質是規劃出來，而不是檢查出來的 專案的品質是所有開發人員的工作品質之積 例如專案成員有 10 名，每個人都只達到 90% 的品質要求 則整體專案的品質將只有 0.9^10 = 3% 品質管理非一次性活動，而是貫穿整個專案 品質等級是相對的，識客戶需求與產品價格而定 品質管理是一種精神，不非通過 ISO9000 或 CMM 就能做出有品質的產品 .

42. 專案品質 (Quality) 管理 (2) QA – Quality Assurance Is it done right? 是一種 “管理”職能 在專案執行期間，依品質計畫對專案各方面進行品質稽核 (Audit) 規劃、設計、實現、外包、測試…等階段都應該被稽核，以確定是否有破壞產品品質的可能性 QA 應為獨立單位，且擁有越級上報的權力

43. 專案品質 (Quality) 管理 (3) QC – Quality Control Is it right done? 是一種 “檢查”職能 執行 QC 的方法 TR - Technical Review Code Review 測試 趨勢分析 缺陷跟蹤

45. 專案人力資源 (Human Resource) 管理 (1) “ 人”是軟體專案中最重要的因素，而”人”這種資源具備主動性與情感，且每個人都有自己的特性 . 組織結構 職能型組織 ( 組織與專案利益可能衝突 ) 專案型組織 ( 資源重複、無法貫徹公司策略 ) 矩陣型組織 ( 職能經理 與 專案經理的衝突 ) 人員的組織管理是否得當，是影響軟體專案的決定性因素 MS 有一個明確的規則 – 專案組的人數不要超過 10 人

46. 專案人力資源 (Human Resource) 管理 (2) 強矩陣組織

47. 專案人力資源 (Human Resource) 管理 (3) 團隊管理 軟體開發是高密度的智力工作，太多 SOP 會限制了人的主動性  宏觀上採用制度管理，微觀上採用自我管理 . 激勵理論 - PM 應利用任務分配權，盡可能滿足成員的需求層次 5. 自我 實現 4. 自尊 3. 社會 2. 安全 生理 Maslow’s Hierarchy of Needs

48. Motivate like A CEO 懷抱目標與熱情 明確地傳達使命 了解激勵員工的因素有哪些 ? 與員工建立個人連結 把談話重點放在員工身上 讚賞、表揚、獎賞 言出必行 授權員工

49. 專案溝通 (Communication) 管理 管理中 70% 的錯誤是因為不善於溝通造成的 PM 80% 的時間是用在溝通 (or 90%) Communication Channel N(N-1)/2 為保持溝通的良好效果 , 必須保持溝通渠道的暢通與單一

51. 專案風險 (Risk) 管理 (1) Risk 三要素 : 是一個事件 有發生的機率 會對專案造成一定的影響 風險管理是專案管理中最容易被 ( 故意 ) 忽略，而且是最難以管理的環節 風險識別 風險評估 風險規劃 風險控制

52. 專案風險 (Risk) 管理 (2) 風險識別  產出 風險列表 風險評估 定性分析 產出 機率 / 嚴重性 矩陣 對專案的薄弱環節有一定的了解 定量分析 – 基於定性分析成果的數學處理過程 產出 “專案可能風險 排行榜” ( 機率 x 嚴重性 )

54. 專案風險 (Risk) 管理 (3) 專案管理不可能消除所有的風險 , 但仍必須制訂風險計畫 , 以期消除或減弱特定的風險事件 . 風險應對計畫 迴避風險 – 及時改變專案計畫 轉移風險 – 外包 or 保險 損失控制 承擔風險 持續維護 “風險跟蹤控制表格”

55. 專案風險 (Risk) 管理 (4) 常見的風險 專案缺乏可見度 新技術的吸引力 技術相容性風險 性能問題 倉促全面上線 可用性問題 (for end user) 缺料、零件漲價

56. 專案合約管理 軟體外包 , 比本身開發的淨投資多 15%~20% 外包專案的管理比企業開發專案更複雜 , 風險更大 : 溝通問題 作好詳細計劃 避免延誤 明訂驗收標準 ( 軟體規格與 API…)

57. 專案配置 (configuration) 管理 貫穿專案開發的全過程，目的是用於建立和維護產品的完整性和可追朔性 對應軟體開發案中成熟的 版本控制 流程 軟件配置管理 – 對開發過程中的產品進行 標識、追蹤、控制 的過程 程式碼 版本 技術文件 硬體配置 (BOM…)