好的Schedule該有什麼呢?

好的Schedule該有什麼呢?

我始終相信,PM最好的朋友絕對是一份正確且精細的排程。 這是因為一份思慮周詳的Schedule(*)將能涵蓋專案最核心的三個元件,也就是:範躊、時程、以及成本的資料;而有經驗的PM甚至可以將合約重點、請款條件、品質需求、採購時程、人力調度都考慮並排進Schedule中。 這東西將是專案執行中,對內對外溝通的一個重要媒介。

甚至我深信,當大家都知其然不知其所以然的把五大程序這類東西琅琅上口,並自以為讀過一兩遍PMBOK就是學會專案管理時,好與壞的PM最大的差異就在於有沒有具備規劃Schedule的能力啦。

我一直在講好的Schedule,可是一份好的Schedule到底該有什麼東西呢?

我覺得最少要能符合下面五點:

1. 有前瞻性的WBS切割
2. 好的流動性
3. 涵蓋所有關鍵工作
4. 能真實的反映現狀
5. 可以在驗屍時,Tells a good story

(*)對我而言,所謂Schedule並非只是工作還有時間而已,還要包含WBS、資源指派、以及專案成本。 當這些都有時,自然會涵蓋Scope、Time、and Cost的資訊。

 

1. 有前瞻性的WBS切割。

很多人以為WBS切割是可以很隨性的,或是有人以為一率按照某個方式 (如階段)就可以。 但實際上WBS切割的好與壞,將決定後面整個專案是否容易被管理。 比方說,你打算怎麼計算進度、你打算如何發包、工作會不會交疊、有多少Team可以調度、有多少Leader可以協助管理下層的範疇、要不要使用實獲值

等。

如果工作包切的不合理,那後續規劃中,團隊必定有大半的時間在爭執、以及推卸責任上。 PM發包工作、追蹤進度也都會增加困難。 也因此,後續的執行是否有效率,將大幅取決於PM在這裡的規劃能力。

而範疇切割還有個問題,在於切割出的WBS是否能反映合約、請款原則、或是公司的評量基準。 如果你的專案裡頭有大量的難以計量的工作包、或是有一些是難以計量、一些是容易計量的工作包時,這部分能否切割與定義清楚將影響你是不是有辦法在之後的專案進行中能解讀專案執行的健康狀態。

甚麼意思呢? 比方說,你的專案裡頭若同時涉及材料、人員、設備等資源且又被分成多個階段時,那材料或採購金額的所佔的比重可能影響到後續進度的評量。 或是某些工作無法量化評估進度時,你都需要在規劃的初期就考慮如何切割、如何歸類、如何計算。 這些若不考慮,很可能會做出一個「似乎」涵蓋了所有交付項目,卻無法拿來日後管理的WBS架構。 那這也就可惜了。


2. 好的Schedule必須要具備「流動性」

所謂流動性指的是極少的限制條件。 有些PM以為所謂排程,只是根據自己的想法或期待把作業的時間定死在某個時間上。 這樣的排程方式,只是把排程軟體當Excel在用,這會造成整份Schedule全部都是限制式而沒有任何排程運算的可能性。

這除了造成完全沒辦法應用CPM的技術以外,之後專案有任何變動時,後面工作的時間也不會因為前面的延遲而產生變化。

那這樣不就失去辛苦排程的意義了嗎?

因為這種Schedule只呈現原本的計畫,一旦專案開始執行跟計畫有落差時,沒有流動性的計畫將完全沒辦法反映這些變動的影響。 但有人碰過專案能完全如計畫執行的嗎? 最少我是沒有。 那沒有如計畫執行的時候怎麼辦? 這種排程就只是廢物,因為變的完全沒用啦。

時間既然花下去,就是希望能得到最大的效益,若只是做個半吊子的東西還真不如不要做。 也因此,好的Schedule需要盡一切可能保持它的流動性。 能夠越少限制條件越好! 請一定要記得,排程的目的不是只為了產出一個看似漂亮的甘特圖計畫而以,執行時能拿來追蹤與比對才是Schedule最有價值的部分。


3. 要能彰顯專案執行中「關鍵的部份」

專案事項繁多資源有限,但並非每一樣工作都能投注同樣的心力。 簡單的講,你要優先把心力放在要徑、還有浮時到達危險邊緣的工作上。 但這樣的事情,並非所有人都可以簡單查覺。 技術力強的資深人員,或許可以透過過去的經驗,直覺的辨識出哪些工作重要(哪些可能是要徑)、而且可能開始有危險了;但是大部分專案成員是完全不具備這樣的能力。

