肥蝦的專案"瞎"日誌-龐大混亂的Organizational Process Assets

肥蝦為了找WMONEY原系統的文件，可說是千辛萬苦！問阿強機器人：「是否有保留原有相關的文件，而且後續的變更是否有繼續更新？」答案當然是沒有！問俠女：「您有印象嗎？」「有！但是原先的負責人到現在已轉手了三次，現在交接給誰要想想看？也不知道有沒有交接清楚？」最後，終於在最不相關的阿基姐的櫃子的深處裏給挖出來了。

不知道別的公司對於建置專案的標準流程與作法，以及以往的專案資料是如何管理的？肥蝦所”呆”過的公司ㄚ！不多，但不管在那家，每次問起來公司是否有既定的專案標準流程，以及可以參考的歷史資料，每個同事都說的有條有理，只是每個人的說法都不一樣！問起是否有以往的歷史資料，也都找的到，只是數量龐大，沒有整理，資料大小動不動就上G，而且不保證正確喔！

基本上，肥蝦以為專案的組織流程資產(Organizational Process Assets)就是指所有針對專案發展中的流程與決策相關的政策、準則、手冊、範本、要求與作業程序等規範，以及以往的專案程序所產生的資料、資訊、文件、程式碼、報告、記錄，這些統稱為專案文件(Project Document)暨公司內部的相關資料庫等。這些均是有助於後續專案應用與發展的所有軟性資產。

有時候，肥蝦的一些專案管理道友，會被組織流程資產與企業環境要素(Enterprise Environmental Factors)兩者的界限搞迷糊。其實肥蝦認為其間的判斷依據很簡單。組織流程資產與企業環境要素(Enterprise Environmental Factors)的不同點，就是企業環境要素是所有影響專案，但不涉及”此次”專案發展程序內部作業的所有企業內、外部影響因素。比如說：政府與業界的法規或規範，公司整體的文化、架構、程序，公司的既有軟、硬體設備，現有的人力資源，公司的授權方式，市場的情況，公司現有的專案管理資訊系統…等等。組織流程資產就是以往(/現在)專案開發被要求遵守的公司政策、標準與作法，以及其所衍生的相關資訊已轉化為可再次利用與應用的知識。

組織流程資產又包括兩大部份：(一)流程與程序(Processes and Procedures)與(二)公司知識基礎(Corporate Knowledge Base)。此外，組織流程資產在專案的監控(除整合Integration的程序外)與結案流程群組中，常常因為實際的執行狀況，而不斷加以更新，以達到資產的可用性。在執行流程群組中的品質保證、管理專案團隊、與傳播訊息暨管理利害關係人的期望，也會因為狀況而加以更新。因此組織流程資產在專案的整個管理週期中是非常重要的投入或產出，僅有少數如：收集需求，驗證範圍，發展專案團隊等程序未參考。

雖然最終是找到了原WMONEY系統的相關文件，但加起來一共有80M，沒有索引目錄，不保證資料的正確性，更遑論專案管理的相關資料。天ㄚ！這可真讓肥蝦，一個蝦頭十個大囉。

肥蝦的專案"瞎"日誌-千頭萬緒的專案管理計劃

週一了！所謂「人無遠慮，必有近憂！」眼看著阿強機器人與韓舊都只顧埋頭作著自己原有的工作，一點都也不管WMONEY系統的升級案。說實在，肥蝦的心頭有點不是滋味。

我要如何繼續進行John協理的交代呢？看看自己手頭上有的東西：(1)Project Charter：3/26的內部會議記錄。(2)Identify Stakeholders：目前只有John協理、阿強機器人、韓舊都、小甜業務、一把刀工程師。不知覺的！肥蝦的眼角泛著悽苦的淚水。不管了，凡事起頭難！接著著手下一步的規劃。

想想自己以前上過的PMP課程，發展專案計劃(Develop Project Management Plan)的投入中有一個【所有其它規劃流程的產出(Outputs from planning processes)】，課堂上把它放到規劃的第一個程序，肥蝦感覺上是顛倒了，應該是要先把所有規劃程序都作過一個循環，才能到發展專案計劃，也才能藉由專家的判斷(Expert Judgment)的協助產生專案管理計劃。難怪人家會說：「通過PMP的認證，不代表他就會執行專案。」

但肥蝦認為這講法有點初淺了，因為一個邏輯必須要能清楚的交代難免會有講解上的順序，但是專案管理可是要靈活應變呢！肥蝦肥是肥，但是還蠻靈活的！尤其這個蝦腦，還蠻能解決問題的。

