推薦一個專案管理小茅屋

昨日肥蝦上網找相關衝突管理相關的文章,無意間發現了一座專案管理小茅屋(Project Management Hut) http://www.pmhut.com/

在這個網站中有一些不錯的小文章,對於文章等相關資源的分類非常清楚,更可貴的是它還有ITIL跟Project Management的共通性與相輔性的文章討論!因此肥蝦推薦這個網址與大家一同分享。

ITIL:IT Infrastructure Library(資訊技術基礎架構庫）是由英國電腦和電信局（The Central Computer and Telecommunications Agency）所開發出用於規範IT服務管理的架構。藉由流程的利用將資源最佳化，以提昇 IT 服務水準，試圖結合技術面向與商業目的，證明IT組織的價值。

5.1.3.1的Requirements Documentation是否流入4.2Develop Project Management Plan?

近來有一位朋友問了很多有關4.2 inputs的問題,肥蝦我個人建議他看一下PMBOK page 49的Figure 4.5!但4.2.1.2的說明跟Figure 4.5有一個衝突點：即是Requirements Documentation是否流入4.2Develop Project Management Plan.

基本上,4.2.1.2的Outputs from Planning Processes基本上主要是三個baselines跟十二個子計畫(可從PMBOK 4.2.1.2的說明可知),但如參考Figure 4.5可以發現5.1除了 Requirement management plan流入4.2外又多一個requirements documentation也流入4.2.1.2! 這requirements documentation是有點爭議性的!

以肥蝦個人的理解,就從整個PMBOK的角度,可以把4.2看成是做完各個領域的規劃後進行彙總的過程:
(1)所以首要的是先確認專案的存在與業務(Business)的要求(=>project charter).
(2)再來是彙總所有規劃程序主要產出的子計劃跟baseline,追求其間的一致性,總不能子計劃之間彼此打架吧!(=>Outputs from Planning Processes).
(3)另外因為是我們的組織要在現有的環境下去執行它,所以現有週遭環境法令的限制,公司的組織與資源,以及以往公司或外界相關的經驗,都可以拿來作參考或調整的依據.(=>Enterprise Environmental Factors;Organizational Process Assets)

由於此處的工作主要是進行彙整,最重要是需要專家的能力進行處理(Expert Judgment),而產出當然就是在專案執行,監控,結案所要依據的規範了(Project Management Plan)!

因此你可以想成如果其他規劃流程的產出是為了完成相關的子計劃或baseline,基本上就不會再流入4.2了.因為4.2要的是所有領域規劃的最終可納入專案後續作業依據的產出!

只有requirements documentation要特別留意一下!就規劃的流程,你可發現:5.1的output:Requirements Documentation會留入5.2產生Project scope statement(還有project document updates=>當然就是指Requirements Documentation);以及5.3配合Project Scope Statement一起產生WBS,WBS Dictionary(還有project document updates=>當然就是指Requirements Documentation).以及12.1去判斷那些需要外購,進而有Procurement Management Plan與Procurement Documents!

因此基本上5.3的產出Scope Baseline,在規劃的產出而言,已能大體上包含了Requirements Documentation的要求!因此就PMBOK的文字說明僅寫了Outputs from Planning Processes是代表baseline and subsidiary plans. 可是在Figure 4.5又特別把requirements documentation列為4.2的input!當然也是可以把他想成requirements documentation是客戶/USER的原始要求,因此需要在彙整Project Management Plan時需要再特別的考量(在Project Scope Statement中有所謂Project exclusions)!但肥蝦以為針對這些在你的邏輯架構屬於例外的部份就特別記一下就好了!(一本書由多人所作,因此有些前後稍微衝突的地方在所難免!)

以上是肥蝦個人的淺見跟說明,還請 參考!

誠信才是永遠的!-"誠信"漂流記讀後感

今日收到一位好友寄來一封聽說是對岸那邊聯考的作文─"誠信”漂流記

內容如下：
----------------------------------------------------------------------------
話說誠信被那個“聰明”的年輕人投棄到水裡以後，他拼命地游著，最後來到了一個小島上。“誠信”就躺在沙灘上休息，心裡計劃著等待哪位路過的朋友允許他搭船，救他一命。

突然，“誠信”聽到遠處傳來一陣陣歡樂輕鬆的音樂。他於是馬上站起來，向著音樂傳來的方向望去：他看見一隻小船正向這邊駛來。船上有面小旗，上面寫著“快樂”二字，原來是快樂的小船。

“誠信”忙喊道：“快樂快樂，我是誠信，你拉我回岸可以嗎 ？ “

“快樂”一聽，笑著對“誠信”說：“不行不行，我一有了誠信就不快樂了，你看這社會上有多少人因為說實話而不快樂，對不起，我無能為力。”說罷，“快樂”走了。

過了一會兒，“地位”又來了，誠信忙喊到：“地位地位，我是誠信，我想搭你的船回家可以嗎？”

“地位”忙把船劃遠了，回頭對“誠信”說：“不行不行，誠信可不能搭我的船，我的地位來之不易啊！有了你這個誠信我豈不倒霉，並且連地位也難以保住啊！”

誠信很失望地看著“地位”的背影，眼裡充滿了不解和疑惑，他又接著等。

隨著一片有節奏的卻不和諧的聲音傳來，“競爭”們乘著小船來了，“誠信”喊道：“競爭，競爭，我能不能搭你的小船一程？”競爭們問道：“你是誰，你能給我們多少好處？ ”

“誠信 ”不想 說，怕說了又沒人理，但“誠信”畢竟是誠信，他說：“我是誠信……”
“你是誠信啊，你這不存心給我們添麻煩嗎？如今競爭這麼激烈，我們‘不正當競爭’怎麼敢要你誠信？”言罷，揚長而去。

正當誠信感到 近乎絕望的時候，一個慈祥的聲音從遠處傳來：“孩子，上船吧!”，一個白髮蒼蒼的老者在船上掌著舵道：“我是時間老人。”“那您為什麼要救我呢？”誠信問道。 老人微笑著說：“只有時間才知道誠信有多麼重要！”

在回去的路上，時間老人指著因翻船而落水的“快樂”、“地位”、“競爭”，意味深長地說道：“沒有『誠信』，快樂不長久，地位是虛假的，競爭也是失敗的。”
-----------------------------------------------------------------------------

這篇文章肥蝦以為可以作為一個專案經理在做利害關係人溝通管理之時的註腳!

一個專案當然專案經理要設法建立公司,專案團隊在利害關係人心中的credit!唯有credit才能使得利害關係人對專案有信心,對你-專案經理有信心!

任何手法都是一時的!最重要的是一旦您的或專案團隊的credit失去,你將一無所有!

就順序上來說,肥蝦個人的作法如下:

利用公司的credit接下案子->建立PM的credit->建立專案團隊的credit->建立公司在這個專案的credit!

如果利害關係人已經認為公司是騙人的,你一定要設法保住您專案經理的credit!否則此專案必敗無疑!

因讀到此篇文章心也所感,肥蝦特與各位一同分享!

推薦一個另類但有趣的網站--http://tx.shu.edu.tw/

肥蝦現正進修世新的資管在職碩班，向第二個碩士學位挑戰！

本學期修讀了一門【研究方法】授課老師是吳統雄老師。他的思考可說非常地非主流，但伊的思維肥蝦覺得非常有趣！

吳老師個人有一個學習網站：
http://tx.shu.edu.tw/

伊強調的主旨：「多元學習，獨立人格！」肥蝦覺得非常符合一個專案經理應有的態度。

吳老師可說以自身的學習與經驗，提出了自有的看法與見解。當然各位先進也許初看之時，會覺得伊過於自大與自誇，但深究其理，相信可有不少收穫！

加以專案管理可說是一門社會學科與整合管理的藝術，因此吳老師的一些看法與見解，肥蝦以為可提供給專案經理進一步修練的參考。

上週讀書會的一個成員，希望肥蝦提供一些forms或tools以供伊使用。肥蝦這方面的資源尚稱豐富，私下分享亦無問題！但肥蝦非常強調一個重點：「任何forms或tools均是他人在某些環境下的產物。而身為一個專案經理的你，有否堅實的理論基礎與豐富的經驗，加以消化，並且因地、因時、因人加以修正，符合自己本身的風格與特質！」

前一陣子，辦公室的另一部門的同仁也在問：所謂的系統分析文件是否一定要以UML的diagrams去呈現給客戶？

肥蝦特別的提醒她：應注意專案的本質與文件的對象。對從未接觸過與學習過UML的客戶來說，使用UML的diagrams可否達到專案所要求的溝通目標？是否加速雙方的溝通進度與深度？是否針對溝通對象的特質與背景，使用雙方可接受或客戶願意採納的方式去撰寫系統分析文件？就如「讓事情發生」第七章所言：「和所有工具都要保持柏拉圖式的關係，工具和圖表可以成為重要的東西，只要保持客觀。」

就肥蝦個人的想法:身為一個專案經理切不可受限於工具與過程，任何的作為應以順利交付專案的產出、服務或結果為目標！

「自傘自度還是上帝之手」讀後心得

－兼論科學人雜誌第90期「市場與計劃，缺一不可」－

「自傘自度還是上帝之手」是我閱讀陳沖先生專著的第二本，記得第一本「法國狼與貓頭鷹」是前年於客戶端進行一個專案之時，與我合作的user推鑒我閱讀的。在那個案子我所學甚多，與我合作的users更是讓我受益良多。

陳沖先生，記得在我擔任立委助理之時與他有數面之緣。當時即感覺他的金融實務與財金法律知識非常紮實；但卻隱約感覺此人有點恃才傲物。在觀看這「自傘自度還是上帝之手」之時，感覺上也許是幾次宦途浮沈，展閱他的文章之後，發現他的意見寬容了許多。正巧前日也翻閱了科學人雜誌第90期薩克斯(Jeffrey D. Sachs)先生的專欄－「市場與計劃，缺一不可」發覺兩者在理念之間，有些異曲同工之妙，因此特寫此篇心得以記錄個人的感想。

我於就讀經濟學碩士之時，指導教授的專長在於【發展經濟學】，因此攻讀碩士之時，也修了一年政治研究所所開設的【政治經濟學】課程。這兩個學門均主要在探討經濟環境中，市場與制度這兩個支柱，但彼此間的觀點與立場卻有一定的差異。

就我個人初淺的認知，發展經濟學基本上是尊重市場經濟(看不見的手/上帝的手)的功效，但為弭補市場機能的不足或缺限，則須加以良善規劃的制度(政府管制/那把傘)；而政研所的政治經濟學，感覺上比較偏向政府政策與制度的重要性，經濟就是人為的活動，因此需要加以適當的管制，市場的機能很多時候，只會讓現況脫離了發展的目標與途徑。也許有些讀者感覺：「這只不過是孰重孰輕的問題罷了！」，就我個人的思維與架構來說，卻是非比尋常！

以往個人認為，市場如同流水一般－水往低處流，市場逐利而行；那政策與制度，就如那堤堰一般，藉由增加成本或設定成本，讓水往人們設想的路徑流去，但一旦過於強迫，常會導致堤毀人亡的慘劇發生。近來隨著肥蝦自我工作與社會經驗的成長，深覺任一現象的背後大多有著糾葛難分的事因。各種原因間影響的比重或有深淺，其間的互動關係可能曖昧未明。因此為達成目標、解決問題，就如陳沖先生所言：「政策既定，如何執行？又如何避免副作用？就必須有所配套！」(金管會的好棋，page 109-110)，也如那薩克斯(Jeffrey D. Sachs)先生所言：「不論公私部門，任何大規模的行動要成功，市場與計劃兩者缺一不可。」

在現今之中，市場與計劃兩者之間兩者實無法切割，各位可查看「六法全書」的厚度，就可知道政府的制度何其繁多與重要；參看每日的股市交易，就可知多少人忙於追逐利潤。因此任一現象或問題的背後，影響因素可能是已存在的法令，也可能是市場趨利的誘因，也可能是人性的一時不易變更的固有偏好。而要解決問題就如同pareto法則(80/20法則)，我們僅能就最重要的成因去設法改進。

就如同在【誰是火箭專家】乙文中所說，美國次貸風暴的源頭是：Rocket scientists、Rating agencies、Regulators；而在【原來是國王之手】所認為解決金融風暴的好方法，首推英國的是針對流動性問題，並連結至市場利率的SLS(特別流動性規劃)。陳沖先生的此言深得我心，也給了吾等警語，就同專案經理在設法解決問題達成專案目標一樣，在面對繁多頭痛的病徵之時，如何針砭主要病因，規劃與執行解決之道。

此外在【樓梯間的欄杆】乙文中，作者也以票據法為例，說明經濟方法才是解決經濟問題的有效方式。法制就如同那樓梯間的欄杆，不見得用得到，修法僅是在欄杆上精雕細刻；但如要人不跌倒，重要的還是那樓梯必須拾階平穩。這讓肥蝦想起「愛上經濟」(中譯本經濟新潮社出版)這本書中男主角山姆所言：「伊小時，政府強迫要他家在樓上露台裝設鐵欄杆，政府意圖扮演父母一般的角色，確忘了民眾們應自我培養自己應有的風險與效益間取捨的態度。」這次金融風暴，不管是民眾購買連動債的損害，或者銀行的損失，其主要癥結，不就在於民眾或銀行缺乏自我負責的風險意識，以及應有的管理風險的態度。

台灣金融主管單位積極要求金融業者應該要KYC(Know your customer)，在購買衍生性新商品前，購買者須填寫或回答一定格式的問卷。因此，肥蝦以為政府已設定相關的法規與制度，因此執法重點應在誰逾越了欄杆，而不是如在【誰是火箭專家】陳先生所說：「不懂的商品，別再碰了！」而是設法將商品的資訊公開化與透明化，並建立每人應有的風險意識。

如果有人願意當風險愛好者，又何必去禁止他呢？金融市場之所以發展，不正是這世界上存在了風險中立、愛好與趨避的各色人等嗎？真正重要的是：不如藉由制度與市場的結合。政府可藉由制度，要求具有更多資源的一方，強迫其發佈相關的資訊，再經由市場去解讀與評價，達到一定的目的；並設法把人民當個成人看待，應讓伊培養自我承擔風險的態度。政府主要將功能與角色，應放在那些沒傘可自度之人。對於有傘自度者，推廣風險自負的正當心態，嚴懲翻牆越梯之徒，如此，個人以為才有可能將台灣推向一個區域的金融中心。

利潤與風險實為一體的兩面，追求利益當得承受風險，因此追求多大的利得就得看自我能承受多大的風險。這就如同專案管理一般，專案經理與團隊的要責之一，不就在風險的辨識、衡量、專人專責、監控、報告，以及設法找出風險背後的主因，設法防範於事前，並密切與連貫的連結至公司的風險承受度。

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解決問題森林地圖。

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