2010-10-05 13:54:08IT肥蝦

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



    
『時程是一種Model!時程常會陷入了五大迷思-(1)時程僅是一些圖形?(2)時程只是用來管理時間?(3)時程要分毫不差的進行?(4)計劃趕不上變化,變化趕不上老闆一句話?(5)是否有最好的排程方法?-這世上沒有聖杯,沒有特效藥!』沒聽過這些話語的,一看也知道這一定是出於擁有豐富專案管理經驗的人之口;聽過的,就知道這是出於【專案管理的生活思維】部落格主人JoeBryan兩位先進的金口。

上週肥蝦分享了個人參與「Dynamic Scheduling with Microsoft Project Workshop」中研討個案三的規劃結果,現在肥蝦就來說說這次與會的整體心得。這是對肥蝦來說是一次滿滿的豐收,從研討會的四個案例可以看出兩位先進的用心與努力,在講授微軟的Project軟體之時是循序分層,對於功能所對應的管理重點也著墨甚深,尤其一再提醒參與的學員:「千萬不要被管理工具迷惑,應要審勢度量專案的特質與型態,以及組織的特性與文化,而善用Project軟體的功能。」光是這個再次的提醒,就說明了JoeBryan不是坊間的一些教師匠,而是有心於推廣專案管理的善心人士。當然以肥蝦這個賤嘴,還是會吐吐槽,也許有些看法與建議,JoeBryan能【審勢度量專案的特質與型態,以及組織的特性與文化】,斟酌斟酌。

這次研討會,依據肥蝦個人的心得看法,將這三天的活動內容區分為六大區段:()時程的真相。()工作包(work package)與活動(activity)間的關聯與限制。()時程中的資源。()時程的安排。() 時程的控制。()諄諄告誡。雖然每位學員都有自己的看法與卓見,甚至JoeBryan應該也有自己的想法,但以下的論述僅是代表個人的學習心得與看法,如蒙不棄就斟酌著看吧!

()時程的真相。

項次

專案管理的意義

微軟Project軟體的重點

I

專案時程的五大迷思:

(1)時程僅是一些圖形?

(2)時程只是用來管理時間?

(3)時程要分毫不差的進行?

(4)計劃趕不上變化,變化趕不上老闆一句話?

(5)是否有最好的排程方法?這世上沒有聖杯,沒有特效藥!

(1)專案/專案資訊

(2)工具/變更工作時間

(3)工具/選項(檢視、排程、行事曆、編輯)

II

工作包(work package)與活動(activity)的擬定建議區分為上下兩個層級,上層依據專案經理的認知與專案執行的過程,下層則可以需要參考組織相關的SOP或其他資源。專案經理再加以連結與調整,並設定必要的里程碑。

(1)專案/任務資訊(進階)

應依需要設置里程碑,任何獨立或無前/後置任務的Task應連結至里程碑,讓時程中的活動都有連結的關係。

 

III

注意每個任務的工期型態,是依循工作日還是日曆日。

(1)ed:日曆日;d:工作日;h:工作時。

時程不只是所有工作包與活動的內容,與其間的邏輯關聯,最重要的是,時程還表現出如何完成專案的策略意圖與戰術作業。一般人往往忽略了時程的宗旨與目的,一碰到時程表之時先會關心完成期限與成本,然後就落入了每個Task的內容與交互關係,忘了審視時程背後所隱含主事者要完成此專案的意圖與作法。

因此,JoeBryan特別說明了時程的五大迷思,希望大家跳脫這迷思的框框。在【讓事情發生-第二章 時間表的真相】也說明了時程的三個主要功用:(1)對事情何時完成許下承諾。(2)鼓勵每個人,將其付出視為整體的一部分;並盡力使其工作,能和他人配合。(3)提供一個追蹤進度的工具,並把工作切成可管控的小部分。這也說明了時程不僅僅是一張圖,這背後涵蓋了承諾、協調、合作與專案的全貌。

在這個段落中,對應的作業案例是農產品展覽活動設計的個案,大夥們均忘情於建置專案的任務內容,學習如何使用微軟Project軟體建立一個Project檔案。由於肥蝦以前都會利用Project軟體繪出甘特圖以提供予上層長官與客戶進行參考,對此個案,肥蝦以為JoeBryan的本意只是讓大家對軟體有一個初步的體認,但肥蝦可能要針對一點在此提醒。在Bryan給的案例中,所給予的工期資料都是以工作時計算。假設,團隊成員均是以工作時呈報,那專案經理可否自行換算為工作日呢?就肥蝦的認知與經驗,會建議因應審閱時程表的對象進行區別-若是與團隊成員討論所用之時程表,那也許尊重原提案人們的一致用法,採用工作時,方為上策;若是對sponsorcustomer,則可建議使用工作日,但也許可對細項任務用工作時,上一層則可利用系統自動換算為工作日。-因為團隊成員間溝通語言的一致性是非常重要的,另外這也進一步關聯了PMBOK 2004 7.1.2.2 DetermineResource 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 20086.2 Sequence Activities,針對四種依賴或邏輯關係(FSFFSFSS)所代表的意義,使用者必須要有明確的瞭解,切不可混淆,否則將對專案在後續的更新與控制上產生極大的誤解。

針對此區段所練習的案例是一個籌設咖啡廳的案例。由於肥蝦所屬一組未能完成案例實作,因此在分享之時,肥蝦只得利用唬爛的方法去硬坳,結果好像搞得一些成員很不服氣。但在此肥蝦有幾點應該可以與大家分享:(1)專案經理的角色與定位。(2)提綱挈領的能力。(3)PMBOK 6.2.2.4Dependency Determination

    每個組織中對專案經理的角色與定位均有著非常明顯的差異,就像PMBOK中,也提到了coordinatorexpediter兩種層級。因此並非每個專案經理均能逕行決定專案中應有的任務細項。就算能!肥蝦認為也應尊重各要項負責人、或所有人、或公司現有SOP的作法,當然專案經理以為不足之處,則應列示相關疑問,而與團隊間進行討論與對話。肥蝦個人常說的一句話:「只要您能解答我的疑問,原則上我是絕對尊重您的安排!」當然這也不是說專案經理就能置身事外,專案經理首要統籌整體專案的能力,因此對於專案的全貌與限制,甚至成本,應該要具備有著提綱挈領與初略估計的能力,這就有點像PMBOK12.2.2.3 Independent Estimates的技能,當然愈專業、愈有經驗、愈隨時更新自我的專案經理,伊所具備此能力的強度愈強。最後,肥蝦要補充的就是Dependency Determination,在會場上JoeBryan雖未特別強調,但此二人可是很壞心的放在實作的案例中喔!在電力負載與消防測試的任務,甚少學員針對這任務Dependency提出問題!學員們都被導入在設定Mandatory的關聯,對於Discretionary的關聯甚少著墨,更忘了去鑒別那更需要專案經理關注的External Dependency(待續)