把心一橫，自己可不能受阿強機器人、韓舊都的影響。首先！我要設法跟阿強機器人與俠女，索取當初WMONEY系統的需求規格書與建議書，設法釐清原有系統的需求界定－功能與非功能的需求。再者，設法參考網路上的同一性質應用系統的簡介，正是所謂：「知己知彼，百戰不殆。」肥蝦如果無法先界定新系統所要包含的作業範圍與要求，那後續的WBS、時程、人力…等等一切皆無法規劃！

加油吧！「肥阿，肥阿，小肥蝦！在那IT邊緣拚命的掙扎…。」

克服專案的限制-「關鍵鏈(Critical Chain)」

本書是物理博士與企管顧問高德拉特(Eliyahu M. Goldratt)先生，將其理論TOC(Theory of Constraints)應用到專案管理的一本著作，天下文化於2002年出版。Critical Chain在PMBOK明有記載，但僅強調其與Critical Path的區別，在於考量投入資源的有限性。這短短幾句話引起了筆者一探究竟的念頭。

在限制下追求極大化，對我來說好像回到大學時念經濟的基本課程一般，該方法論已是建構個體經濟供給曲線(在既定成本下追求最大產出)，與需求曲線(在所得限制下追求最大效用)的基本出發點，因此該理論的基石對我不是新穎的理論。但是高德拉特先生的一句話點醒了筆者個人思考的關鍵點：「成本世界(Cost World)」與「有效產出世界(Throughput World)」的區別。

在我大二時的個體經濟學的推導中，在（有效產出世界）「既定成本下追求最大產出」與（成本世界）「在既定產出下追求最小成本」兩者間是同義的；但在本書中強調「成本世界」的思維與「有效產出世界」是迥異的。因為專案獨特的特性，完全是「有效產出世界」的產物，因此從事專案的人士，必須不同於一般人所早已習慣的成本世界思維去管理專案。

那麼成本世界與有效產出的思維差異在那裏？「成本世界」的要點在於生產過程中每(任)一環節只要能有效節省成本百分之一；那整體專案也同時節省成本百分之一。「有效產出」的重點在於生產過程中最弱的環節增加產出百分之一；那整體專案才能增加產出百分之一。

針對一個追求有效產出的專案，要如何解除制約的束縛呢？「關鍵鏈(Critical Chain)」陳述了五個步驟：確認制約(Identify the constraint)、有效剝削制約(Decide how to exploit the constraint)、其他一切遷就制約(Subordinate all other processes to above decision)、鬆綁制約(Elevate the constraint)、回頭重新檢視(If the constraint has moved, return to Step 1.)。

(一)確認制約：制約可分為：(1)有形的實質限制，如：關鍵人力、資源、過程，以及(2)無形的限制，如：錯誤的決策。因此首要工作是找出最弱的一環，就是要【聚焦】。
(二)有效剝削制約：設法創造制約的最大產出，如：設法增加有效的人力投入，有效安排最弱環結的生產順序與流程…。
(三)其他一切遷就制約：在整個生產流程必須因應剝削後的制約進行改變，如：重新安排作業流程，設立特定的中繼點與監控點…。
(四)鬆綁制約：此時原有的制約可能已不再是最弱的一環，因此可以解除對該制約的所要持續投入的關心與資源。
(五)回頭重新檢視：再重新回到步驟一，重新檢視整個生產流程，再找出最弱的環結，進行步驟二到步驟五。

此外書中有幾個有趣的探討，也值得在此列舉：
(一)問題衝突的階級性：「員工職位愈低，矛頭愈是指向公司內部，而不是外界。」專案並不是一個重複持續性的工作，階級式的強迫管理，往往將問題推諉與上一階層。

(二)專案管理的盲點： 「一條路徑的進展，可補償另一條路徑的延遲。」但是專案可是在最長的一條路徑完成後，才算完成。

(三)有效評量的要求：如何化解問題衝突與管理盲點？

有效的評量方法要求：

(1)評量方法應誘導系統各部分做出對系統整體有益的事。

(2)評量方法應引導管理人員注意需要注意的地方。

(四)時程估計的陷阱：本書提出時程安全係數的三個盲點：

(1)預估時間是根據以往慘痛經驗來制訂，即機率分布曲線的最末端。

(2)涉及的管理層愈多，預估時間總數愈大，因為每一階層都會加進各自的安全係數。

(3)為防範高層刪減整體完工時間，執行預估者會灌水自保。

(五)安全時間(Buffer)的浪費：如上述所估計出的時程為何還不夠用？

(1)「學生症後群」：不用急，所以到最後一刻才動工。

(2)多重任務。

(3)各步驟之間的依存性，導致延遲的累積。

(六)專案緩衝的安排：如何縮短高安全係數的時程，並能避免時間的浪費？

(1)接駁緩衝：針對步驟依存性。

(2)資源緩衝：針對資源有限性。

(3)瓶頸緩衝：針對必要程序限制性。

