PMITW活動-"開創永續的契機 – 綠能與創新"

此次PMITW於2010年11月12、13日於台北縣新店圓頂劇場舉辦

"開創永續的契機 – 綠能與創新"

(網址:http://www.pmi.org.tw/ipmf10/IPMF2010index.htm) 兩日共可獲得16PDU!

就活動安排看來倒是豐富多元,師資也是來自兩岸三地的專家! 雖有些商業色彩,但有些課程應是精彩可期! 費用是高了些!

	會員	非會員	5人以上團報
	定價	定價	定價
11/12(五)	3,000	4,000	3,000
11/13(六)	2,500	3,500	2,500
11/12~13 (全程參與)	5,000	7,000	5,000

建議大家不可錯過此良機!

第九講 跳脫框架

審勢明辨、究境量情

(一)決策的能耐，總是與欠缺多少賴以下判斷的根據成正比

(1)我們必須思索、猜測或運用人類的價值觀和情緒。做決策時人的因素是重要的關鍵。所有的判斷都是情緒性的。

(2)在幾乎所有要下判斷的情況中，難就難在判斷的價值只能留待未來驗證－做了決定之後。

(3)替代方案的數量只受限於我們的想像力。

(二)決策前框架－決策時所處的環境：背景、需求、時間表和形態

(1)背景

(i)背景如何？

(ii)你得在什麼樣的環境－冷靜、恐慌、衝突、競爭壓力…－下做出決定？

(2)需求

(i)為什麼必須做個決定？

(ii)為什麼現在需要做個決定？

(iii)如果暫時擱著，事情會自動解決嗎？或者是失去了一次機會？

(iv)有必須做決定的壓力嗎？

(v)這個壓力是自己強加於自身的、別人強加給你的？或是受累於朋友的建議？

(3)時間表：時間表必須包含下決定及其影響。

(i)這決定得在今天下還是這個月、今年、未來十年內？

(ii)這決定的後果什麼時候會顯現－下星期或未來二十年？

(4)形態

(i)它是需要調整，改變方向，還是要改弦易轍？

(ii)這決策是要停止還是開始做某事？

(iii)萬一行不通，能不能取消？

(iv)這決定是眾多決定中的一個，或者是為後續進程定調的決策？

(v)這個決策的決策者有沒有下判斷的能力？

(三)價值觀與優先順序－決策方法

(1)到了必須做決定的時候，費力發掘替代選項的步驟就得喊停，期望能找出最終極的替代選項並不切實際。

(2)遇上難以做抉擇的時候，就值得回頭嘗試設想另外的替代選項。

(3)優先順序有時候等同價值觀，有時候價值觀可視為次要目標。

(4)決策方法：

(i)骰子法

(a)說明：列出所有的替代選項，然後擲骰子決定從哪個著手。意即做決定的負擔是放在「別人或別的事物上」。在某些做決定比選擇正確的決議重要的情況下適用。

(b)重點：要明瞭：「做出對的抉擇比較重要，還是滿意於你所做的決定？」

(c)舉例：用命牌決定這次出門要往南走或往北走！

(ii)容易者勝出法

(a)說明：到最後不僅要做決策，還要有後續行動。「容易者勝出法」強調在有什麼最容易的方案可選？所以這選擇是主觀的。

(b)重點：容易者勝出法取決於當事人的個性，是主觀的！但一旦挑出簡單的方案，接下來便是要努力發展並支持這個決定。假如結果不如預期，則有必要另換一種。

(c)舉例：中午午餐一堆餐廳，但決定要開水泡麵吃，然後想想也一段時間沒吃泡麵，這是一個不錯的決定，結果吃了也不會餓！

(iii)詳加說明法

(a)說明：決策者想像他依次選出一個選項，在每個選項中，他想像要對朋友解釋做此決定的理由。每個理由都要寫下來，然後再看一遍，要是有些支持理由十分薄弱，就讓它們自動消失，以從選項中挑出一個最好的。

(b)重點： 若能將支持理由的論述做得愈有條理，這個方法的成功機會就愈大。

(c)舉例：詳加說明你跟每個交往對象交往的原因跟理由，從中決定一個適合你情況的！

(iv)布里丹的驢子法

(a)說明：布里丹的驢子原意為一頭驢子站在兩堆一樣多的秣料中間，因為遲遲無法決定要走向哪堆秣料而餓死。因此引申為做決定的人要盡最大的努力依次「貶損」或挑毛病，讓每個選項看來都不吸引人。當放棄任何一個不會覺得痛苦，接下來即可看出最好的選擇。

(b)重點：反面思考，說服自己放棄！

(c)舉例：把每個交往對象都數落一遍，看那個是你可以忍受的！

(v)理想解決法

(a)說明：列出所有選項－然後擱在一邊，接著導入一個適合此情況的「理想的解決辦法」。這個理想解決辦法的「樣子」是經過謹慎考慮，不必太在乎細節，但應該留意其特質。再拿出選項清單，逐一檢視哪一個選項最接近「理想的解決辦法」。

(b)重點：重要是誠實，在未設想「理想的解決辦法」下列出各種可能的選項，而不是為迎合某個選項去塑造「理想的解決辦法」。

(c)舉例：把每個可能的交往對象都列出來後，然後挑一個你最喜歡的女(男)公眾人物，看哪個最接近她(他)的特質。

(vi)最佳生息地法

(a)說明：指這個主意最能在該環境或背景下茁壯。所以我們可以描述某個特定主意的最佳場景或「生息地」，在這種情況下，這個主意就成為決策的選項。因此我們要為每個選項尋找最佳「生息地」：對什麼樣的人、在什麼樣的情況下，選擇這個選項會是最好的？

(b)重點：同理想解決法，要客觀誠實地為每個選項設想一個最佳「生息地」的樣貌。

(c)舉例：把每個可能的交往對象的最佳情人類型都列出來後，想想自己與哪一個交往對象對應的最佳情人最接近。

(vii)「要是...」法

(a)說明：變換「要是...」以改變狀況，看看到哪個點之後選項變得不再吸引人。

(b)重點：就是what-if analysis，當你發現「要是...」讓你的某一個選項失去吸引力，你就已經挑出了該項選擇的背後原因。

(c)舉例：就每個交往對象逐一設想要是你娶(嫁)後，你跟他家人相處與一同生活的狀況！找出哪個對象於婚後會使得你不奈煩！

(viii)簡單矩陣法

(a)說明：是一種「倖存」法－哪個選項能夠在「關鍵」性質的嚴格篩選下倖存。目的是要挑出在做決定時少數幾個關鍵性質。

(b)重點：就重要的特質篩選出不適合的選項，可不斷重複對不同重要特質進行檢測篩選。類似screen system，因此要慎選檢測的特質。

(c)舉例：依據你擇偶條件，依優先順序過濾所有的交往對象，不合格時就淘汰！

(ix)詳盡矩陣法

(a)說明：矩陣列出做決定時所需的全部優先順序、價值和考量。所有因素要在一開始就全部列出來，逐一檢視每個選項所擁有的性質，最後再重新檢視那些擁有最多性質的選項。

(b)重點：要客觀的列出所知的選項的一切特質－含正面跟反面。因為每個特質間的比重並不一致，此法可能需要搭配一些rating的機制。這不同於詳加說明法，詳加說明法是列出你選擇的理由，而此處是儘可能列出每個選項的正反面特性。

(c)舉例：把每個交往對象的收入、身家背景、學經歷、是否與父母同住、生活習慣...等要項，依據你的需求將每個要項打一個分數，看誰的分數最高！

(x)懶人法，又稱FGL(Fear, Greed, Laziness)法

(a)說明：逐一檢視選項，看看哪個會引發擔憂、貪婪和偷懶，再來決定。驅使當事者做此決定的真正動機是什麼？

(b)重點：檢視你內心的真正動機，切不自欺欺人。

(c)舉例：把每個交往對象，針對你內心的慾望－擔憂：少不更事；貪婪：貌美、身材、有錢；偷懶：隨呼隨到…進行剖析。

(四)決策後框架－個人風格和自我形象、相關的人、檢測時點、執行問題、整體情勢、後退狀態

(1)如果能清楚了解你的優先順序和期望(或需要)，將比只著眼於周遭情勢和你可以有什麼選項更容易下決定。

(2)以上十種的選擇替代選項的方法都不是在於強調各選項的重要性，而在於它們是否「適合」。思考者在做決定和選擇都需要推測未來，未來無從得知，但對整體情勢愈了解，情緒的運用就愈合宜，就能將困難的決定改變成容易的優先。

(3)決策之後要考慮的因素：

(i)個人風格和自我形象

(a)決策需要客觀，決策者的個人風格也是此客觀中的一部分。

(b)這決策是某人會做的嗎？

(c)能夠忍受由自己付諸實行嗎？

(ii)相關的人

(a)相關的人可能得同意這決定，且可能為執行者或受此決定影響！

(b)可用OPV或邏輯泡泡法。

(iii)檢測時點

(a)決策的後果應該在哪些時點進行檢測－立即、短期、中期和長期。

(b)可用C&S法。

(iv)執行問題

(a)Who? How? Existed Channel? Or Create a new channel?

(b)各階段細節？可能的問題與滯礙處？風險與危險？

(v)後退狀態

(a)所有的決定都是推測，不想冒險和未雨綢繆是兩回事。

感想：

在第三講中，作者說明了替代選項的重要性，以及如何去思考替代選項。在本講則說明了如何在適當的決定點時去決定決策，此處作者詳列了十種方法－(1)骰子法。(2)容易者勝出法。(3)詳加說明法。(4)布里丹的驢子法。(5)理想解決法。(6)最佳生息地法。(7)「要是...」法。(8)簡單矩陣法。(9)詳盡矩陣法。(10)懶人法。

以上這些方法，並無法找出一個客觀中立的最佳選項。因為任何的評選都還有賴於人的抉擇與認知，就如詳加說明法或理想解決法一般，如果不能誠實的列示出對應選項的特質，揭露出決策者的真正慾念，這種種方法也僅是外在粉飾、自欺欺人之誇詞罷了！因此就如本講中最後所述：「如果能清楚了解你的優先順序和期望(或需要)，將比只著眼於周遭情勢和你可以有什麼選項更容易下決定。」不過此講對於決策前後，決定者之應有作為倒有一番見地：事前要審勢明辨(背景、需求、時間表和形態)；事後要究境量情 (個人風格和自我形象、相關的人、檢測時點、執行問題、整體情勢、後退狀態)，如此方能進可立其功，退可守其本。

記得前陣子肥蝦看陸劇「雍正皇朝」，其中有一段雍正登基前被康熙委付追比官僚國庫欠款乙事。雍正之作為與事後康熙對伊之評斷正可為此講之最佳案例：「雍正雖是忠勇任事，卻失之操切，疏於深究，並且未能量情斟酌！」這可對應說明了決策之時應考量背景、環境、需求與形態，決策後要審視自己的立場，以及與專案利害關係人間的影響，退路之安排，以及執行之中的諸多細節，甚至是對人、對事的執行步驟與輕重緩急。

軟體專案管理第四週課程心得

Proposal Evaluation Techniques

由於肥蝦常常自以為自己對PMBOK有一定的瞭解，加上自己這十年多的實務經驗，因此有時不免會自我陶醉一番，自我感覺良好。肥蝦昨日聆聽李坤清老師於課堂上的教導後，不禁有了「聽師一席話，勝讀十年PMBOK！」的感嘆！

話說昨晚，軟體專案管理課程，肥蝦一組報告【軟體專案管理】課本(林信惠、黃明祥、王文良合著的)第三章軟體開發模式，其中肥蝦負責第一節導論、第二節瀑布模式與第三節快速雛型法，以及自己所選擇的一篇期刊論文：”On exceptions and the software development life cycle”。當肥蝦於課前準備，閱讀課本第二節之際，發現書中對瀑布模式的圖形表示與肥蝦以往認知不一，就去找了那Royce於1970年發表的名作"Managingthe Development of Large Software Systems: Concepts and Techniques“一看究竟，並將原版的圖形列示於簡報之中。當初Royce所提出的五大步驟─STEP1: PROGRAM DESIGN COMES FIRST；STEP 2: DOCUMENT THE DESIGN；STEP 3: DO IT TWICE；STEP4: PLAN, CONTROL AND MONITOR TESTING；STEP 5: INVOLVE THE CUSTOMER─雖說內容上因電腦科技的進步與時代環境的變異有所出入，但其核心精神仍是現今軟體開發專案所要繼續努力的方向。

本組中的錦崇同學報告了一篇1997年發表的” Methodologies for Information SystemsInvestment Evaluation at the Proposal Stage”，該文對歷來評選建議書的方法作了一個整理、彙整與比較，並且提出了所謂的一般觀察(generalobservations)與建議(Recommendations)。針對1997年的這篇文章，令肥蝦最感興趣的是其對於評選中對於風險衡量的述說。該文中將風險視為特定投資的不確定結果的衡量數值，在一些評選方法中或將之列為獨立的評選項目，或是將不確定性改以支出的提高，或是預期收入的減少，或者可如敏感性分析中的最佳(best)或最差(worst)的情況進行分析。其中，多重標準方法(multi-criteriamethods)中的SIESTA(Strategic Investment Evaluation and Selection Tool Amsterdam)的模型中，對於風險倒是有較全面的描述。該文對照於現行的實務作法，大都能涵概，但就如文中所說，目前尚無文獻或研究，提出評選方式與專案成功間的因果關係。

對照於PMBOK對於Proposal Evaluation Techniques的說明，該篇文章所述當然是更為深入與有條理。原在PMBOK2000版中的12.4 SOURCE SELECTION中Input有建議書(Proposals)、評選標準(Evaluation criteria)、組織政策(Organizationalpolicies)，經由使用契約協商、加權系統、篩選系統或獨立估算等工具與技巧後，即產生了合約(Contract)，全無Proposal EvaluationTechniques此一字眼；到PMBOK 2004 12.4 Select Sellers方出現此一名詞；2008版因將第十二章採購管理併為四節，因此ProposalEvaluation Techniques對應出現在12.2 Conduct Procurements。

鑑於專案之中確實存在了諸多的不確定性，那如何在評選建議書之時經由評選的機制，進而洞燭機先？這一直是肥蝦個人的主觀以為。不意李大師於報告後的指導中，一語驚醒夢中人：「目前實務中的評選機制，都是假設該建議案經採納之後是確實能實現的！」也許專案延遲，也許專案超出成本，但這個終能完成的假設，確實是肥蝦所經歷過專案評選中的前提。這假設本身就存在了多大的風險與盲點，肥蝦以往就如1997年該文所說的一般，將風險視為支出的增加或是預期收入的減少。李師的這一提醒，那肥蝦頓時冷汗直冒，對於自己的無知更多了一份警醒！接著李師提出了一個方式，作為評量風險對於整體資訊專案的影響。其法為在以成本效益分析中，將所估算成本再以【專案完成機率】與【完成百分比】兩個緯度，進行專案效益分析。這就像把「12.2.2.2Proposal Evaluation Techniques」引入「11.4.2.2 中Expected monetary value analysis」的概念！把每個方案以不同的完成機率與不等完成百分比，進行效益與成本分析。這觀念可以如上圖表示：

當然要計算出所有專案其成功機率與完成百分比率下的效益成本比，誠為困難，並且需要耗費不少資源；但如具有此等觀念，比較與選評專案之際，就能更加審慎的；而且就算概估出50%與100%，也比單純以100%視之，更加妥適。

李師雖常自稱離開業界、隱於杏林，沉浸佛學、疏於專業已久，但這實是老師自謙之辭，光這一句：「假設該建議案經採納之後是確實能實現的！」讓這自以為凡事能先審視假設前提的肥蝦，受益斐淺，對自我所習以為常的【執見】，更是多了一分認識與破除。

「D3 Dynamic Scheduling研習營」與後感(後篇)

(五)時程的控制。

項次	專案管理的意義	微軟Project軟體的重點
I	Schedule Baseline	(1)專案/專案資訊(狀態日期) 狀態日期為表示該日期下的現有任務狀況。 (2)工具/追蹤/儲存比較基準 (i)儲存比較基準：儲存專案的所有資訊。 (ii)儲存成中期計劃：只儲存任務時間的起迄，對應resource與cost並未儲存，適於作what-if分析使用。 ※微軟Project軟體可存放11個比較基準。
II	Performance Review Period Performance status update Performance status refresh	(1)工具/追蹤/進度線(日期與間隔) (2)插入欄(完成百分比、實際完成百分比) (i)完成百分比：為依據時間(時程)進度的百分比， (ii)實際完成百分比：為依據任務的實際狀態的完成比率。 (3)工具/追蹤/更新任務 完成百分比：依時程比率設定。 實際完成時間：為時程完成時間。 (4)工具/追蹤/更新專案
III	必要監控的專案資訊	(1)視窗/分割 上層為追蹤甘特圖；下層為任務分配狀況。 任務分配狀況右方表格可利用滑鼠右鍵/詳細樣式，設定基準工時/實際工時/實際加班工時。
IV	專屬化管理介面	(1)工具/自訂/工具列,欄位,表單 ※微軟Project提供十個欄位供使用者自訂。 (2)檢視/其他檢視(新增) 新增使用者所需要之檢核畫面。 (3)專案/群組依據/自訂群組依據 (4)工具/組合管理 可依使用者需要刪除特定的作業，或者轉存入Global.MPT，供其他專案使用，或者自Global.MPT轉存入專案名稱.mpp以供該專案使用。

專案管理工具的主要功用之一即為追蹤專案的狀態，因此設定比較的基準與狀態更新的頻率非常重要。頻率太過頻繁將加重專案成員非專案工作的負擔；頻率太過疏遠，也將使得專案管理狀態失真。因此設定一個適當的更新週期是專案控制的首要之務。其次，則為搜集專案狀態的訊息。為了資訊的完整與確實，Bryan特別提出他個人的任務資訊搜集要項：AS(Actual Start Date)實際開始日期、AF(Actual Finish Date)實際完工日期、AD(Actual Duration)實際工期、RD(Remainder Duration)剩餘工期、AU(Actual Unit)實際工作單位、RU(Remainder Unit)剩餘工作單位、ES(Estimation Start Date)預估開始日期。當然這些要項間有一定關係與邏輯，如受訪者回答了AS，然後專案經理還要受訪者回答ES，那這個專案經理不被受訪者數落跟譏笑才怪。因此針對在特定狀態日期下，對應不同特定進度的任務資訊，Joe與Bryan特地整理說明如附圖。

附圖表格中已經包含了基本需要的專案資訊，Joe與Bryan將第一天的作業案例－作業案例是農產品展覽活動設計的個案，設定學員是擔任一個PMO助理的角色，根據一些專案陳述，以及專案成員訪談的內容，要求學員們除了更新專案的狀態外，要更進一步發現專案的外顯/潛藏的問題。

此隨堂案例，當然首要要運用Joe與Bryan所教導的狀態資訊更新要項表，除了搜集AS、AF…等必要欄位外，還提醒我們應加入備註的欄位，以註記必要的其他資訊。各組分組討論後，E組的學員們大方分享了他們的心得：(1)該專案成員們的自我認知太過良好，缺乏彼此間的溝通協調，大夥各做各的。(2)權責不明，部分成員的報告對象有誤，就是PMBOK 9.1 Develop Human Resource Plan作得不好。翻閱PMBOK page 218，可以看到對Develop Human Resource Plan 主要目的描述為：「確認和記錄專案成員的角色，責任，必備技能，報告從屬關係，和建立員工管理計畫。」(3)某一重要的專案成員因病休假，要設法提供對應的替代方案。學員間的分享都是寶貴的經驗，也都提到了重點。但如果肥蝦擔任該案中的專案助理角色，可能還會有以下幾點小小的作為：

(1) Joe與Bryan所教導的狀態資訊更新要項表，肥蝦會在插入一欄叫作「資訊來源」。重點是要確認該資訊的來源，如果彼此間有所衝突，也可以根據來源者作進一步判斷的基礎。

(2)設法於該案中設置一專案助理的角色。因應該專案的狀態，肥蝦會建議PMO的長官，是否對該專案派任一專案助理，以協助工作繁忙的專案經理 (背景陳述中提到該專案經理是公司副總的親戚)。

(3)對專案中屬於主要工作項目的目標一貫性進行檢核。除了專案中的Mandatory與External Dependency必須要進一步檢核其是否符合專案要求外；對於非位於要徑之上，但涉及專案重要的工作主軸的工作項目，比如此次案例中的展覽標的、展覽項目清單、展覽文案內容等，也應檢核專案主軸工作項目內容與專案目標暨彼此任務之間的一致性與一貫性。

(4)定義明確的Project Organizational Breakdown structure。應產生如PMBOK 9.1所載的OBS，以對於專案團隊之間的關係有一明確的界定，並設法與WBS進行對應整合。

(5)加強資淺成員的Training。如果可以會建議PMO指派指導員進行協助與輔助，並檢核專案的工作項目，尤其是要徑上的項目由資淺成員負責是否適當。

(六)諄諄告誡。

項次	專案管理的意義	微軟Project軟體的重點
I	見樹又見林	(1)插入/專案
II	時程表可讀性	(1)專案/任務資訊(前置任務) 如使用者對於微軟Project工具不熟悉，建議任務間的前置(後續)任務應擇要建立。 (2)專案/任務資訊(進階-標示為里程碑) (3)任何open start /open end的任務應設定前置(後續)任務為特定的里程碑。
III	時程動態分析 What-if analysis	(1)工具/追蹤/儲存成中期計劃 (2)專案/任務附註 除非必要任務不應建立constraint，如須設定應加註附註。

「見樹又見林」、「時程表可讀性」與「時程動態分析」，是這三天的研討會中，Joe與Bryan一而再、再而三的提醒大家要時時注意的，尤其當對專案管理工具不熟悉之際，切勿有【想把所有功能都應用上】的不當心態。其實，整個workshop的重心在於強化時程在專案管理的意義與重要性，對於微軟Project只是教授在對應相關管理作為下可以應用為輔助的工具。但因為課程的安排合適，使得成員對於微軟Project這工具也有了一個基礎與全貌的認識。

而這諄諄告誡的三點也恰可呼應在【讓事情發生-第二章 時間表的真相】所描述時程表的三個主要功用：惟有在對專案有全貌的瞭解(見樹又見林)之下，才能對專案的期限給予承諾；惟有專案的時程表具有相當的可讀性，方能作為專案成員與專案利害關係人間的溝通工具，也才能作為有效追蹤進度的工具；也惟有時程設定能進行動態的分析與規劃，專案成員所為的付出，以及與他人配合，方能具見成效。

這三天的研習課程實讓肥蝦收穫良多。Bryan有時會問肥蝦這課程會不會對我個人太過瑣碎，其實這是Bryan多慮了。倒是肥蝦這老是無的放矢與口無遮攔的蝦嘴，反而可能讓參與活動的其他成員產生反感，進而影響Joe跟Bryan的聲譽，這才是肥蝦應該致歉之處呢！

我記得Joe於D1/D2 workshop所說的一句話：「專案管理在某個方面來說，每個人都是專家，但每個人也可能都不是專家。」對於個人已瞭解，但卻因工作所屬環境的限制而忽略或甚少接觸的專案管理程序、投入、工具、或產出，就可藉由參加各種的研討會，以及接觸不同公司、不同產業、甚或是甲(業主)、乙(承包)、丙(IV&V)這不同角度的朋友，而有重新的認識，獲得不同的啟迪。尤其是Joe與Bryan所設計的案例，更是引人入勝，常常能讓人從其中感觸到強大的挑戰、不同的體會，以及專案管理上的意義。但就如Joe與Bryan所說：「這是一個非常小眾的市場。」較之如坊間多如過江之鯽的企管顧問公司與相關課程，專案管理顧問公司尚屬有限。而且這為數不多的公司中幾乎90%以上都只是著重於證照考試。現今台灣專案管理領域之中，有者豐厚實務經驗與紮實專案管理理論的賢人達士，願意挺身與大家分享相關經驗者實在是少之又少，甚多都是只知攻詰他人，讀些書籍就妄言稱霸稱雄者。因此，肥蝦看著Joe與Bryan的努力實在是就”感心”，此外當然也是為要提升肥蝦自我的能力與獲致更多的成長。

對於這個workshop的活動安排，肥蝦倒有兩點小小的建議，可供Joe與Bryan【審勢度量專案的特質與型態，以及組織的特性與文化】，自行參酌。

(1)減少任務項目名稱的打字時間。肥蝦以為，專案經理對時程的學習首重專案整體性的掌控，以及因應可能風險與限制的因應。因此如能先提供一個不分群組不分階層的任務清單，而由成員自行安排與設定，應可強化成員在學習專案管理上的要點。

(2)可將農產品參展或籌設咖啡廳的案例，比照D1/D2 Workshop中彼此勾心鬥角的同組互動方式。這也許可模擬專案經理為達成專案目標所需要的軟/硬性skills，以及設定跨越跨專案任務間Dependency與資源安排的學習。

(3)增加些案例背景討論的時間。這三天的課堂案例都有Joe與Bryan深思熟慮的背景陳述：「有被捉去關的、有裙帶關係的不稱職專案經理、有跨國公司的籌設咖啡廳…。」如果這些精彩的描寫未能有多點的討論，實易讓學員僅落入微軟Project功能的操作學習之中。

以上的建議當然多少也是肥蝦的自私考量，對於體胖手抖的我來說，光是看到這要打字的任務項目，這蝦螯就抬不太起來；然後這打字要如何分工？也是讓肥蝦一時之間不知如何配合！

最後，肥蝦還是要謝謝Joe與Bryan這麼費心安排與教導的課程；對於同是C組與共同與會的成員，如因肥蝦個人的不當發言與舉措，則還請多多海涵；還有啦！如果是不像D1/D2 Workshop有供應點心，那請先告知一下嘛！害肥蝦第一天早上沒早餐吃耶！