『時程是一種Model！時程常會陷入了五大迷思－(1)時程僅是一些圖形？(2)時程只是用來管理時間？(3)時程要分毫不差的進行？(4)計劃趕不上變化，變化趕不上老闆一句話？(5)是否有最好的排程方法？－這世上沒有聖杯，沒有特效藥！』沒聽過這些話語的，一看也知道這一定是出於擁有豐富專案管理經驗的人之口；聽過的，就知道這是出於【專案管理的生活思維】部落格主人Joe與Bryan兩位先進的金口。
上週肥蝦分享了個人參與「Dynamic Scheduling with Microsoft Project Workshop」中研討個案三的規劃結果，現在肥蝦就來說說這次與會的整體心得。這是對肥蝦來說是一次滿滿的豐收，從研討會的四個案例可以看出兩位先進的用心與努力，在講授微軟的Project軟體之時是循序分層，對於功能所對應的管理重點也著墨甚深，尤其一再提醒參與的學員：「千萬不要被管理工具迷惑，應要審勢度量專案的特質與型態，以及組織的特性與文化，而善用Project軟體的功能。」光是這個再次的提醒，就說明了Joe與Bryan不是坊間的一些教師匠，而是有心於推廣專案管理的”善心”人士。當然以肥蝦這個賤嘴，還是會吐吐槽，也許有些看法與建議，Joe與Bryan能【審勢度量專案的特質與型態，以及組織的特性與文化】，斟酌斟酌。
這次研討會，依據肥蝦個人的心得看法，將這三天的活動內容區分為六大區段：(一)時程的真相。(二)工作包(work package)與活動(activity)間的關聯與限制。(三)時程中的資源。(四)時程的安排。(五) 時程的控制。(六)諄諄告誡。雖然每位學員都有自己的看法與卓見，甚至Joe與Bryan應該也有自己的想法，但以下的論述僅是代表個人的學習心得與看法，如蒙不棄就斟酌著看吧！
(一)時程的真相。
|
項次 |
專案管理的意義 |
微軟Project軟體的重點 |
|
I |
專案時程的五大迷思： (1)時程僅是一些圖形？ (2)時程只是用來管理時間？ (3)時程要分毫不差的進行？ (4)計劃趕不上變化，變化趕不上老闆一句話？ (5)是否有最好的排程方法？這世上沒有聖杯，沒有特效藥！ |
(1)專案/專案資訊 (2)工具/變更工作時間 (3)工具/選項(檢視、排程、行事曆、編輯) |
|
II |
工作包(work package)與活動(activity)的擬定建議區分為上下兩個層級，上層依據專案經理的認知與專案執行的過程，下層則可以需要參考組織相關的SOP或其他資源。專案經理再加以連結與調整，並設定必要的里程碑。 |
(1)專案/任務資訊(進階)。 應依需要設置里程碑，任何獨立或無前/後置任務的Task應連結至里程碑，讓時程中的活動都有連結的關係。
|
|
III |
注意每個任務的工期型態，是依循工作日還是日曆日。 |
(1)ed:日曆日；d:工作日；h:工作時。 |
時程不只是所有工作包與活動的內容，與其間的邏輯關聯，最重要的是，時程還表現出如何完成專案的策略意圖與戰術作業。一般人往往忽略了時程的宗旨與目的，一碰到時程表之時先會關心完成期限與成本，然後就落入了每個Task的內容與交互關係，忘了審視時程背後所隱含主事者要完成此專案的意圖與作法。
因此，Joe與Bryan特別說明了時程的五大迷思，希望大家跳脫這迷思的框框。在【讓事情發生-第二章 時間表的真相】也說明了時程的三個主要功用：(1)對事情何時完成許下承諾。(2)鼓勵每個人，將其付出視為整體的一部分；並盡力使其工作，能和他人配合。(3)提供一個追蹤進度的工具，並把工作切成可管控的小部分。這也說明了時程不僅僅是一張圖，這背後涵蓋了承諾、協調、合作與專案的全貌。
在這個段落中，對應的作業案例是農產品展覽活動設計的個案，大夥們均忘情於建置專案的任務內容，學習如何使用微軟Project軟體建立一個Project檔案。由於肥蝦以前都會利用Project軟體繪出甘特圖以提供予上層長官與客戶進行參考，對此個案，肥蝦以為Joe與Bryan的本意只是讓大家對軟體有一個初步的體認，但肥蝦可能要針對一點在此提醒。在Bryan給的案例中，所給予的工期資料都是以工作時計算。假設，團隊成員均是以工作時呈報，那專案經理可否自行換算為工作日呢？就肥蝦的認知與經驗，會建議因應審閱時程表的對象進行區別－若是與團隊成員討論所用之時程表，那也許尊重原提案人們的一致用法，採用工作時，方為上策；若是對sponsor或customer，則可建議使用工作日，但也許可對細項任務用工作時，上一層則可利用系統自動換算為工作日。－因為團隊成員間溝通語言的一致性是非常重要的，另外這也進一步關聯了PMBOK 2004 7.1.2.2 Determine Resource Cost Rates所提到的the unit cost rates。
(二)工作包(work package)與活動(activity)間的關聯與限制。
|
項次 |
專案管理的意義 |
微軟Project軟體的重點 |
|
I |
時程是一個模型，一個動態的模型，是統合專案的目標、策略與戰術的模型，可以用來呈現專案的狀態，以及進行專案的規劃、what-if分析、以及專案的掌控。 |
(1)專案/任務附註。 所有的限制一定要登錄附註。 (2)專案/任務資訊(前置任務)。 應儘量減少限制式，以維持動態的邏輯連結關係。 |
|
II |
注意每個Task其間的軟邏輯與限制條件，合作的模式與重大的Dead Line。 |
(1)專案/任務資訊(進階)。 任務限制中的期限，可加註重要的截止日期。但會影響系統對於時程back forward的推算 (2)檢視/其他檢視(網狀圖、關聯圖表)。 (3)視窗/分割 可分割畫面為上下兩層視窗。 |
這個對應到PMBOK 2008中6.2 Sequence Activities，針對四種依賴或邏輯關係(FS，FF，SF，SS)所代表的意義，使用者必須要有明確的瞭解，切不可混淆，否則將對專案在後續的更新與控制上產生極大的誤解。
針對此區段所練習的案例是一個籌設咖啡廳的案例。由於肥蝦所屬一組未能完成案例實作，因此在分享之時，肥蝦只得利用”唬爛”的方法去硬坳，結果好像搞得一些成員很不服氣。但在此肥蝦有幾點應該可以與大家分享：(1)專案經理的角色與定位。(2)提綱挈領的能力。(3)PMBOK 6.2.2.4 Dependency Determination。
每個組織中對專案經理的角色與定位均有著非常明顯的差異，就像PMBOK中，也提到了coordinator與expediter兩種層級。因此並非每個專案經理均能逕行決定專案中應有的任務細項。就算能！肥蝦認為也應尊重各要項負責人、或所有人、或公司現有SOP的作法，當然專案經理以為不足之處，則應列示相關疑問，而與團隊間進行討論與對話。肥蝦個人常說的一句話：「只要您能解答我的疑問，原則上我是絕對尊重您的安排！」當然這也不是說專案經理就能置身事外，專案經理首要統籌整體專案的能力，因此對於專案的全貌與限制，甚至成本，應該要具備有著提綱挈領與初略估計的能力，這就有點像PMBOK中12.2.2.3 Independent Estimates的技能，當然愈專業、愈有經驗、愈隨時更新自我的專案經理，伊所具備此能力的強度愈強。最後，肥蝦要補充的就是Dependency Determination，在會場上Joe與Bryan雖未特別強調，但此二人可是很壞心的放在實作的案例中喔！在電力負載與消防測試的任務，甚少學員針對這任務的Dependency提出問題！學員們都被導入在設定Mandatory的關聯，對於Discretionary的關聯甚少著墨，更忘了去鑒別那更需要專案經理關注的External Dependency。(待續)
留言列表
資管在職碩班課程 (2)
