Transcript 專案時程表
課程名稱︰PMP專案管理實務 講師︰林登雄 群毅國際管理顧問公司 執行長 1 • 林登雄 LIN TENG HSIUNG • 個性積極, 熱忱, 樂觀, 樂於分享 • 電話: 0910831686 • Email: [email protected] • 現職: 群毅國際管理顧問有限公司 執行長 行政院勞委會職訓局TTQS顧問、講師 行政院勞委會職訓局核心職能合格講師 • 學歷: 義守大學管理研究所畢業 • 座右銘: 改變、快樂、創新、幸福感 2 專案管理架構 3 專案與專案管理 當您的主管或客戶對您說： 請把﹝什麼事﹞，在﹝什麼時候﹞做好。 您可能就有一個專案要進行 -什麼事 (What) = 範疇 (Scope) 什麼時候 (When) = 時間 (Time) 做好 = 品質 (Quality) 您還要考慮您是否有足夠的 資源和能力 = 成本 (Cost) 來符合上述的條件，以達到 顧客滿意 (Customer Satisfaction) 因此，不論其大小，專案是無所不存在的， 而且您要去管理它！ 4 專案的共通點是甚麼？ 均希望達成一個特定的目的， 可運用的資源是有限的， 有時間的限制， 能夠在最少的成本內完成， 人員面臨多重任務之壓力， 專案的性質因時因地而異 5 5 專案的特殊條件與其意涵 明確的開始與結束 要依賴良好的計畫 需投入必要的資源 靠團隊的協調合作 建立要達成的目標 6 6 「專案」之基本特性 無論執行時間的長短，它都具有一 定的程時、明確的開始及終止點。 執行專案需使用資源，而通常專案 都是在資源有限的環境下運作。 7 「專案」之基本特性 專案內部間各任務具有「相互倚 賴」、「介面」 及「互動關係」 而亦與外部環境息息相關、彼此 間需密切合作按一定執行程式，並 需要有高度的整合性。 8 「專案」之基本特性 它是獨一無二且未曾發生過的。 執行專案的組織內外經常隱含著 「利益性的衝突」。 9 無所不在的專案 在工作上： 公司上市計畫 特定產品行銷 資訊系統建置 科技產品研發 國內外建遷廠 土木營建工程 老闆交辦的特別工作 …………… 10 10 無所不在的專案（續） 在生活上： 全家假日出遊 家庭用品採購 過年清潔掃除 擇偶、約會、結婚 論文寫作與評審 舉辦同學會、舞會、運動會 新書發行與出版…………… 11 11 專案做到100分好不好？ 12 專案品質Project Quality 做到讓顧客感動，才是品質的最高層。 100分已無法勝出，101分才是贏的關鍵；能把 「人的溫度」放進冰冷的專案中，才是未來的 大贏家。 13 專案管理失敗的主要原因 - 最高管理階層的不了解與支持不足 - 選錯專案的時機﹝如專案基礎弱、不適時的變革﹞ - 選錯人當專案經理 - 計劃不詳細、未規劃專案的結束 - 專案團隊的訓練及經驗不足 - 任務目標定義不清﹝缺乏專案團隊、管理階層與客戶對 專案目標的共識﹞ - 組織權責不清造成溝通不良 - 進度量測及監控不足14 一個成功的專案管理，除著重於專案 進度的即時掌控和成本效益的控制， 更重要的是，必須能夠掌握市場商機 。 15 專案管理的經驗學習 (Lessons Learned) - 當一展開專案管理，就計劃徹底執行 - 適當的人做適當的事、不要草率認定專案經理的資格 - 確保工作分項 (Work Package) 的大小適中 - 建立及使用規劃及管制系統為專案執行的焦點 - 確保資訊流通實際可行 - 準備隨時再規劃專案工作以適應經常的變化 - 聯繫責任、績效與獎勵 - 及早規劃專案的結束﹝特別是人力資源的流失﹞ 16 學習分享 你想到時，別人還沒想到； 別人想到時，你已經在做； 別人在做時，你已經做得不錯； 別人也做得不錯時，你已經做到最好； 別人做得跟你一樣好時，你已經換跑道在做！ 17 不斷學習，不斷創新。 做變革的領導者，不要被變革追著跑 ！ 專案管理 意示圖 Streams of Projects Project A 啟動 規劃 監控 執行 結案 公 司 水 準 Commitment資源 Direction Resources Product產出物 Service Capability Vision願景 Mission Objectives We are here !!!現在 18 時序 11 SWOT分析 內部分析 策略分析 外部分析 機 會 (O) 威 脅 (T) 1.終身學習風潮。 2.景氣不佳企業人事 精簡、多元能力受 重視 。 3.現今社會使用電腦 處理事情為基本條 件。 4.政府趨勢。 1.學校、公協會、民 間訓練機構等競爭 激烈。 2.金融風暴導致企業 公司瀕臨倒閉、裁 員，進而影響參訓 者的意願 。 優勢(S) 1.協會成員具專業背景 2.業界背景豐富且多元 3.新穎電腦教室 4.位於市區、交通便利 ※攻擊策略(SO) 1.多元能力、專業技 術培養。 2.配合政府計畫，協 助公司企業產業升 級。 ※預防策略(ST) 提升訓練及服務品 質，不只以通過TTQS 門檻為目標，以好還 要更好為努力方向。 劣勢(W) 1.承辦人員執行中變更 2.辦訓人員專業不足 3.宣導經費不足 ※補強策略(WO) 承辦或辦訓人員參加 TTQS培訓課程，規劃 並且設計符合目前社會 需求的課程。 ※迴避策略(WT) 不只規劃設計符合目 前社會需求的課程，以 提升參訓者能力為優先 考量，激發參訓者上課 慾望。 專案管理的九大知識領域 為滿足專案 “一英哩寬三吋深” 的特性，專案 經理需對各知識領域有一定程度的涉獵，故PMI 依知識領域將專案知識分為九大知識領域 九大知識依PMBOK排序: 採購 時間 整合、範圍、時程、 範圍 成本、品質、人資、 溝通、風險、採購。 風險 整 成本 合 溝通 20 人資 品質 39 起始-規劃-執行-監控-結束 五大流程 起始 規劃 監控 執行 結束 起始: Initiating 規劃: Planning 執行: Executing 21 監控: Monitoring and Controlling 結束: Closing 38 專案啟動書(章程) 22 目的:為何而戰、正當的理由 目標:SMART原則 產出物:產品、服務、計畫書、文件 限制 範圍 時間 成本 風險 品質 技術 假設:把沒把握的事先當成真的，再逐一驗證 指定專案經理及授權範圍 發起人簽字 目標:SMART原則 Specific (具體性) Measurable Achievable Relevant (可衡量性) (可行性) (關聯性) Time-bounded (有時間表) 範圍說明書 目標 產出物:產品、服務、計畫書、文件 產品範疇:特性與功能 驗收原則 專案範疇:必須做的所有工作，以里程碑顯 示 限制 假設 24 範圍說明書 範例 專案目標 1、以1000萬內資本額在4個月內於台北地區開設 第4家分店 2、展店後第一季營業額預計達300萬元 1、店面必須座落於文化學區生活圈 產品範圍說明書 2、店面總面積需求約150坪 3、全店服務人員必須接受專業餐飲服務訓練 1、市場調查有效問卷需達500份 專案要求說明書 2、店面設計規劃需參照遠洋企業連鎖店展店設計 原則 3、全店人員需經健康檢查合格並通過訓練測驗 1、市場分析評估 2、店面建構 專案範圍(專案邊 界) 3、設備建置 4、團隊建構 5、行銷推廣 25 範圍說明書 範例 1、可行性評估報告 2、店面設計圖及施工報告 專案可交付成果 3、設備採購書 4、人員訓練成果報告書 5、行銷推廣計畫書及成果報告書 1、店面座落於涵蓋主生活圈人口數達5萬人 2、店面總面積至少需達130坪 產品驗收原則 3、店長需通過3個月展店經營管理訓練課程認證合 格 4、全店服務人員需通過2週餐飲服務專業訓練及格 專案限制 1、最遲於2009/10/01開幕 2、資本額上限為1000萬 1、若人員招募不足，行銷期間可向其他分店調派 專案假設 2、若店面設計規劃未能完全依據展店設計原則， 26 則可視店面實際狀態作適當調整。 專案範疇管理 1. 確保專案達到目標所需完成的工作事項 2. 拒絕不在工作分解架構的多餘工作(no extra) 3. 免避 (專案的鍍金no gold plating) 27 WBS工作分解結構 28 將詳細範圍說明書展開成工作分解結構 專案的工作可交付成果定義 不涵蓋在WBS的專案就不在專案的範圍 分解後的任務應該是︰ 可管理的、可定量檢查的、可分發任務的、 獨立的 複雜工作至少應分解成二項任務 表示出任務間的聯繫 不表示順序關係 子專案 Subproject 專案通常被分割為較好管理的工作包或子專案。 子專案也可以當作是專案來管理 專案可展開成工作分解結構 WBS， 一直分解到 工作包(≤ 80小時的可交付成果)或子專案 工作分解結構圖示: 專案750Hrs 子專案 第一階段80Hrs. 工作包1.1 80Hrs. 工作包 第二階段250Hrs. 交付成果2.1 100Hrs. 交付成果2.2 150Hrs. 第三階段150Hrs. 工作包3.1 80Hrs. 工作包3.2 70Hrs. 子專案四270Hrs. 交付成果4.1 150Hrs. 交付成果4.2 120Hrs. 工作包4.2.1 70Hrs. 工作包4.2.2 50Hrs. 工作包 交付成果2.2.1 100Hrs. 工作包2.2.2 50Hrs. 工作包 工作包2.2.1.1 60Hrs. 29 工作包2.2.1.2 40Hrs. 工作包 工作包4.1.1 70Hrs. 工作包4.1.2 30Hrs. 工作包4.1.3 50Hrs. 工作包 12 製作WBS的陷阱 不要分解得過於細微 勿超出您能管理的程度（太粗或太細） 考慮成本效益（值不值得） 分解過細會造成大量的文件製作 30 建議每一工作包的工期勿大於2週，勿小於 1天 ERP建置專案 ERP 1 需求評估 2 ERP規劃 3 ERP導入 ERP上線 5 ERP結案 公司內需 評估 公司未來 流程架構 專案 KICKOFF ERP正式 上線 績效考核 功能需求 評估 系統規格 架構 需求訪談 系統功能 修正 專案結案 風險,時程,預 算,成本評估 軟硬體架 構 人員訓練 供應商評 估 廠商簽約 BPR進行 流程資源盤 點 客製化開 發測試 上線模擬 31 4 功能驗收 專案的主要工作項目 工作分解結構圖(WBS) 藝術音樂饗 宴專案 人員聯絡 (10%)﹝1﹞ 藝術宣傳 (20%)﹝2﹞ 場地規劃 (10%)﹝3﹞ 節目表演規劃 (50%)﹝4﹞ 邀請卡分發 (60%)【1.1】 海報設計 (50%)【2.1】 場內聽眾引導 (40%)【3.1】 舞台背景設計 (20%)【4.1】 接待安排 (40%)【1.2】 邀請卡設計 (50%)【2.2】 車輛路線管制 (40%)【3.2】 音響及燈光 (20%)【4.2】 秩序維護 (20%)【3.3】 節目設計 (60%)【4.3】 行政 (10%)﹝5﹞ 道具器材搬運 (50%)【5.1】 場地整理及善後 (30%)【5.2】 公文及場地租借 (20%)【5.3】 32 案例討論 假如您要在自己的家裡舉行一次生日宴 會，請按WBS為你製定一份工作的分解計 畫？ 33 生日宴會 1 準備 1.1 邀請來賓 1.2 採買物品 2 晚宴 2.1生日蛋糕 2.2飲料 2.3清洗 2.3.1食品 2.3.2餐具 2.4做菜 34 2.4.1涼菜 2.4.2熟菜 2.4.2.1菜蔬類 2.4.2.2海鮮類 2.4.2.3其它類 3 娛樂 3.1音響 3.2燈光佈置 3.3室內佈置 3.4CD/VCD光碟 WBS Workshop 時間 1.分組：每組 ５－７人、時間：20 分 2.產出：專案工作分解結構圖 (WBS) (1).共同工作領域的專案 (2).WBS以組織圖型態畫出 (3).最底層為小於80小時的工作細目 35 分解WBS的輔助工具軟體 表格編製法 樹狀結構法 36 Microsoft Excel, Project 心智圖, 輔助工具軟體－Project 37 輔助工具軟體－心智圖 X_MIND下載網址 http://www.xmind.net/ 38 IDEO創意解決問題的五步驟 1.觀察 2.腦力激盪 3.迅速做出樣品 4.不斷改進 5.執行 39 個案-「IDEO產品創新開發設計」 影片分享 ..\..\..\..\..\IDEO公司影片 40 專案時間管理作業與主要產出文件 WBS WBS 詞彙表 OBS 專案角色及 職掌規劃表 資源清單 風險 登記冊 1. 活動定義 2. 活動排序 3. 活動資源 估算 4. 活動持續 時間估算 5. 發展時程表 活動清單 專案網圖 活動資源 需求預估表 活動時程 估算表 專案時程表 里程碑 41 時程 管理計畫 6. 時程控制 活動定義 42 「活動定義」流程的主要工作：辨識需要 執行那些專案活動(schedule activities)， 方能完成WBS工作包(work packages)之 交付物 專案活動 專案活動(schedule activity)是以WBS工作包(work package) 為基礎做更進一步的分解，以便對該項工作做更好的估算、排 程、執行、管控 WBS工作包的交付物通常為名詞(或動名詞)，專案活動則通常 是動詞＋受詞 例如工程圖是一項交付物，為了完成這一份工程圖可能需要經 歷「設計」工程圖、「審查」工程圖、「核准」工程圖、「發 行」工程圖…等活動 活動只會出現在工作包之下， 而且只有一層 工作包 活動1 43 活動2 活動3 活動清單(Activity List) 活動清單為「活動定義」流程的主要產出 文件 通常是由負責該WBS工作包的團隊成員來 負責條列出完成該項交付物的專案活動有 那些 這些條列出來活動就是專案時程表的基本 元素 44 定義活動-活動清單 工作 編碼 45 工作 名稱 輸入 輸出 內容 負責 單位 協作 單位 相關 工作 里程碑(Milestone) 專案的重要 “事件”，通常是一個主要(重 要)交付物的完成點 里程碑的工期(duration) =0 專案里程碑必須有交付成果，而非只是一 些活動或過程 對於里程碑狀態的評審，只能有兩種情況： 完成、未完成 46 里程碑圖範例 事件 一月 資料日 二月 三月 四月 五月 六月 七月 八月 次合約的簽署 規格定案 設計審查 子系統測試 交付第一個單位 完成生產計劃 計劃的 △ 實際的▼ 47 47 里程碑(Milestone Chart)範例 專案編號 123 製表日期 99.6.5 ：已完成里程碑 專案名稱 製表人 新辦公室專案 MICHAEL ：未完成里程碑 日期 活動 活動內容 期 程 需求確認完成 0d 購置完成 0d 設計公司評選完成 0d 裝修設計完成 0d 搬遷工程完成 0d 99年7 月 99年8 月 8/11 99年9 月 99年 10月 99年 11月 99年 12月 100年 1月 8/20 9/20 9/1 9/10 9/28 10/10 12/25 1/10 Report date: 98/10/28 48 34 活動排序 「活動排序」流程的主要工作：找出活動 之間的順序(sequence)及關連性 (dependency)，並予以文件化 活動若未經排序，將無法計算出正確的專 案總工期 「活動排序」流程的產出物為專案網路圖， 簡稱網圖 49 專案網路圖(1/3) 順序圖示法(PDM) Arrow 箭頭 = Dependencies 依存關係 (先後順序) Node 節點(方形或長方形) = Activity 活動 亦稱為 「節點表示法」( Activity-On-Node , AON) A C 開始 B 50 結束 FS+3D D E 專案網路圖(2/3) 順序圖示法範例： 程式 製作 Start 專案 規劃 需求 分析 系統 設計 系統 測試 測試 資料 51 系統 驗收 End 專案網路圖(3/3) 順序圖示法的四種依存關係： Dependency 依存關係 Predecesso r 前置活動 (A) Successor 後續活動 (B) Finish-to-Start (FS) Must finish 結束到開始 (最常使用) 要先結束 Before can start 才能開始 Finish-to-Finish (FF) Must finish 結束到結束 要先結束 Before can finish 才能結束 Start-to-Start (SS) 開始到開始 Must start 要先開始 Before can start 才能開始 Start-to-Finish (SF) Must start 開始到結束 (最少使用) 要先開始 Before can finish 才能結束 52 Diagramming 圖示 A B A B A A B B 活動的依存關係 強制依存關係(Mandatory Dependencies) 刻意依存關係(Discretionary Dependencies) 又稱為軟邏輯關係 (Soft Logic) 通常是根據專案團隊的知識與經驗，或是某些特定應用 領域的「最佳實務」或專案的特性來設定依存關係 外部依存關係(External Dependencies) 53 又稱為硬邏輯關係 (Hard Logic) 活動間必然存在的依存關係，這些關係常常是某些制約 性因素所造成 與專案外部相關活動之關係 活動資源估算 「活動資源估算」流程的主要工作：估算 執行每一個專案活動需要那些資源、多少 數量，以及何時需要使用這些資源 在進行活動資源估算前，必須知道組織內 有那些資源可用(resource availability)， 若組織內的資源不足時，可考慮透過專案 採購管理作業自組織的外部取得 54 專案活動資源需求預估表(範例) 55 活動持續時間估算 56 「活動持續時間估算」流程的主要工作： 估算個別專案活動完成所需要的時間(工期) 活動持續時間的估算方法(1/3) 專家判斷法(Expert Judgment) 儘可能使用有經驗的專家，依據歷史資料提供工期的判斷與 認定 類比估算法(Analogous Estimating) 利用先前類似活動的工期為基礎，來估算本次專案的活動工 期 亦稱“由上而下估算 (Top-Down Estimating)” 是專家判斷的一種型式 當先前專案與本次專案在實質上相類似(不僅是外觀上類)， 且進行估算的人員有所需的經驗時，類比估算才較可靠 57 活動持續時間的估算方法(2/3) 參數估算法(Parametric Estimating) 透過將基本單位量化，再乘上工作數量的方法 來估算工期 工期 = 工作數量 * 單位產能 例如：50份藍圖 作天 58 * (2工作天 / 1份藍圖) = 100工 活動持續時間的估算方法(3/3) 三點估計法(Three-point Estimating) 利用「最有可能的工期M」、 「樂觀的工 期O」 、 「悲觀的工期P」三個數值予以 平均取得較為準確的工期 (P+M+O)/3 計畫評核術(PERT) (P+4*M+O)/6 59 發展時程表(進度表) 60 「發展時程表」流程的主要工作：分析專 案活動的順序、工期、資源需求，以及排 程的限制，製作成專案的時程表 要徑法(Critical Path Method)(1/4) 61 在不考慮資源的限制下，對所有的專案 活動計算其(最早及最晚)開始和結束日 期，提供可能的進度計畫 正向排程：可計算出最早開始(ES)和結 束日期(EF) 反向排程：可計算出最晚開始(LS)和結 束日期(LF) 要徑法(Critical Path Method) (2/4) 要徑(Critical Path) 專案網路圖中總工期最長的活動路線就稱為要徑 專案的總工期即為要徑上活動的工期總和 浮時 (Float) 一個活動可延後而不影響下個(後續)活動開始或專案完成的 時間，又稱為寬裕時間 (Slack) 要徑沒有浮時 可據以判定哪些活動的時程彈性最小，需保持關注 計算方式 利用單一(最可能)估算值 浮時 = LF- EF = LS - ES 62 浮時分析說明(3/4) 總浮時 (Total Float；TF) ：不影響整 體期程下，活動之最大允許寬裕時間 TF=LS-ES =LF-EF 最晚完成日期 最早開始日期 總浮時=4 ES=0 6天 EF=6 LF=10 6天 LS=4 總浮時=4 ES D EF 0 63 TF 6 活動 活動 LS 6 LF 4 4 10 49 要徑法(Critical Path Method) (4/4) 要徑計算： 請找出本網圖中的要徑 A 3天 C 7天 F 9天 Start 開始 End 結束 B 8天 浮時計算： 請計算活動 64 G 5天 G 的浮時 D 3天 專案網路圖實作 ( by 實際天數 ) 7/1 2 7/2 7/3 活動 A 4 5 活動 C 活動 F 6 SS 3 6 活動 B 活動 E FF Notes: ES D EF Activity LS S 5 活動 D 活動 G LF 備註 ES: Early Start最早開始日期 EF: EarlyFinish最早完成日期 LS: Late Start最遲開始日期 LF: Late Finish最遲完成日期 D: Duration活動持續時間 S: Slack 時差=LF-EF=LS-ES , 2 7/17 填寫步驟 1.任務最小單位為 1天, 假設不考慮假日 2.先把關鍵路線 (CP: Critical Path) 找出來, 在路線畫上粗紅線 3.填入CP 的 ES, EF. EF=ES+D-1 4.由於CP 沒有時差, 故 S 皆等於0 5.由於CP 的 S=0, 故 EF=LF, LS=ES 6.其它的可由S=LF-EF=LS-ES 算知得來 @ . 65 壓縮專案時程的方法 在不改變專案範疇的情況下，縮短專案時 程的方法： 趕進度 (Crashing) 以最小的成本增加(增加資源的投入)，達到最大的 時程壓縮 代價是成本的增加 快速跟進 (Fast Tracking) 將原有先後順序的活動平行進行 代價是常會造成重工及增加風險 66 資源撫平(1/2) 將資源的運用時間分散，以避免資源過度 集中 通常會造成更長的專案工期 作業考量 有限的資源如何作有效且合理的分配? 如何在工期限制的狀況下，有效的的運用資源? 67 資源撫平-範例(2/2) 假設資源最大使用率 = 10 天/月 資源撫平前/後比較 18 16 14 12 天 10 前 8 後 6 4 月 2 0 68 1 2 3 4 5 前 8 14 4 18 16 後 8 10 8 10 10 6 7 10 4 專案時程表 69 包含每項活動的預計開始和結束日期 可以摘要的方式呈現 (Master Schedule 主排程)，或 以細目方式表示 以表列方式及圖形方式呈現， 一般常使用長條圖方式 表示 專案時程經主管認可後，即成為專案時程基準，供往 後專案執行之績效評量之用 為整體專案計畫(project plan)中的主要文件之一 專案時程表－甘特圖(摘要性任務) 70 專案成本管理作業與主要產出文 件 WBS 資源清單 WBS 詞彙表 專案時程表 活動時程 估算表 1. 成本估算 2. 成本預算 專案成本 預估表 成本預算 S曲線 成本 管理計畫 71 活動資源 需求預估表 3. 成本控制 成本估算 72 「成本估算」流程的主要工作：編製完成 專案活動所需資源的大致費用 成本的估算方法 類比估算(Analogous Estimating) 參數估算(Parametric Estimating) 由下往上估算(Bottom-Up Estimating) 73 類比估算法 利用先前類似專案的成本為基礎，來估 算此次專案的成本 亦稱“由上而下估算 (Top-Down Estimating)” 是專家判斷的一種型式 估算的可靠性 當先前專案與本次專案在實質上相類似(不 僅是外觀上類似)，且進行估算的人員有所 需的經驗時，類比估算才較可靠 74 參數估算法 利用專案的特性建構數學計算模式，用 以計算專案費用。 例如：資深程式設計師或一般程式設計 師的單位工時成本，乘上某程式撰寫所 需的時數，可估算出該程式的人工成本 75 由下往上估算法 依據 WBS ，先估算底層個別活動的成本， 再向上累加，以得到專案總成本 以底層的活動來做估算，雖可使估算的準 確度提高，但花在估算這些活動的作業時 間與費用亦會相對的增加。 76 建議之專案成本估算方式 Top-down + Bottom up 前者適用於專案起始階段 按比例分配，其好處為不會超出預算限制， 且省時 但前題是有類似的專案做為參照基礎 後者適用於專案規劃階段 有詳細的工作項目時 其好處為估算較為精準，缺點為耗時 77 專案成本預估表—簡式(範例) 78 成本預算 79 「成本預算」流程的主要工作：集結每一 個個別活動或WBS工作包的預估成本，建 立專案的成本基準。 成本基準(1/2) 以時間階段來表示累計的預算費用，其形狀通常 趨近一個 S形，故又稱S曲線 做為專案成本執行績效的量測和監督依據 專案計畫書(Project Plan) 的績效評量基準 (baselines)，分為以下三種: 範圍(Scope)基準 ：工作分解結構 時間(Time)基準：專案時程 成本(Cost)基準：分時間階段的預算 80 專案預算表(範例) 81 S曲線圖(範例) 82 專案品質規劃 83 品質規劃 「品質規劃」流程的主要工作：判斷哪些 品質標準與本專案相關，並決定應該如何 達到這些品質標準。 1. 品質規劃 84 2. 實施 品質保證 3. 實施 品質控制 品質的成本 品質的成本＝預防成本＋檢驗成本＋失敗 的成本（例如重工） 1:10:100原則 85 品質規劃流程的產出物 品質管理計畫 品質衡量指標 86 描述專案管理團隊應如何將組織的品質政策 落實在本專案中執行，是整體專案管理計畫 書的一部份 為特定的產出物建立操作性定義，做為後續 執行品質控制量測的依據 專案品質管理重點 挑出WBS中重要交付成果 1.影響專案績效的關鍵 – 成本、時程、範圍 2.影響專案品質的關鍵 訂定交付成果的驗收品質標準、如何驗收 1.驗收品質標準 – 量化、明確 2.如何驗收 – 具體、可行 87 校園徵才專案 品質管理指標 如果您是校園徵才負責人，您該如何擬定您 的專案品質管理計劃呢? WBS 重要交付成果 驗收品質標準 如何驗收 專案成員 徵才廠商評估報 告書 前500大企業 依天下雜誌調查 規劃組 小群 攤位施工設計 符合設計圖規格 驗收施工是否與 設計圖符合 外包組 汪先生 現場服務人員訓 練 訓練時數滿5小時 訓練、實作模擬 且考試合格 訓練組 陳小姐 廠商攤位佈置 符合大會規格 參加廠商 88 參加者票選最佳 攤位 品質管理指標 Worskshop 產出 重要交付成果 驗收品質標 準 如何驗收 客製化開發測 單元->整合- 測試報告 試 >系統測試 89 驗收頻率 單元測試->週 整合測試->天 專案人力資源管理作業 與主要產出文件 WBS 活動資源 需求預估表 WBS 詞彙表 1. 人力資源 規劃 OBS 專案角色及 職掌規劃表 RAM 人力資源 管理計畫 2. 取得 專案團隊 3. 發展 專案團隊 4. 管理 專案團隊 ＰＭＩ的人力資源管理觀點 1.專案經理必需了解專案成員執行工作必須要獲 得 該有的報酬或補償 2.在規劃階段專案經理應立即著手建立獎賞制度 3.專案經理需花時間建立利害關係者的角色與權 責 及文件化，並讓他們接納(buy in) 4.實際上大多數專案都會在矩陣式組織執行，所 以 激勵理論及專案經理在矩陣式中權力輕重需 特別 注意 5.因現實結構，衝突無法完全避免，但專案經理 需 花心思預防及處理衝突的因素，避免造成衝 突． 若有衝突，應由造成衝突的成員自行處理 91 1.發展人力資源計畫書 Develop Human Resource Plan 92 一句訣：組織架構為何？每個人的角色責任 是啥？如何讓所有人完成任務並有卓越績效 表現。 人力資源計畫書確認專案成員的角色與責任， 所需要的技能、報告關係及建立相關的用人 管理計畫書 專案的成員可以來自公司內部，亦可來自外 部 2009.5.29 「如魚得水」顧問公司 總經 理 洪家祥 組織分解結構圖(OBS) (範例) 專案角色及職掌規劃表 (範例) 責任分派矩陣 (Responsibility Assignment Matrix, RAM) WBS OBS R R A A R A P A R,S I I I A I P I,R A S P R,S I I,R P A A A A P = Participant參與 A = Accountable 主辦 R = Review required審核 I = Information only 資訊通知 S = Sign-off required 驗收 責任分派矩陣 ( ▲ 負責 審核批示 责任者 WBS 專 案 經 理 ●輔助 土 建 總 工 機 電 總 工 總 會 計 師 工 管 處 △承包 總 務 處 计 計 劃 處 □通知) 機 電 設 備 設 計 單 位 顧 問 電 力 局 睡 墊 布 中 技 公 司 電 工 處 中 工 處 大 成 ▲ ● □ 〇 □ □ □ ▲ ● 〇 □ □ □ □ 〇 □ □ ▲ □ ● ● 設計 ● ● ● ● 招標 ● ● ● ● 施工準 備 ▲ ● □ □ 採購 〇 □ ● □ □ ● ● ▲ □ ▲ ● □ ● ● ● ● ● ● ▲ ▲ ● ● ● ● ● ● ● ● ● □ □ 施工 專案管 理 ▲ ● ● 副主 管 部 門 經 理 項 目 經 理 工 程 經 理 軟 體 經 理 生產 經理 市場 經理 次程式 生產經 理 次程式 軟體經 理 次程 式硬 體經 理 次程 式服 務經 理 6 2 1 3 3 3 3 4 4 4 4 定義WBS 5 1 3 3 3 3 3 3 3 3 建立硬體 2 3 1 4 4 4 3 4 1 建立項目計畫 建立軟體 4 建立界面 2 3 1 4 4 4 生產監測 2 3 4 4 1 4 定義檔案 2 1 4 4 4 4 3 5 4 4 4 1 準備勞動力估 計 3 1 1 1 4 4 4 4 準備設備成本 估計 3 1 1 1 4 4 4 4 準備材料成本 3 1 1 1 4 4 4 4 編分發程式 3 1 1 1 4 4 4 4 建立時間進度 3 1 1 1 4 4 4 4 建立市場計畫 5 1─實際負責 2─一般監督 3─參與商議 4─可以參與商議 5─必須通知 6─最後批准 專案經理的角色與權責 1.專案經理是負責專案達成目標的人，主導與指 導計劃的方向，負專案成敗之責 2.在專案的生命週期中愈早被指派愈好 3.應被適當地授權，以利完成專案的管理工作． 是專案唯一在做整合的人，以達到專案的目標 4.常作的事：激勵團隊，訓練成員，為專案成員 未來鋪路 5.有權利拒絶專案額外的事項 6.時時控制專案的進度並提出改善行動 7.建立專案的變更管理系統 98 專案經理的人資職能 1. 建立團隊通訊錄(Team Directory) 2. 與功能主管協商最佳資源 3. 建立並確認利害關係者的Ｒ＆Ｒ 4. 與專案建立專案的角色與權責及工作事項 5. 了解團隊能力的限制，並確保他們取得訓練的 資源 6. 為利害關係者建立正式的人力配備管理計劃 7. 為專案成員後續的職涯發展鋪路 8. 適時鼓舞團隊士氣激勵團隊，建立獎勵制度 99 專案發起人的角色與權責 1.專案發起人是專案資金的提供者，也是專案的 保護傘，可能是公司的高階主管或是外部客戶 2.在啟動階段，角色最為吃重 1)協助專案團隊解決資金籌備 2)提供專案工作說明書（先有專案工作說明書， 再有章程） 3)發出專案章程，授權權限及組織資源給專案經 理 4)提供專案限制（完成日期，主要里程碑）及交 付成果 5)澄清專案範圍，決定專案優先順序，簽核正式 的專案 管理計劃 6)訂出可容忍的風險度 100 7)協助專案經理無法解決的瓶頸問題 2.獲得專案團隊 Acquire Project Team 獲得專案團隊是找到專案所需人力的 過程 先行指派 Pre-Assignment 某些專案的成員在一開始就被指定，被納 入在章程 (Charter) 裡 為何獲得專案團隊會在執行階段？ PMBOK以大型專案為主體，故大部份的 成員都在專案規劃後才加入。例：廠商、 執行成員 故可解讀成 定案的專案團隊 101 3.發展專案團隊 Develop Project Team 發展團隊可以改善成員的能力及團隊的 互動關係，用以提昇專案的績效。目標 包含： 提昇成員的能力達到完成專案活動的 目標 提昇團隊彼此間的信賴及默契，發揮 團隊效能 團隊發展要越早開始越好，在整個專案 生命週期持續進行著 102 您如何讓矩陣組織裡不同產業經驗、不同 語言、不同文化的專案成員與您共同協力 完成專案目標呢？ 答案就是 “建立共識與信任”並持續進行 團隊建設 團隊合作 (Teamwork) 是專案成功的關鍵 因素，而發展有效專案團隊是專案經理主 要任務之一 ..\..\..\..\..\美好文章201101\教學影片\雅尼現場演奏 (E)\Yanni(雅尼)..[Yanni.Live.The.Concert.Event.2006].avi OJT-Competence Map 多能功訓練表: I:未熟悉, L:可勝任, U:純熟, O:可教導他人 作業#1 作業#2 作業#3 作業#4 作業#5 作業#6 作業員 Andy 作業員 Ben 作業員 Joe I O I L O I U L L L U I O U L O O U 馬斯洛需求層級理論 (Abraham H. Maslow’s hierarchy of needs) 內 在 因 素 自我 實現 自尊需求 歸屬與愛的需求 外 在 因 素 安全需求 生理需求 麥克里葛理論 1. Ｘ理論：人性本惡 1) 管理的傳統觀點，由上而下 2) 經理人：控制員工 3) 員工：假設人性是以自我為中心，需鞭策的 2. Ｙ理論：人性本善 1) 經理人：創造讓員工達成目標的舞台 2) 員工：假設人性為願意接受組織行為所賦予的 責任 106 赫茲伯格激勵理論 1. 保健因子Hygiene：不良的保健因子會 喪 失動力，但若提昇保健因子也不會增加 動力．例：薪資，工作環境，主管的行為， 工作關係 2. 激勵因子：激勵因子增加就會增加動 力． 例：工作成就，賦予責任，專案肯定， 獎 金，晉昇 107 專案團隊管理 Project Develop Management 管理專案團隊包含追蹤成員的績效、提供 回饋、解決問題及協調變更使專案績效提 昇 專案管理團隊觀察團隊的行為、管理衝突、 解決問題及獎勵成員的績效 專案經理權責：有效管理雙重報告体 系， 是專案成功的關鍵，尢其是在矩陣 組織 中． 109 績效報告種類 團隊績效評估Team Performance Assessment： 專案管理團隊可以用正式或非 正式的方式對團隊 績效進行不斷的評估，在過 程中可採取措施以解 決問題、改變溝通方式、 解決衝突並提高成員間 的互動 工作績效資訊Work Performance Information： 提供成員績效的訊息，包含會議 的參與、成完成 行動達成率及工作紀律遵守 績效報告Performance Reports：提供績效文 件， 以專案管理計劃為基準 110 專案績效考核Project Performance Appraisals 依據專案的長短、複雜度、組織政策、 合 約要求以及定期溝通的數量和品質決 定考 核方式 專案成員的功能主管需參考專案經理對 組 員績效的回饋 360度回饋法：績效考評參考主管、同僚及 部屬的評比 111 專案與個人績效考核連結 每份登入在PMIS的專案在最後結案都可以 由專案執行者的直屬主管及專案經理進行 專案績效考核．這個分數可以定期匯出做 績效考核的參考 專案在績效考核中建議所佔的比重如下： 1.管理階層：70%~80%(組織的專案績效) 2.技術人員：40%~50%(個人的專案績效) 3.行政人員：30%~40%(個人的專案績效) 112 組織的專案衝突來源 專案衝突包含 (依衝突順序排列)： 1.時程 (Schedule) 2.專案優先順序 (Project priorities) 3.資源 (Resources) 4.技術意見 (Technical opinions) 5.行政程序 (Administrative procedures) 6.成本 (Cost) 7.人格特質 (Personality) 113 衝突管理Conflict Management 成功的衝突管理可以提昇生產力及正向的 團隊工作關係，衝突有時是有利的 衝突無法避免因為： 1.專案利害關係者間的需求可能互相衝突 2.專案經理在組織中有限的權限 3.專案經理使用功能部門的資源 解決衝突的初始權責在成員本身，若衝突 逐漸上昇，則專案經理需協助解決 114 如何避免衝突： 1.很清楚的任務指派及說明 2.專案成員無重疊的角色與權責 3.成員有很清楚的責任(ownership)概念 4.激起工作鬥志並賦予挑戰性的任務 5.成員間良性溝通： 專案的聚焦重點、限制及目標、章程內容、 關鍵決策及專案的變更等需讓成員明瞭 115 衝突解決方法 1.解決問題(面對)Problem Solving/ Confrontation－最佳方法．雙贏Win-Win 2.妥協或折衷Compromise：第二好的方法，雙 方各退一步．雙輸Lose-Lose 3.舒緩或安撫Smoothing：只是安撫情緒，並未 把問題解決 4.撤退或遠離Withdrawal/ Avoidance：暫時性 的措施，雙方從衝突中退出，但仍未解決問題 5.強制或獨裁Forcing：最壞的方法，一方得逞， 另一方失敗．贏輸Win-Lose 6.合作︰從不同看法融入多元的觀點及見解，而 獲致共識與承諾 116 專案溝通管理作業與主要產出文件 假設與限制 清單 範圍說明書 1. 專案溝通 規劃 利害關係人 辨識與分析 溝通管理 計畫 2. 資訊分送 3. 績效報告 4. 管理 利害關係人 溝通管理Project Communication Management 1.專案溝通管理流程確保專案資訊在適當時 間並及時的建立、收集、發布、儲存、搜 尋並作 最終處置 2.專案溝透過程建立良好的溝通管道，提供 利害 關係者與資訊作關鍵性的連結 3.專案經理需花大量的時間和專案的利害關 系人、 專案團隊、客戶及發起人溝通 4.專案經理花９０％以上的時間在溝通 118 ＰＭＩ的溝通管理觀點 1. 案經理在溝通管理應完專成三件重要事情 1) 確認利害關係者所需的資訊及溝通的需求 2) 建立溝通管理計劃 3) 定期發佈專案狀態報告 2. ＰＭ花９０％的時間在溝通，包含面對面、電 話、傳真、e-mail及 製作書面文件的時間 3. 每次面對面溝通的比重：５５％非語言、３８ ％語言、７％文字 4. 專案進度及績效報告需定期發佈給利害關係者 5. 專案大小事情發生及變更皆需知會利害關係者 119 6. ＰＭ需了解利害關係者的專長，了解他們的需 求及期望 7. 確保專案在專案控制及結案的知識是足夠的 8. 專案經理人並不會依靠開會來掌握每個人的進 度，事實上還有許多 工具可以收集進度，如ＰＭ ＩＳ、成員專案週報．． 9. 溝通無法被掌控，但專案經理仍需儘可能掌握 溝通 10. 溝通管道和專案成員數呈等比級數關係，３人 ３個，４人4個．． 11. 經驗學習是組織過程資產的重要產出，可供下 次專案使用 利害關係者分析，通常依循下列所述之步 驟進行 第一歩：辨識所有潛在的專案利害關係者 與相關資訊，諸如，他們的角色、部門、 利益、知識程度、期望及影響力的程度等 第二歩：辨識每一位利害關係者可能產生 的潛在影響或支持，並將他們分類，已定 義出一個策略方案 121 如何找出所有的利害關係人? 利用利害關係人分類表，找出利害關係人 種類 例如 完成專案交付物的人 專案團隊、合約廠商… 使用專案交付物的人 顧客、組織內的用戶… 提供支援以協助專案完成的人 技術支援部門、行政部門… 資金提供者 執行長、專案贊助者、股東… 檢驗或稽核人員 內部品質部門或外部的檢驗機關、環 評單位.. 受到專案成果影響的人 競爭對手、工會… 其他有關人員 提供資源的功能性部門主管.. 分析利害關係人 這些人是誰 那些是主要(核心)利害關係人 與本專案的關係 對本專案的影響力 關注的議題為何 對本專案的支持程度 溝通策略(口頭、書面、主動、被動、正 式、非正式…) 利害關係人辨識與分析表(範例) 會議與簡報計畫 (範例) 專案經理不可不知的溝通兩三事 溝通是專案經理人最重要的技能 專案經理人90%的時間是花在溝通上 人多未必好辨事 不能寫下的承諾等於什麼也不是 靠記錄而不要靠記憶 溝通規劃Communications Planning 溝通規劃的過程包含確認利害關係者所需的資訊及溝通的 需求，如： 誰需要什麼樣的資訊 什麼時候會用到 如何傳遞 誰來發佈 溝通計劃在專案一開始即需要被規劃，這屬於主動的溝通 專案執行的結果需要在整個專案的生命週期中定期審查並 更新進度給利害關係者，如： 專案進度：甘特圖、狀態報告、進度報告、績效報 告．． 會議文件：會議記錄、應完成項目完成情況． 127 全方位的溝通 l 需確保溝通方向是均衡發展 發起人、客戶、組織、機關 其它利害 關係者 專案 其它專案 專案團隊 128 專案管理計劃 Project Management Plan 專案管理計劃提供專案的背景資訊，包 含 與溝通計劃有關的日期，限制與假設 限制：限制團隊意見的因素，例如：在不 同 地理位置的成員；使用中文版或英文版 視窗 介面；使用溝通設備的限制 假設：適合個別專案的假設，例如：成員 皆 可順利的用英文溝通，每天都會看Email， 手機都會開機．． 129 溝通需求分析 Communications Requirement Analysis 溝通需求分析 1.是專案利害關係者對資訊需求的總合 2.包含定義所需要的資訊類型以及資訊的價值分析 3.目的在於避免專案利害關係者接收到不完整或過多的專案 資訊 確定專案溝通的要求需要以下的資訊： 1.專案組織圖 2.專案利害關係者的職責關係專案所涉及的專業、部門及紀 律 3.多少人參與及所在地點 4.內部資訊需求，例：跨部門 5.外部資訊需求 6.利害關係者的背景資訊 130 溝通管道 CommunicationsChannel 溝通管道數量Ｎ Ｎ＝n(n-1) ，n 為利害關係者的人數2 2 例：４個利害關係人 的溝通管為６個管道 131 練習︰ 一个项目班子共有五个成员，然后又增加 了两个。请问总共增加了几个沟通渠道? 132 溝通技術Communications Technology 溝通技術是如何將資訊有效地傳達給專案利害 關係者， 例如：定期會議或將已完成的事項記 錄到可共同存取的 網頁 影響專案溝通技術的因素： 1.資訊的需求頻率，例：多久需要提供資訊一次 2.技術的可使用性，例：是否有傳真設備 3.專案成員的能力，例：專案成員是否會使用Email 4.專案的長短，例：溝通設備ADSL是否可以使用到專案生 命週期結束為止 專案環境，例：專案成員是否可面對面，或者是處 在虛 擬環境裡 133 溝通管理計劃 Communication Management Plan 溝通管理計劃可以是正式或非正式、詳細或概要，依專案的需求而定， 它提供以下的內容： 1.專案利害關係者的溝通需求 2.需要被交換的資訊，如：格式，內容，資訊詳細的程度 3.負責發佈訊息的成員 4.誰接收發佈的訊息 5.使用什麼方法來發佈資訊 6.溝通頻率 7.當低階層的成員無法處理問題多久的時間，即應反應到應 處 理的更高階層主管 8.專案進行中的更新溝通管理計劃的方法 9.共同語言或詞彙 134 績效報告Performance Reporting 專案績效報告包含收集所有基準的資料及發佈績效報告給 利害關係者 績效資訊包含： 1.資源如何被應用 2.專案目標如何被達成 專案績效資訊範圍包含： 1. 範圍 2. 時程 3. 成本 4. 品質 5. 風險及採購 135 工作績效資訊 Work Performance Reporting 關於可交付成果的完成狀態及已完成項目的工作績效資訊， 屬績效報告的一部份 績效量測基準Performance measurement baseline：在 一個核准的專案計劃中，用以比較專案執行的結果，量測 的差異用以控制及管理專案績效，需在專案執行階段開始 前完成 績效量測基準通常整合： 1. 範圍 2. 時程 3. 成本 4. 活動時程估計 136 資訊演示工具、狀態審查會及匯 報系統 資訊演示工具：使用的軟体包括工作表的分析、製作報表、 簡報或圖形能力． 狀態審查會：是定期的會議，用以交換專案資訊，可依不 同頻率及不同層級來召開： 1.專案經理每週與成員定期開會 2.每週與高階主管簡報專案進度 3.每月與客戶簡報專案里程碑 匯報系統： 1. 時程報告系統：記錄及提供專案用掉的時程 2. 成本報告系統：記錄及提供專案用掉的成本 137 績效報告Performance Reporting 績效報告組織及摘要收集的資訊，呈現與績效基準量測的 比較及分析的結果，實獲值分析(EVA)通常會包含在績效 報告內 績效報告的種類： 1.狀態報告：專案的目前狀態（現在在哪裡） 2.進度報告：專案完成了什麼 3.趨勢報告：檢視專案成果與時間的關聯，看績效是否改善 或惡化 預測報告：用專案過去的績效來預測專案未來狀態及績效， 例：完工時程估算，完工尚需估算 差異分析報告：分析實際與預期間的差異 實獲值：整合範圍、成本及時程以量測專案的績效 138 專案進度與狀態報告(範例) 139 2009.5.29 「如魚得水」顧問公司 總經 理 洪家祥 活動一：溝通練習 140 有效溝通vs.有效聆聽 有效溝通 Effective Communication 有效聆聽 Effective Listening 傳送訊息者： 1. 詞達意 2. 找最好表達的工具 3. 確認傳送的訊息被理解 接收訊息者 1. 仔細解讀 2. 確認所收到訊息的意思 回證如下：〝妳可否將我的話再重 覆一遍〞 回證如下：〝剛剛你的意思是這 樣．．．的嗎？〞 使用聲調及節奏增加表達 使用聲調及節奏增加表達 有５５%的溝通是非劉言性的 主動聆聽：接收訊息者以詢問訊息 確認他所聽到的內容 141 溝通的方法及使用時機 正式／ 非正式 書面／ 口述 溝通例子 使用時機 正式 書面 複雜問題、專案計 需要被記錄在正式文 劃、章程、長距離溝 件 通 正式 口述 簡報、演講 非正式 書面 備忘錄、Email 、筆 簡單的資訊交換、有 記 點複雜的問題、避免 誤解 非正式 口述 會議、對話 大眾場合溝通、特殊 事件、公司對外發佈 有效率地溝通或交換 資訊 142 有效的會議管理 1. 會議原則： 3. 會議中： 1) 2) 3) 4) 每個會議都要有目的 是否真的需要開會 定期會議或不定期會議 找對的人開會 1) 開會時依據議程及原則來 開會 2) 指定人員產出交付物及完 成日期 3) 記錄決議 2. 會議前： 4. 會議後： 1) 2) 3) 4) 權責 設定明確會議的時程 議程要有團隊的討論 發佈議程 在開會前讓成員知道他的 1) 錄 2) 於２４小時內發出會議記 追蹤執行狀況 143 會議種類 1. 1) 2) 3) 2. 1) 2) 3) 4) 啟動會議Kick-off Meeting： 讓團隊彼此認識 建立工作關係及溝通規則 建立專案目的及目標 定期會議Periodic Meeting： 預先設定時程 有清楚的目的及議程，並事先發佈 讓成員清楚地知道他的責任 將會議記錄保存起來並發佈 144 風險 v.s. 專案風險 問題：何謂「風險」？ 風險是能夠影響目標的不確定性 專案風險是指能夠對專案目標產生正面 ﹝機會﹞或負面﹝威脅﹞影響的不確定性 145 專案風險管理作業與主要產出文件 範圍說明書 WBS 1. 風險管理 規劃 風險管理 計畫 146 假設與限制 清單 風險辨識 檢查表 2. 風險辨識 3. 風險定性 評估 4. 風險定性 評估 5. 風險回應 規劃 風險登記冊 6. 風險監控 3.1 風險管理規劃 「風險管理規劃」流程的主要工作：決定 如何著手規劃、執行專案的風險管理活動 風險管理計畫書 147 風險管理的步驟 風險識別 風險評估 風險應對規劃 風險監控 148 3.1 風險辨識 149 「風險辨識」流程的主要工作：判斷那些 風險將可能影響專案並記載其特性 風險辨識的方法與技術 150 歷史資料法：參考公司過去類似專案的資料， 找出本專案潛在的風險事項 查檢法：透過使用查檢表，逐一檢視各項目潛 在的風險事項 面談法：訪談公司內外具有相關經驗的個人或 機關，找出本專案潛在的風險事項 腦力激盪法：運用團體腦力激盪方式，找出本 專案潛在的風險事項 德爾菲(Delhi)法：運用德爾菲(Delhi)法，找 出潛在的風險事項 上述方法與技術可以混合運用 風險辨識檢查表(範例) 151 影響ERP專案成功的風險-範例 監控與行動 監控評估程序 是否完整恰當 監控規劃階段 BASELINE是否訂定 及適當性和可行性 監控執行階段 是否發生未在 規劃控制內的事件 152 3.2 風險評估 「風險評估」流程的主要工作：評估已辨 識風險發生的可能性及對專案目標的衝擊， 排定優先順序 可分為定性分析與定量分析兩種方式 153 定性分析-風險度量方式與風險等級 風險度量參數： 風險機率：風險發生的可能性，以「風險可能 性評等表」表示之 風險衝擊：風險一旦發生，對專案目標之達成 所造成之損害程度，又稱危害嚴重性，以「風 險嚴重性評等表」表示之 154 風險可能性評等表(範例) 155 可能性 評量準則 量化指標 非常高 發生的機率≧75% 5 高 發生的機率≧50 ,＜75% 4 中 發生的機率≧25,＜50% 3 低 發生的機率≧10%,＜25% 2 非常低 發生的機率＜10% 1 風險嚴重性評等表(範例) 專案目標 成本 低 中 高 非常高 1 不顯著的 2 成本增加 4 成本增加 8 成本增加 16 成本增加 增加成本 <5% 時程耽誤 5-10% 時程耽誤 10-20% 時程耽誤 >20% 時程耽誤 <5% 5-10% >20% 範疇中的 範疇中的 10-20% 範疇縮減 次要工作 受到影響 主要工作 受到影響 僅非常嚴 苛的應用 品質降低 到需要經 受到影響 審查核准 時程 不顯著的 時程耽誤 範疇 不顯著的 範疇縮減 品質 156 非常低 不顯著的 品質降低 到無法被 專案發起 人接受 品質降低 到無法被 專案發起 人接受 專案產出 結果完全 無法使用 專案產出 結果完全 無法使用 風險等級(範例) 風險等級 風險評分 說 明 R1 (主要風 險) >16 不可能被接受，必須予以嚴密監控，並利 用任何有效方法以避免風險 R2 (中度風 險) >6, ≦ 16 雖可忍受，但仍須研擬回應對策以消除或 降低風險之損害 R3 (次要風 險) ≦6 不需執行特定的活動，僅需保持觀察即可 157 風險機率與衝擊矩陣圖 158 將「風險機率」及「風險衝擊」的數值相 乘，可得到「風險評分」，集合各種「風 險評分」即形成「風險機率與衝擊矩陣圖」 上，透過顏色區別，只需將每一風險評估 所得之「風險評分」標示上來，即可很容 易判定該風險的等級，並可做為觀察風險 演變歷程的視覺化工具 可能性 風險機率與衝擊矩陣圖(範例) 非常高 5 5 10 20 40 80 高 4 4 8 16 32 64 中 3 3 6 12 24 48 低 2 2 4 8 16 32 非常低 1 1 2 4 8 16 1 2 4 8 16 非常低 低 中 高 非常高 嚴重性 159 R1:主要風險 R2:中度風險 R3:次要風險 風險總表(範例) 160 風險評估的內容 由該風險項目的負責人根據現況及相關的資訊， 對該風險項目做出初步風險評估，再經由專案 小組的討論，決定以下資訊： 161 對專案目標（範疇、成本、時程、品質）的影響 風險發生的可能性、嚴重性及風險等級 風險發生後可能造成的潛在成本或潛在延誤天數 風險的成形指標 風險回應對策 風險管理是資料、知識與經驗的累積 經驗學習： 昨日的問題就是今日的風險 從過起幾年各專案所遭遇的問題中，把排名前 20名的問題列出來，很適合做為下一個類似專 案的初始風險列表 162 3.4 風險應對規劃 163 「風險應對規劃」流程的主要工作：發展 選擇方案與決定採取的行動以提高專案目 標成功的機會並降低威脅 風險應對策略 消極應對策略 積極應對策略 迴避(Avoidance) 開拓 轉嫁(Transference) 分享 減輕衝擊(Mitigation) 提昇 接受(Acceptance 164 迴避(Avoidance) 對於不可能被接受的風險，必須予以嚴密 監控，並想辦法用各種措施來預防風險的 發生 例如天氣惡劣，班機就選擇延遲起飛 165 減少衝擊(Mitigation) 當風險無法完全避免發生，就需採取某些 對策或行動，以降低損失 例如汽車的安全氣囊 166 轉嫁(Transference) 167 藉由適當的合約條款，將風險轉移到有能 力管理或承擔這些風險的供應商或承包商， 對於那些無法用任何方法迴避風險者，則 可考慮將部份風險轉嫁給保險公司，但風 險發生，本司仍將無可避免會受到損害， 故平常仍應採取對策努力避免風險的發生 接受(Acceptance) 168 即使風險發生也不會有太大的危害，故不 需執行特定的活動，保持觀察即可 定量分析-風險承擔 vs 風險準備 169 風險承擔=風險發生的潛在成本X發生的機率 把所有風險承擔的金額加起來，就是風險準備（金 額） 同理，亦可應用在風險準備（時間） 軟體委外開發的採購管理 1. 2. 3. 4. 5. 6. 170 採購規劃(MAKE OR BUY) 發包規劃 要求賣方回應 賣方評選 合約管理 合約結束 專案採購管理作業 與主要產出文件 1. 採購與取得 規劃 2. 發包規劃 3. 要求賣方 回應 4. 賣方評選 採購管理 計畫 採購文件 建議書 合約 171 5. 合約管理 6. 合約結束 驗收文件 2.1 採購規劃(專案規劃階段) 「採購與取得規劃」流程的主要工作：辨 識有那些專案的工作需要藉由向外購買產 品或服務來達成，並決定如何採購、何時 採購，以及採購多少 工作重點： 採購項目與工作/需求說明(SOW=Statement of Work) 採購方式與合約型態之選擇 172 一般採購～小型採購流程 買方 賣方 主要產出文件 採購規範 / 規格書 需求提出 請購 請購單 詢價 詢價單 報價單 供應商報價 比/議價 比議價記錄 下訂單 訂購單 履約管理 產品交付出貨單/簽收單 驗收單 測試/驗收 請款/付款 採購結案 註：以上流程未將簽核程序納入 報支單 採購檔案 173 一般採購～大型或政府採購流程 買方 賣方 主要產出文件 計畫書、工作說明書(採購規範) 計畫提出 招標須知、RFP 、契約條款 製作招標文件 招標文件(招標須知、RFP、契約條款…) 公告/招標 投標 評選標準 /比議價記錄 審標/評選/議價 契約書 決標/簽約 履約管理 建議書(proposal) / 投標文件 產品交付 出貨單/簽收單 驗收單 測試/驗收 請款/付款 採購結案 174註：以上流程未將簽核程序納入 報支單 採購檔案 自製或外購分析 自製的時機： 當買方本身具有能力和足夠的資源、要自行掌 控、和有智慧財產要保護時 外購的時機： 當賣方有專業能力並能以更低的成本和風險執 行工作時 175 應用系統軟體的主要建置方式 自行開發 委外開發—購買套裝軟體 委外開發—客製開發 委外開發—購買套裝軟體+客製開發 176 合約型式選擇 1. 固定總價(總金額)型合約(Fixed Price (Lump Sum) Contracts ) 2. 成本報銷型合約(Cost-Reimbursable Contracts) 3. 工時及材料型合約(Time & Material (T&M) Contracts) 177 固定總價(總金額)型合約 FP 合約之金額固定 優點（對買方而言） 缺點（對買方而言） 需更多的功夫建立工作範疇 適用時機 178 最常用、風險較低、需要較少的管理、全部價格已知 全部工作範疇已清楚定義 成本報銷型合約 CR 付予賣方實際發生的成本再加上額外利潤。 優點（對買方而言） 缺點（對買方而言） 風險較高、買方需要更多的投入來管理賣方的工作、全部 成本未知。 適用時機 179 以較少的努力、時間和成本建立工作範疇。 全部工作範疇未知/不完全 (只有概要的效能或功能需求)、 需要特定的專業能力時。 工時及材料型合約 介於「固定總價型合約」及「成本報銷型合約」 之間 優點（對買方而言） 全部價格未知、需每天持續的監督 適用時機 180 合約建立迅速。 缺點（對買方而言） 單位費率已事先訂定（像固定總價型合約） 合約最終價格在發包時未知（像成本報銷合約） 專案期間短、緊急時、買方要求更多的控制權、工作 範疇未知或不完全時、需要雇用外部人力時。 發包規劃(專案規劃階段) 「發包規劃」流程的主要工作：準備詢價/招標所需的 文件，以及找出潛在的供應商。 軟體開發的詢價/招標文件： 招標須知 契約條款 建議書徵求文件(RFP, Request For Proposal) 評選標準 181 投標須知(範例) 182 專案名稱 專案需求說明 法令依據 投標廠商資格 招標委外程序 履約保證及保固保證金 其他附則 契約條款(範例) 工程契約 勞務契約 財務契約 183 服務標的 服務費用 付款方式 建置時程 專案人力 驗收 保固維護 履約管理 保險 權利及責任 … 建議書徵求文件(範例) 概述 （背景、起因、現況及欲達成之理想…） 專案性質描述 （名稱、目標、範圍、時程、費用…) 需求說明 （整體需求、技術需求、環境需求、管理需求、 交付產品與交付時程…） 智慧財產權的歸屬 驗收事項與權責 建議書的製作規定 建議書評審與廠商遴選方式 其他 184 供應商評選項目(範例) 185 技術能力 品質能力 管理能力 產品功能 價格 過去履約實績 商業條款 財務計畫 其他與採購之功能或效益相關事項 要求賣方回應(專案執行階段) 186 「要求賣方回應」流程的主要工作：自可能的賣方 取得回應 (投標、報價、出價或建議書 )。 建議書範例(1/2) 專案概述 廠商經驗與能力 專案需求之規劃與建議 技術建議 187 方法、技術、工具 架構、設計 預期效果 工作時程與完成期限 交付項目 建議書範例(2/2) 管理建議 成本建議 188 專案管理 專案組織 專案驗收 預估費用 付款方式 需求變更 其他 2.4 賣方評選(專案執行階段) 189 「賣方評選」流程的主要工作：審查賣方的投標資料， 評選出合適的供應商，並議訂合約。 2.5 合約管理(專案監控階段) 190 「合約管理」流程的主要工作：管理與賣方的關係， 並確保賣方的執行績效符合合約要求。 合約管理的主要工作 191 監督供應商的專案管理流程與活動 審查供應商的專案執行與進度報告 執行合約的變更管理 2.6 合約結束(專案結束階段) 192 「合約結束」流程的主要工作：合約完成 及驗收付款，並含任何未決事項的解決。 專案監控規劃 193 1 專案監控管理 專案監控的目的在瞭解專案的狀況，以便 於專案過度偏離專案計畫時，能採取適當 的矯正措施，使專案能順利達成專案目標 專案規劃時，須將專案監控計畫納入專案 計畫書中 194 專案監控之依據 195 專案監控係根據專案計畫書，於專案執行 期間持續地對專案的各項活動蒐集資訊， 分析、記錄與計畫預估值的差異及採取矯 正措施 專案監控項目(範例) 196 專案時程 工作交付物產出狀況 預算使用狀況 人力投入狀況 資源使用狀態 專案資料管理 人員訓練 產品品質 流程品質 專案風險 供應商狀況 矯正措施執行狀況 變更執行狀況 2 訂定專案績效指標 197 根據專案監控項目訂定專案績效指標，並 透過專案量度與分析機制評量專案之表現 3 專案量度與分析 專案度量與分析的目的係客觀蒐集有關產 品、流程及專案活動之資訊，以提供專案 監控及決策之用 專案規劃時，須將度量與分析計畫納入專 案計畫書中 198 度量目標(範例) 依據專案的目標及資訊需求，訂定以下的度量目標 與優先順序（以下範例僅供參考） 度量目標 199 專案需求 優先順序 ■ 專案時程 達成預定的時程 1 ■ 產品品質 產出高品質產品 2 ■ 專案成本 不超出預定的成本 3 ■ 專案範疇 維持需求的穩定 4 ■ 流程品質 流程改善 5 度量項目(範例) -1/3 專案時程 各項工作實際開始的時間 各項工作實際完成的時間 各項工作預計與實際時程差異 預計與實際時程差異 產品品質 缺失比率 預計與實際產品大小差異 200 度量項目(範例) -2/3 專案成本 各項完成工作所花費的實際成本與預估成本 預計與實際成本差異 各項工作實際投入的人力 預計與實際人力投入差異 專案範疇 需求變更次數 需求變更比率 201 度量項目(範例) -3/3 流程品質 計畫修訂次數 風險數目與發生次數 矯正措施結案率 供應商需求變更次數 202 度量項目之定義 每一個度量項目應有明確的定義（含計算 公式）、度量單位、資料蒐集頻率，以及 何處、何時、如何蒐集及向何人報告 蒐集資料時應有統一的表格與填寫方式， 以便於後續彙整 203 度量資料之蒐集 資料蒐集的機制要與專案成員日常的工作 整合在一起，以提高專案成員的配合度 資料之蒐集可採人工作業，但建議最好透 過自動化的方式，將有助於蒐集到更完整 與正確的資料，並可節省額外的彙整工作 應提供資料蒐集人員正確的的蒐集程序與 清楚簡明的指引 204 4 專案變更 205 專案執行過程中可能會因業務需求、作業 環境、技術條件之改變，或是因為採取預 防或矯正措施，而必須對原有專案計畫書 所規範之專案範疇、時程、成本、預算、 品質等項目內容進行變更 一般性變更管理流程 識別需要變更的內容 包含三個主要過程 識別引起變更的因素 確定變更是需要的，並 確保變更是有益的 管理已發生的變更 對變更進行分析 確實需要變更 no yes 填寫變更申請單 不予 變更 影響評估及審查 核准變更 yes 執行變更 追蹤與監控變更成果 206 no 績效評量與報告 專案績效報告分成以下兩種： 狀況報告(status report)：描述專案執行的狀 況，適用於專案內部審查專案進度時使用 進度報告(progress report)：描述專案團隊已 完成的工作項目，適用於對高階管理人員簡報 專案狀況 207 專案進度與狀態報告(範例) 208 專案結案作業 209 合約結束 「合約結束」流程的主要工作：合約完成 及驗收付款，並含任何未決事項的解決。 1. 採購與取得 規劃 2. 發包規劃 3. 要求賣方 回應 4. 賣方評選 採購管理 計劃 採購文件 建議書 合約 210 5. 合約管理 6. 合約結束 專案結案作業 專案結案作業 成果交付 費用結算 文件交付 成果驗收 費用結算 彙整歸檔 專案檢討 成員解編 •接收單位確 認符合需求 •正式被接收 單位接受 •專案相關收 入、支出費 用結算 •交件驗收與 確認 •經驗傳承 •什麼做得好 •獎勵嘉勉 •什麼做得不好 •改善行動 •解編規畫 •成員績效回饋 211 檢討改善 成員解編 專案結案會議 主要目的 212 公布專案結果與目標達成率 待決事項之處理 專案小組分享與學習專案活動中所得的經驗 討論專案活動過程中的利弊得失 以及感謝專案成員的貢獻 有創意，才有競爭力 感謝指導 213