项目范围管理课件

專案範圍管理專案範圍是指專案組織為了成功地完成專案，確保專案目標得以實現，生產出客戶期望的產品或提供客戶需要的服務，所必須完成的而且僅限於必須要做的全部工作。全部的,指成功地實現專案的目標所進行的“所有工作”。必要的,指成功地實現專案的目標所規定的“必要的、最少的”工作。

專案範圍防止專案範圍“蔓延”和範圍“萎縮”。2

專案範圍

專案範圍包含專案產品範圍和專案範圍產品範圍（ProductScope）客戶對專案最終產品或服務所期望包含的功能和特徵的總和.專案範圍是為了交付滿足產品範圍要求的產品或服務所應做和必須做的工作.產品範圍的完成情況是參照客戶的要求來衡量專案範圍的完成情況則是參照計畫來衡量3專案範圍管理包括以下三個部分的內容：確定專案範圍核實專案範圍控制專案範圍變更4第四章專案範圍管理控制專案範圍變更核實專案範圍確定專案範圍專案範圍管理概述5確定專案範圍實際上就是給專案小組的工作劃定一個邊界。專案範圍說明書包括：專案名稱專案專案目標專案產出物範圍規定專案工作範圍的規定專案約束和專案假設條件專案主要里程碑專案各方面要求和規定（配置關係、變更請求等）確定專案範圍61目標確定1/3專案目標是專案預期的結果或最終產品，應明確具體，並儘量定量化，主要涉及：時間約束性目標費用約束性目標技術Productrequirementsspecification產品滿足特定需求、個性化的可交付性成果品質費用時間71目標確定2/3專案目標遵循的原則:SMARTSpecific明確的Measurable可度量的Achievable可達到的Resultdriven結果驅動的Timing時間性81目標確定3/3專案目標三要素時間，成本和品質專案目標優先順序特性專案經理的首要工作之一是管理時間、成本和績效之間的平衡。9

“中星22號”衛星業務管理站建設專案主要是負責衛星運行業務管理。其建設專案主要包括：通信、天伺饋、射頻網路、遙測遙控、數據處理、在軌測試和測試模擬等。專案總投資1800萬元。為滿足05年11月發射的衛星，本項目於2004年9月初開始，2005年9月前建設完成，工程總工期為1年。專案目標與描述示例-“中星22號”衛星業務管理站建設專案10“中星22號”衛星業務管理站建設專案目標交付成果：衛星業務管理站工期目標：工程於2004年9月初開工建設，2005年9

月前完成，工程總工期為1年。費用目標：總造價1800萬元品質目標：各單機設備合格率100%，優良率70%以上，爭創一流。安全目標：杜絕人為事故。11某無人駕駛的小型氣象探測飛機研製專案某飛機製造公司承擔無人駕駛的小型氣象探測飛機研製生產專案。專案擬於2001年7月開始實施，市場需求為50-100架，首架交付日期為2004年12月。專案目標包括飛機研製和為保證飛機性能的特種設備/設施採購，為保障小型氣象探測飛機研製與試飛任務的順利進行，專案總投資為1.2億元人民幣。

問題：對專案的目標進行描述？12無人機研製專案目標可交付成果：研製無人駕駛小型氣象探測飛機；工期：首架交付日期2004年12月，研製時間從2001年7月費用：研製總經費為1.2億元人民幣。到2004年月12月，總工期為3.5年；13專案範圍說明書-北京西直門立交橋的改擴建工程

