PMP::第一次讀書報告

http://www.umltw.com/2008/06/pmp_18.html

學員：邱郁惠(271080@gmail.com)
範圍：(4.1) Develop Project Charter
說明：這是一份會讓大家越念越多的筆記，完全違反講師的論調，各位可以收到後丟棄，也可以自行影印並於週日帶到課堂，但這份文件最起碼證明了我有確實執行上週交付的工作。謝謝各位。

-----
前言
在專案執行過程中，慣用的專案管理流程(project development process)，總括來說可以分為44項。當然，在專案執行過程中，不見得44項流程會全派上用場。再者，PMBOK依照知識領域(knowledge area)將44項流程分組，所以才會有44個子流程、9大知識領域之稱。

因此，在PMBOK一書中，ch1~3在對PMBOK的內容做整體性的介紹跟定義外，接續的ch4~12就針對9大知識領域分別描述歸於其中的流程，並且在各章中每一個小節，正好說明一個流程。所以，如果您加總ch4~12的小節數，會發現一共是44小節。

比方說，在ch4談到專案整合管理(project integration management)，歸於這個知識領域的流程一共有7項，所以小節的名稱就是流程的名稱：

4.1 Develop Project Charter
4.2 Develop Preliminary Project Scope Statement
4.3 Develop Project Management Plan
4.4 Direct and Manage Project Execution
4.5 Monitor and Control Project Work
4.6 Integrated Change Control
4.7 Close Project

這樣的分類結果，導致一個學習上的困難，就是—我們是依照著知識領域的順序來學習，但實際的專案運作過程中，這44項流程並非依照著PMBOK章節順序發生。

此外，PMBOK又將44項流程依照專案管理流程(project management process)角度分為五大群組(group)，這樣的分組有依照實際專案進行過程中的所發生的流程順序，這就是我們常聽到的5大流程(IPECC)，也是我們比較熟知的專案流程。在PMBOK第3.2章提到的5大流程的概念：

3.2.1 Initiating Process Group
3.2.2 Planning Process Group
3.2.3 Executing Process Group
3.2.4 Monitoring and Controlling Process Group
3.2.5 Closing Process Group


(4) Project Integration Management
與其說專案整合管理(project integration management)有何獨特的定義，我倒認為它其實更像個大雜燴，所有無法明確歸類於另外8大知識領域中的子流程，或者屬於全面性的子流程，通通都歸為專案整合管理。

所以，舉凡專案的起迄、全面性的管理、監控、以及涉及整體的變動等子流程，可以推想，它們大都歸屬於專案整合管理。在PMBOK中，將下列7項子流程歸屬於專案整合管理：

4.1 Develop Project Charter
4.2 Develop Preliminary Project Scope Statement
4.3 Develop Project Management Plan
4.4 Direct and Manage Project Execution
4.5 Monitor and Control Project Work
4.6 Integrated Change Control
4.7 Close Project


(4.1) Develop Project Charter
既然，專案的起迄歸於專案整合管理，可以想見，其內的第一項子流程便是在處理專案剛設立的情況，這個子流程稱之為—develop project charter。中文譯名，將它稱之為—制定專案章程。
我認為中文譯詞不佳，charter有憑照、許可證、憲章等等的意思，我猜想譯者應該是採用「憲章」的概念。其實，章程是一個模糊且抽象的子眼，會讓人聯想到條列式的條文，而且是高空喊話，不具實的條文。

但是，如果譯詞改成專案「許可」(project charter)之類的，反而比較能夠理解專案一開始設立時，當然必須明確指定專案經理、專案目的、目標、預算等等一連串在專案設立之初就必須指明的事項。

現在，我們可以再回過頭來思考一個根本的問題—一開始為何會需要設立一項新專案，常見的需求如下：

1. 市場需求(market demand)
2. 營運需要(business need)
3. 客戶要求(customer request)
4. 技術提升(technological advance)
5. 法律要求(legal requirement)
6. 社會需要(social need)