(4)專案緩衝：針對整體專案性。

針對所有的緩衝，都必須要作到有效的監控與警示。

(七)投資成本的判斷：成本的投入是包含金錢與時間兩個面向，以時間為單位的還本期(Payback Period)，以金錢為單位的淨現值(Net Present Value) 均不能完整的代表書中提出了元-日(dollar-day)的觀念。

個人認為以上的諸多觀點，除了元-日(dollar-day)的評量標準外，其他均是可立即納入專案實務的思維之中。元-日(dollar-day)的觀念雖然清晰易懂，卻缺乏足構的應用工具，以及與會計暨財務部門間的共識，不易採用。以上為個人對「關鍵鏈(Critical Chain)」乙書的心得感想，還請 多多指教！

肥蝦的專案”瞎”日誌-到底誰是我的利害關係人

今天下班前，John協理突然地走進我的辦公室，「我們開個會吧!去把"阿強機器人"與"韓舊都"叫來一起到我辦公室！」「難道是要"如期"的開會討論WMONEY的升級案嗎?」已經準備打包落跑的我心裏想著。
阿強機器人、韓舊都、我與John協理一起圍著會客桌前坐著。John協理一般在討論事情時不會坐在他的龍椅上，因此相處起來感覺像兄弟一樣；但他一定坐在內側，並保持一定的距離，以顯示與我們間的地位差距。

John協理開口說道：「大家都知道我們的WMONEY系統已經五、六年了，也需要進一步的升級。那WEB是目前的趨勢，因此我打算將其改成WEB的架構，不知道大家有什麼看法？」大家一陣沉默，我只好開口回應道：「協理您希望我們先作些什麼事?是不是以現有的WMONEY的功能為範圍？」協理說：「我們要作的是升級，基本上以現有產品功能為範圍。我希望您們下星期給我一個開發所需的人力、時間、資源的分析報告。」阿強機器人接著說：「一定要改成WEB嗎？是現有客戶要我們改成WEB嗎？」協理回說：「是的，我們不能要業務拿著老東西一直賣呀！WMONEY的開發你都有參與，還希望你多付出點心力。你很聰明，反應很快，雖然文件撰寫的能力有點不足，但是肥蝦可以幫你。」協理接著說：「大家也知道我的管理模式，我不認為事情由官階高的決定，而是懂的人作決定，因此希望你們要多密切配合。」韓舊都接著問：「是否一定要用dotNet的Solution？還是J2ee也可以？」協理說這沒有定論，那你們就作一下分析好了。下週四連同人力、時間與資源的估計報告一起討論。」協理回應的像是會議要結束了，那我趕緊說：「我覆述一下今日會議的結論，我會寫成會議記錄，於明日交付給各位。」在肥蝦的公司文化中，我們的PM在內部研發的案子上，比較像是Coordinator(協調者)或是Expeditor(督導者)的角色。我還是要把此次的會議記錄當作個"Project Charter"，最少可以拿著小雞毛，達到PMBOK所說的第一步(Develop Project Charter)。

阿強機器人、韓舊都、我一起走進我的辦公室。阿強機器人首先發難：「一定又是業務在搞鬼，你跟我說WEB跟FORM的那一個比較優？WEB不過是搞些噱頭，騙客戶。」韓舊都說：「沒關係，反正等肥蝦把報告寫出來再討論。」「芭樂你個香蕉！又再推。」我心裏罵著，但嘴巴笑笑的說：「沒關係啦！我們先從操作功能與業務功能兩個面向，去分析現有的產品，釐清Client-Server所扮演的角色，然後我們再來看WEB能怎麼作。」韓舊都趕緊開口說：「我對業務不懂耶，dotNet我也不會！那請機器人先列出清單再討論。」阿強機器人說：「WEB跟Client-Server有很大的差異，絕大部份都不能REUSE。」我趕緊笑說：「沒關係啦！我們先把分析與比較的功能清單作出來，再來一步步檢測那些要重寫，那些可以REUSE，那些可以部份REUSE。我們可以儘量試著把修改的重點放在Client的部份，現有Server那邊儘量REUSE。」「叫業務去死！」機器人狂叫著。韓舊都說：「有些現有功能要放棄，協理不是說分階段開發。」哇累！「協理有說這句話嗎！」我心底快速地回想會議狀況三次。我還是得笑著說：「Open Mind一點，大家多少替業務想一下嗎！」一下子兩者一起圍攻我！「沒有啦！我是說我們先列出功能清單跟WEB的對應作法，以及WEB要走的架構，讓協理去決定嗎。」舊都一口說：「我跟機器人的觀念比較一致！」說著邁著堅定的步伐走出我的辦公室。

