煮萎日誌-2009/12/27

「一個不敢表達自我的人，如何獲得別人的敬重？一個只想到自已的人，如何獲得別人的善意？」

為何人不敢當面表達自己的意見跟看法，而只敢在背後吱吱喳喳！
這是肥蝦擔任社區主委的第一感受，如同先前的匿名信一般，好似大家還活在威權體制的時代！
怕！怕別人記恨。怕！怕別人報復。怕！…。
但是不敢忠實勇敢的說出自己的感受與看法，別人要如何得知自己的立場與處境？
溝通第一步：「勇敢的說出來！」

別人不應該晚上洗衣服，別人不應該讓小孩喧鬧，別人不應該…。
凡事只想到自己，要求別人改變！「自我為中心」是社區百分之九十五的問題核心。
在工商煩忙的社會，生活作息不再是一成不變的「日出而作，日落而息。」也不是「瓜棚豆架，雞犬之聲相聞。」
社區住戶之間如果不能互相尊重，關懷彼此，而一味地責怪別人，問題是永遠不能解決。

不具名鄰居的指教回覆-我還沒上任耶

不具名鄰居(以下簡稱為您)惠鑒：
首先必須向其他各位先進抱歉，因為弟尚未上任(本月26日方進行交接)已接獲了某些住戶的指教。其中因有一封信直接投入弟的住戶信箱(交接後即設住戶意見反應箱，還請多加利用)，因為不知對方的貴姓與大名，更不知伊居所所在，就伊所建議事項，進行初步瞭解後，書寫投遞至所有住戶的信箱，尚請 海涵！爾後，弟衷心冀望各位先進如有任何意見，均能惠賜貴姓與住所，以便弟能向各位先進當面請益。
承蒙您的指教，弟自感慶幸，也深感惶恐！弟也僅是本社區的小小住戶，也是從士林移居至此，但弟日後在管委會的作為必定在遵守法令、符合程序，以及社區住戶多數共識的基礎之上。
針對您來函所陳述的兩項建議，如有任何未明而誤解之處，還請 見諒，並請進一步告知。至於後續的任何作為，因管理委員會乃是採取委員制，非弟能一人專擅！加以管委會之上尚有區權大會，因此後續的可能作法，弟還得與各位委員一同討論，以及廣聽社區住戶的多數意見。個人將至目前僅有的瞭解、認知，呈述於下。
(1)建議一：警衛室不能放電視。
(A)目前的瞭解：
就弟向前任的主委與委員請教，此決議應是第一屆管理委員會(或區權會)之時的決議事項。該電視為以前住戶搬離之時贈予管理委員會；有線頻道為廠商無償贈與。
(B)個人的認知：
弟能感受您對警衛桌前放置電視可能引發的安全問題有所擔憂，但弟以為當時管理委員會的諸位賢達作此決定，必有當時背景與住戶反應的考量。如今也許時空環境遷移，因此需要作些變更，但弟以為還得遵照一定的程序，如果住戶多數反應不應設置電視，弟將敦請總幹事自警衛桌前撤除電視。
此外，入口大廳並不專為警衛而用，弟一心想將其轉換為社區住戶的聯誼中心。如果爾後，社區的長者或住戶們能多於該處進行活動，弟思考將電視轉換為供住戶休憩使用，不但可促進社區的良性互動，減省各住戶之私電費、增進環境保護，更可多加利用朱總幹事的護理專長。
(C)未來的作法：
(i)弟於26日上任後會調閱三年來之管委會與區權會會議記錄，明確界定該事是否記載於相關文件之中。
(ii)如果下任管委會認為應進行檢討，或者具名反對之住戶達9戶(含)以上(住戶1/10)，弟將發放問卷進行調查。如果反對者達住戶中之一定比例(弟以為管委會決議事項，應有1/3以上反對；區權會則應有1/2以上反對)，則敦請總幹事協助將電視自警衛桌前撤除。

(2)要求警衛針對住戶與住戶間的樓層間，以及其間電燈關閉的定點巡邏。
(A)目前的瞭解：
就弟之目前瞭解，先前胡主委曾要求警衛進行此等作為，但因住戶們對於自己樓層間的電燈開關有不同的見解，因此無法確實地實行。
(B)個人的認知：
弟以為整體社區的安全防護與住戶緊急求助事件的處理，為社區警衛的首要職責。況且我們社區僅有單哨警衛，日間因尚有總幹事在入口大廳上班，因此日間警衛可適時進行巡邏活動，巡視各樓層的共用電燈；但夜間警衛除必要活動外，其警衛重點應以入口大門、停車場大門、社區監視器螢幕、及社區話機機台為重點，伊巡邏與活動空間應以聽得見話機音響，與能及時反應為原則。
此外，樓層間的電燈僅為對門兩戶共用，兩造之間應視雙方共識，於平時即發揮彼此公德，注意隨手關燈，節約能源。尤其夜間之時，警衛進行您所要求之活動，估計需花費20-30分鐘，屆時如有任何住戶有緊急事故，這幾近半小時的時間恐成為重要的關鍵。
(C)未來的作法：
(i)弟將與新任委員們討論我們社區的日、夜間警衛作業準則。針對社區的需求與現況，依優先順序，擬定適當的作業程序與活動要求。
(ii)針對我們社區管理委員會與相關聘用單位間的作業組織架構與權責，弟也將一併與新任委員們共同依據相關法令與社區規約，擬定管理委員會的組織細則。

以上均為弟目前的瞭解與認知，如有不明或不妥之處，尚請進一步予以指正。因弟僅是社區無給職之委員，生活上也須為五斗米折腰，加以夜間尚於世新進修第二個碩士學位，並偶至補習班兼任專案管理的顧問講師，因此能為社區貢獻之時間實屬有限。弟也自認個人的為人品格與民主素養有一定的層次，不會四處造謠、惡意破壞社區和諧，因此懇切盼望社區先進們日後對小弟有任何指教，請加具大名或住所，或者於個人於入口大廳輪值之時不吝親臨賜教，以免使弟誤解本意或一時無所就教。
此外，就弟這幾日與些許住戶溝通。在住戶們的要求下，上任之後，關於此次區權會議通過之停車場管理辦法，弟必得全力執行。上任後，爾後如有停放於共用區域，住戶專用車位在原所有權人授權委託下，對於任意停放的車輛、放置物則請保全公司進行強制保管；專有車位內置放不當物品，則進行宣導與進行必要安全處理，若因此而有得罪之處，還請 海涵！

敬祝
闔家平安

距主任委員交接尚有二日的小小住戶
IT肥蝦 敬上
2009/12/24

PMBOK的應用－【賣辣椒的女人】

自從肥蝦通過PMP考試後，在工作職場中總有不少長官或朋友常會問的問題就是：「如何把PMBOK的流程應用到專案中?」

大哉問！說真格得，PMBOK的流程從2000年的39個，到2004年的44個，至目前的42個，若加上每個流程的輸入與產出，如何應用到實際的工作中，這已是一個非常的難題，那就更遑論那眾多的工具了。

如何把專案管理知識體系應用到實際的專案，甚至生活中呢？是不是通過所謂的PMP考試，就是一個稱職的專案經理？是不是在特定行業或特定的個案中，是一個良好的專案經理，就代表他永遠都是一個稱職的專案經理呢？

肥蝦我個人的答案是否定的！書就只是書，工具就只是工具，Lessons Learned就只是Lessons Learned，這都是死的，就算PMBOK會四年調整一次，那又代表它能把所有攸關專案管理的常識、知識與特質，清楚描述嗎？

重點還是在專案經理自身的修為、信心與態度，書是死的、考試是死的、而人是活的！因此如何活用、適用、量用、衍用這些死知識，才是專案經理應強加鍛鍊的功課！

肥蝦在網路上看到此篇【賣辣椒的女人】，足以說明肥蝦心中對PMP證照與PMBOK的心態－「生活中的智慧可以被寫成書，但你不能簡單地照著書上寫的智慧去生活，因為生活只能是鮮活而靈動的！不要在智慧中夾雜著傲慢，不要使謙虛缺乏智慧。」


【賣辣椒的女人】

賣辣椒的人，恐怕經常會碰到這樣一個眾所周知的問題，

那就是不斷會有買主問「你這辣椒辣嗎？」
不好回答。答「辣」吧，也許買辣椒的人是個怕辣的，

立刻走人；答「不辣」吧，也許買辣椒的人是個喜吃辣的，生意還是做不成。

當然解決的辦法也眾所周知的經典，那就是把辣椒分成兩堆，

吃辣與不吃辣的各選所需，這是書上說的。
我一天沒事，就站在一個賣辣椒婦女的三輪車旁，

看她是怎樣解決這個二律背反難題的。

趁著眼前沒有買主，我自作聰明地對她說：
「你把辣椒分成兩堆吧，有人要辣的你就跟他說這堆是，

要不辣的你就給他說那堆是。」
沒想到賣辣椒的婦女卻只笑了笑，輕聲說：「用不著！」
說著就來了一個買主，問的果然是那句老話「辣椒辣嗎？」

賣辣椒的婦女很肯定地告訴他：「顏色深的辣，顏色淺的不辣！」
買主信以為真，挑好辣椒付過錢，滿意地走了。

也不知今天是怎麼回事，大部分人都是買不辣的，

不一會兒，顏色淺的辣椒所剩無幾了。
我於是又說：「把剩下的辣椒分成兩堆吧！不然就不好賣了！」

然而，賣辣椒的婦女仍是笑著搖搖頭，

說；「用不著！」又一個買主來了，問：「辣椒辣嗎？」

賣辣椒的婦女看了一眼自己的辣椒，信口答到：「長的辣，短的不辣！」

果然，買主就按照她的分類標準開始挑起來。

這一輪的結果是，長辣椒很快告罄。看著剩下的都是深顏色的短辣椒，

我沒有再說話，心想：這回看你還有什麼說法？

沒想到，當又一個買主問「辣椒辣嗎」的時候，

賣辣椒的婦女信心十足地回答：「硬皮的辣，軟皮的不辣！」

我暗暗佩服，可不是嘛，被太陽曬了半天，確實有很多辣椒因失水變得軟綿綿了。
賣辣椒的婦女賣完辣椒，臨走時對我說：

「你說的那個辦法賣辣椒的人都知道，而我的辦法只有我自己知道！」



我忽然有所頓悟：

生活中的智慧可以被寫成書，

但你不能簡單地照著書上寫的智慧去生活，因為生活只能是鮮活而靈動的！

不要在智慧中夾雜著傲慢，不要使謙虛缺乏智慧。

什麼是知識?-研究方法課堂隨記