歸納上述需求大抵可分為：問題(problem)、機會(opportunities)、營運需求(business requirement)。

所以，一份project charter中，應該包含：

1.需求(requirement)，以滿足顧客、贊助人(sponsor)、或其他利害關係人
2.營運需要(business need)
3.專案目的或理由(project purpose or justification)
4.指派專案經理與權限等級(authority level)
5.整體的里程碑進度表(milestone schedule)
6.利害關係人(stakeholder)的影響
7.職能組織(functional organization)與其參與
8.組織、環境與外部的假設(assumption)
9.組織、環境與外部的限制(constraint)
10.投資報酬率(return on investment)
11.整體預算(budget)


依據、工具與技術、產出(Inputs、Tools&Technigues、Output)



Develop project charter流程執行結束的產出為—project charter，產出的過程中，可以參考合約(contract)、專案工作說明書(project statement of work)、企業環境因素(enterprise environmental factors)、組織過程資產(organizational process assets)等資料文件，還可以善用專案選擇方法(project selection method)、專案管理方法論(project management methodology)、專案管理資訊系統(project management information system)、專家判斷(expert judgment)等工具或技術，以便產出此流程的project charter。


依據
此流程建議的工具與技術有4項，分別說明如下：

1.合約—如果這個專案是由顧客發起的話，則會有來自外界的合約。

2.專案工作說明書(SOW)—用來說明專案提供之產品或服務。對內部專案(internal project)而言，專案發起人(project initiator)或贊助人將提供SOW，主要依據營運需要、產品或服務需求。對外部專案(external project)而言，顧客將提供SOW，其內容通常來參考招標文件(bid document)的一部分內容，諸如提案書(request for proposal)、招標書(request for bid)、合約等。其內容主要包含：
*營運需要(business need)
*產品範圍描述(product scope description)—說明專案的產品需求及特徵。
*策略規劃(stategic plan)—所有專案都需要支援組織的策略性目標。

3.企業環境因素—常見影響專案成功與否的因素有：
*組織文化與結構(culture and structure)
*政府或業界標準(industry standard)
*基礎建設(infrastructure)
*現有的人力資源(existing human resources)
*人事管理(personnal administration)
*公司工作核准制度(company work authorization system)
*市場條件(market conditions)
*利害關係人的風險承受力(risk tolerance)
*商用資料庫(commerical database)
*專案管理資訊系統(PMIS)

4.組織過程資產—組織累積的知識資產也是很好的參考資料，這些資產可分為兩大類：
*組織執行工作的過程與程序—組織標準流程、標準指南、樣板、指南、組織溝通需求、專案結案指南或需求、財務控制程序、缺陷(defect)控制、變更控制程序、風險控制程序、工作授權程序等。
*組織的知識庫(knowledge base)—過程測量資料庫、專案文檔、歷史資料與教訓學習(lessons learned)、缺陷管理資料庫、配置(configuration)管理知識庫、財務資料庫。


工具與技術
此流程建議的工具與技術有4項，分別說明如下：

1.專案選擇方法—用來找出組織所需的最佳作法，這些方法一般分為兩類：
*效益量測方法(benefit measurement methods)—比較方法(comparatives)、評分模型(scoring models)、效益貢獻(benefit contribution)或經濟學模式(economic models)。
*數學運算模式(mathematical models)—線性(linear)、動態(dynamic)、整數(integer)、多目標編程算法(multi-objective programming algorithms)。

2.專案管理方法論—可以是正式或非正式的技術。
3.專案管理資訊系統(PMIS)

4.專家判斷—針對流程一開始的依據(input)資料，可以請專家來提供意見，具備專業知識的專家有：
*組織中的其他單位(other units)
*顧問
*利害關係人，包含顧客或贊助人
*職業和技術協會(professional and technical associations)
*工業團體(industry groups)