改擴建工程的工作範圍包括：拆除現狀舊橋；新建上層三座匝道橋；新建中層東西向跨線主橋和南、北輔橋；拓寬下層二環主路；新建高粱橋立交；完善輔路系統，交通設施、照明及綠化等配套工程；完善周邊路網；完成新建橋區的地下管線和地下構築物的改擴建。工程總體目標：計畫開工日期1999年2月27日，計畫竣工日期1999年9月5日，計畫工期211天。品質目標：合格率100%，優級品種90%，單項檢驗合格率100%，杜絕重大品質事故。工程主要的假設前提為：周邊房屋及其他設施按時拆遷；施工之前路網改造完成。工程主要的制約因素為：施工期間確保二環路上下行各三車道暢通、西直門內外大街公交及慢行車和行人通行。確保拆舊橋過程的安全、西直門地鐵樞紐的絕對安全。在該工程合同金額之內完成全部工程。城區文明施工和環境保護要求：執行市建委“文明施工”條例，施工現場設立圍擋，文明施工：不揚塵、不遺灑、低噪音、排水設施完善，周邊路況良好。14房屋專案範圍陳述專案目標：5個月內成本不超過15萬美元的情況下構造高質量的房屋。可交付物－一座2200平方英尺、2個浴室和3個房間的完工房屋。－一個完工的車庫。－廚房用具，包括電爐、烤箱、微波爐和洗碗機等。里程碑1批准許可－－3月5日2澆灌地基－－3月14日3框架、水管、電力和通過機械檢查－－5月25日4最後檢查－－6月7日技術要求1房屋必須滿足地方建築標準。3所有門窗必須通過NFRC40能量分級檢驗2結構必須通過地震穩定性標準。4車庫必須可容納兩輛大型汽車。限制和排除1房屋必須根據客戶提供的規格說明和原始藍圖設計來建造。2業主負責風景。3冰箱不包括在廚房設備內。4現場工作限制在從星期一到星期五早上8點到下午6點。15汽車門鎖開發專案範圍說明書專案名稱及描述：

該門鎖是為客戶新車型PQ-25配套專案，客戶要求為該車開發專門的門鎖，需具備高強度、易操作的特點，能實現遙控、密碼識別等功能。專案目的：

1為客戶的新產品配套；

2優化現有產品結構；

3滿足售後市場的需要專案目標

時間：12月底提供樣件，次年3月形成批量供貨能力費用：專案預算1200000，其中500000元用於購買測試設備品質：設計圖紙並獲得客戶的確認，樣件符合圖紙要求，按時提交樣件並獲得客戶的接受，按要求形成批量能力；專案主要交付結果：

專案計畫書；圖紙；

100套樣件；樣件測試報告；每月一次的專案進展報告，專案驗收報告制約因素：

樣件必須在正式生產線上完成；必須製作100套樣件；樣件測試必須在生產線上假設條件：

客戶對樣件的幾何尺寸、材料結構參數、性能要求明確；樣件製作工具及設備工具具備。162專案分解內容：專案分解就是把專案整體分解成較小的、易於管理和控制的子項目或工作單元的過程。工具：專案分解的工具是工作分解結構ＷＢＳ原理，它是一個分級的樹型結構，是一個對專案工作由粗到細的分解過程．目的：保證專案的系統性和完整性使專案概況及組成明白、清晰有利於界定職責和許可權是網路建立的基礎便於確定專案所需技術和資源方便各方面的溝通便於跟蹤、控制和回饋。17工作分解結構（WBS）WBS(WorkBreakdownStructure)主要是將一個專案分解成易於管理的幾個部分或幾個細目，以便確保找出完成專案工作範圍所需的所有工作要素。它是一種在專案全範圍內分解和定義各層次工作包的方法，WBS按照專案發展的規律，依據一定的原則和規定，進行系統化的、相互關聯和協調的層次分解。結構層次越往下層則專案組成部分的定義越詳細，WBS最後構成一份層次清晰，可以具體作為組織專案實施的工作依據。18WBS分解類型基於可交付成果的劃分上層一般為可交付成果為導向下層一般為可交付成果的工作內容基於工作過程的劃分上層按照工作的流程分解下層按照工作的內容劃分按產品本身的結構劃分19WBS編制方法自上而下法從專案的最終產品開始分解到中間產品至更低層次的元素，以便於管理和綜合控制。自下而上法從明確專案所涵蓋的所有可交付成果（或工作包）開始，將相關聯的工作包（或可交付成果）進行分組並彙集到上一個層次，直至所有子元素均被彙集以形成專案的交付物。WBS（組織的）標準一個組織的WBS標準包括一系列創建WBS應遵循的原則，如格式、編碼系統、命名方式等。WBS標準在專案管理成熟度較高的組織中非常普遍。WBS範本WBS範本是將一個不同級別的元素填入對應細分層次的WBS“容器”。前兩種方法適用創立新的WBS，後兩種方法是重複利用原有資料20WBS舉例:輪船輪船動力系統電氣系統管道系統船體軸系木作系統輪機系統上層房間A段B段C段D段E段F段G段H段K段鋼材除鏽下料加工小組裝配套存放大組裝船臺焊接0級1級2級3級船體分段示意圖21WBS舉例軟體開發專案設計說明書根源程式用戶手冊支持文檔培訓資料手機開發專案市場調查設計生產采購測試上市22WBS舉例:新軟體包安裝0級1級新軟體包安裝確定要求設計開發測試安裝完成確定需要設計作業系統修改外購軟體包修改內部程式修改手工操作系統流程測試外購軟體包測試內部程式測試手工操作系統流程修改外購軟體包修改內部程式2級23例：2008年奧運專案分解模式圖2008年奧運會體育競賽國際聯絡場館建設專案1專案2

