6.3 Estimate activity resources不用Project Scope Statement?

有一位朋友在閱讀PMBOK IV的專案時間管理的規劃程序之時，問了一個問題：「為什麼6.2 Sequence Activities，6.4 Estimate Activity Durations，6.5 Develop Schedule要用到Project Scope Statement，而6.3 Estimate activity resources卻不用呢？」

肥蝦非常欣賞該友人準備PMP考試的心態－去思考PMBOK的邏輯與流程，而不是去背考題！－因為肥蝦一直認為一個欠缺邏輯思考能力的人，恐難擔任專案管理乙職。在肥蝦將當初個人的回應整理如下，希望獲得更多先進的指教！

肥蝦以為在思考Project Time Planning Processes之時應先注意三點：
(一)Activity與Work package的差別：
在PMBOK IV page 426中對Activity的定義是：「A component of work performed during the course of a project.」；而對Work package的定義是：「A deliverable or project work compinent at the lowest level of each branch of the work breakdown structure.」。因此就專案管理的角度而言最小的控管單位是Work package，而Activity是要完成Work package所要進行的活動項目。

(二)五個time planning processes中的關係：
在PMBOK IV page 47的圖3-8中有關Project time management的圖形。

在此圖中，顯示了這五個time planning processes中的關係是彼此兩兩相關的，並不是單向順序的推演。而其中的關鍵是何者呢？就是每個process output的project document update所列示的內容－其中最主要的就是Activity Attributes。

(三)Schedule與activity的區別
第三點可說是由前兩點推演而來，6.1到6.4均設在設法估量適當與合理的活動項目，以其每個activity之間的關係、資源與活動期間；而schedule則是以整個project的角度去思考，並有非常大的可能再進一步去調整每個activity。

而為了解答「為什麼6.3 Estimate activity resources不用Project Scope Statement」肥蝦認為可從二個立基點─Project Scope Statement、Time Management Processes─去串連思考。
(一)首先瞭解Project Scope Statement的由來與目的。
Project Scope Statement是5.2的產出, 參考了project charter跟requirements documentation跟Organizational Process Assets後的產出。

Project Scope Statement主要包含的內容項目有：
1. Product scope description
2. Product acceptance criteria
3. Project deliverables
4. Project exclusions
5. Project constraints
6. Project assumptions

因此我們可以看到Project Scope Statement是把要Business的Product轉換為Project重要過程文件！對於專案範圍中什麼要交付，什麼不作，專案的前提與限制，均有了較明確的說明！

(二) Time Planning Processes的目的。
6.1 define activities: The process of identifying the specific actions to be performed to produce the project deliverables.

6.2 sequence activities: The process of identifying and documenting relationships among the project activities.

6.3 estimate activity resources: The process of estimating the type and quantities of material, people, equipment, or supplies required to perform each activity.

6.4 estimate activity durations: The process of approximating the number of work periods needed to complete individual activities with estimated resources.

6.5 develop schedule: The process of analyzing activity sequences, durations, resources requirements, and schedule constraints to create the project schedule.

(三)串連的思考
6.1 define activities:因為activity是從work package再分解，所以必需參考scope baseline。而是scope baseline包含Project Scope Statement、WBS、WBS Dictionary，因此6.1 define activities也要使用Project Scope Statement。

6.2 sequence activities: 接著必須針對每個活動的特性與一些限制，來安排其間的順序。此處參考PSS是怕發生見樹不見林的問題，所以只要Project Scope Statement，而WBS跟WBSD可以視為轉化融入到Activity List跟Activity Attributes了。

6.3 estimate activity resources:是要估計每個Activity所需要的人、物、料、設備的種類與數量，重點是放在每個Activity，而著眼點是組織對資源提供的限制，所以對整體專案的範圍、限制、前提，已不是重點。另外，請注意6.2有一個output：Project Document Updates，它可會視情況需要更新了Activity List跟Activity Attributes，還有Risk register。

6.4 estimate activity durations:是要估計每個活動所需要的活動期間，此處為何還要參考Project Scope Statement?
因為6.3僅是估計每個活動所需要人、物料、設備的種類與質量，那每個活動要作多久呢？如果資源沒有問題，當然就直接估計出工時；但是Project Scope是要完成所交付專案產出的所有活動，比如一個Work Package會有那些活動必須在那時完成的限制，那些活動必須配合管理活動期間(如每週、月的報告)...這些活動的期間估計就必須參考由Project Character與Requirements Documentation而來的Project Scope Statement。
其實妳可以把它單純的想成有些活動的期間必須配合合約、 買方的要求等限制！比如：買方可能會要求會議的前兩天，必須傳送會議的agenda，那這些準備會議準備活動的期間就會受到限制！
此外，不要把6.3到6.4是one way的喔！每個活動之間會有互動的。如果6.4activity的duration無法滿足Project Scope Statement的要求，也可以回頭經由增加這個activity的resource.來減少activity的duration。

6.5 develop schedule:因為要訂出專案的時程，那當然Project Scope Statement所記錄的時程限制等資料就是非常重要的。

因此在6.1到6.5的Time Planning的過程中，除了6.3在估計每個活動所需要的資源外，其餘都是要參考Project Scope Statement的。而6.3的目的是根據Activity List跟Activity Attributes去對應組織的資源狀況(Resource Calendars、Enterprise Environment Factors、Organizational Process Assets)。