唉！PMP真是沒學到家，拍不到馬屁。我下一步該怎麼作呢？我不能讓案子被技術人員拉著走。PMBOK第二步：鑑別利害關係人(Identify Stakeholders)。這是一個內部研發案，協理是sponsor，也是最最重要的Stakeholder。那其他的Stakeholders呢？業務是一定要把他們給拉進來，這可攸關他們未來的生計。另外，可不可以在開發的適當時間把一個關係優良的客戶給拉進來呢？其他未參與本案的原有技術人員呢？技術的轉變有可能會引起他們的反彈。有些原產品的配合廠商我要不要考量他們呢？公司內部其他部門的WEB技術專家呢？我得好好想一想，並作一下分析。明天我得去請教一下俠女，問她一下以前當初原產品開發時的組織架構。再找個機會私下跟協理再作個溝通。

肥蝦的專案”瞎”日誌-難產的專案許可證

終於舒了一口氣，把"MAYBESUC"建議書趕出去了。一份建議書，歷經了一年，換了兩個專案經理的一份建議書，終於在我這第三任的手上交出去了。在這短短一個月之內，在只有前手留下被抱怨的紙本建議書的基礎上，把客戶需求，相關的軟硬體架構、功能與合作廠商的建議規格，在不斷的探詢、分析、溝通、整理與融合下，終於寫出一份七十二頁的建議書、161項的功能清單與一份全開的網路示意圖，並且八八九九的底定下來。幸好客戶是跟我們公司往來了近二十年的老字號，合作廠商也有配合的經驗，雖然被不斷抱怨，但大家都很配合，終於在上星期五交付給了業務與管理部門的手上。後續上，將由管理部門的"俠女"負責詢價；"小田田"業務負責交付給客戶，我就是等通知，配合著行動！

還記得星期一早上七點多。正躲在公司後陽台抽著我的兩節濾嘴的Marlbore，正在怡然自得之時，突見我的老闆也拿著煙盒出現在我的身後。John協理是一個個性溫和、待人和善的主管，早期DOS時代的技術背景出身。John協理和氣的問著：「我看到你寄出的建議書了，已經交給俠女去詢價了嗎?」我口頭回答：「是的，也寄給業務了」心裏卻納悶：「我不是都CC給您嗎?而且公司的sometime-non-Exchange Server還寄給我"John已讀取"！」心裏正在犯著嘀咕。果不其然，John協理開口說：「公司的現有主力應用軟體-WMONEY-是用VB開發Client-Server的架構，也已經五、六年了，雖然功能不斷增進，但最近被客戶要求升級的壓力愈來愈大，應該要作大幅升級改版了。你有什麼計劃？我想呢！用DOTNET的架構去開發一個WEB BROWSER的產品，你認為呢？」我那能認為什麼！只能順水推舟諂媚的說：「是ㄚ！協理我們是應該升級了，加上原產品並沒有留下完整的規格與設計文件，正可趁著這次一次弄齊，以免公司人員進進出出的，對公司有個什麼閃失。」講歸講，心裏卻是一陣惶恐ㄚ！聽以前的前輩說：「WMONEY想改WEB架構已經講了好幾年了，但因為牽涉廣泛，上面一直都沒有定案，加上WMONEY的架構龐大，功能又雜，人員異動，又沒有文件，因此都只能嘴巴講講！」John協理滿意的點著頭說：「那好，這個星期四或五，找你跟"阿強機器人"、"韓舊都"一起開個會。」

此刻掐掐手指算來，已到了星期四，偷偷地問了"阿強機器人"、"韓舊都"有沒有聽聞此消息！兩者是一口回應：「肥蝦ㄚ，你走運了，是第一線消息喔！」"哇累"，這情況又發生了！公司除非是有"貢識"(老闆的老闆的意識)的案子，不然是不會成案的！也不可能在管理部門成立"案號"，這可叫我怎麼辦！當聽見？還是沒聽見？沒有"帥字旗(Project Charter)"，怎麼擬定作戰計劃！怎麼組織軍隊！那裏找糧草供應！我的好協理，您只跟我說我要消滅的敵人(Business Case)在那裏！難道您要我單螯匹蝦，拿著石頭去K嗎？

百加資通「線上多專案管理操作體驗營」參加心得

今日至台北縣電腦公會參加百加資通所舉辦的「線上多專案管理操作體驗營」。全場約有十五個人左右吧！感覺上有資深的專案管理人、有剛畢業的資管高材生，因此感覺上，此次體驗營的目標對象很參差。而產品的特性，也是針對一般專案管理的作業，目標客群應該是一般的中小企業，或是有比較標準作業流程的產業。收穫是有；但說實在地，跟原先的預期有些差距。不過這不能太過苛求，因為IT應用軟體，當在鎖定特定的目標時，其實就已經給軟體的應用範圍設限了。