市場開發場館管理環境保護餐飲住宿觀眾服務24大型會議的工作分解結構1000專案管理1100專案策劃1200專案計畫1300專案啟動1400專案啟動會議1500專案溝通1600專案評估1700專案總結2000專案市場化運作2100尋找合作單位2200廣告宣傳策劃與實施2300會議論文及其他資料2400招收會員2500展會招商3000後勤保障3100預定會場3200會場佈置與安排3300接待會員4000專案實施4100會議開始4200開幕4300主會場4400分會場4500閉幕4600會議結束5000資訊保障5100前期資訊收集5200聯絡相關行業單位及人員5300專案進展情況分析5400資訊的接受與發佈25WBS工作編碼有高層向下層用多位碼編排，要求每項工作有唯一的編碼1000110011101111111211131120112111221123120026專案工作分解結構表專案名稱：專案負責人：單位名稱：製錶日期：工作分解結構任務編碼任務名稱主要活動描述負責人1000

1100

1200

1x00

1x10

1x111x12

專案負責人審核意見：

簽名：日期：27WBS注意事項分解後的任務應該是：可管理的、可定量檢查的、可分配任務的、獨立的複雜工作至少應分解成二項任務表示出任務間的聯繫不表示順序關係與任務描述表一起進行28WBS表達形式層次結構圖清單式

1．0系統

1．1元素A1.1.1任務

1.1.2任務

1．2元素B1．0系統1.1元素A1.2元素B1.1.1任務1.1.2任務29WBS小結WBS中的每個工作包：定義工作；識別完成一個工作包的時間；識別完成一個工作包所需資源；識別完成一個工作包的成本；識別完成一個工作包的個人或組織；識別度量進度的監控點；30案例討論生日宴會假如您要在自己的家裏舉行一次生日宴會，請按WBS為你制定一份工作的分解計畫？十年慶典某企業恰逢建廠10周年，為了擴大企業知名度，準備組織一次慶典活動。為保證此項活動的順利進行，需要進行工作分解。辦公室主任小張在考慮是不是需要準備一些資料、邀請相關人員等等………31生日宴會1.0準備

1.1邀請來賓

1.2採購物品2.0晚宴

2.1清洗

2.1.1清洗食品

2.1.2清洗餐具

2.2做菜

2.2.1做涼菜

2.2.2做熟菜

2.2.2.1製作蔬菜類2.2.2.2製作海鮮類

2.2.2.3製作其他類

2.3宴請

2.3.1切蛋糕

2.3.2吹蠟燭

2.3.3吃飯3.0娛樂

3.1音響佈置

3.2室內佈置

3.3唱歌4.0結束

4.1送客

4.2打掃衛生32

