(五)時程的控制。

專案管理工具的主要功用之一即為追蹤專案的狀態，因此設定比較的基準與狀態更新的頻率非常重要。頻率太過頻繁將加重專案成員非專案工作的負擔；頻率太過疏遠，也將使得專案管理狀態失真。因此設定一個適當的更新週期是專案控制的首要之務。其次，則為搜集專案狀態的訊息。為了資訊的完整與確實，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)定義明確的ProjectOrganizational Breakdown structure。應產生如PMBOK 9.1所載的OBS，以對於專案團隊之間的關係有一明確的界定，並設法與WBS進行對應整合。

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

(六)諄諄告誡。

「見樹又見林」、「時程表可讀性」與「時程動態分析」，是這三天的研討會中，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有供應點心，那請先告知一下嘛！害肥蝦第一天早上沒早餐吃耶！