此次的體驗營，區分為兩個階段。第一階段是廖文祥顧問簡單說明了專案管理的現況與面對的問題；第一階段是林崇仁專案經理介紹PM-PLUS的操作。

就第一階段而言，廖顧問所說明台灣專案管理的現況，是在基本流程(可重複的)，正試圖邁向可重複流程(定義良好的)的境況。這個說明個人深敢贊同，但對有標準專案作業流程的產業來說應該是已達到可重複流程在往更高階的發展前進中；對IT產業來說，我認為很多還在基本流程掙扎。

第二階段PM-PLUS的操作說明，個人以為對一些公司的管理者來說是有一定的幫助；對專案經理在掌控內部成員的訊息溝通，以及文件處理也有很大的作用；對公司內部專案經驗的傳承上，因為能保留相關的資料也有某些程度的貢獻。

以下重點說明個人對該產品的感想。

(1)首先PM-PLUS能整合MS Project, Freemind, Gantt Project；而且匯出檔案能以多樣的型態呈現，這一點就值得給予肯定。

(2)在使用友善性上，對一個WEB界面的操作，能作到此等水準，已算不易。但受限於WEB平台的操作，要作細部的設計有先天的限制。

(3)在專案進度的呈現上，也有報表與圖形的表現方式，使得進度的展現也很生動。

(4)在專案文件的掌握上，有文件版本管理、訊息發佈、工作日誌等編輯界面，也能符合一般專案管理的需求。另外的高級版”Project-PLUS”，有電子表單與表單簽核等功能，更符合一般的現況。

以下個人就個人從事IT的背景，認為也許可以繼續強化的地方。

(1)PM-PLUS除了進度外，成本也由成員回報，這是個人所接觸的專案中比較少碰過的。一般上這會由會計部門的事後資料、管理部門的費用管理，以及人事部門的薪資成本所彙整而成。以往個人甚少從成員口中，獲得成本的相關資料。

(2)缺乏要徑的掌控。PM-PLUS只能顯示所有TASK的延宕，或已選定特定重要TASK的進度，如此易造成專案管理的假象。

(3)風險與議題的管控與處理上太過薄弱，建議此部份也許可以藉由整合的方式，或得進一步的提升。

(4)品質與外購的管理上則付之厥如，甚是缺憾。

(5)對於專案訊息內容的處理上只有原貌呈現，缺乏相關的資訊篩選、整理與彙整的功能。

簡而言之，PM-PLUS算是一套簡單版的專案管理資訊系統，對於範圍、時程、成本、人事管理與溝通有著基本的作為；對於呈現專案的結果表現上有一定的功效。但對於專案管理裏面所強調的決策處理過程，風險的鑑別、分析、處理與追蹤上則非常薄弱。

以PM-PLUS的價格來說，算是非常誘人，但最終還是在於現今您是否瞭解您所面對的處境中，您所需要的功能！“專案管理資訊系統”雖然重要，但切勿使得PMIS成為專案管理的累贅與包袱才好！

Risk Response Plan, Contingency Plan and Contingency Reserves

上週，正在準備PMP考試的J經理問了我一個問題：「對於Risk Response Plan, Contingency Plan and Contingency Reserves間在PMBOK 2004裏面所闡述的定義與彼此的關係。」

到底什麼是Contingency Plan?筆者想也許有些人也有著同J經理一樣的疑問，因此把個人的心得與各位同好分享，並請 多多指教。

在PMBOK2004裏面，我們可以看到關於”Contingency”的字眼散佈在：
(一)第四章
-(Contingency Plan:page 77)

(二)第六章
-(Contingency reserves:6.4.2.5)
-(Contingency reserves:6.4.3.2)
-(Contingency Plan and response plan:6.5.2.4)
-(Schedule contingency reserves:6.5.3.2)

(三)第七章
(Contingency cost:7.1 page 161)
(Contingency allowances& Contingency reserves:7.1.2.7)
(Cost contingency reserves:7.1.3.1)
(Contingency reserves:7.2.2.2)
(Management Contingency reserves:7.2.3.2)

(四)第十一章
-(allocate general contingency:11.1 page 240)
-(Contingency reserve:11.3.2.2 page 252)
-(Cost and time contingency reserves:11.4.3.1)
-(Contingency reserve & Contingency plan:11.5.2 page 261)
-(Contingency reserve:11.5.2.3)
-(Contingency response:11.5.2.4)
-(Contingency reserves & Contingency plans and triggers:11.5.3.1)
-(Contingency plans:11.6)
-(Contingency or fallback plan:11.6 page 265)
-(Time and cost contingency reserves:11.6.1.2)
-(Budget and schedule contingency reserves:11.6.2.5)
-(Contingency plans and workarounds:11.6.3.2)
-(Contingency plans and workaround plans:11.6.3.3)