十周年慶典WBS10周年慶典1000資料準備1100外部聯繫1200來賓接待1300會場佈置1400紀念冊編制1110回顧展1120媒體宣傳1210對外邀請1220交通安排1310食宿安排1320佈置條幅1410音響準備1420接送站1311訂票1312慶典活動召開大會文藝演出333責任矩陣責任矩陣(Reponsibilitymatrix，縮寫RM）是以表格的形式表示完成工作分析結構中工作細目的組織或個人責任的方法。使用RM，明確框架內的權利、責任。OBS

(OrganizationBreakdownStructure)34責任分配表

(▲負責〇審批●輔助△承包□通知)責任者

WBS專案經理土建總工機電總工總會計師工管處財務處計畫合同處機電設備合同處設計院諮詢專家電力局水電部中技公司十四局大成公司設計●●●●

▲●□〇□□□招標●●●●

●●

▲●〇□□□□施工準備▲●□□

〇□□

▲□採購〇□●□□●●▲□●●

施工

▲●□●●●●●

●

▲▲專案管理▲●●●●●●●●

●

□□352009年安徽省抗雪保暢責任表

36責任分配表圖例：▲負責●輔助△承包

責任者（個人或組織）

工作分解結構任務編碼任務名稱

專案負責人審核意見：

簽名：

日期:：374專案可交付結果與里程碑事件通過WBS分解出項目的工作任務後,要將每項任務的交付結果定義出來.在專案的一系列可交付結果中，可能會有一些事件的開始或結束對專案目標的有效實現至關重要，它們稱為里程碑事件。確定里程碑事件應做到：介面清楚可以度量38三峽工程重大里程碑及其主要提交成果1993年，宣佈三峽工程正式開工若干提交成果必須驗收完畢（如四通一平，工區征地，甚至包括主席臺的準備）1997年，右岸明渠通航、大江截流2003年，首臺機組開始發電、2009年，工程全部完工、電站全部投入運行。39第四章專案範圍管理控制專案範圍變更核實專案範圍確定專案範圍專案範圍管理概述40專案範圍說明書的核實在專案實施之前還必須就專案的範圍、任務介面的劃分、雙方的介面界線等與客戶進行書面核實，征得客戶的同意和認可簽字。專案交付結果的核實專案最終的交付成果交給使用者或接受者之前，專案組和使用者都要對已完成的工作成果重新進行審查，並決定是否接受專案的移交結果。核實專案範圍41通過不斷進行範圍審查，以核實所做的工作沒有脫離客戶的需求。專案範圍管理計畫應該清楚完整地描述專案範圍變更的識別和分類方法，在專案產品的性能尚未完全確定的情況下，做到這一點是很困難的，但也是絕對必要的。範圍Vs需求客戶為什麼總是反反復複？“客戶怎麼好象總是反反復複、粘粘乎乎的”，比如，開始提需求的時候和顧問表達了三點意見，顧問開始做方案以後又告訴顧問兩點詳細說明，看到顧問的方案以後，客戶好象受了啟發，一下子又冒出了五點六點的需求要顧問實現。42第四章專案範圍管理控制專案範圍變更核實專案範圍確定專案範圍專案範圍管理概述43修建壁櫃

張先生怎麼也沒有想到，不起眼的一組壁櫃，競花了他一萬元。而當初他要建壁櫃的時候，裝修工曾明確地告訴他，花不了多少錢。記得那一天跟裝修工討論壁櫃時，對他說：“我想在臥室建一組壁櫃”。“沒問題，這個容易”。“那你們還能按時完工嗎？我們要到新家過年，可別耽誤了”。“沒問題”。裝修工十分有把握地說。“這樣很好，我還有一個問題，這會花多少錢？”張先生問到。“花不了多少錢”。裝修工隨口答到。這件事就這麼定了下來。等壁櫃完工後，裝修工交給張先生一張一萬元的帳單。44範圍變更控制專案範圍計畫制定得非常好，但是想不出現任何改變幾乎是不可能的。專案變更原因：專案要求變化，專案委託人對專案的需求和期望發生了變化。專案範圍計畫或定義時出現錯誤或遺漏；工藝技術的變化，專案團隊提出新技術、手段和方案；經營環境的變化，外部環境的動態開放性引起專案經營環境的變化，從