所以一份好的Schedule中必須要能顯露你的專案要徑、顯露關鍵工作的順序、顯示資源投入量與需求時間、顯示累計成本的狀況。 這讓你好溝通、好聚焦、也確保大家能得到相同的認知。

這樣PM才有可能掌握大事,而讓下面人分層負責。 不然如果事事都重要,那除非三頭六臂,否則誰又能完全顧的周延呢? 顧不周延的話,PM得花很多時間解決枝節末端的事情。 當你都被這類事情綁住時,自然沒辦法從大處著眼去思考與決策。 惡性循環下,將會越來越見樹不見林,最後將因此被拖累。 也因此,回歸原點來看,有個好的Schedule是很重要的!


4. 而最重要的,就是Schedule要能反映現況,要能讓人安心

老闆也好、客戶也好,總是會擔心案子的進度。 如果你的Schedule無法反映現狀,或是報告歸報告、現場規現場時,你就把自己曝露在很高的風險中。 老闆或是客戶很可能就會強迫你報告,甚至伸手進來干涉。

有些人習慣有一份對外(對上)的Schedule,而另外有一些資料是自己用來做追蹤與紀錄的。 但這很花工、很花時間,也很容易發生錯誤。 尤其案子複雜且出問題時,將剛好是你最沒能力維持好多份資料,而偏偏又很多人追著問你專案實際狀況的時候。 你又要解釋、又要更新資料、又要製作報告,很可能不小心就交出錯誤的訊息,或是根本回答不出來。 這些都只會降低你在客戶或是主管面前的信賴度。 既然如此,為何不一開始就想辦法能把所有訊息都反映在一套Schedule並讓相關計算都有所原則可遵循 (比方說如何認定工作的進度等)? 隨時有人跟你要資料,隨時就能有真實進度時,自然可以避免很多不必要的信任問題。

當然,也有人不是故意要這樣做。 他們也不是故意要維持兩本帳,只是每次規劃好,案子一開始執行就發現計畫跟實際完全走不一樣了。 然後自己就完全無能為力,甚至完全無法掌握實際進度了。

這通常都是PM的排程經驗不夠,才會排出一個紙上漂亮完全不可行的Schedule。 這時候,勉強去讓計畫去追實際狀況是不切實際的。 最好的方法是要整個Re-plan過,讓後面的製程或是專案走向能夠較符合Schedule的定義。 這樣才能促使自己的Schedule跟實際做法結合,也才能讓自己學會下次該怎麼預防與改進。 好的規劃者本來就是得在這樣的互動下,慢慢增加自己的實力。


5. 好的Schedule還需要在將來「驗屍時」解釋死因

很多PM認為Schedule辛苦做好後印出來貼在牆上也就了事了,實際發生甚麼事情也不做紀錄與回報,也不拿實際進度跟Baseline做比較。 這在專案一路順暢時,當然是沒問題的;但是如果專案不順利呢? 甚至專案出了大麻煩被停止、被客戶索賠、甚至被政府機關調查時呢?

如果你的Schedule並沒有一路走來的歷史紀錄,工作沒有連結說明、工作沒有連結相關的產出以及文件,有問題發生時、有任何合約爭議、或是決策遭受質疑時,你將完全無法說明當時為何做了特定的決定。

這尤其在按照合約執行的專案中更加重要。 因為一份好的Schedule在面對客戶質詢或是爭議發生時,是唯一能把來龍去脈交代清楚的重要文件。 你可以證明某些東西是原始合約的內容、哪些東西是第幾次新增的、為何要新增這些東西、新增的工作造成了多少的時間影響、多少的成本增加。 Baseline是否被同意? Re-baseline是否被核可,進度的成長是怎麼樣按周按月的成長,人力或是其他資源的投入跟預期呈現怎麼樣的差異? 最初的要徑是哪條? 過程中因為變更造成的要徑變異又是哪條? 你的Schedule要能在必要時幫你說這樣的故事,甚至在仲裁庭上能幫你證明過往的決策。

如果這東西沒有,光是要說服別人為何你準備在某個作業增加人手,都將困難重重,更別說更複雜的決策了。

---

所以呢,如果你有志向當一個專案經理,或你已經是專案經理想要更拓展你的高度時,請一定要多花些心思來研究排程這件事情。 別看字面上的兩個字平淡無奇,但其實是一門非常深奧且變化無窮的有趣領域喔!

 

延伸閱讀

我們的排程訓練

基礎班 106排程基礎課程

