【破窗】"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或相關性的依存關係。

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