在PMBOK IV的Project Time Management中有一個肥蝦認為PMBOK IV與III最大的差別在於圖6-2所列舉的scheduling method，scheduling tool，scheduling model。在PMBOK IV對於scheduling method與scheduling model並沒有清楚的交代－僅有提到scheduling methodology－而scheduling tool在6.5.2.8與6.6.2.8的說明是一個自動的排程工具，根據時程的資料進一步產生活動的起迄日期。但如果我們回頭參考PMBOK III對scheduling model的說明，第四版可說利用此圖把schedule model作了更清楚的描述，所謂的scheduling model可說是包含特定的時程方法論、排程工具，以及專案中有關時程的訊息而成。但是圖中的e.g. CPM的說明圖形應該是說明scheduling method而不是scheduling tool。

以和為貴的整體問題解決法-「問題不能拆開來看」讀後感想

本書是日本TOC(Theory of Constraints)理論大師－岸良裕司－所撰寫的TOC(Theory of Constraints)的思考流程(Think Process)，以「整體最適」的觀點，尋求雙贏的最佳解決問題的方法，時報文化於2009年出版。
本書立基於限制理論TOC(Theory of Constraints)的基本理念：「人類天性是善良的；事物本質是簡單的。」；而「人」是糾結問題(繫鈴)與解決問題(解鈴)關鍵；而解決之道在於突破錯誤的假設，建立有邏輯性的正確假設，進而利用正確的假設形成正面的企業文化。最終的希望在於希望讀者不要以局部最適的解決問題方法，導致無盡衍生的問題；而是要以整體最適的思考去達成雙贏的結果。
本書提供了五個工具樹圖、兩個圖形及一個地圖，提供予下列解決問題的步驟：(1)如何去改變：擬聚共識；(2)要改變什麼：界定核心問題、化解衝突；(3)改變成什麼：確認目標、防範可能風險；(4)如何造成改變：建立中繼目標，確立執行順序。
以下分別說明其間的關係：

(1)如何去改變？
=>策略與戰術樹(S&T-Strategy & Tactics Tree)：運用整體最適方法，集結眾人之力的策略戰術執行法。

(2)要改變什麼？
=>撥雲見日圖/衝突圖(Clouds)：讓彼此形成共識的對立消除法。
=>現狀樹(CRT-Current Reality Tree)：找出問題關聯性的現況掌握法。

(3)改變成什麼！
=>未來樹(FRT-Future Reality Tree)：改變現況創造未來的未來構思法。
=>負面分枝(NBr-Negative Branch Reservations)：預測「不良效應」盡早防範。

(4)如何造成改變。
=>條件樹(PRT-Prerequisite Tree)：專注於中繼目標的目標達成法。
=>轉換樹(TrT-Transition Tree)：鍛鍊洞燭機先能力的執行順序確立法。

此外，書中強調了解決問題之道：「尊他、重己、時宜、妙策」的重要思維：
(i)尊他－自己設法滿足對方的要求。
以「體諒」為基礎的作法，察覺他內心的真正需求，並予以尊重。

(ii)重己－檢視自己的需求是否符合對方的行動。
以「給對方面子」為基礎的作法，希望自己的需求，能符合對方行動。

(iii)時宜－按時間與場合，分別採用雙方作法。
透過確立時間與場合，或許就是發現對立其實不存在的契機。

(iv)妙策－去尋求「改變」與「不變」之外的第三妙策。
跳脫對立點，從並立點，回頭思考解決問題的方法。

在順序上，肥蝦以為最佳的應用方式為：
(1)以策略與戰術樹建立與分享共同的願景與目標。

(2)以現況樹，區別不良症狀(病症)與真正的問題(病因)，找出核心問題。

(3)以撥雲見日圖，化解彼此的對立與衝突，達成共識。

(4)以未來樹圖，呈現達成策略與戰術圖的願景與目標的美好景象群。

(5)利用負面分枝思考每一個美好景象可能造成的負面效果，以期防範於未然。

(6)使用條件樹，建立達成終極目標的中繼目標，構思達成目標的完整路徑圖。

(7)轉而以轉換樹，思考達成中繼目標的明確作業程序。

其中，現況樹、未來樹、條件樹、轉換樹，四者均應與策略與戰術樹緊密的連結，隨時以零基思考的模式，思考終極目標的正當性與需求性。此外，負面分枝所擬定的預防目標應納入條件樹的中繼目標。
整體架夠構就如書後封面所繪製的TOC解決問題森林地圖。

此外，本書均環繞在「人」的中心上。「人為城牆，人為城堡」，所有目標的達成，問題的解決，均有賴有共識的人們一起努力克服。因此書中所引的山本五十六的名言：「不做給對方看、不說給對方聽、不讓對方嘗試、不誇獎對方、人則不為所動。」實可做為本書結尾的最佳註腳。惟有不強加自己的主觀意識於他人身上，尊重他人的立場與需求，時時謹記以「好處兩點，好還要更好處一點。」想著別人與自己的優點，方能建構一個以和為貴的正面企業與專案組織的氛圍。