進階應用班 204 進階排程研習營

若有轉貼需求,請來信討論。 轉貼時禁止修改內容及標題、須保持所有連結、禁止商業使用,並且必須註明原文標題、連結、及作者訊息。
覺得這篇文章好嗎? 請分享給您的朋友
歡迎「讚」一下我們的粉絲專頁,接收最新文章!
張國洋 Joe Chang

現為識博管理顧問執行長,也在台灣百大上市櫃公司擔任管理講師與專案顧問。歷年客戶包含工研院、台積電、廣達、富智康、光寶集團、台灣大哥大、遠傳電信、中鼎工程、建國工程、台橡公司、大同公司、三陽工業、TVBS、特力屋集團、城邦集團、誠品集團等。 為了對抗雙魚座的感性,一直在努力強化理性思維與邏輯思考。 相信邏輯發展能解構任何事物,並讓我們找到合宜的人生策略與方向。

Joe G+ ICON Joe LInkin ICON

7 則讀友回應

  1. Leo Kao 2012-11-02 12:00:43 第 7 則

    1. Schedule應該不是一份表單,而應該是一份檔案
    請問Joe大,檔案的定義...是指多份文件(表單)的集合體嗎?

    • Joe Chang 2012-11-04 22:16:53

      一般來說,我們對於排程的定義 那是一份專案的模擬
      而專案排程軟體 (比方說MS project, or Oracle P6等)做的事情就是讓PM能在其中拆分階段、拆分工作包、分工、工作規劃、工作順序連結、時間預測、資源規劃、成本規劃,並把這些東西丟進去後變成一份分析結果。 就是電腦模擬一遍專案工作的意思。 而最後結果會是在單一的一個檔案中。 因為如果是分成好多表單(這裡指的不是資料庫的table),那資料之間是毫無關聯,也就無法看到相互之間的"影響"了

  2. 研發小助理 2012-04-27 22:00:05 第 6 則

    請問Joe大大
    1. 請問此表單還是會執行但可以不放在ISO研發模組管制程序做發行裡嗎? 這樣在稽核時是否可行?原因是因為表單會隨著有些項目增減.

    2. 假使要發行,工作清單項目是否可以是空白?只留下例如 預計時間 實際時間 負責人等等

    謝謝~~

    • Joe Chang 2012-04-28 01:23:03

      你的問題(如表單是否得發行(發布?))涉及你組織在ISO程序上的規定,我不清楚你的狀況,所以恐怕不是一個簡單Yes or No的答案。
      重點可能在於你們組織對於內容變更的處理目前規定是如何呢?

      撇開你們公司的程序不談,關注點應該先放在怎麼把專案管好
      純粹就管理的角度而言
      1. Schedule應該不是一份表單,而應該是一份檔案
      2. Schedule自然該常態性的發布,讓組員了解狀況是很重要的
      3. 發布的內容當然都是過去的歷史資料以及未來的預估狀態。 這也是為何我會強調Schedule是個動態的模型。

  3. Varo Liou 2012-02-01 12:32:13 第 5 則

    我站在B&J的角度回答:『Oracel P6』!

    • Joe Chang 2012-02-01 15:52:44

      這當然也是一個選擇

  4. 小汀 2012-02-01 10:19:10 第 4 則

    有沒有可以推薦的軟體能用來製作涵蓋這麼多內容的schedule文件? 比如Microsoft Project可以嗎?

    • Joe Chang 2012-02-01 15:52:28

      其實還滿多工具都可以啊
      Project也可以
      不過用法要對才行就是~~

  5. halcyon 2010-06-09 18:48:39 第 3 則

    但不是每間公司針對每個專案都掛一位時程控制工程師
    所以...........

    • Joe Chang 2010-06-10 00:28:33

      國內專業的時程控制人員供需失衡,PM或是買方承辦人員如果有錢聘請顧問專業顧問是最好的方式,不然就要靠自己多下功夫了。我覺得幾個重點要先掌握到:


      1. 專案中關鍵的Deliverable(交付項目)是不是有以Milestone(里程碑)的方式,並且有合理時程預估。
      2. 專案開始後,要將真實進度(已完成部分)以及未來預估(未完成的工作)反應到時程中,並且和原始版本(Baseline)比對。
      3. 每期專案會議,廠商有責任說明時程差異的原因,以及未來的改進計畫。


      以上建議只是最基本的方針,其中還是有非常多的"眉角"是說不清處的,不然一些知名的公司也不會花大筆投資在這些地方了。如果你後續有更明確的問題,歡迎隨時上來提問喔~