肥蝦正在修讀世新的資管在職碩班，這學期修了一門「研究方法」，授課老師為吳統雄老師(http://tx.shu.edu.tw/)。
在第一堂課，老師以新接龍為引子，意圖灌輸我們一個正確的學習觀念，以及追求知識的正確的觀念。課堂後要求學生們針對「什麼是知識」作一個簡要的回答。
肥蝦野人獻曝，把自己對「什麼是知識」想法的簡易初淺說明在此呈現，期盼藉由能發揮拋磚引玉的效果，並誠盼經由 各位的指教，肥蝦能獲得更多正面有益的認知!

(一)什麼是知識？
簡述：
在探討什麼是知識前，個人覺得必須對真理(truth)與知識(knowledge)間作一個明確的界分與定義。
在目前文獻中對於真理或知識的解釋非常地多，也存在相當大的爭議。
就個人自我的觀感，個人將兩者作了以下的定義：
(1)真理(truth)：符合客觀事物實際情況及其發展變化規律的道理。
(2)知識(Knowledge)：人類將所認知到的經歷，經由適當方式加以整理及陳述的結果。
因此人類現有的知識與真理之間，個人以為不能劃上絕對的等號。個人以為知識只是人類在試圖追求真理的過程中，所不斷累積下來的成果。
在關於知識的描述中有兩點是比較容易發生問題的：(1)人類認知。(2)適當陳述。
人類的認知，其出發點為以人為主軸，認知的過程則必須以自我感官或內心的知覺進行探索。因此在先驗上，對於認知的主客觀上即很難超脫"人"的立場。
此外，陳述的公正、不偏頗、準確與精確，更有著相當的距離。單就溝通理論上就溝通的流程中即可能出現很多失誤的節點。
就以個人對於此題目的認知為例來說，此題目對於知識的定義已先假設：「知識為對真理的描述」，或者一般傳統上的：知識是"證成為真的信念"(justified true belief)。因此就如老師於課堂上所言：「知識是可被實證與可被預測的。」但是單就" 可被實證與可被預測的"的單純字面意義，目前就個人對於量子力學中的「測不準原理」的初淺瞭解，已經對此有某些的衝突。但是本質上，個人以為經由人類知覺的探索，發現所謂的「測不準原理」，也是一種追求"真理"下的"知識"！

(二)什麼是實證知識？
簡述：
就個人所接觸有限的文章中對實證的對應英文多為Positive或Empirical兩個單字。
Positive多被解讀為被事實所證明或者確鑿的證據；而Empirical則含有實驗或經驗的含意。
個人認為可稱為所謂的實證知識乃是：針對特定的人為認知陳述的結果，可被經由人為特定設計或規畫的程序，進行重複的過程，或者該結果存在共有認可的輔助現象，
基本上，個人以為實證的核心本質，存在著人為設計或邏輯推論的脆弱基本點。人為現有的實證方式不外乎實驗室實驗、統計實驗兩大類型。在實驗室實驗的重點，為對控制變項(自變數)的釐清與精密掌控；而統計實驗，除了需要設法釐清控制變項(自變數)外，並需進一步對於母體假設的認定，以及驗證追求適當的合理性。
目前知識架構的建立，大分為純理論建構與實證驗證。兩者之間相輔相成的目標：即在於期望追求對於真理正確陳述的知識。因此個人以為對於實證知識的吸收，應特別注意於其人為設計程序的邏輯合理性思考，以及相關控制變數的釐清與假設。

(三)什麼是機率型知識？
簡述：
人們經由實證的過程，可發現陳述的現象為一個特定結果－如：在其他環境不變下，水受熱為蒸汽。－或為一種規律性的呈現狀態－如：在其他環境不變下，投擲骰子的點數分配。－人類以為所認知到的經歷結果，為呈現一個有規律的分佈狀態，對此規律行為的描述可稱為機率型知識。
另外，就機率可再區分為先驗型機率與後驗型機率兩者。先驗即認為是不證自明的，如太陽必從東方升起。而後驗型的就是經由人為不斷的模擬與實證，而歸納出的規律型態。
針對母體甚小的現象，進行大量實證，當然可以推論出合理的機率分佈，但對於母體廣袤的現象，要得出完整的機率描述，就目前的人為方法/科技可說是非常困難。就如現今眾多的研究報告，在卷首均為假設該現象符合常態分配(normal distribution)，再進一步進行實證。這個盲點就在於：該現象是否真的符合人為所設定的機率型式呢？這個問題個人以為今年的金融風暴，就可以明顯的曝露出人類追求機率型知識的侷限性。

(四)為什麼有數字，就可能有知識？
簡述：
數字是一種人為創造的較為嚴謹的語言，藉以試圖描述所認知的現象。因此首先的要點，即是必須先要瞭解該數字，在描述現象之時的代表意義－絕對性、相對性。
一個實體蘋果，加上另一個實體蘋果，可得出兩個實體蘋果，這可稱為絕對性數字的陳述；一個蘋果的甜度，加上另一個蘋果的甜度，是否可得出一個蘋果的兩倍甜度，則非必然(這甜度這代表數字是一種相對性的數字)。
數字背後存在知識，也許可以更適當的敘述為：以較為嚴謹的語言，所描述人為認知的現象，就是知識。符合了個人在問題一：什麼是知識？中對知識的解釋。
數學語言，可說是人類目前發展至今最為精確的語言，加以數論中對於數字的探索，更加推演出進一步的邏輯性演繹。但是個人以為數字的基本問題，還在於對描述事物的根本性問題－即被呈述的事物所代表的數字是一種絕對，還是相對性？

推薦一個專案管理小茅屋

昨日肥蝦上網找相關衝突管理相關的文章,無意間發現了一座專案管理小茅屋(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解決問題森林地圖。

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

串連PMBOK IV的思維模式－個人心得

肥蝦這幾日來整理了PMBOK IV的內容,自己想了以下的方式去串連PMBOK IV各章節!

(1)組織活動與專案：區別出組織活動中專案的本質。
-作業與專案
-部門經理與專案經理

(2)組織目標層級與專案：明瞭專案與組織的關聯性。
-Portfolio、Program、Project

(3)組織架構與專案：專案成立的基準原點。
-Organizational Structure

(4)影響專案的外在因素：專案的限制與資源。
-Enterprise Environmental Factors
-Organizational Process Assets

(5)專案參與者的角色：專案的人為互動與責任。
-The category of stakeholders

(6)專案創造的價值：專案成立的價值。
-Project Life Cycle
-Product & Project (Product, service, or result)
-From Product Scope Description to Final Product ,Service, or result

(7)專案文件：專案活動的基準與記錄。
-Project Management Plan
-Project Documents

(8)PMBOK的程序與互動：專案流程的運作。
-9 Knowledge Domains & 5 Process Groups
-42 processes
-throughout the project
-iterative
-Change Requests

(9)PMBOK的工具：專案可參考使用的工具。
-估算工具
-量化工具
-圖形工具
-合約型態
-Cost of Quality

肥蝦目前是利用上述九個區塊架構出PMBOK IV！

不知各位是如何去閱讀PMBOK IV，探討PMBOK的核心精神與應用!

會寫程式就是會做專案嗎？

肥蝦之前和最近都遇到一些朋友，他們對於不具有程式能力的專案經理會有一定的排斥。在軟體開發業界，程式撰寫能力被一直認為是專案成功的必備條件。目前也由於很多公司主導專案的專案經理都是從以往的技術人員出身，因此也反相的認為程式撰寫能力是專案成功的惟一條件。

在如此交互作用下，導致目前市場上很多以技術專業自居的專業人士，在專案團隊內會有意無意地輕視"專業"專案經理，導致專案經理的主要職責之一：「創造與維護專案團隊的正面氛圍」非常不易作到。

在PMI網站上的有下列一道考題：
To be a good project manager, how much do you have to know about the industry or business that you are serving?
A. It is more important to have a good project management foundation than to know the business.
B. Each business is so different, in-depth knowledge in the field is key to a successful project.
C. Organizational politics drive project success, so focus on your ability to sway management.
D. Project success is random, so all you can do is work with the skill sets you have.

PMI網站，Barbee Davis, MA, PHR, PMP,所公布的答案是A。各位讀者可上去看伊的說明(網址：http://www.pmi.org/eNews/Post/2008_09-12/QQ_ToBeGoodPM_HowMuchToKnowAboutBusinessYourServing.html) ，Barbee Davis從大中小型專案來分析為何專案經理的專案管理知識、技能與能力，比商業的瞭解、認知重要。

就考試的立場而言，肥蝦認可Barbee Davis的解說，以PMI立場，專案管理能力一定是比產業專業知識更為重要！但肥蝦在此，想從另一角度去說明專案成功的要件中，專案經理的職能與角色中所謂的管理能力，是不是僅瞭解如何去管理專案比較重要？

因為此篇不是為考題解析，準備考試的朋友還是不要看肥蝦以下的推論比較好！

何為專案經理所需要的知識領域，在PMBOK IV版中，已經第III版中圖1.2-Areas of expertise needed by the project team拿掉，針對專案經理的角色寫在1.6 role of a project manager。針對專案經理的角色，PMBOK說明好的專案經理應具有下列特性：
(1)知識(Knowledge)：針對專案管理的知識。
(2)技能(Performance)：有效的運用專案管理知識。
(3)個人特質(Personal)：態度、性格與領導力。

肥蝦個人是以為如此的修正，是PMI為了行銷目的，強調專案管理知識與技能的重要性。一個專案團隊應具有PMBOK III版所載明的五種專家領域知識─應用領域的知識、瞭解專案所在的環境因素、一般的管理知識與技能、個人的特質與技能，以及專案管理的知識。因此專案經理必須能有效的與專案團隊與客戶進行溝通，設法營造整體環境的正面氛圍，以提升專案的成功機率。

在前述的要求與架構下，專案經理的第一要務是什麼？肥蝦個人是以為要先設法取得信任－來自公司內部的信任、來自客戶的信任、來自專案團隊的信任。基於肥蝦的認知，對於專案管理知識與其它應用領域知識作了如下的解釋：
(1)專案管理是一個基本面的know-how，就算不是專案經理，專案團隊成員也應該要有基本專案管理的知識，才能解讀專案工作的本質，瞭解專案團隊成員的互動必要，如此才能促進團隊的有效運作。

(2)那專案經理要強化的那些專案管理能力，才能顯出他適合當一個專案經理！因為每一個專案都是獨一無二的，且有一定的時限。所以專案經理的專案管理能力如果依據堅強(兼具廣度與深度)的應用領域專業知識，以及應有的一般管理知識，那可能無法有效的去整合(Integrate)專案團隊成員、客戶與公司的需求。

(3)專案管理能力跟一般的企業管理能力差異在那裏？
試想：「一個資訊公司行銷部門的經理，進入房地產公司擔任行銷經理比較容易？還是一個從資訊專案的專案經理，進入房地產專案的專案經理容易？」
肥蝦先前曾撰寫【MBA乎？PMP乎？-兩種管理"專業人材"之我見】乙文，說明兩者之間並不違背，而且是相輔相成，並且是糾葛難分的！

(4)PMI的想法！
PMI是試圖把專案經理知識抽離出來向企業管理一樣。就像行銷學一般，不管你是資訊公司行銷部門的經理，,還是房地產公司擔任行銷經理，大家的基礎學術訓練，都是都唸行銷學。
但是因為專案的本質，導致很多專案管理的應用都要立基於對專案的領域知識有一定深度的瞭解，才能進一步發揮我們所學到的專案管理知識，強化PMBOK IV版中所說的技能(Performance)。

(5)「領域專家不一定適合當專案經理，可能比較適合當顧問。」
肥蝦可以同樣把這句話反過來說：「一個專案管理的專家不一定適合當專案經理，可能比較適合當顧問。」因為一個專案經理重要的是營造完成專案的正面氛圍，引入專案所必要的專家，並與伊溝通，作為溝通的中心介面。就如同在PMBOK IV版第26頁，對專案經理的說明：「The project manager is the lead person responsible for communicating all stakeholders. The project manager occupies the center of the interactions between stakeholders and the project itself.」

基於上述肥蝦淺薄的認知，肥蝦將原有第III版中圖1.2-Areas of expertise needed by the project team的圖形，修改為如上圖的專案經理知識架構。

RISKOLOGY-"與熊共舞"所提供的風險評估工具

肥蝦近日於專案管理交流論壇(http://bbs.pm-i-study.net/)寫了一系列"與熊共舞"的導讀！
再看過該書提供的風險評估工具(Riskology)，雖然只是一個用EXCEL寫的工具，但已包含了一些風險評估的要點，加以該工具是作者免費提供給讀者大眾，因此肥蝦特把下載網址與個人的觀感整理如下，以供大家一起分享！

下載網址：http://www.systemsguild.com/riskology
版本名稱:RiskologyV4.xls
使用說明:RiskologyManual.pdf

使用簡要說明:
使用者需要輸入專案名稱、預估起迄日期、風險名稱、對應每個風險的三點估計值，每個風險導致專案取銷的百分比值。RISKOLOGY將協助您計算最小與最大完成期間概估。

工具背後理論:
基於三點估計法(three-points estimate)與利用隨機變數(random)，隨機取樣五百次(取樣值介於三點估計的最佳與最壞之間)，以蒙地卡羅(MONTE CARLO)模擬風險的概估值。

肥蝦建議:
(1)目前該工具僅能提供十個RISK FACTOR的輸入。可客製化加入新風險因子。
(2)奈米機率日必須先行輸入。使用者可再工具算出最小與最大期間之後，再行參考修正奈米機率日！

遇到更正時程問題時，專案經理的優先選項是?

When correcting a scheduling problem, what is the FIRST technique a project manager should consider?
A. Crashing.
B. Reducing project scope.
C. Fast-tracking.
D. Out-sourcing.

肥蝦就個人對PMBOK的瞭解解析該題答案；並分享個人的經驗，關於專案經理在發現時程問題的考量與對應作法。

(一)PMP考題解析
各位可以注意本題的關鍵詞：「correcting a scheduling problem」。在第六章的六個processes，那一個process有"Recommended Corrective Actions"？各位可以發現是在6.6 Control Schedule，那時project management plan已經產生，其中的cost baseline都已經放入project management plan了。

因此，如果cost reserve不夠，那要怎麼辦？因為向公司要人、要錢，如果超過cost baseline都是要Change Request；而針對專案經理所掌控的contingency reserve是針對know-unknown；如果這個問題是unknown-unknown，那就要動到management reserve，那就要sponsor的approved。

而Project Schedule Network Diagrams不是schedule baseline喔！並未納入project management plan中。所以應該思考調整fast-tracking中的選擇性依賴關係的順序，設法變更其中的leads 跟lags的安排，還有請記住Schedule Compression是6.5Develop Schedule的Tool and Technique；Adjusting Leads and Lags可是6.6 Control Schedule的Tool and Technique喔！

(二)實務經驗分享
在實務上，肥蝦碰到的專案中，很多的管理高層在碰到時程的問題時，很多人是喜歡優先採用crashing，但個人以為這是受到"人多好辦事"這古老諺語的影響！可是相對地，很少人去考慮到為什麼會造成延誤(提前)的原因！

一般專案經理最普遍的作法，就是回去跟公司要人、要錢！

我以為，這一方面是專案經理給自己一個藉口：「這是資源不夠，而不是專案當初規劃有問題，或是專案經理管理上有些不當的地方。」另一方面，當專案經理向公司要資源之時，就把專案的問題，上綱到公司人力資源管理政策的問題！把問題推給公司，然後變相的給自己增加緩衝的時間。

肥蝦認為每個專案經理處理的方式會跟，會因為外在的限制、sponsor的壓力與利害關係人的要求而變化！也會跟時程問題發生的時點在專案作業的時點有很大的關係！

以肥蝦個人參與專案的淺薄經驗與認知，肥蝦在解決更正時程問題時，會進行以下的程序：

(1)釐清原因：為什麼？造成問題背後的原因是什麼？與當初所設想的差在哪裡？
=>事前的規劃與現在的狀況之間到底出了什麼狀況？到底是有什麼沒想到？或是想到了而沒去注意？背後造成的原因在哪裡？真正的關鍵點是什麼？

(2)設法集中問題的焦點，縮小問題的範圍！
=>基本上， crashing如果不是用專案已有的reserve，你會發現你將落入公司內部競爭的難題！如果你很紅，有時候你會發現跟公司要錢比要人可能簡單一些！如果公司是要給你現有公司的員工，有時候要到的人很多都是別的團隊不要的！如果是招募新人，很多公司的政策跟管理，會需要一定的時間，新進的人如何融入團隊，多久融入，這些都是問題的範圍！

(3)考量對問題解決方案外在跟內在的限制！
=>比如合約的限制，專案團隊成員是否已經呈報買方，而且變更需要申請跟審核；合約的金額是否允許你增加成本；專案現有的文件跟作法，是否足以訓練一個新手儘速的融入團隊；團隊是否存在強烈的排外性。

另外，針對同一個更正時程的問題，肥蝦會考慮更正的時間點：
(1)時間點：合約簽定前
=>完工日期是買方強力要求的，那用crashing增加成本，或減少產品功能與性質(scope)或品質(quality)。

(2)時間點：規劃中
=>crashing跟fast-tracking，我會同時思考！尤其對於fast-tracking中的選擇性依賴關係儘量去調整，crashing所增加的成本則可納入cost-baseline。

(3)時間點：執行前期
=>我會先看看fast-tracking中的選擇性依賴關係！如果schedule reserve能cover，那不管它，但要強力監控！如果cost reserve充足，那我會考慮用crashing。而且在專案執行的前期，新人的加入，可以有一些緩衝與容忍度讓新人融入團隊！或者外包給別人，但自己的團隊要花費些心力在外包廠商跟專案範圍的接合處！

(4)時間點：執行後期
=>如果reserve都已經被用了差不多，而且團隊之間已有一定的默契跟向心力，那我會考慮fast-tracking先。因為rework的風險，跟加人把團隊搞雜的風險，我會比較擔心團隊垮掉的風險！

(5)時間點：快驗收的時候
=>考量工作的本質，如果只是文件撰寫等行政工作，或是黑箱測試可以比較獨立於原有團隊之外的工作，可以考慮crashing！那fast-tracking就比較不考量了，因為大概沒有什麼activity可以平行運作了！如果這些時程所包含的activity的delivery不太影響交付產品的主要功能，也在stakeholder的tolerance的邊界，那我會設法去嚕掉它，作變相的scope change。

以上是肥蝦個人小小的看法！以下，肥蝦將分享一個我個人的實例：

曾經有一個專案的部份活動在執行發生delay，經深究原因發現是兩個同事在工作的接合界面有衝突。因為前者工作的負責人，比較懶散與不負責任，因此導致後者activity的負責人必須花費很多精力跟時間，去檢核前者的delivery。後來跟後者打個商量，如果他去cover前者的工作，他是否能負荷？對他是否也比較方便？而後者的回答是正面的。因此前者被要求離開團隊，不但省錢、省人，省下的錢一部份，發給後者當獎金！結果，大家是皆大歡喜，且有效的縮短delay的時間呢！

因此如果把時程問題背後的原因找出來！你會發現：並不是增加資源就會有效喔！

資訊相關文件的分類方式－利用ISO27001為分類的依據

在資訊單位裏，我們都會發現我們辦公室內存放著滿坑滿谷的文件，舉凡如縈縈大者的公司管理政策、法規與標準，組織圖，軟硬體清冊，網路架構圖…，到每位使用者的權限與申請單。很多單位都有自己的一套分類標準，這分類依據可能已經不可考，或是參考特定的規範而訂定。

針對資訊文件的分類，肥蝦個人以為，如能照國際的標準與規範進行分類，不但能有較完整的架構，在申請國際認證時也能有一定的幫助。憑藉著肥蝦先前上過ISO27001的課程，對於對於ISO27001的初淺認識，建議可以依據ISO27001的架構訂定分類。

在此處必須先強調的是先約定分類的大綱，暫且不要去新增記錄或表單，因為新增表單將會擴大組織的抗拒。表單的適用與新增、變更，需要因應組織的需要與需求去訂定，此處僅是單純的標明分類大類，以供參考！

(1)資訊安全管理政策
如：公司資訊政策、公司資訊作業標準...

(2)資訊安全組織管理作業流程及程序
如：資訊組織架構、聯絡表、聯絡程序、聯絡記錄...

(3)資訊資產管理作業流程及程序
如：資訊資產清冊、資訊標示與處理的程序、資訊資產分類指導綱要

(4)人員安全管理作業流程及程序
如：聘雇合約、營業保密協定、競業禁止協定、教育訓練記錄...

(5)實體安全管理作業流程及程序
如：安全區域進出登記表、安全區域進出授權記錄、硬體(含網路)設備清單、網路架構圖
...

(6)操作安全管理作業流程及程序
如：變更管理程序、變更申請單、職務分工表...

(7)存取控制管理作業流程及程序
如：存取控制政策、使用者工作職掌與其存取權限比對、使用者申請/異動/註銷控制程序、單位人員與系統存在使用者對照表、使用者申請/異動/移除記錄...

(8)資訊系統開發與取得作業流程及程序
如：系統分析文件、採購合約、系統測試記錄、程式設計文件、資料輸入過程的日誌

(9)資訊安全事故管理作業流程及程序
如：資安通報程序、通報聯絡清單、獎懲辦法/記錄...

(10)業務持續管理作業流程及程序
如：營運持續計畫、定期測試的程序與記錄、責任分工表...

(11)符合性管理作業流程及程序
如：管理階層的定期審查記錄、矯正行動報告...

文件的分類標準很多，肥蝦是拋磚引玉，希望大家能貢獻更多的經驗與方式。

「電腦一開就會洩密」讀後心得

科學人雜誌 NO.88；96-101頁；撰文：W. Wayt. Gibbs；翻譯：王怡文

重點提要：
(i)即使最嚴密的網路安全系統，也無法確保你的電子資料不被有心駭客竊取。
(ii)研究人員已經證實，光是利用眼球反射的電腦螢幕影像或印表機發出的聲響，就能從中讀取資訊。
(iii)這類攻擊難以防禦，而且無法追蹤。最簡單的竊密管道是繞過網路安全系統偷窺，而且事後完全不留痕跡。

肥蝦先前曾經上過ISO27001跟CompTIA Security+的課程。感覺上ISO27001(Information security management system)強調資料分類、資料存取、人員、環境與實體、通訊與作業…等的安全規範。CompTIA Security+比較著重在網路與通訊的安全(雖然在資料存取、人員、環境與實體等議題上也有著墨。)。因此肥蝦心中對於資訊安全的定義與範圍，就是僅以ISO27001與CompTIA Security+為主軸。身為一個金融軟體系統整合商的員工，肥蝦僅是在意，程式碼與文件的安全控管，使用者身份鑑別與權限管理，資料存取與trace log的機密性，程式換版的作業管理，網路通訊的加/解密，PKI，目錄管理、Signal Sign-on、網路病毒、防火牆/UTM等有關議題。直到翻閱本文，發現自己像個"缸中之蝦"，不知外面的世界是如此的寬廣。

在本篇文章中，提到了一些正在發展/已發展的一些竊取資料的方式－從電腦螢幕的倒影(眼球、杯子、眼鏡…等反光物體)，鍵盤的電波，印表機的聲響，網路視訊，網路設備的閃爍訊號－等所謂旁通道(side channel)的資料竊取方式。雖然該文提到旁通道攻擊有一定的限制，如：必須要接近目標，而且必須使用者正在讀取資訊時行動。但所謂：「殺頭的生意有人作，賠錢的生意沒人作。」在肥蝦所專長的金融軟體資訊領域，不正是屬於「殺頭的生意有人作」的範疇嗎？

資訊安全在國內目前可說是在如火如荼的推展當中，就金融產業來說：除了政府內政部門的要求外，金管會銀行局與銀行公會也相繼推出新的資安要求與法令。其目的之一：就在保護消費大眾的權益，以及社會的安全。記得肥蝦在四月二十三日與二十四日參與的「2009台灣軟體品質與資訊安全研討會」。不少學者也提出：目前國內軟體廠商從軟體設計開使就忽略了資訊安全的要求，導致國內產品與國際大廠無法於市場角逐的要素之一。其實，肥蝦也深深感受到客戶端雖然有考慮資訊安全，但在業務導向下，也僅是遵照政府的法規行事而已。但對身為專案管理與系統分析的肥蝦來說，在產品設計之時就能考量資訊安全的需求與必要性，這是一個重要且必要的課題。

雖然如本文所說明的旁通道攻擊，真得很難有有效的防範方式，但是資訊安全是目前與日後的重大議題，背後的商機也是無限的龐大，值得大家一起來關注。

什麼樣的鋼琴老師才是合適我家的小朋友？-論學習專案管理

肥蝦的大女兒─肥肥嚕─從幼稚園中班，跟著現在的林老師學鋼琴，至今已有兩年，聽說程度為"拜爾中級"。上週六才在民權路的一處演奏廳，參加了林老師所有教導學生的發表會，演奏了一支卡門跟不知名的小步舞曲。小女孩學琴難免會有點懶散，自己很難主動練習，難免要我家老婆大人親自督促與要求。

而肥蝦的內人從事國小教職，對於教育的理念與學習的步驟有一定的堅持與要求。而肥蝦是個音癡，對於教育也是個門外漢，心中只認為小孩子只要快快樂樂學習，培養一點音樂的欣賞能力，就是我這個老爸心中所期待與所盼望的目標。

這二個月來肥蝦跟老婆大人一直對於林老師的教學方式與學習進度掌控上有所討論。老婆大人認為肥肥嚕的樂理基礎與識譜能力不夠紮實，雖然彈到"拜爾中級"，可是對於應俱備的基礎能力太過欠缺。認為老師教學進度過於快速，造成小孩太大的負擔。當然老婆大人也跟林老師溝通過一次，目前教學的進度是緩了一些，但是老婆大人還是不滿意。

但肥蝦是以為，因為除了每週一次一小時的正式教學外，老婆大人幾乎每天都會要求女兒練習，對於女兒不懂或不會的地方，也會親自指導，勿必於林老師下次上課前練會。因此老師在每週在驗收上週的樂曲時，幾乎都能通過，因此很自然的就往下教。

為了鋼琴教學的問題肥蝦的老婆大人也詢問了她的同事(學校的音樂老師)，以及住家附近的一家才藝班的小王老師(肥蝦的小女兒─肥肥皮─在此學跳舞)，因此希望將肥肥嚕轉往才藝班學習。最後經由肥蝦與老婆大人進行面對面的討論，肥蝦逐一分析老婆大人的問題後，找出了關鍵的問題點－(1)教學程序：老婆大人認為要先從樂理基礎，開始再到彈琴。(2)老師的打扮：林老師比較敢穿，讓比較保守的老婆大人不能接受。最後肥蝦終於建議了一個方案，讓老婆大人接受－七月讓大女兒兩邊都學，再由她自己決定她要跟哪一個老師學習。

這個過程不禁讓肥蝦想起在坊間的補教業者學習專案管理的過程。還記得肥蝦在我的「專案管理(PMP)學習之路」的文章曾經提過我曾在前進國際、展頡跟遠景，上過相關的管理課程。每位老師均有自己的教學風格與邏輯，但重要的是學習者的自我認知：「您能否接受老師的教學方式？」就像在前進國際學習上「軟體開發專案管理實戰班」之時，一些有著豐富實務經驗的學員私下認為講課老師的經驗與授課實例都是侷限在小案子，對於他們的期望有太大的落差，無法實際應用。

現在很多的PMP補教業者所強調的都是如何快速考上PMP！雖然大家各有各的行銷花招，但就教學理念與方法也是有所不同的。有的老師教學方式是強調觀念的釐清，利用題目打通學員的盲點；有的老師教學方式是強調背誦，大量作題目、背題目，以求學員通過PMP考試；當然有的老師只是照本宣科讀完PMBOK…。但是肥蝦以為最重要的是學員自己要知道自己追求的是什麼？所想要學習的是什麼？

如果您想要學習的是PMBOK的思考邏輯與方法，那您當然需要的是一位強調觀念釐清的老師；如果您的記憶力好，要的只是快速通過，拿個證照，那強調背誦的老師也許適合您。

台灣目前的市場上，質疑PMP的聲浪不算小，肥蝦認為問題還是在根源上。到底每位學習PMBOK的學員心態！就算PMI把考試的難度提高，還是有方法把PMBOK當成應付指考的教科書教。

肥蝦以為專案管理在國內並不是顯學！您可以發現國外很多專案管理相關領域的書籍，但國內的翻譯作品多是集中在考試用書。這個PMP市場是由局勢所創造的？還是PMP市場創造了局勢？其實很難有定論。反正市場僅會朝向有錢的地方走！如果每個想學習專案的人都沒有追求自我不斷成長的自覺，想靠由外面的政策或公權力單位來主導，肥蝦以為這都不是一個良善暨有展望的作法。

【破窗】"The Broken Window"-您與人交往，是相信"資料"還是相信"感覺"？

肥蝦是一個推理小說迷，在美國當代的推理小說中，個人非常推崇與喜愛Jeffery Deaver(傑佛瑞·迪佛)的「神探萊姆」系統。還記得當初觀看「人骨拼圖」電影，丹佐華盛頓飾演林肯·萊姆；安吉莉娜裘莉扮演的艾米莉亞，深深吸引了肥蝦的目光。在日後，陸續購置與閱讀了一系列的「神探萊姆」，更是對林肯·萊姆的細緻、有序的邏輯推理能力，以及精確縝密的證物資料庫；艾米莉亞無畏、勇敢的精神，以及玲瓏有緻的身材著迷不已。

趁著這四天連假中陪個小孩的空檔，翻閱了「神探萊姆」最新出版的翻譯作品－The Broken Window【破窗】－身為碰觸資訊軟體的人，心中有著不同的感觸！肥蝦曾參與過某些銀行的信用卡核心與週邊系統，對於銀行利用持卡人的消費行為資料，進行產品行銷，有實際的參與；也對於稅務單位為掌控國民的稅務資料，要求銀行逐筆傳送交易資料，也有很深刻的印象。

近來有些許的小說，都在談論個人資訊保密的問題，如肥蝦先前看過的"Digital Fortress"【數位密碼】－Dan Brown(丹·布朗)著。【破窗】乙書，就在闡述犯罪者掌握了被害者的相關資料，利用被害者熟悉的生活作息與社交的弱點，加害於被害者。在應用現代人彼此間的疏離，對於"個人虛擬資料"的信任，大於對個人實際印象的信賴，入罪於他人。

其中，肥蝦對於書中431頁到449頁所列示的個人特徵的明細項目，對於作者的功力與細心，不得不深感欽佩！若有某家行銷公司真能掌握該書所列示明細的40%，其時就可以完全掌握該人所有的一切了。(其實若有需要分析個人特徵，該書431頁到449頁的明細，可作為一個非常有價值的參考依據)。

想到此處，肥蝦不禁憶起，近來參加過相關的專案管理資訊系統(PMIS)產品的發表會。雖然很多專案管理資訊系統，均強調使用者能經由該產品完全掌控專案(單一/所有)的"實際"進度，相關風險與問題的議題處理狀況，精確控制專案的實際成本，以及…諸多的好處。這就讓肥蝦想到，資訊系統所顯示的"虛擬"資料，就真得能完全精確的反應出專案的"實際"狀況嗎？

姑且不論專案管理資訊系統在專案管理中扮演的角色！若專案經理僅僅是利用資訊系統(如：PMIS,eMail,線上會議系統…)就能完全瞭解專案團隊成員的個人性格、品行、作為、習慣，進而就能完全掌握專案的確實狀況嗎？若是公司高層或是客戶，僅僅單憑專案經理以"虛擬"的資料所提報的專案進度數字，就是否能完全相信專案是在按照既有的計劃推進中？

肥蝦常碰到一些友人，他們相信資訊科技可以處理所有一切的事務，也在追求一個所謂的完整解決方案(Total Solution)，但是他們卻往往忽略自己的真正需求，也未深入評估過自己真正的處境。更是有些客戶，更是滿心盼望引入一套資訊系統，就能完完全全解決他們從未認真評估與仔細探索過的問題。

肥蝦想起先前一個手機業者的廣告詞「科技始終來自於人性」－強調其產品，乃是應用理性的科技原理，並考慮感性的人性因素設計出來的。可是肥蝦所遇過或聽過的很多資訊系統的問題，也是來自於人性。人性真得能用科技來完全取代嗎？我想這是一個見仁見智的問題！但是，肥蝦個人還是以為：「惟有藉由人與人實際、有效的接觸與信任，才是專案成功的不二法門。」

專案管理厚黑學-"大明王朝"讀後感

肥蝦這幾日因為得到"類"流感，臥病在床。還好，肥蝦是身無三兩銀，人家一看也不像剛從國外回來的貨色，因此沒被認為得到的是"豬流感"。

這幾日在病榻上，全身無力，也看不下一些電腦專業書籍，也讀不進專案管理的閒書；恰好生病的前兩天，逛到了天瓏隔壁的幼獅書局，在全館七五折下買了四本對岸劉和平先生寫的大明王朝。

肥蝦這幾日看完了大明王朝。不知道是專案管理學過了頭？還是著了專案管理的迷竅裏？突然對嚴嵩，這個歷史書上的大貪官，起了無限的同情心！單就專案管理的角度看來，肥蝦我突然覺得張居正跟海瑞他們那夥人，才是阻礙專案進行與破壞專案成功的壞人。

初看這部小說的第一眼，就覺得本書的故事主軸－"改稻為桑"－在國庫通府庫的時代，不就是為了彌補府庫的虧空，不就是為了滿足上位者的主要欲求。而胡宗憲所執行的蕩倭，也是服譍在同樣的策略目標－戶部尚書張居正說的：「海外一匹絲綢的價格是國內的兩倍。」－的一個專案。

而那大明王朝內惟一的sponsor與惟一的customer是誰？那就是「雷霆雨露，莫非王恩」的嘉靖帝了！而portfolio manager是內閣首輔－嚴嵩；program manager是浙直總督－胡宗憲；"改稻為桑"專案的project manager是浙江巡撫－一開始是胡宗憲兼，後來則改由倒楣的鄭泌昌；專案的end user是淳安跟建德兩縣五十萬的平民，利害關係人則是天下四萬萬兆民；那擔任淳安縣令的海瑞不過是專案團隊的成員之一而已。

整部小說所講的，就好像公司內部為了奪取公司資源而引發的人事糾纏，而最佳的觸發點，就是一個重要的專案－"改稻為桑"－的執行成功/失敗。就如那胡宗憲一開頭所點出的重點：本來專案的問題，僅是專案要如何的在制約下(減緩end user的衝擊下)，追求目標的達成(改稻為桑，擴大絲綢生產)。結果因為下一任sponsor與customer－裕王，跟裕王週邊的師傅－徐階、高拱跟張居正，為了爭取portfolio manager的職位，藉由引入海瑞，去阻擋"改稻為桑"專案的進行，將一個原本的專案擴大為公司內部派系糾葛的鬥爭。

一方的人馬為了要加速專案的進行，不惜違反的專案管理應有的倫理與道德─破壞堤道，毀壞民田；一方的人馬為了阻礙專案的進行，拉高土地收購的價格，降低了"改稻為桑"的獲利率。就在這兩方人馬爭執當時，那一方有真得替end user著想？就如胡宗憲去向江蘇巡輔趙貞吉借米時，趙貞吉說的：「兩邊都有人打招呼，不要把米借給浙江。」最後是誰打破這僵局！還是portfolio manager－嚴嵩。嚴嵩倒台後，張居正還是仿傚了同樣的作法－六成歸田主跟棉商；三成歸朝廷；一成歸棉農－去取得專案的成功－十萬匹棉布。

看了整個故事，肥蝦不禁想起作過的一些專案！當專案的customer跟end user是不一樣的人時，在執行專案有真正為了end user的需求與需要在用心嗎？捫心自問！沒有，因為專案驗收的時候是customer，而不是end user。而且end user遠比customer的人數多得多了！誰有辦法去伺候那些沒有權力直接決定驗收，又人數眾多的人。

如果為了加速專案的完成，您會選擇為了拯救九百九十九個人，而去犧牲一個人嗎？雖然那犧牲的作法有點違背心裡的良知跟倫理！就像影響五十萬人口的一點生計(不會餓死他們，只是變為農奴！)但確可增進四萬萬兆民的福利。肥蝦個人是會考慮去作！

雖然大明王朝說得是嘉靖跟海瑞，肥蝦確把它看成是一本專案管理厚黑學的四部曲─(1)藉由推薦與專案目標與意念相反的人，到專案團隊去阻礙專案的進行；(2)藉由彰揚受到專案成果負面影響的利害關係人，去摧毀專案基本的策略目標的正當性；(3)藉由非自己負責的專案失敗，去奪取所要的公司資源；(4)藉由消滅異己後，再採行同樣的手法，獲致專案的成功。

以上是肥蝦在病床上對大明王朝這部書的感想，還請 指教！

遇到更正時程問題時，專案經理的優先選項是?

Question : When correcting a scheduling problem, what is the FIRST technique a project manager should consider?
A.Crashing.
B.Reducing project scope.
C.Fast-tracking.
D.Out-sourcing.
題目所標示的正確答案是A，但肥蝦深不以為然！我個人無意就個人經驗或坊間其它書籍的看法進行說明!

就針對PMI的考題與PMBOK的內容，說實在地！此題出得並不好!此題的情境並不足以支持選擇Crashing。

在PMBOK裏面，並未寫到PM要修正時程的問題時，首要優先採用的工具或技術為何?

此題有很多的模糊地帶!

(1)scheduling problem:此處大家是假設是delay！
但從6.1-6.5規劃的階段，我們可以發現可能的問題有:
6.1漏/多了activity。
6.2依賴邏輯關係弄錯了。
6.3漏/多估了所需要的資源。
6.4漏/多估了所需要的duration。
6.5太過樂觀/悲觀。

當然結果就會出現在6.6.(監控)。6.6的recommended corrective actions強調的是分析偏差,可沒有說一定是delay。

(2)crash跟fast-tracking是6.5的TT-schedule compression，如果此題考的是規劃的問題，不管那一個都要針對在critial path上的activity，然後再重新界定critical path。

(3)就6.6的recommended corrective actions說明中，只有說包含expediting；另外也要求要有root cause analysis；還有強調除了造成偏差的activity進行分析外，也會進行多個schedule activities的分析！

肥蝦以為PMBOK的精神，在於告訴我們不管是造成delay或advanced，都應該要去找出問題何在，並去解決真正的問題。

"運用協同專案管理，創造企業競爭力研討會"會後感想

2009年5月19日下午一點半的這場研討會，肥蝦一個非常詭異的感受！

雖說是名義上是由凌群電腦、PSIG博鴻國際專案管理顧問公司，以及台灣思科系統合作舉辦，但真正的主辦者應是博鴻；而凌群電腦與台灣思科，不過是趁此機會推銷一下凌群電腦所代理思科的【WebEx】網路會議系統。會場中的主要主題是博鴻在推展自己的顧問服務、認證課程，以及所提供的8th Management專案管理系統。

當天下午計有四場主題的演講，分別是：

第一場(14:10-14:50)
主題：專案溝通與利害關係人管理
主講人：熊培霖 博士／PSIG博鴻國際專案管理顧問公司

第二場(14:50-15:20)
主題：專案管理整合服務
主講人：馬淑怡 處長／PSIG博鴻國際專案管理顧問公司

第三場(15:40-16:10)
主題：建置企業e化的專案管理溝通平台-提升專案如期、如質、如預算的目標
主講人：徐重光 處長／PSIG博鴻國際專案管理顧問公司

第四場(16:10-17:00)
主題：強化企業協同模式，提升企業競爭力
主講人：陳德利 經理／凌群電腦公司

第一場應該算是整個下午惟一有些內容的場次。為搭配8th Management專案管理系統，以及【WebEx】網路會議系統，熊博士應是特別以PMBOK 2008第十章的溝通管理為講題。不愧薑是老的辣！熊博士近五十分鐘的演講可說是幾無冷場。雖然內容不脫PMBOK第九、十章的內容，但與台下聽眾親密的互動，演說中間雜博士自己個人的經歷，在博士流利的口才，笑口常開的嘴型，溝通管理講來真是頭頭是道。惟一少數缺憾，是熊博士把專案經理的referent power定義講解成expert power；以及過於把conflict的根源窄化為資源缺少，以及將資源缺少與制度間拉上等號。

至於第二場的專案管理整合服務，美其名為整合管理服務，但全部的內容就是把博鴻的主要營業項目講一遍，內容乏善可呈。

第三場8th Management專案管理系統的介紹也僅只流於表面。說是產品介紹呢？又僅是帶過幾張系統的投影片。說是PMIS的重要性呢？連PMBOK所強調的Configuration management system與Change management system，又沒有明確解說。整個對8th Management的介紹，反而不如肥蝦先前參加百加資通所舉辦的「線上多專案管理操作體驗營」。由於肥蝦並沒有明確的資料，也無法線上測試，因此無法妄加斷言。

第四場介紹【WebEx】系統，思科在網路領域是領導廠商，所併購來的系統產品自是有一定的水準。

整個下午將近三個半小時的感受，比對起肥蝦的原先懷抱的期望，是有一段落差，這不禁讓我想起很多IT先進在IT邦幫忙的發言。的確一家公司是確實需要以營利為導向，但如果是文不對題的研討會，有可能會容易引人不當的聯想。不過對肥蝦個人來說，如果博鴻真得給了兩個PDU(尚未拿到須待博鴻寄發電子郵件)，那也是不無小補。

Brook定律-加人有用嗎?

Brook定律："在一個時程已經落後的軟體專案中增加人手，只會讓它更加落後"

以肥蝦個人的想法：" Brook's Law"不管是個人定義或是Law！所陳述的問題是在Crashing所要顧慮以及解決的問題。

就肥蝦個人淺薄的經驗發現目前對" 加人"，在公司與專案團隊之間有下列背後的駝鳥原因：

(1)逃避問題或找不出問題的推託藉口
專案經理：工作太多，作不完！人手不夠，無法完成當初專案的規劃！
高層主管：金額才那麼一點大，竟然要那麼多人作！

(2)推卸責任的推諉藉口
高層主管：照你的意思給你人了喔！還無法如期作完，是你專案經理專案管理不力！
專案經理：給的人素質、經驗都太差，來這邊是搞破壞的，專案延遲是主管找的人有問題！

這以上的對話是肥蝦個人常碰到的！然後就變成內部爭議，對專案只有雪上加霜！

其實專案延遲，一定是現況與當初所預定的計劃有了出入，有了當初未想到的問題！如果不能先找到問題的癥結，把一切都推到人手不夠，就算有一個功能強大的協同運作系統，也是無濟於事！況且新的成員對於協同運作系統也需要學習的時間，良好的協同運作系統，也僅能增進團隊運作的效率與效度！協助釐清專案的問題！但它可不是可以完全取代專案團隊在專案管理中的角色與功能。

增加資源(Crashing)所說的可不一定是加人，就算加人也要考慮幾個重點：
(1)時點：
專案晚期再加人，應考量新人學習成本與專案管理的成本，以及公司的成本！有時全面的考量終止合約，可能是比較划算的方案！

(2)經驗與配合度：
加入新的專案新成員，應先設定好他的角色與作用，需要何等程度的水平。先前肥蝦就遇過專案找進了一個經驗豐富的新成員，一來就批評那裏作錯！那裏不對！結果造成來一個走三個的困境。有時候，新成員的配合度比經驗還重要。

(3)其他選擇方案：
加快專案進度有很多種方式，基本上就有Crashing跟Fast-Tracking兩種！就算是Crashing也有提升開發環境與工具，採用外包把特定工作轉包，…。也不一定要直接於專案團隊中增加人手。

遇到專案延遲，專案經理應先跟團隊間開誠的找出問題根源，以及建議方案。如果需要加人，也要釐清新加入的成員所應負責的工作區塊，需要的技能與水準，融入專案所需要的時間。

專案成員對於變更控制程序應有的認知與責任

「Change Control Plan Preparation Guidelines」讀後感
原文：http://www.pm-i-study.net/dis/redirect.php?tid=127&goto=lastpost#lastpost

看了【專案管理交流論壇】成員Miller所上傳的「Change Control Plan Preparation Guidelines」後，肥蝦心中有一些想法，想提出與各位分享。

說實在的，「Change Control Plan Preparation Guidelines」是一篇不錯的變更管理計劃的範本，搭配文章中所提到的「Change Log」、「Status Report」、「Change Request Form」可以成為一個變更管理、監控與追蹤的完整架構。

文章中的章節－本文目的(Purpose of Document)、變更控制程序目標(Objectives of Change Control Process)、名詞定義(Terms, Acronyms and Abbreviations)、變更審核權限(Approval Authority for Changes)、變更控制委員會(Change Control Board)、變更控制程序(Change Control Process)、角色與責任(Roles and Responsibilities)－也是一般所常用到變更控制計劃的節次。各位讀者可以細讀這一份這11頁的指導手冊，相信可以有一個完整明確的瞭解。

肥蝦此時所要闡述的是，個人對於專案團隊成對於變更控制程序所要參與的程度，以及相關的權限設定。

在「Change Control Plan Preparation Guidelines」乙文中主要陳述專案經理(Project Manager)、專案贊助人(Project Sponsor)、變更控制委員會(Change Control Board)，與變更控制委員會之上的指導委員會(Steering Committee)的互動與分工。文中並依據專案的大小與複雜程度，提供了假想的【簡易】與【比較複雜】的兩個層次。但文中就如PMBOK一般，並未對專案成員對於變更控制程序的參與程度，以及有關的權限多所著墨。

肥蝦也仿照該文的【簡易】與【比較複雜】的假設，提出個人認為專案成員對於變更控制程序的可能作法。
(一) 【簡易】
假設：系統分析、設計與程式人員，並未直接與使用者面對面溝通需求。

在此假設下，專案經理應設法瞭解客戶的需求背後目的與理由，協助客戶擬具變更的目的與要項，再請系統分析、設計與程式人員就需求提出意見與建議解決方案。如果專案經理並未具有相關的技術與商業邏輯能力，應先設法尋求團隊成員的協助。在客戶與專業的團隊成員間，扮演一個完善的中介界面，儘量設法不加入自我的主觀判斷。

(二) 【比較複雜】
假設：有專屬的需求分析人員，直接與使用者面對面溝通需求。

在此條件下，需求分析人員應先設法釐清變更後面的動機與原因，並由需求分析人員擬據與客戶討論過的解決方案。再經由填寫「Change Log」、「Status Report」後進行變更控制的流程。如果需求分析人員能自行處理，則專案經理僅需要經由以客戶具名填寫的「Change Log」，以及專案成員填具的「Status Report」的review與檢驗，確認客戶的需求是否有效的滿足；如果需求分析人員無法自行處理，再由專案經理、需求分析人員，與客戶進行溝通，瞭解客戶的真正意圖，確認需求分析人員的分析與建議後，請客戶在需求分析人員協助下填寫「Change Request Form」，再依據該文的流程處理。

此外，「Change Control Plan Preparation Guidelines」中以對專案預算與時程影響程度比例，為介定權責歸屬的依據。這雖然也是一個參考準則，肥蝦也建議就每個activity、work package的角度以及buffer與reserve的owner權限著手。

如果一個要求僅限定在特定的activity或work package，不影響到別個activity或work package的owner所定義的資源、要求與條件，原則上專案經理應尊重每個activity或work package owner的判斷與建議；如果影響層面牽涉到不同的activity或work package owner應由專案經理進行協調與掌控。

肥蝦所繪製的流程圖可加入原文的前半，以為更完善的變更控制程序流程圖。以上肥蝦的看法與作法，還請 各位先進給予指教與建議！

風險鑑別與管理工具-VIRT簡介

「Visual Ishikawa Risk Technique(VIRT) - An Approach to Risk Management」讀後心得
原文網址：http://www.pmi.org/Resources/Pages/Risk-Management.aspx

專案的本質就是【不確定】，因此如何管理、辨識、分析、回應與監控專案的不確定因素，對於專案的成敗有著非常密切的影響！在PMBOK Guide 2008的第十一章風險管理程序群組中列了六個管理程序－11.1 Plan risk management; 11.2 Identify risks; 11.3 Perform qualitative risk analysis; 11.4 Perform quantitative risk analysis; 11.5 Plan risk response plans; 11.6 Monitor and control risks－在鑑別風險程序所產生的risk register，持續地於整個專案生命週期扮演非常重要的角色，需要不斷的追蹤、更新與新增。

在肥蝦個人從事專案的經驗中，很少有專案團隊會專注於風險的管理。一來，是因為專案經理已經花費大量的精力，在滿足緊迫的時程與嚴苛的成本金額要求。二來，風險有點虛幻，因為還沒發生，所以很難擁有實際的感受與急迫感。三來，風險管理的工具，大多感覺太理論了，與現實的專案實際狀況好像有些脫節。

以往，肥蝦自己在整理風險因子列表，會先檢視專案的相關文件(如：合約、RFP、建議書…)；接著詢問已有經驗的同事。再來就是憑藉相關的會議與自己的認知進行分析。在PMBOK Guide 11.2 Identify Risks也提出的七項工具－Documentation review; Information gathering techniques; Checklist analysis; Assumptions analysis; Diagramming techniques; SWOT analysis; Expert judgment。

在鑑別風險因素的程序中，肥蝦個人的慣常作法：(1)先進行SWOT的分析區分出幾個風險類型群組。(2)根據每個風險類型群組思考可能的潛在問題(其實肥蝦之前很少考慮到機會)。(3)思考每個風險間可能存在的關聯性。(4)建立風險清單，標明序號、等級、風險類別、風險項目與內容、負責人、狀態、登錄日期與備註。

但肥蝦遭遇最大的問題是溝通，因為風險清單是以表列與文字的方式呈現，所以很難讓團隊成員或長官瞭解整個風險的架構跟全貌。一旦逐一就每個風險因子進行討論，常會陷入「見樹不見林」的窘境。僅針對每個風險項目深入討論，有時所提出的意見會牽扯到其它的風險因子；但是在缺乏整體架構的討論基礎下，有時會產生太過或不及的回應與處理方式。

Rubin Jen於PMI網站所發表的－「Visual Ishikawa Risk Technique(VIRT) - An Approach to Risk Management」說明了一個風險管理的圖形工具(VIRT)。文章也闡述了風險管理的基本概念－【Risk management should not be performed in isolation and must be performed as a group, while being championed by the project manager.】，以及使用VIRT的步驟－(1)建立風險分解結構(Create the RBS)。(2)鑑別專案失敗要點(Identify Points of Failure)。(3)鑑別顯著的障礙(Identify Significant Obstacles)。(4)分解專案失敗要點至風險細項(Decompose Points of Failure to Detailed Risks)。(5)完成後續的風險管理活動(Complete Following Risk Management Activities)。(6)運用至持續狀態報告與重複狀態顯示(Apply to Ongoing Status Reports and Recurring Status Presentations)。

Visual Ishikawa Risk Technique(VIRT)是一個以圖形呈現與分類風險因子的工具。以圖形陳列出高階的風險群組與風險因子，在依據每個高階的風險因子，繼續探究其下的相關風險要項，其間用實線描繪出風險因素間直接的關聯性，如此可以呈現出一個風險的整體架構，也易讓人具有完整的印象。

肥蝦深覺VIRT是一個不錯的鑑別、追蹤與重新檢視風險的好工具。以肥蝦個人的愚見：如果再以虛線描述之間的不同群組或類別間風險因素的互動，如此將更能助益於之後的風險回應計劃的討論與建構。本文所展現的圖形，即是肥蝦個人稍加修改過的圖形表示法。但是麻煩的是會把圖形弄得非常複雜，因此肥蝦利用MS Visio的圖層屬性去分層表示以保持圖形的明確性與可見性。

本文附屬的圖片，所表現的是肥蝦近來負責內部研發專案的風險清單中的部份項目轉化為VIRT的樣貌。黑框藍底的方塊表示可能導致整個專案失敗的Failure point；紅色橢圓表示主要的風險要素；褐色方框表示次要的風險要素。

其中肥蝦以綠色的虛線表示不同Failure point下風險要素間的邏輯相關，如【外面訓練課程不符合實際需求】與【三個月內完成第一階段雛型】，以及【內部研發成本限制】三者之間也有緊密的互動；【跨部門合作溝通】與【組織部門間成本計價】也有密切的關係。這些關聯的風險因素在後續進行風險質性分析與量性分析，以及擬定回應計劃，都會存在TRADE-OFF或相關性的依存關係。

以上是肥蝦的個人淺見，還請 各位先進不吝指教！

Project與Project Management的差別！

有些朋友在面對專案跟專案管理、專案計劃跟專案管理計劃，有著模糊與存疑的態度，不太明瞭其間的異同。其實在PMBOK Guide 2000之時也把兩者攪混，直至2004與2008才明確的區分兩者的不同。

在PMBOK Guide 2008的第一章第二節與第三節，分別闡述什麼是專案(1.2 What is a project?)跟什麼是專案管理(1.3 What is project management?)。雖然專案管理指導手冊(PMBOK Guide 2008)中對專案定義為：「進行一段時間地努力，去創建一個獨特的產品、服務或結果。」；專案管理就是：「應用知識、技巧、工具與技術去達成專案的要求。」

說實在的，肥蝦對指導手冊中對專案管理的說法不甚滿意。肥蝦比較偏好用企業與企業管理的解釋邏輯，去解釋專案與專案管理。

以一般公司行號來說，企業就是人與資源的實體存在集合體；公司目標就是公司法第一條所序：「公司以營利為目的。」而企業管理就是組織、規劃、領導、指導、執行、控制、監督等行動或作為，去達成營利的目標。

而專案與專案管理與上述是反過來的，專案是為達成一個特定的目標，所存在人與資源的暫時性集合體。專案管理就是為經由規劃、組織、領導、指導、執行、控制、監督等行動或作為，達成專案目標。

因此肥蝦把企業與企業管理，認定為是由內而外的互動循環；而專案與專案管理，是由外而內的互動循環。

專案的目標大體上是由外來的因素決定的。目標是先設定的、是外來的，選擇執行那一個專案也是企業先行決定的。在PMBOK Guide 2004將Project Selection Methods設定為發展專案許可證(Develop Project Charter)的一個工具技術(TT)；在2008版則將其刪除，而在投入中新增一個Business Case，肥蝦以為這是比較貼近實務的現況。在一般公司的運作中，選擇一個或數個合適投資的專案，大多也是另一個專案，而此專案的目標是「最有效率與有效性的達成公司已定義的公司策略。」

當選擇特定專案後，為延續與追蹤的考量，應把公司策略、所要達成的策略目標、選擇此專案的理由等Project Selection Methods的投入與產出，列入專案計劃中的第一章源由或目的。依據此目的，進一步標示所要達成的實際與可見的成果，以及確認達成目標的檢測標準。

而專案管理就是要在專案要求之下，規劃、組織、領導、指導、執行、控制、監督等行動或作為，籌建一個暫時性人與資源的集合體，去完成專案目標。

那何為專案計劃與專案管理計劃？其間的差異何在？

專案計劃其實標準範例很多，大至行政院的施政計劃、小至一般家庭的購屋計劃，都是標準的專案計劃。專案計劃大多會先述及專案的背景與源由，專案所要達成的內容與目標，需要的資源，專案交付物的內容，專案的成效，專案的期限。

專案計劃書的重點是陳述－Why為什麼有這個專案；What專案所要達成策略目標的內容；When此專案在公司策略的要求上，應該要何時完成，或者每個重要時點的重要產出；Who公司內部的主導部門。

專案管理計劃所述的主要會集中如何達成專案的策略目標與要求－How執行專案的方法與戰略依循；What組成專案要求的成份內容；When在專案策略期限下的執行時程；Who專案工作的實際負責、執行與監控人員(小組)；Where每項專案工作的作業地點；Why每項專案工作的發展原因與使用工具的原因。

專案計劃書中對於專案的內容與時程，就會是4.1 Develop Project Charter的投入－Project Statement of Scope與Business Case－的主要依據。

那專案計劃書與專案管理計劃的順序性如何呢？以肥蝦個人的經驗，基本上是Start-to-Start的依賴關係。在專案目標與要求確定後(不是專案計劃書完成後)，其實就可以開始進行專案管理的程序與活動。

也許有人會問：「那在沒有Project Charter下如何進行專案管理活動呢？」如果在專案計劃中掛名的主要負責人員或組織部門，其實很多就是公司內部此專案的Sponsor(公司最大的Sponsor是董事長/總經理，但此專案的Sponsor可能是一個事業群的副總/協理)與負責部門。在實務上，執行部門的主管就會先行指派特定人或一組人馬開始擬定專案管理計劃。執行權力的來源與型式，很多是執行部門的內部的會議記錄、或口頭佈達、或備忘錄等非正式的溝通型態。此時除研擬專案管理計劃外，也會同時起草專案許可證。尚在起萌的階段，所需要跨部門溝通時，會由(或透過)部門的主管進行或協助下進行。

此外，在專案管理計劃的擬定上，也非一定依照PMBOK Guide的順序依次執行，也有可能是平行進行的。PMBOK Guide所說的Progressive elaboration(rolling wave planning)大多是進行專案管理規劃的進行方式。而且範圍、時程、成本、品質、人力、溝通、風險與採購管理群組的規劃作業，是互相糾葛，有時很難明確切割。但最重要的是專案管理計劃必須具有一致性，因此PMBOK Guide 2008將所有的計劃產出都匯入4.2 Development Project Management Plan後，再行匯出為其他程序的投入，是符合實務的，其目的就在要求專案管理計劃的一致性。

肥蝦拉拉雜雜的寫了一堆，為了說明肥蝦的認知，個人舉一個生活上的購屋還款計劃，來說明專案與專案管理。

(一)購屋還款計劃
(1)專案目標：在二十年內，還清五百萬的房貸。
(2)專案計劃：於每月的二十日前，須要籌足本金二萬一千元與依據特定利率計算的利息。

(二)購屋還款管理計劃(不用initiating process group的活動了)
(1)專案管理目標：如何從每月的收入，扣除生活必要開支後，擠出每月的本金加利息的還款金額。

(2)起始作業：
還款人就是我；來源就是每月的微薄收入；利害關係人是XX銀行。

(3)規劃作業：
(a)支出方面：檢討每月生活開支項目，並進行必要性的確認。預估生病或突然狀況所可能引發的支出(風險)。
(b)收入方面：先考量失業所可能帶來的問題，以及因應之道(風險)。其次，考量增加收入來源的可能性與作法(如：每月買一次樂透)。
規劃作業產出：每日允許之生活開銷計畫、每日生活開銷記錄表。

(4)執行作業：
每日要花錢前先檢核該商品或支出是否列入專案每日允許之生活開銷計畫中的允許項目。支出後應確實填入當日生活開銷記錄表。

(5)監控作業：
可再細分為：
(a)執行績效的監控：每日睡前，針對實際支出與預計支出進行比對。
(b)每日允許之生活開銷計畫檢討：所列項目是否合理，如漏列了衛生紙的開銷，那總不能不用衛生紙！所以只好回頭修改每日允許之生活開銷計畫。
(c)專案管理目標的監控：貸款銀行的利率是否比其他銀行高？是不是要轉貸，以降低還款的利息金額。

(6)結案作業：
拿到銀行的還款完結證明文件。

以上是肥蝦的個人認知，還請 各位先進不吝指教與給予指導！

時間表的用途-"Making Things Happen" Chapter 2

歐萊禮所出版的「專案管理之美學-讓事情發生(Making Things Happen)」(Scott Berku著，陳建勳編譯)的第二章－【時間表的真相】，提到時間表(Project Schedule)有三個用途。肥蝦覺得非常好玩與有意義，因此予大家分享個人的心得。(以下將文中的時間表"schedule"改稱為時程表，以配合肥蝦自己的用法；大陸的PMBOK Guide 2008簡中版稱"schedule"為進度計劃。)

肥蝦在未看到本文之前，一直認為時間表僅是定義工作作業的起、迄時間，以及作為監控管理的用途－就是公司用來迫害專案工作人員的工具。當然從PMBOK Guide 2008的角度看來，時程表(Project Schedule)除了是監控時程的重要投入外；也是估計成本、決定預算，以及計劃採購的重要參考依據(input)。

但是Scott Berku所提出的三個用途：
(1)對事情何時完成許下承諾。
(2)鼓勵每個人將其付出視為整體的一部份，並盡力使其工作能和他人配合。
(3)提供一個追蹤進度的工具，並把工作切分成可管控的小部份。

第三點在PMBOK Guide中有著明白的解說，實際從事專案的人也有過切身被"傷害"的經驗，肥蝦就不在多說明。

第一點則是一個心理作用，有一個明確的完成時間，就好像給了客戶與內、外相關的利害關係人，對未來一個承諾一樣。這就好像男女交往當初，男方發誓說：「我會永遠愛妳！」一樣，大多不切實際，但對女方確很受益，男方也有了進一步行動或需索的藉口。

在肥蝦個人的經驗上，最後定版的結案日期很多是來自專案團隊之外的要求。比如：合約上的日期(有些議價方式的合約，專案團隊會跟客戶進行協商，但最後還是由客戶決定)、法律的落日條款、行銷部門的要求、長官的決定…。

專案的最原始假設(或說幻想)：就是專案所交付的產出、服務或結果是一定存在的，也會如期在特定日期產生。依憑於此，專案贊助人(Sponsor)或客戶(Customer)才願意把資源投注在專案的身上，就比如男方發誓說我永遠愛您後，女生才有可能委身於他(不過現在很多一夜情或…，不在觀念呆板的肥蝦理解之內)。

第二點則是肥蝦覺得最有趣的。從PMBOK Guide 2008的觀點來論在6.5發展時程表之前在6.2排序活動項目下的專案時程網路圖(Project Schedule Network Diagrams)就會標明出每個活動的順序與依存關係，就是每個人工作的關聯性。這依存關係與專案時程中定義的完成日期，有著關係，但確沒有絕對的關係。因為就算專案延遲，這每個活動間的依存關係依然存在，除非一開始專案活動間的排序是不合理與盲目制定的。但這背後所發揮的對團隊成員的推進作用(forcing function)的心理活動－事情一旦發生，能自然而然的迫使觀點、心態或行為改變，就稱為推進作用。這個心理因素肥蝦有深切的經歷，但在Scott Berku未標明前，肥蝦還沒有深切的思考過。

時程表的完工日期，背後是一個機率的概念(此書與「與熊共舞」、「關鍵鏈」、「人月神話」以及一些專案管理書籍都是此種觀點。)機率在實務上，是客觀跟主觀的混合產物！在統計或機率學上，機率是企圖去猜測上帝的未來作為。任何機率的分配都有很多的假設與限制，能提供一些客觀的分析；但如何確認自己所處專案的情況符合特定的假設與限制則就有很多主觀的因素在內。

最重要的主觀因素就是"你相不相信"，對專案的利害關係人因為所處位置的不同常會有不同的認定與理解。

一般人會為可能達成的目標努力奮鬥；但不會對絕不可能有機會成功的事情打拼。因此如何凝聚，以及延續大家的機率共識，是很重要的！

之前，肥蝦也碰過一些情況，當公司內部於選擇專案之時，重要高層對於一個近新台幣三億元金額的案子有95%的人認為絕不能成功(機率為0%)；另一部份的人認為是沒問題(機率為100%)。但是不幸的是有決定權的人就在5%的人裏面(這其中，竟然還有因為子公司的一位副總)，因此有決定權的人決定引進子公司的人，擔任最重要的角色(專案經理與AP組長)，而且是以T&M的合約方式引入。

專案初始時期，團隊成員已經缺乏對完工日期達成機率的共識，進入規劃的搜集需求與差異比較後，團隊成員對於達成完工日期的機率是大幅下降。更嚴重的是。來自這些子公司的重要成員眼見專案無法如期完工，竟然開始閃避與推拖，更使得團隊成員的信心瓦解。因此專案的下場可以想見。

因此時程表背後所代表著的信心機率，是一個專案成功與否的重要立基！雖然專案延遲，如果沒有外在的限制下，而且專案團隊與客戶或利害關係人認為延後完工日期後成功的機率是上增的！那專案將會繼續執行直至這機率降至無法接受的地步。

專案經理追求的修為－"Pursuing the Perfect Project Manager"讀後感

近來正開始翻閱Scott Berkun所著的"Making Things Happen"(專案管理之美學－讓事情發生)，對於第一章「專案管理簡史」所提到Pursuing the Perfect Project Manager乙文感到非常的好奇，因此依據書中所記載的網址(http://www.tompeters.com/col_entries.php?note=005297&year=1991)，上網複製原文內容，細細拜讀了一番。

針對文中所提到的八種相互衝突的特質─1. Total ego/no ego(自我/無我)；2. Autocrat / delegator(獨斷者/委託者)；3. Leader/manager(領導者/管裡者)；4. Tolerate ambiguity/pursue perfection(忍受模糊/追求完美)；5. Oral/written(口頭/書面)；6. Acknowledge complexity/champion simplicity(承認複雜/支持單純)；7. Think big/think small(思慮廣懋/思慮精微)；8. Impatient/patient(急迫/耐心)。─必須內化於一個優秀的專案經理，深感贊同，但也覺得惶恐。贊同的是：專案本來就是要面對複雜、不確定的環境，努力追求一個被認同、有效的結果。惶恐的是：這八種特質真的是很難以學習跟內化。

在拜讀之後，肥蝦把這八個特質區分為專案經理的心態、思考、行動與經營四個層面。

(一)心態：
Total ego/no ego(自我/無我)；Impatient/patient(急迫/耐心)
專案經理應該要比專案成員投入更多的心力在專案上，對自己負責的工作與要求，必須能以「日日新、茍日新」的心態，不斷的催促自己往前邁進。但對於專案成員負責的相關工作，必須能讓成員去追求表現與成長；必須能"寬"以待人，以"共工"的態度對待相關的專案成員與協力夥伴，對於成員的意見與反應必須能寬容的對待與討論。
以下是肥蝦的一些想法：
(a)專案的成功是成員一起開創的，不是您"英明"的領導。
(b)成員的問題是您的問題；您的問題千萬不要變成所有成員的問題。
(c)身教重於言教，身體力行取代碎碎念。

(二)思考：
Tolerate ambiguity/pursue perfection(忍受模糊/追求完美)；Think big/think small(思慮廣懋/思慮精微)
專案本質就是模糊與不確定。專案經理應該具有一個思慮清晰與條理分明的的頭腦，在模糊之中應設法釐清其間的脈絡與層次；在不確定之中捉住重點與順序。
思考上，應先以鳥瞰的方式，試圖捉取全貌，並加以分類；再設法以關鍵因素/不同的使用者角度，去深思其間的影響與互動；經由以上二維的角度切割出不同的區塊；針對每個區塊再行仔細思索，追求每個區塊明確的意圖。接著從明確的區塊，再回頭組合成專案的全貌與架構。如此重覆的反復思考才能儘量貼近事實的真象。
在這思考的過程中是非常耗費心力的，也不斷的有所疏忽！因此自我的心態調整與壓力舒緩是很重要的！不要把壓力直接呈現在成員面前，也千萬不要把壓力累積在自己的心頭。

(三)行動：
Oral/written(口頭/書面)；Acknowledge complexity/champion simplicity(承認複雜/支持單純)
一個專案的工作非常的繁瑣。上至專案管理計劃，下至例行會議的舉行與記錄；內與團隊成員間彼此的溝通；外與客戶、長官等人的協談，這諸多的事前、事中、事後工作，都需要去執行與管理。如何將複雜的事項與因素，轉化為簡單、明確的工作事項與作業流程；如何有效的宣導、溝通、記錄與追蹤，這需要"眼高手低"的行動準則，採用合適的溝通管道與方式。
專案管理工作目的，在協助專案工作的執行與完成。千萬不可將手段目標化，造成團隊成員疲於滿足管理工作要求，而佔用了執行專案工作的時間與資源。

(四)經營：
Autocrat / delegator(獨斷者/委託者)；Leader/manager(領導者/管裡者)
在專案團隊的經營上，專案經理應記住的是：「不要急著去解決成員的問題，當他們可以自行處理時！」專案經理的首要工作應是主導專案團隊的正面氛圍，以及創造前進動力的因素。在專案團隊的正面氛圍與創造前進動力的因素上，個人以為可以扮演獨斷者與領導者的角色；對於專案成員間的溝通以及成員的工作上，應該要以信任的態度，以及從旁協助管理的立場，則以一個委託者與管理者的角色出發。

以上是肥蝦的心得與感想，還請 參考原文，以及「專案管理之美學－讓事情發生」的第一章「專案管理簡史」給予肥蝦一些批評跟指教。

推薦一個不錯的新專案管理論壇

這個論壇剛成立不久，專注在專案管理的領域，感覺也很中立，肥蝦也在其中貢獻小小的版面，還希望大家能多多共襄盛舉！

肥蝦衷心希望專案管理能在臺灣蔚為風潮，在基礎的專案管理與作業上能走向一定的制度與架構；並能傳遞前輩與大家的心智精力，讓臺灣的軟性產業與服務業，能在國際市場上一爭長短！

論壇網址

http://www.pm-i-study.net/dis/index.php

問題，真得是問題嗎！－"你想通了嗎(Are you lights on?)"

本書如同"從需求到設計(Exploring Requriements)"一書，也為溫伯格(Gerald M. Weinberg)與高斯(Donald C. Gause)合著。本書的重點在闡述問題的界定、發掘與陳述，提供了如何去釐清問題陳述的方法。本書與肥蝦先前所閱讀的"發現問題的思考術(Professional Problem Finding)"(作者：齋藤嘉則)有著同工異曲與互補之妙。齋藤嘉則的重點則在分析"未來願景"與"現狀"去找出問題；溫伯格強調問題的陳述與自省。

肥蝦以為溫伯格所強調的問題的循環：問題=>解決方案=>解決方案所帶來的新問題=>解決方案=>解決方案所帶來的新問題=>…。說明了問題是永無止盡與無法百分之百解決的，但是要藉由問題釐清、思考、分析、陳述；進而界定功能、特性、限制、偏好、期望，轉化為可解決方案的空間；轉化為設計，以提供特定客戶與供應者可接受的解決方案；重新追蹤原問題與鑑別新問題；重新不斷地循環，以將期望與滿意度之間落差縮小至客戶可容忍(tolerance)的範圍內。

本書內容區分為六大部份：(一)問題是什麼－定義問題(Definition)；(二)這是什麼問題－問題定義(Analysis-What is the problem?)；(三)真正的問題是什麼－問題溝通(Communication)；(四)這是誰的問題－問題共同化(Analysis-Who has the problem?)；(五)問題是從哪來的－自我反省(Analysis-Where does the problem from?)；(六)我們真的想解決問題嗎－回應到目的(Problem and solution must be return to the business need)。

以下將各部份的重點摘要如下：
(一)問題是什麼
(1)問題是期望與感受間的落差；問題是Expectation與satisfaction的落差；問題是未來的願景與現狀的落差。
(2)解決問題可以考慮改變期望？或是改變感受？還是兩者均設法改變。

(二)這是什麼問題
(1)不要把問題的解決方案當作問題的定義(尤其解決方案是自己提出的時候)，回復問題的原貌，試著用不含解決方案的語意去陳述問題。
(2)你永遠無法確定自己是否已經取得了正確的問題定義，甚到到了問題已被解決！但決不要放棄追求一個正確的定義。

(三)真正的問題是什麼
(1)解決方案引發新問題與不合身，一旦設定任何決定其實就給定了範圍與限制。
(2)問題陳述需要不斷重覆調整，直到問題清楚的進入每一個人的腦袋。
(3)釐清問題陳述的方法：
-按順序強調一個字詞。
-字典法。
-肯定與否定互換。
-強迫語句與可選擇語句的互換。
-所有格的互換。
-頻率用字的轉換。
-籠統字眼的特定舉例與明確描述。
(4)定義問題應回應到真正原始的目的。

(四)這是誰的問題
(1)問題的共有化，解決問題的人必須要跟問題有實際的關聯。
(2)不要急著解決別人的問題，如果他們可以自己解決很好的話。意即要克制自我膨漲的欲望，先設想與尊重對方的立場。
(3)提供別人問題的解決方案，有時不如一個簡單的提醒。

(五)問題是從哪來的
(1)問題基本上都不會是從"自然"而來，但確是推諉問題的最佳藉口。
(2)問題的來源大多跟自己有密切的關聯(53.27%問題是出問題解決者身上)。

(六)我們真的想解決問題嗎
(1)人們很少知道他們的真正需求是什麼，直到你給了他們要求的東西。
(2)到了最後分析階段，沒有多少人真的願意想解決問題。
(3)解決方案絕對沒有所謂的絕對完美，因此不要想著不斷修改解決方案，達臻所謂的絕對完美。
(4)問題解決方案提供者，一定要忠於自我，忠於專業。

肥蝦以書中的一句話：「可以確定的是，大多數的人都認為自己知道問題到底是什麼，然而，實際上他們通常是錯的。」與各位共勉，還請 指教！

推薦微軟的一位技術經理的程式開發專案管理專欄

昨日有幸與一位微軟的技術經理-周旺暾先生見面，看著他名片上的PMP標識，因此上去台灣的MSDN看看，結果到他所撰寫的程式開發專案管理！

雖然專欄內的篇數不多(僅有三篇)時間也稍嫌久遠，但文章的內容非常不錯！
1.成功開發團隊的八項特質 (2005 年 3 月)
2.軟體架構師的成功秘訣 (2005 年 1 月)※第二篇應該是【程式開發工作的時程預估】。
3.談程式開發專案進度管控 (2004 年 12 月)
大家可以上網參考！
http://www.microsoft.com/taiwan/msdn/columns/PMP/default.htm

肥蝦對於【成功開發團隊的八項特質】乙文最有感觸！近來負責的研發專案，由於團隊成員缺乏一個成長與激勵自我的態度，在溝通與願景的凝聚上困難重重！
特別把八項特質列述於下，以供肥蝦與各位先進一同勉勵與參考！
1.促進開放的溝通
2.為共同的願景工作
3.授權給團隊成員
4.建立明確責任並共同負責
5.專注於提供商業價值
6.為了變動, 隨時保持最佳的彈性
7.投資於品質
8.從經驗中獲得學習

Five ways to make or break your team

PM Network Vol. 23, No. 4, Page 53-57.
本篇文張舉出了五個會嚴重破壞專案團隊的五種狀況─(一)失控的會議。(二)隨機變更專案的方向。(三)利害關係人的過份需求。(四)未預期延遲。(五)專案人員的爭執。─這種情況在肥蝦的專案經驗中其實常常遭遇，對於專案的進行，以及專案成員間的和諧，真得有莫大的衝擊。文中提供了一些實務的經驗予讀者分享，個人認為非常具有參考性。因此肥蝦特就文章內容，並對應個人的經驗，分述五種情況的核心，以及可能有效的建議。

(一)失控的會議(Out-of control meeting)：專案從啟始到結束總有不斷的會議要開－kick off meeting, group progress meeting(Daily), status review meeting(weekly, project performance report meeting(monthly), change control meeting, project management meeting…。但經常都是流於形式，參與者大多不知道會議的目的與要求；或是成為長官單向佈達的會議，無法真正的有效溝通，更進而長官們厭倦聽到問題；簡報的資料一再重複，會議資料與實際狀況嚴重脫節，無法真正的反應現況，更進而專案經理或長官玩起數字遊戲，藉由變更計算方式粉飾太平；與會人員雜亂，主題失焦…。這種種的會議惡象，我想很多人都有經驗。

在本文中提供了一些方法試圖杜絕上述的惡果：(1)聚焦：每個會議必需有確定的目標與議題，切忌離題。(2)慎選與會人員：會議人數應適當參與人員須對會議主題有明確相關。(3)訂定基本規則(ground rules)：遵守既定的規則獲取與會人員以及未與會人員的信任。(4)限制會議時間：會議應有明確的起始與結束時間，冗長的會議徒使與會人員喪失注意力。(5)確保會議是雙向(上層與執行者)有效的溝通。

(二)隨機變更專案的方向(Seemingly random changes in project direction)：專案管理計劃最重要的是標明what、when、how、who (why基本上會建議寫在project document)去執行一個專案。因此專案的目標必須非常明確；標明每個特定區間與milestone的重點，專案成員才有依循的努力方向。

但是專案的本質就是【變化】，在遭逢無法避免的改變下，惟有開誠佈公的跟專案團隊說明變更的理由，大家同心合意下，才能化解因為專案方向變更，所導致成員戰鬥力的衰減。試想，如果專案方向經常在成員無法獲知、無法理解的情形下變更，專案成員將會如何迷失工作的方向，喪失鬥志。當一個人不知道今天或以往的努力是否有效的情況下，誰願意去努力達成目標。

(三)利害關係人的過份需求(Overly demanding stakeholders)：在專案的進行中利害關係人(包含使用者或客戶或公司高層)常會無端的加進很多臨時的要求。這不只發生在客戶身上，更常遇到的狀況就是公司內部的高層，常會為了某些理由(如公司管理…)要求專案成員提供相關的資料或報表，更可悲者，還會限定交付時間。

一般的情況下，每個成員在瞭解專案的目標與方向下，大多會擬定每日的工作進度與內容。突然安插的要求，常會導致成員淪落於疲於應付非專案主體的工作。此時專案經理必須有所擔當，除了建立一個暢通完善的溝通管道與流程，應將要求記載於書面，獲致正式的同意，按照標準的作業流程處理；對於不合專案目標的要求，應該要明白的向要求來源陳述事實跟現況，爭取有利與合理的作法；對於不可避免的要求，也要向成員坦誠的溝通，獲取成員的支持。

(四)未預期延遲(Energy-zapping soul-sucking unexpected delays)：專案的任何計劃均無法保證百分之百無誤，難免會有疏漏或執行上有所錯誤，進而影響專案的時程。因此最重要的處理方式就要是向成員充分的揭露，發現問題，戮去解決，保持專案不斷的往前進行；而不是去找個替罪羔羊，想個卸責的藉口。因此在遭遇某些問題或發現疏失，第一步是要向成員主動的說明。再來，就是與團隊中的相關人員商討解決的辦法，凝聚團隊的共識，朝向克服問題與達成專案目標前進。

(五)專案人員的爭執(Team squabbles gone awry)：專案團隊間常會諸多因素引起爭執或紛爭。雖然PMBOK說明要求爭執的雙方先行協商合解；如果無法獲致解決爭端的方法時，再由專案經理介入。但在本文中要求專案經理應立即安排面對面的會談；如果無法解決，接著是專案經理與爭執的雙方依序的一對一面談；如果確定爭執雙方無法在一同合作之時，專案經理應透過上層管理階層留下對專案有較大的貢獻者。

針對上述五種情況，肥蝦認為主要可歸類於專案的溝通管理(失控的會議、隨機變更專案的方向、利害關係人的過份需求、未預期延遲)，以及人力資源管理(專案人員的爭執)。由於專案的本質就是要集聚特定人員與資源的力量，處理變化難測的狀況，達成既定的目標。因此對於專案團隊、公司內部以及客戶，首要的是建立"信任"的關係。

如果客戶能相信您與所有專案成員，都是為了建置一個為客戶設想的系統的前提下，對於雙方的溝通奠定穩固的基礎，在共通的基礎與限制上，雙方才能進行折衝商談，共同追求一個較佳的解決方案。肥蝦至今的經驗還沒有遇到一個案子，客戶擺明就是要您掛掉的狀況。一旦專案無法完成，不只會對vendor side造成傷害，對user side也有一定程度的損失，惟有設法使客戶認清這個事實，才可以有效減少客戶過份的要求。

在公司內部的溝通上，也是如此一旦公司上層懷疑或認定專案出現問題，上層主管將會不斷地想探索專案團隊，甚至每個成員，每天的工作內容與進度。如此一來專案成員會光填寫報告與進度回應將浪費掉無數的寶貴光陰，進而使專案停滯不前。坊間很多專案管理的工具或方法論，但實行的結果往往本末倒置。原本為著加速與方便控管專案的管理流程，反過來變為成員每日的主要工作。因此專案經理應設法強化公司與專案間的溝通，扮演一個折衝的角色，必要時應坦白的向上層反應。說句實在地，如果上層執意如此，並可預知將造成團隊的生產力與士氣蕩然無存，與其委曲求全，不如另謀他路。

至於處理專案成員爭執的作法，每個人基於自身的經驗與瞭解有著不同的作法。個人能認同文中所說：「專案沒有時間可以浪費。」因此先由爭執雙方自行處理可能無法獲得滿意的答案。以肥蝦個人的經驗，會建議由專案經理與爭執雙方一同與會討論。但是會前專案經理應設法私下分別與爭執雙方以及相關的周遭成員討論，設法釐清爭執的"起源"－工作界面不明、專案資源爭取、或個人情緒問題…。不同的爭執原因應有不同的處理方式。如果是雙方個人情緒上的問題，已經無法排解，我會建議如溫伯格(Gerald M. Weinberg)在"從需求到設計(Exploring Requriements )"乙書中所說的讓雙方都離開團隊，以免可能造成留存的人自大的心態。

有效收集需求－"從需求到設計(Exploring Requriements)"

溫伯格(Gerald M. Weinberg)在IT軟體專案管理界是耳熟能響的國際大師，伊寫了一系列的專著，都是專案管理人士的必讀經典。本書為溫伯格與高斯(Donald C. Gause)合著，主要在探討如何有效的釐清客戶的期望，以精確、正確、完整，且保留應有設計空間的去記錄使用者的需求。個人以為每章之後的摘要，敘說why(為什麼？)、when(何時？)、how(如何？)、who(誰？)可說是精華中的精華、值得一再的閱讀與深思。

本書區分為五大部份：

第一部 先有一點共識：語意曖昧(ambiguity)是整個需求要件(requirements)作業的最大問題，因此如何有效的釐清需求，並建立與客戶間的信任關係，是收集需求階段的最重要目標。

第二部 起步的方式：需求要件作業重點在縮短客戶的期望(expectation)與感受(satisfaction)間的落差。在探訪需求之前，雙方均一同假設解決方案一定存在，再經由有效的訪談、找到對的人與群組、有效的會議、不斷澄清與調查，去減少語意曖昧的字句與敘述。

第三部 探所各種可能性：說明經由有效方式，集思廣意去擴大解決方案的基底。

第四部 釐清客戶的期望：逐步以功能、特性、限制、偏好、期望的作業程序，從解決方案的基底，進一步獲致一個合理與認可的解決方案空間。

第五部 大幅提升成功機率：應儘量設法將解決方案的界限與問題加以數字化與圖表化，藉由一些有效的工具─技術審查、滿意度的檢測、黑箱測試案例、與現有產品的比較與區隔─達致雙方一致的意見，雖然承諾繼續溝通，但以獲得客戶有效(sign off)的認可，為一切的後續作業核心。

本書提供了很多有效，而且實用的工具，如：叢群法、決策樹、使用者分類法、功能表、特性表、所值幾何圖(what-if worth) 、期望表、語意曖昧的衡量指標、滿意度測試、黑箱測試案例等等，協助分析人員有效地搜集、彙整、分析，以產出精確、正確、完整，且不失嚴苛的需求文件。

文中也對如何舉行一個有效率的會議(一般的討論會議、激發創意的腦力激盪會議、技術審查會議) ！如何進行訪談！如何進行開放式問題詢問！如何調和衝突！如何界定解決方案的適當空間！均提出不少有用的建言、規則，與應注意防範的重點。

本書也一再強調：收集需求重點，不但在產出有效的需求文件；也在經由建置、研議、探索需求的過程中，獲得重要的收獲，回饋至專案的成功。因此過程與結果是同等的重要。

書中以兩個例子貫穿本書探討的所有主題：一、超級粉筆專案。二、電梯資訊裝置專案。因此對沒有IT背景的人士而言，閱讀起來也一樣"輕鬆愉快"。

書中對肥蝦啟發較大的有：

(1)不可將困難的部份留給他人處理。各人對圖表的解讀不同，務要接受不同的解讀意見；而不可要求齊一意見。並且要確認每人都可以瞭解與使用，相關的圖表與方法。

(2)使用圖表的目的應根據我們現有手上的工作類型，以及希望避免的錯誤(使用工具；而非被工具使用)。

(3)使用者的確認(Identify stakeholders)後應再繼續將其分別群組；並列示產品(product, service or result)對使用者的態度－friendly ,Ignore, Unfriendly。鑑別使用者或利害關係人是專案初期(initial)的重要工作，但肥蝦往往並不會再加以分類；並記錄產品對使用群組應有的態度，以致後續在處理需求變更或相關變更、修正的議題時，迷失的應有的立場與態度。

(4)偏好的度量與以圖形化表達需求、期望與限制。肥蝦非常喜愛作者於第四部份－藉由功能、特性、限制、偏好、期望－這五個步驟，來建立一個解決方案的有效空間的說明。

(5)對於專案決策的分類－選擇(基於有意識的思考判斷) 、假設(未察覺、偏見、資訊不足、錯誤判斷)與強迫(法律、習慣、高層指示)－應加以區別，並寫下原因。以便後續可以追溯決策立基的緣由，檢視其是否已經不存在或異動，以擴大專案成功的可能性。

(6)凍結需求要件是一種妄想，收集需求的最後一個步驟是：雙方同意繼續溝通。但可以進行下一階段作業的前題是：有足夠的同意書(客戶簽字) ，以及有效的需求收集程序。

(7)培養自己以專業做事的勇氣，以及至少要將一半以上的時間花在自己的身上；而不要被技術層面的事務，或為他人進行協調佔據所有的時間。

本書不但是一本探索如何作好需求文件的說明書籍，更可以當作是一本工具書。對應於PMBOK 5.1 Collect Requirements有著幾近完美的闡述，與詳盡的作業說明。

The Global Risk Factor

PM Network, vol. 23, No. 4. Page 34-39

此篇文章一開頭以去年十二月所發生義大利與埃及間的海底電纜斷線，說明目前專案國際間合作模式所遭遇的風險因素與風險考量。主要可說集中在PMBOK方法論架構中的第十二章(外購管理)與第十一章(風險管理)。

由於國際間因為國家間藩籬的降低，以及網路無國界，專案經理為追求預算的最大效益與縮短開發的時程，會考慮將專案的部份工作(task)或工作包(work package)經由採購(procurement)的方式轉移出去。但如果轉包予國外的廠商，就必須考慮到國際間的溝通、不同國家間的文化差異，以及外包商所在國家的國家風險等，不同於一般專案所認知的風險。

該文中所提及的風險，包含供應商所在國家的政治、經濟的動亂到恐怖攻擊、重大公共基礎設施的損害(如本文一開頭所提及的海底電纜斷線。)、當地流行疾病等都應列入考量，並提出適當的風險因應對策(contingency plans, fallback plans, workaround)，以減緩所遭受到的衝擊。其所建議的方式有：(1)一定至少一次的面對面溝通。(2)將外包商結合至整體專案的利益。(3)儘量分散在不同的區域或國家。(4)對於比較重要的部份應轉向成本效率高以及標準高的國家或地區。(5)該國的公共設施是否允許在家工作。(6)合約中訂定服務水準等級與處罰條款。(7)堅強穩固的fallback計劃。

因此專案經理在將自國外外購專案的工作應首要思考：「什麼是可以外購？什麼不應該外購？如果外購的話會附帶進什麼樣子的風險？」而且也要建立一個觀念：「外購也不是經由合約將應有的責任完全轉包出去，而應要考量自己與外包廠商不同但互相關聯的義務與責任。」因此最終的決定，還是在於專案經理的理智與聰明的決策跟判斷！

土法煉鋼出來的─肥蝦版"訪談作業程序"

在建置應用服務資訊系統時，需求分析師或系統分析師最重要的工作之一就是去訪查客戶的需求與期望，釐清現有的作業流程，溝通雙方彼此的意見。因此肥蝦在初步累積了近十年來的經驗與參考一些書籍的方法，土法煉鋼的擬定了一個簡單的訪談作業程序"一個基本、二個希望、三個步驟、一個注意"：，希冀經由這拋磚引玉的動作能獲得更多的收獲。
(一)一個基本：
(A)"採購合約"與"工作說明書"要滾瓜爛熟。

(二)二個希望：
(A)希望工程師可以不用跟(只要能有效掌握需求，並不需要工程師跟，有時兩者間的語言不同會造成更大的問題；而且有可能造成客戶直接跟工程師約定了不當的承諾！)
(B)若非有工程師在場不可，希望要跟我事先先演練或套好招。

(三)三個步驟：
(1).訪談前：
(A)瞭解受訪者的背景、單位、與專案利害的衝突，以及受訪單位在專案中的角色與定位。
(B)瞭解此次訪談目的、牽涉到專案的範圍與重要性。
(C)詳列訪談的重點與預測可能的發展。
(D)事先約定受訪者受訪之人、時、地、物，以及告知預估所需花費的時間。
(E)訪談記錄的標準format。

(2).訪談
(A)約定前五到十分鐘到達與準備。
(B)穿著打扮要得體(注意工程師)
(C)先行詢問可否錄音或記錄
(D)注意訪談的技巧(避免誘導、避免主觀...)與問題的次序性。
(E)受訪結束前詢問是否還有我們應該要知道的
(F)告知訪談記錄交付時間，並請求訪談若有不足或不夠詳盡處，是否可以電話通知或再次見面。

(3).受訪後
(A)快速並有效整理撰寫受訪記錄(受訪記錄的詳細程度與次序應要斟酌)。
(B)先給予會自己公司的內部同事看過。
(C)email給受訪者，特電話告知已寄出，並請受訪者告知記錄中有任何不妥或不當之處！
(D)訪談事項進行分析、歸納，並列入相關的專案議題或追蹤項目。
(E)條列出三到四行的訪談重點email給主管。

(四)一個注意：
對於需求超出合約的部份通常我會如下處理：
(A)刺探需求的重要性跟急迫性。
(B)以客戶角度出發是否有更好的方案。
(C)哀兵政策或博感情。
(D)儘量不當面回絕，會說帶回研究。
(E)針對此點會在訪談記錄作些小小的..。
(F)看程度是否要報告主管。
(G)從其他人再刺探受訪者。
(H)非作不可，那就上呈主管與業務，請他們再去溝通(或要錢)。

以上是肥蝦個人的作法，還請 各位先進惠賜更適當的建議或任何忠告！

題目在精，不在多；解答在求打通任脈，而不是背答案。

肥蝦我喜歡回應好友們關於PMP題目的疑問，因為一方面可以助人外，最主要還是能清楚的明白自己的成長，以及PM觀念與邏輯的融會。

但是近來發現一些有趣的地方與自己的觀念，提出來予大家討論與溝通！

最近我週遭的朋友或網友喜歡上網或到處去搜集題目，花了很多的時間在作題目！但對於題目的來源，以及答案的正確性，似有不求甚解的現象。

朋友們作了很多我以前沒作過的題目，但對於他們拿著答錯的問題，或相關聯性的問題來討論之時，最直接回應：「答案就是這麼寫的！」

一聽到這個回應，肥蝦就想到曾在IT邦幫忙看到一些IT人對於PMP不屑的原因之一：就在於台灣把PMP當作考試，而不是知識。

朋友們拿著回答錯的題目來討論，直接開頭就問：「為什麼是這個答案!」肥蝦起初都是一臉茫然，因為如果友人是說：「他這個答案好奇怪，因為我認為...。」我都會非常高興！因為肥蝦可以明瞭不同人對於同一個題目的想法跟思考模式，我一直認為PMI所推出考試的目的不在讓別人通過考試；而在把較佳的專案管理模式與思維推廣到每個人的心中！

肥蝦近來在看唐納德．高斯與傑拉爾德．溫伯格寫的"從需求到設計(Exploring Requirements: Quality Before Design)"一書，書中主要提到如何去正確認知使用者的需求，如何以適當的方法與工具釐清溝通者間的"語意曖昧"。

這就拿一次與我家兩位小孩溝通的狀況。我說：「一杯思樂冰$10，您們買兩杯，那爸爸給您們$50，那7-11的姐姐要找給爸爸多少錢？」大女兒接口說出：「$30！」，但小女兒馬上反口說：「不對，是$0！」看著她們兩個低頭私語地進去7-11，我跟我內人去水果攤買個水果。過了一會出來後兩個異口同聲地說：「那7-11的姐姐找給爸爸$0！」我看著她們手上只有兩杯思樂冰，沒有別的!結果姐姐說：因為(1)那7-11的姐姐給她們$30(2)而她們決定不把$30給爸爸=>所以結論是：「那7-11的姐姐找給爸爸$0！」

這對專案管理來說也是一個好的例子！當我們在專案中不管在作溝通或者需求搜集，常會犯的一個毛病：就是認為對方應該要懂的，或對方應該要舉一反三。其實整個活動的流程是有兩個步驟的，我已經先預設了我的假設(她們拿到錢就會給我)！這個假設不就也是風險所在嗎?

肥蝦當初雖不是以非常高分通過PMP，但我在意的是準備考試的過程！我是否瞭解PMBOK的邏輯，在題目的選擇上儘量是在精不在多！因此我只作課程中老師提供的題目，以及RITA每章後面的題目！

因為我個人對於題目的認知是：「題目在精，不在多；解答在求打通任脈，而不是背答案。」肥蝦是發現一些友人已經可以一瞄到題目的一句話馬上就知道答案的地步，但真正在管理或參與專案之時有所謂的最佳或標準答案嗎?現實的環境不是一道四選一的考題模擬的出來的。

對於自己以往作答錯誤的題目，會將其先記入於控管的EXCEL表格中，然後到PMBOK、或RITA、或網站、或其他參考書籍找資料！至於上網問問題，也會把自己的想法或思考寫出來，希望獲得的解答是弄通我思考的邏輯，而不是要答案然後去記他。
肥蝦舉一個我以前問問題的寫法：
=======================================================================
Question : The product audit should NOT contain:
A.Project baseline and current project status.
B.Audit methodology.
C.Future change recommendations.
D.Corrective actions

正確答案是D
在TT中有明確audit有quality audits(8.2),risk audits(11.6),inspections and audits(12.5),procurement audits(12.6)。其它有帶到audit字眼的有inspection,configuration management system。其中有明確提到有audit of product應該只有configuration management system。但PMBOK中並未明確說明product audit。
個人以為答案A與B是無庸置疑的！所以就C跟D中選擇的話，個人選C。
因為在PMBOK第190頁QA的Recommended corrective actions有提到corrective action is an action that is recommended immediately as a result of quality assurance activities, such as audits and process analysis.
另外對於答案C個人覺得"future"這個字眼似乎不太適當
=======================================================================

現在呢！肥蝦知道答案為什麼是D了！
因為product audit參考的是Approved Corrective actions，決不會是直接就是Corrective actions！產出的也應該是Recommended Corrective actions也不會直接就去執行Corrective actions！

雖然有人以為這題目在玩文字遊戲，但對肥蝦個人而言，我更深的體認到一句俗諺：「不在其位不謀其政。」這句話在專案管理的應用意義！

以往(甚至現在)在參與專案的過程中，常會覺得為什麼那個人那麼差勁！明明事態就是這麼顯明，就是要這樣作，他為什麼不作！然後就越俎代庖。後續上事態的發展，如果作對了！也許長官會稱讚您，但對專案成員的互動上就有了不良的影響！如果作錯了，那就更不用說了！

專案管理的學習是無止境的，PMP的考試只是其中的一個里程碑，重要的是把這所有學到的一切融入個人的工作與生活中，我想這才不會讓人瞧不起PMP這張證照！

肥蝦的專案"瞎"日誌-邊界難定的範圍界定

這幾天心中不斷地思考著要如何去界定WMONEY應用系統的範圍！其實整個專案的範圍界定最麻煩也是最困難的不在範圍的中心地區，而在如何界定範圍的邊界！WMONEY應用系統為自原有產品進行升級，因此基本的交易自是不可免除，也不會招致爭議。但是如何界定邊界就是明確標明排除條款，講明什麼東西是未來系統不提供的，這就非常棘手！

小甜業務多年來實地接觸客戶，難免的會將一些客戶的"wants"想趁此次的升級加入未來的系統之中。而此次計劃可能採用微軟dotNet的新架構，一把刀工程師也是磨刀霍霍，想趁此次一顯身手，對於一些的作法與整體架構提出他的看法。而當初的收集需求產生的requirements documentation，是在阿強機器人與韓舊都的把持之下產生，此次韓舊都病倒送醫至今未醒，小甜業務也希望能回頭修改requirements documentation。但是肥蝦知道此時回頭再翻版可能引起更多的麻煩與誤會，只得跟小甜業務口頭敷衍的說：「因為requirements documentation已送呈給John協理了，現在此刻，如果沒有重大的理由，不太適合再從頭去修改requirements documentation，可否先討論WMONEY的範圍後再來重新檢視！」

今天討論一開始，肥蝦首先表明：「此次範圍界定的會議我們將依據三月二十八日的會議記錄，逐條的對requirements documentation的需求要件討論！」開會的時候先界定一些規則是很重要的，以免會議偏離了主題或落入意氣之爭的窘境。

經過四小時的討論會議，初步的產生了WMONEY的專案範圍說明文件(Project Scope Statement)。在會議的討論中有兩點肥蝦認為可以寫出來分享給大家的。

(一)功能要求－專案範圍的排除(Project Exclusions)

原系統的功能這部份比較沒有爭議，因為基本上都必須保留。另外對於權限的控管與作業流程的方式上，大家也同意以現有方式為基準。最重要的癥結在小甜業務提到了：「我們客戶常常反應我們目前的系統提供的訊息廣播服務沒有提供編、審、放、移除的權限管理功能，只能單純的把訊息與發佈對象或群組打上去，不符合客戶現有的內控規章，因此希望把權限控管與作業流程功能加入訊息廣播服務。」馬上阿強機器人就提出異議：「我們是交易作業系統(TPS)耶！如果客戶需要這個服務應該去買另外的系統嘛！」其實肥蝦也是限入兩難的境地！因為訊息廣播的功能服務是現有的，可是要作到訊息廣播的作業流程管，可不是如此容易地！加以目前的權限管控是以交易為基礎，並不會再根據交易的內容分類進行管控；而且以肥蝦先前的經驗，這部份將來會因為每個客戶內部作業規章的不同會有不同的修改。因此肥蝦趕緊出面說：「我們在此次的會議記錄先寫下小甜業務的提議，因為正如阿強機器人所說的我們是交易作業系統，因為我們可能要採用新的架構，升級原有的功能服務的風險已經很大了，而且我們採用的是開放的系統架構，也許將來可以開發新的模組的達成小甜業務的建議，但是此次我建議先不考慮在這一次的專案範圍內。」

在PMBOK的Project Scope Statement要項內有特別標明需要列出Project Exclusions，這一部份在如上述"wants"是處於模糊地帶時是非常困難界定的，這就要憑藉一些經驗與知識進行判斷了！

(二)連結資料庫的方式與那個資料庫比較好？－選擇方案的確認(Alternative Identification與Project Assumptions)。

因為原有系統會連結微軟資料庫(MS SQL)，小甜業務說：「微軟的資料庫要成本，有時後客戶會希望我們用自由軟體如MySQL，以減低報價。」阿強機器人可是微軟的擁護派，馬上接著反對：「MySQL如果發生問題怎麼辦？而且用MS SQL已經那麼久了現有的functions都是現成的，不應該換成MySQL。」沒想到平常冷若冰霜、沉默不語的一把刀工程師突然說話：「聽說微軟現在有一種LINQ的技術，可以作到更換不同的資料庫只要變更設定並不需要修改原有程式與語法。」肥蝦心中歡喜著：「我想小甜業務與一把刀工程師所說的，也許我們可以先把它當成此次專案假設(Project Assumptions)，但我想首先要去釐清LINQ的確實功能，如果LINQ真得work那我們就可以不管資料庫的種類了！不過這部份可否請一把刀再去詳細瞭解，我們就先列在專案範圍文件內。

其實很多時後一些選擇方案的採行與專案的假設有緊密的關聯。我們會選擇特定的一個方案通常是基於某些認知或假設，一旦我們選擇了該方案，就應特別列註其所使用的認知或假設，以便去檢測，管理專案的風險。

會議之後，肥蝦得專心整理一下會議記錄，並寫出WMONEY應用系統專案範圍文件。以便進行分割與定義工作包(Work Package)的討論了！

看醫生我會怕！－專案的風險回應與品質控管

最近一年來，發現自己的命盤與木柵x芳醫院與台北xx大學出來的醫生不合，使得我對臺灣的醫療品質有些擔心。自從去年十月輸尿管結石被x芳醫院弄到病假一個半月；日前又因為二月於木柵x牙醫診所特聘x芳醫院的醫生補牙，結果發現所補的牙齒，在把原補的地方打開後內部腐爛了，只得作根管治療。因此個人已徹底失去對台北xx大學的教學與醫療品質的信心，如有友人欲至木柵x芳醫院就診，莫不懇切的忠告個人的案例，希望友人能重新思考。

記得去年在北市衛生局與x芳醫院暨醫師公會的代表調解爭議時，醫師公會的代表醫師所說的一句話：「輸尿管結石手術重點在排除腎的積水，而不是輸尿管毀損；因為輸尿管因手術難免損傷，所以我們會放置雙J導管。」而我的情況是因為輸尿管結石手術後的輸尿管毀損，導致體內感染，因此不禁懷疑台灣的醫學教育不會學習品質管理嗎?還是台灣現在交出來的醫生已忘記病人求醫的目的，在學七年只是一味的記憶跟背誦標準醫療程序(SOP)。

我以為我可用一例來說明我的輸尿管結石的醫療問題。

就像我們執行一個工程專案，依據客戶的需求，擬定專案的目標、工作範圍與風險應對…。

(一)目標：為保障附近居民的安全，防範因為堰塞湖的阻塞，再後續的河水繼續灌注下溢流崩毀。

(二)專案工作項目是：移除阻塞，恢復河水的順暢，將河水導引回原有的河道。

(三)風險疏緩計劃：在專案的計劃時，因為考量執行過程中，可能因為工程影響原有河道毀損，導致堰塞湖的湖水氾流至附近民宅，所以擬定的風險疏緩計劃為加高河道兩側的堤防。

不幸的，因為堤防工程有損兩旁的國家景觀無法施行，但堰塞湖阻塞移除工程還是繼續進行，結果就導致湖水灌入河道附近的民宅。

從上例個人所舉的案例中這個工程專案的執行是否成功?我想大部份人都會同意該專案是失敗的。原因何在？

因為專案管理理論(如：PMBOK第十一章的風險回應計劃)告訴我們：當主要(primary)的風險回應策略無法奏效或無法實行之時，應立刻更換為備援(backup)的風險回應計劃，補救(fallback)計劃或者是Workaround。

當我的主治醫生發現我的雙J導管引起輸尿管動脈微血管出血，移除雙J導管之時，就像例子中的堤防工程無法建置。就個人專案的經驗，如果遇到此等問題之時，而且預估河道好似可以胃納湖水的排放，那所採取的策略應該是隨時緊密觀測原有河道的排放湖水狀況，並設置警示高度，並準備好相關的補救(fallback)計劃或者是Workaround。再就品質保證的角度(如：PMBOK第八章的品質保證)，當發現專案的程序不適用特定的專案之時，並不進行流程改善計劃，執意以以往的經驗一意孤行，結果無法滿足客戶的期望與需求。

再來就我個人就醫的最大期望與需求是恢復身體健康，而不僅是把結石拿掉而已。就如同例子中的工程專案原目標是保障附近居民的安全；而手段(專案工作項目)是移除阻塞，恢復河水的順暢。而工程的實行確是導"果"為"因"，變成以完成手段為首要目標。結果導致河道附近居民身家損害，因此客戶的期望與需求均未達成。

再拿我所補牙的狀況，我要去診所補牙，是希望解除疼痛，且牙齒的形狀以人工材料復原。因此正常的專案流程應該是先把設法原有牙齒內的疼痛病源與污染移除，再行以人工材料回復牙齒的形狀。但該名醫生可能因為專業的經驗與知識，作業執行上缺乏品質控管的應有程序，並未將原有污染移除乾淨，就以人工材料覆蓋其上；或者缺乏應有的專業道德，稍微清除後，就以人工材料復原，給客戶一個表面上的合格的交付物。後續上，客戶在使用交付物，卻引發衍生出更大的災禍。

個人以為就專案的定義來說(臨時性與獨特性)，雖然輸尿管結石手術與牙齒補牙的作業程序都是一樣的，但是每個病人的身心都是獨特的，就向蓋大廈一樣，每個病人的每次醫療診治，都可視為是一個專案。醫生應具備專案管理的思維去進行醫療行為，而不是把醫療視為一個日常重覆性的作業。

醫療關係建立在病人對醫生的信賴度上，也就像執行專案時甲方對乙方的信任是專案成功最重要的基石。如果現在與未來的醫生不能有如像專案管理師一樣的思維，可預見醫療糾紛勢將層出不窮，臺灣的醫療品質將日落江河。

「2009台灣軟體品質與資訊安全研討會」與會後心得感想

本月二十三日與二十四日，筆者自費參加中華民國軟體品質協會所舉辦的「2009台灣軟體品質與資訊安全研討會－採購者與供應者實證經驗分享」，全場共有三十五場的講題，主要區分為流程改善、資訊安全、軟體工程實作經驗與工具。筆者因為二十四日下午另有公事不克參加外，其他時間共參與了九場演講，有幸聆聽先進們的教誨與經驗分享。

這一天半的參與下來，除了由學術單位的教授所講授的內容外，筆者所聽到的均是言必稱CMMI，感覺比較像是CMMI的推銷說明會，而且講課的企業似乎都是特定公司的客戶，其中雖也有IT界的前輩講說精彩，但感覺上無法與胡理事長所稱的：「想建立一個資訊交流平台的願景。」其間似乎落差過大。

個人決無意批評或是挑戰CMMI，IT軟體業導入一個合理且國際化的標準，絕對是有益而無害，但若是太過一家之言，似乎有些遺憾。

個人參與的場次計有：
(1)從ROI談資安技術佈局：臺灣科技大學 吳宗成教授。
(2)政府採購作業發展策略：研考會 簡宏偉高級分析師。
(3)資訊安全管理新思維與新趨勢：中央警察大學 林宜隆教授。
(4)資訊安全管理系統（ISMS）標準化之回顧與前瞻：樊國楨教授。
(5)凌群電腦經驗分享-創造雙贏的軟體專案管理：凌群 陳奇民產品經理。
(6)CMMI-ACQ與政府採購法的整合：寶發 胡詠晴顧問。
(7)精誠資訊- FFPA 軟體規模估算經驗分享：精誠 李克精協理。
(8)協助企業導入CMMI之組織流程改善及度量分析工具：鼎升 劉立堯副總經理。
(9)知識管控解決方案：鈺新 黃鈺峰總經理。

其中個人比較欣賞吳宗成教授、林宜隆教授、李克精協理與劉立堯副總經理四位講師的內容與態度。由於一場次只有短短的四十分鐘，內容上也僅能略為介紹，無法深入討論，殊為遺憾！

至於其他場次的內容，個人有一些淺見：
(1)簡宏偉高級分析師可說是第一天的風雲人物，為人親和，且有多年中央政府二級單位的經驗。但個人自以為是的以自己四年立委助理經驗建議：「簡先生在撰擬國家的資訊採購政策時，應多去基層與不同的單位走走，實地瞭解像鄉鎮公所與中小學校的資訊採購與後續維護作業的困境。」

【資訊採購二級化】雖是立意良善，期望藉由擴大政府資訊標案的金額，讓資訊軟體廠商能進一步壯大。但個人愚昧地以為政府的資訊專案應予分級，中央單位是可以以二級化為思考主軸，地方政府則建議以縣市為單位，國營企業則以機構主體自行規劃為宜。

考量臺灣獨有的文化與軟體產業的架構，應可建立軟體產業縱深的結構，再經由層級間的合縱連橫，利用層級間的競爭與合作不斷的注入新活水。在國際競爭上，以工業局所推導的旗艦船隊模式，擴展一些未開發或開發中國家的海外市場(資訊發展低或類同於台灣的地區)，藉由海外資金的溢注，協助國內軟體產業的發展，以跟上先進國家的標準與規模。

台灣的資源有限，無法全面俱到，但我們的發展主軸為何？則可進一步思考！軟體產業不似硬體廠商，創意與規模經濟之間應作不一樣的思考。個人以為台灣IT軟體產業未來要走的道路不在系統軟體，而在應用軟體。

(2)樊國楨教授的學識涵養豐厚，見解獨到，對於資訊安全標準更是國內第一把好手。但個人竊竊以為您光憑資訊安全的議題，就認為國內廠商發展沒有遠見，國內IT軟體業者無法承接到銀行核心系統的專案是罪有應得，個人以為實在太過偏頗！

俗諺云：「殺頭生意有人作，賠錢生意沒人作。」就光以您所口口稱：「Master卡前次來台主辦的credit card議題，無IT軟體廠商參加」為例，個人以為是您不瞭解credit card的軟體產業結構。台灣credit card的主體是銀行與聯合信用卡中心，台灣的IT軟體廠商只不過是賺賺寫程式或導入國外系統的血汗錢罷了。IT軟體廠商投資再無法預期可獲得報酬的情況下去，進行投資或參與，就產業而言，是違反公司法第一條：「以營利為目的」！

其次，再以您所稱：罪有應得的，因為資安資訊能力不夠，活該接不到國內銀行核心系統的案子為例！後進不當的發言說：「若一家IT軟體廠商給您一千萬，您能協助拿到專案，並開發完成銀行核心系統的資訊安全的部份嗎?」

另外對於協會所舉辦的目的與程序，個人有些建議可供為下次會議主辦的參考：
(1)會議的主軸：個人以為此次會議如要扮演採購者與供應者間的溝通橋樑，則可依據採購者的角色進行區分。感覺上此次的某些場次主要聽講的對象應該是政府單位，如：「CMMI-ACQ與政府採購法的整合」。因此協會應請求政府單位多派員參與！如果是廠商的經驗分享，同一個議題應由多家不同規模與市場定位的廠商發表經驗分享；如果是學產間的交流，則應以會談的方式舉行，而不是學術界單方指導業界要如何發展！並可能的鼓勵【由學者提出理論思考，再由企業加以商品化】的合作模式。

(2)會議的流程：本次研討會的重點在【品質】，整場卻看不到有品質管控的作業或程序，最簡單的如：【滿意度調查問卷】，一天半下來也看不到一張。

(3)整個會場與會的長官、學者，雖口口稱是產官學，但個人實際的感受是學官產，因此感到不免有點悲哀！

以上是個人小小的心得感想，套句樊國楨教授的名言：「如有得罪，還請多多海涵！」

在職碩士班面試感想-"到底什麼是在職碩班的目的?"

上週日，肥蝦跑去世新資管系面試在職碩士班！在面對四位老師的目光下，肥蝦表現的不盡如意，也回答的太直接了！面試的過程如下：

(1)自我介紹三分鐘！

(2)為什麼報考世新？

(3)研讀計劃？

(4)研究方向？

(5)你已經有一個碩士文憑了，為什麼不去坊間的訓練機構？

我答得有點渾渾噩噩，最近的腦袋已經完全被WMONEY系統的開發給佔據了，根本無法想些有得沒得，應付面試官。我是據實回答以上的問題，內容摘要如下：

(1)自我介紹三分鐘！：經濟碩士，銀行資訊軟體產業十年。

(2)為什麼報考世新？：離家近，之前參與一個案子有間接跟 貴系老師合作過。

(3)研讀計劃？：物件導向分析設計、資訊安全、資料探戡與應用、系統資源規劃整合。

(4)研究方向？：系統資源規劃整合，銀行系統繁多，一般銀行欠缺整合的資源規劃。

(5)你已經有一個碩士文憑了，為什麼不去坊間的訓練機構？坊間訓練機構課程已不符所需。

面試官對於肥蝦報考世新的理由最感詫異，也覺得好笑。沒錯啦！我是該亂編一些理由說世新有多好、多好。可是說實在的，除了那位之前間接合作過的世新老師外，先前我帶過世新資管畢業的，只有給我"釘"的印象。真正的問題點是："世新"碩士文憑對我來說又有何意義！我要的是實質的學習收獲！

我要的不是一張文憑(何況我已經有一個國立大學的碩士文憑了)！我要的是加深我理論的基礎跟應用的擴展。外間的一般課程已無法滿足我的需要，肥蝦已經脫離coding或實際設定的階段。在進行系統分析、設計，或專案管理上，我需要的是更進一步的紮實基礎與全面的觀點。問題是這一部份不是一般坊間訓練課程的重點了！記得去年報名的PHP認證班與SECURITY+認證班，只有SECURITY+的老師讓我覺得值回報名價。

也許就像我同事跟我說的：「你怎麼知道在職碩班的課程能符合需求？」但我總得試一試！我希望能從別人的經驗學習所花費的成本，去抵減自己經歷所耗費的時間。

不管此次面試的結果如何？肥蝦追求成長的心態是不會變的！給自己加油！

您賣(買)的是一個"package"?還是"solution"?

上週約了兩位經研所同學在桂林路的家樂福吃個飯，並聊一聊互相的近況。以大家現在工作的年資，都大約是中低階主管的資歷了，最是勞心勞力的一群，每天面對著繁瑣的工作，總會讓人感到心力憔悴。

其中一位同學現任職於xx壽險的放款科長，他知道我在IT軟體產業，他問我一個問題：「一年計息天數基礎(Days in year)為什麼系統不可以提供給使用者參數的型態，讓使用者自行決定，為什麼一定是360？印度的顧問竟敢要求我們修改作業規則去適應他們的系統，這可不是內部的作業規則，而是金管會的規定，放款的計息天數基礎是365。」

我想很多人的第一反應就是那個系統太爛，設計不良！但我不是如此思考！因為該外商的產品可是已經行銷好幾國，問題真正癥結點是出在當初合約的規範！當初xx壽險招標之時他所設定的想法：「他要買的是一個"package"?還是"solution"?」若是xx壽險所要的僅是一個套裝軟體，而且合約或Request for Proposal(建議書徵求書上)未明載計息天數基礎的需求。沒錯，就如那位印度顧問所言：「這是客戶的問題，要求客戶自己處理。」但如果xx壽險當初所要的是一個解決方案，而且合約已有載明系統必須能提供計息天數基礎的參數設定，那這問題就回歸到廠商的身上。

一般人或許以為這個修改很單純，不過改一下數字嗎？但在金融應用軟體上，基層參數與架構的修改可是牽一髮動全身喔！有些金融應用軟體是每日計息，有些是每月計息；計息天數基礎參數有的是所有產品別一體適用，有的是根據產品類別，有的是根據每一契約。這還牽涉到提前還款，解約，逾期…等不同的繳款狀態；而繳款的方式不同－現金臨櫃、便利商店繳款、支票繳納…－也會造成影響。因此這可不是改一個數字就好了的簡單想法。

個人近來忙於北部一家地方性金融機構的建議案，此次我們所提供的是一個解決方案"solution"。本案中我們除了包括一部份系統外，更擔任了系統整合商的角色。在合作的五家廠商中有的是提供套裝元件，有的是需要提供客製化修改，因此專案管理的責任跟風險就在系統整合商的身上。

日前聽說：「永豐銀行已簽約更換現有的Unisys銀行核心系統為Temenos系統。全程以英文為溝通的語言，而且以現有Temenos系統的功能為交付的功能，不進行修改。」若真得如此！則整體風險將在客戶的身上，廠商其實就只有安裝跟協助使用。

從以上的例子，我的客戶要的是一個"solution"；而永豐銀行要的僅是一個"package"。這其中的價格差異可是很大的！屆時永豐銀行在無法更改"package"下，勢必要修正一些作業規則，或者自行在"package"外面加以包裝，以符合實際的需求。

個人先前也曾親身參與過一個國際知名的應用產品廠商的專案。原國外母公司的規定是他們僅販售"package"和協助進行參數設定。但因為台灣的競爭激烈，業務們當成"solution"去賣，以致後續可能必須以非IT的能力去結案。這個就是一個非常大的盲點：「您賣(買)的是一個"package"?還是"solution"?」這跟專案成本跟時程的考量是緊密連結的，也跟專案進行方式與風險承擔更有著天壤之別的差異。

MBA乎？PMP乎？-兩種管理"專業人材"之我見

就業市場一度上紛紛擾擾，很多人在討論企業管理與專案管理孰重孰輕？就筆者自己的觀點：拋開商業利益的糾葛，其實兩者之間並不違背，而且是相輔相成，並且是糾葛難分的！

一般我們都將企業管理概分為：產(生產)、銷(行銷)、人(組織)、發(研發)、財(財務)，現在很多人又把資訊管理列入；而專案管理則區分為：九大領域：整合、範圍、時間、成本、品質、人力資源、溝通、風險、外購，以及五大程序：起始、規劃、執行、監視與控制、結束。

其間的異同何在? 其實這是一個很大的議題，筆者僅能以自己觀點管中窺天，分享自己的看法。
筆者試著從架構面、功能面、執行面來說明為何兩者間無法切割與區分的原因；最後則試舉一例加以說明。

(一)性質面
(1)長度(時間性)：企業強調的是永續經營；專案追求一定時間內完成。

(2)廣度(全面性)：企業管理的目的是追求企業在不確定的環境中追求成長茁壯；專案管理是要求因應不確定內外環境，追求明確的目標。

(3)深度(周密性)：企業管理首要是確立企業使命，設定企業目標，發展策略，擬定戰略；專案管理是在達成目標的基礎上，遵從戰略的指導，因地制宜的擬定執行計劃。

(4)精確(驗證性)：企業使命一般是無法衡量的，目標與策略的驗證一般可能為廣泛性的數字指標，如：營業額、市佔率、稅前(後)純益、獲利率、股東報酬率…。戰略與計劃則應有非常明確的指標，如：客人流動率、坪效、到訪率、實獲值…。

(二)功能面：
就個人對企業管理的初淺知織，針對企業永續經營的目的作了如下的企業思考與行動的功能結構層級。
(1)使命(Mission)：企業在全球社會中所要扮演的角色。

(2)目標(Target)：企業在使命的驅使下，所要達到的預期成果，可再細分為短、中、長期目標。

(3)策略(Strategy)：為達成目標，因應內外環境的限制與挑戰，整合內外部資源，所訂定的認知地圖。

(4)戰術(Tactic)：在認知地圖的引領下，取得局部領域優勢的可實行方案。

(5)作業計劃(Executive Plan)：執行特定方案的細部執行步驟。

(6)作業程序(Executive Procedure)：執行日常經營活動的執行步驟。

針對已上的企業經營思考與行動的層級，專案的定義在那裏呢？
根據PMBOK 2008對專案的定義：臨時性的(Temporary)，產出獨特產品、服務、或結果(Unique product, service, or result)。因此一般將專案鎖定在作業計劃(Executive Plan)的層級。

但讀者若跳脫臨時性的(Temporary)的特定跼限，以PMBOK對臨時性的(Temporary)的定義：明確的起始與結束時間(definite beginning and end) 則依據結構中對目標的說明，如企業能進一步把短、中、長期明確界定期間(如：一年、五年、十年)，在明確的期間，達成特定目標，這不就是專案的定義嗎？因此在PMBOK 2008的第八頁圖1-1Protfolio, Program, and Project Management Interactions 所表示的三個層級不就正好對應的策略(Strategy) 、戰術(Tactic) 與作業計劃(Executive Plan) 。

(三)執行面
企業管理有六個面向(領域)－生產管理、行銷、組織管理、研發、財務管理、資訊管理；在專案的九大領域中的整合與外購不是就要生產產出，與購入生產過程中需要的產品、服務、或結果，這不是跟生產管理的部分理論雷同。因此筆者依據專案九大領域，排列了一個需要應用到企管六大領域專業知識的對應表。
(1)整合：生產管理、行銷、組織管理、研發、財務管理、資訊管理。
(2)範圍：生產管理、行銷、資訊管理。
(3)時間：生產管理、資訊管理。
(4)成本：生產管理、財務管理、資訊管理。
(5)品質：生產管理、資訊管理。
(6)人力資源：組織管理。
(7)溝通：行銷、組織管理。
(8)風險：生產管理、行銷、組織管理、研發、財務管理、資訊管理。
(9)外購：生產管理、財務管理。
因此一個專案的執行，需要仰賴企管六大領域相關的執行理論與技能。

(四)舉例
ABC有機食品商，立志成為社會中每個家庭的安全、健康的補給站(使命)，因此立定了為期三年的公司目標：「以更豐富、更天然的(50種)食品照護到更多的家庭(1萬個家庭)。」因此總經理擬定了行銷策略與生產策略。在戰術上可能選定人口八十萬以上的都會區為集中戰場，利用宅配與網路的通路，以達到市佔率30%；為強化產品優勢，可能希望建置中央供應站或中央廚房，提供五十樣以上的天然食品。
同樣地我們也可將為期三年的公司目標：「以更豐富、更天然的(50種)食品照護到更多的家庭(1萬個家庭)。」設為一個專案許可證(Project Charter) ，進行一個大型專案(或可稱為Portfolio)－臨時性(為期三年)，獨特結果(提供50種天然食品，給1萬個家庭)。