筆者先說明Contingency Reserves跟Contingency Plans的差別。

(1) Contingency Reserves因為不明確或無法確定的事項，而且無法有確定的預防作業、方案或計劃所以預留了一些的資源。

各位可從PMBOK第十一章第240頁的說明得知Contingency Reserves的用意。
(Known) Unknown risks cannot be managed proactively, and a prudent response by the project team can be allocate general contingency against such risks, as well as against any known risks for which it may not be cost-effective or possible to develop a proactive response.

因此如果一個risk的response是非常明確的那就應該把這些response plan的activities，納入現有的WBS並安排相關的時程與資源。因此在11.5.2.3的說明一般主動的接受策略，會建立Contingency Reserves。

※針對Unknown Unknown risks所預備的資源，為Management Contingency reserves ，其不包含在cost baseline內，但包含在budget內，此處不深入討論。

(2) Contingency Plans則是說明一些風險回應計劃的執行，是等待特定的事件(event/trigger)發生，才會執行。

因此我們可以把risk response plan作如下的區分(參考PMBOK page 261、263、264)：

(a)Primary plan:主要的應對策略所發展出的明確應對計劃。

(b)Backup plan:備用的應對策略所發展出的明確應對計劃。

(c)Fallback plan:因為所執行主要/備用策略所發展出的明確應對計劃失效下，或可接受的風險發生，所要執行的明確應對計劃。總而言知，就是應對計劃失敗所要執行的計劃。

(d)Contingency plan:事先規劃等待特定event或trigger發生所要執行的明確應對計劃。

(e)Workaround plan:事先沒有規劃但因為特定event或trigger發生所要臨時執行的應對計劃。

那風險的應對計劃於執行後可能會有兩種風險也必須說明一下

(a)殘餘風險(residual rsik)：應對計劃執行後與百分之百迴避風險的效果的差距。

(b)二次風險(secondary risk):因執行應對計劃所衍生新的風險。

因此由下列策略─avoid, transfer, mitigate, exploit, share, enhance─所產生的明確的風險回應對計劃，是不應該產生Contingency reserves or plans，而是應納入專案的計劃與WBS內，並排定schedule與cost，在專案計劃與執行就一體實行的。這也呼應了筆者於2009/2/10所發表的"PMP到底實用不實用"的內容。

"IT業務人員"與"網路行銷人員"的差異在那裏?

昨日有幸聆聽某網路行銷公司"F"總經理介紹他的一個新點子。"F"總經理強調跨媒體的整合傳播、虛擬與實體的互搭，藉以推廣一個網站。他的演說讓我立即想起十年多前還在立法院擔任國會助理期間，所聽過吳祥輝先生的演說。兩者風格神似，但沒有吳先生如此強烈與鮮明。

筆者僅以一個IT人員、專案經理與經濟分析的觀點，以及個人對於網路行銷的KNOW-HOW只停留在書本的知識暨參與半段選舉的經驗，來發表個人小小的看法。

就IT人員來說：對於"F"所述及的網站，在技術上沒有問題、也不新穎，只有"錢"的考量；在網頁呈現上，也缺乏如YOUTUBE或AMAZON的人性化。

在專案上：目標雖然明確，流程也算合理，但全無考量風險的議題。

在經濟觀點而言：沒有SWOT分析，沒有成本效益分析，忽視Constraints，誇大Maximum。

就個人薄弱的行銷觀點：個人認為網際網路有所謂”外溢效果”，但卻難有收斂的成效；對物流與金流，以及日後產品服務的想法太過簡化。

因此個人作了些IT業務人員與網路行銷人員的分別：
(1)客戶對象
IT業務人員：客戶多具有一定的IT常識。
網路行銷人員：客戶的IT常識多較薄弱。
(2)售後服務
IT業務人員：怕客戶找上門。
網路行銷人員：先設法把客戶引進門。
(3)推銷能力
IT業務人員：優點宣導－我有的，別家不一定有。
網路行銷人員：宗教宣導－信我就對了。
(4)庸金思維：
IT業務人員：有賺才有的分。(當然有的是賣出就分)
網路行銷人員：賣掉就分。(當然有的是賣不掉也要分)
(5)思考邏輯：
IT業務人員：一般作法是滿足客戶需求，進而引導客戶需求。
網路行銷人員：一般作法是引導客戶需求，進而創造客戶需求。
(6)表達方式：
IT業務人員：分析舉例式，我的東西一定符合需求。
網路行銷人員：條列作法式，照著我說的作就對了。

因此兩者間的邏輯思維與能力要求並不一樣，筆者發現在IT邦幫忙中有一個回答(pluto)個人覺得蠻妙也蠻貼切的：

萬芳醫院對面有家牛肉麵店, 路過的人多,店家請了兩個人在店門口吆喝: "來唷, 不好吃不用錢."
客人一上門, 店小二就招呼說: "客倌吃點什麼, 這兒最有名的是貓耳朵(麵疙瘩)"
吆喝的就是網路行銷人員, 店小二就是IT銷售人員.
吆喝的只管招呼客人進門, 店小二只管多賣些餐點.

您認為呢?

淺論學習專案管理之方法

筆者為學習相關的Know-How，曾上過下列課程:
前進國際：「軟體開發專案管理實戰班」。(2002年)
展頡：「專案管理培訓課程」。(2003年)
遠景：「國際專案管理師認證班」。(2008年)
個人抱持的一個觀念就是"他山之石，可以攻玉"！除了自我經驗的累積外，也想瞭解別人的經驗，以及理論上的說法。
對於一般坊間PMP認證課程，多僅能解說PMBOK所記載的WHO(STAKEHOLDER)、WHAT(ITTO)與WHY(PROCESS FLOW)！至於HOW、WHEN與WHERE是不可能在課堂講解的！"管理是一門藝術"，對於完整的專案管理是沒有一個絕對的答案與作法，只有METHODOLGY。因此在專案管理技能的養成上，就要靠自我經驗累積與不斷理論學習，互相對照，結交志同道合的同伴追求成長。
(一)自我學習
自我的專案經驗學習很重要，但以往個人參與的經驗發現一個很有趣的現象！
之前我有一個"D"上司，RUN 五百萬元以下的專案時，作的不錯；到了一千五百萬的案子時，問題百出；到了金額更大的案子就掛了！我私下分析了一下原因，(1)自我學習有一定的速度。(2)大多的人很難自我突破一些個瓶頸。
因此個人以為外在理論的學習是有一定幫助，除硬性的專案管理教科書籍外，坊間的一些軟性書籍-"與熊共舞"、"人月神話"、"最後期限"、"關鍵鍊"...-是有一些幫助的！
分享另一個案例：先前小弟有一個朋友本身是ORACLE的DBA(當然他通過PMP)，在美國有近五年的領導專案團隊經驗，因家庭因素回台，結果請去參與一個政府網頁二百萬的案子，被PHP的程式設計師搞鬼！PHP的程式設計師說他執行公司很多專案很久都沒問題，但是結果是一直DELAY，被客戶抱怨(不然老闆怎會找我朋友去)，照此情況那個PHP的程式設計師是否能從自我的經驗學習！說實在我很懷疑？而且他是否能有機會繼續學習呢?除非學習那個PHP的程式設計師，拒絕交出文件，沒人知道他在作什麼?但我想每個老闆的忍耐是有一定限度，也沒有很多老闆願意花錢跟名聲給我們練案子！
"成功是來自99%努力,1%天份"。如何自我學習？從生活中作起，就是把您參與中的專案或者您生活中的專案，照著PMBOK的要求作一次！
比方說我的sponsor(河東獅王)要求我於四月春假帶全家去玩個三天二夜，我最重要的stakeholder是另外我家兩頭小獅。如此就有project chart，接著把整套的PMBOK搬出來玩玩看！這種磨練方式，對於自我的成長將有一定的助益。
(二)專案管理資料庫
Project Management Knowledge Management System(KMS)。知識的分享在同一個團隊中甚至同一家公司都很難作到！不是系統難建，而是利害相關的人大都比較藏私！後來都流於型式，最大的理由就是"自己的工作忙"！加以現今很多IT老闆可能是以前的SUPER PROGRAMER或是一流業務，大多好像對專案管理欠缺認知，也缺乏文件化的能力。現在很多IT公司都說是CMMI 3或有ISO，但試問真正將其內化為自身成長動力的有幾家？我想很多公司都是因為要標政府的標案，才去申請。但不可誨言，這當然也是一個好的開始，對於建構專案管理資料庫也有著莫大的幫助。
但是因為每個人與每個專案都是有差異的，不可能把別人的經驗照樣複製一遍，就可以當個好的專案經理。因此從外部搜集(或用買的)，也必須轉化成公司內化的知識，而不是文抄公一般。內建的工夫，就是歷史經驗的傳承，而傳承的首要工作就是PMBOK 2008的Project Document與PMBOK 2004&2008都強調的Organizational process assets。Programer必須寫下文件，analyst要不斷更新他的文件，PM要於案子結束後再行檢討文件，並進行彙整。
如果專案管理的know-how也能像維基百科這樣的作法話，真是一個美好的"夢想"！"站在巨人的肩膀上可以看的更遠"借助別人的經驗，應該可以讓自我的成長更快速；並避免走一些無謂的道路。
(三)團隊合作
很多的IT人員(可能我也算)，尤其是CODING人員，自我意識都非常強，姿態與能力不成正比，也不屑於傾聽與分享。PMBOK的理論是經過一些"專家"群策群力提出的，可說是當前通用的專案管理”語言”。若公司或專案團隊有了一個共同專案管理的"語言"，就如同UML對OO的好處一般。可以凝具共識，更有助於團隊間的合作。
PMP就像證券相關證照，可沒有人說考上證券高業或分析師就一定能每次都從股市賺大錢的(但因法規規定證券高業才能上電視解盤，所以薪水就不一樣了)，但沒有那些專業的知識(基本面分析、技術面分析、線圖...)對您想進一步探究股市的真相與動向是沒有辦法的，就只能當個一般的"菜籃族"，聽聽小道，雖然很多人都可以講的頭頭是道，但是最後很多都會淪入被坑殺的散戶群！

資深MS DBA的忠告-“IT DNA”

年前於書局看到胡百敬老師所著的“IT DNA”， 雖然筆者從未有幸親睹丰采，但在書架上簡單的翻閱後，決定買回家好好的拜讀一翻！近來有不少前輩們紛紛將自己多年的心得著書與後輩分享，不論是重新著書或是將自有的部落格文章集結成冊，個人都覺得這是一個非常好的趨勢，以使我這後輩的學習之路有所指引。
“IT DNA”全書共分為四大篇－工作與實戰、焦慮與生存、閱讀與觀點、創新與價值－分別表達了胡老師的工作經驗、AP架構發展現況、個人閱讀心得與對未來的看法。
從書中的內容，筆者猜測作者乃是以MS DBA為立身基礎，進而建立整體AP架構觀。除了因為書中對MS SQL著墨甚多外，也因為從伊的筆法中發覺伊對於觀念或產品架構的解說非常的挈要，更難得的是最後都要求讀者要有一個AP的整體觀去看待特定的產品。
在”給資訊新鮮人”乙文中有兩句話－「資訊產品是多元的，…大多沒有絕對的好壞，只有適不適合。因此，對各項產品廣泛的了解是絕對必要的，…一旦用了某項產品與技術，很難讓人放下既有的經驗，再從頭學習與適應。」「你應該選擇最有興趣的部份入手，先引發了興趣，再廣泛涉獵其他的領域，以建構圓融的整體觀。」－這雖是老生常談，但確是每個人最難突破與實現之處。筆者為中途轉業進入AP的領域，在這十年中有近三年的時間在AS400上開發COBOL與AS400的專屬語言，後來雖也接觸了在OPEN 平台上的C++、VB、JAVA、SQL，但均只是略懂皮毛；在業務領域上，因為經濟出身，因此在學習信用卡、匯款、外匯、債券、衍生性商品、BASEL II與ISO27001等知識沒有太大的距離，但這十年來苦苦追趕資訊與業務的知識，更遑論獲取一個” 圓融的整體觀”。
在”願”與”職場隨筆”兩文中，也可見作者對於上位資訊管理者的近視作為的萬般無耐。在筆者所接觸的台灣不管是VENDOR或USER SIDE的IT部門，其主管大多是IT的行政人材，缺乏對IT本質的實際認識，或者後來因耽於行政而對IT已經絕緣。筆者在十年AP生涯中有近八年均在同一家公司、同一主管下工作，但無耐的翻臉走人，主管雖也是IT出身、也在從事IT，但自滿的心態、對別人的鄙視、缺乏與時俱進的學習動機、害怕下屬超越自我的心態，我想這也是部份IT主管的寫照。
在第二篇”焦慮與生存”中介紹了BI(商業智慧)、SOA(服務導向架構)、BPM(商業程序管理)，這幾個當紅的”名詞”。資訊產品的推陳出新亟速，常令人目不暇給，但個人以為若迴歸到資訊管理的本質，資訊產品是要支援人類的活動行為，因此由下而上，由分立而整合，這個趨勢是必然的。重點是在個人的心態上，以及學習方法上的認知。第三篇是作者分享了他閱讀的心得。讀者可以這兩篇的內容當作基礎的認識，再決定是否深入鑽研特定的產品或細讀相關的書籍。
最後筆者必須呼應作者於”新浪潮”一文中的一句話－「如何靠團隊學習來快速與有效的成長」－在筆者所接觸的環境中，AP人員是誰也不服誰，自甘為一隻井底蛙的人多！筆者是多麼渴望能有一個學習的團隊與環境，成員間一起追逐共同的目標，一起成長。在筆者參與多個與國外公司合作的專案中，感受到國外IT人材的競爭壓力，但台灣的IT團隊留於媚外、自封，真是擔心在未來的IT環境中應要如何成長，更是否能走出自己的一條康莊大道！