第六章 時程發展 課前指引 每一個專案最常被問到的問題，除了要花多少錢之外？應該就是多久可以完成了？要能回答這個問題，就需要仰賴專案規劃階段，將專案的時程完整發展出來。有專案時程後，才可以回答專案利害關係人對時程的種種關心

章節大綱 6-1 專案時程估算 6-5 估算活動工期 6-2 定義活動 6-6 發展時程 6-3 排序活動 6-4 估算活動資源

6-1 專案時程估算 每一個專案最常被問到的問題，除了要花多少錢之外？應該就是多久可以完成了？ 時程預估的困難度，會跟專案的特性有關。譬如：專案期間越長，當然困難度越高。專案涉及的新技術越多，準確度也越難掌握。專案成員的經驗、合作的默契，也都會是專按時程預估的影響因素之一。

6-1 專案時程估算 專案時程預估可以是由上而下，也可以是由下而上。

6-1 專案時程估算 由上而下估算 需要有很好的參考值，可能是公司以前做過相類似專案的歷史資料，或是業界所共同認可的基準值(bench mark)，或是由外部顧問公司買來的參考依據。 將這些參考值套用後，依據現有狀況，做些調整，估計出專案時程。

6-1 專案時程估算 由上而下估算 譬如：有一軟體開發專案，採用功能點(function point) 計算出有1600 個功能點。 假設業界標準是一個人月可以開發16 個功能點 1600 / 16 = 100 ( 人月) 如果專案成員有5 位工程師 100 / 5 = 20 ( 月) 專案預估需要20個月可以完成，如有必要，可以做些微調

6-1 專案時程估算 由上而下估算 比方預估軟體開發專案需要20 個月，各細項百分比，過去經驗如下： 收集需求需要3 個月 20 * 15% = 3 系統設計需要6 個月 20 * 30% = 6 開發測試需要10 個月 20 * 50% = 10 安裝上線需要1 個月 20 * 5% = 1 此方法既快速又省錢，是一種粗略的估算方法。 但是，如果選用的參考值準確度高，估算結果也不會差異太大

6-2 定義活動 由下而上估算 可以得到比較準確的時程預估值，然而，所需花費的時間與成本，也相對需要增加。 估算的起頭，會由專案範疇所發展出的工作包開始，經由幾個簡單步驟，可以發展出專案時程，如下圖示：

6-2 定義活動 活動定義由工作包開始，請對該工作包熟悉的專案成員分析，要完成該工作包需要進行哪些活動。 譬如ABC 專案是一個全新商場籌建專案，專案範疇除了硬體商場的建設與承租戶的招商之外，還包括要有一年、三年與五年營運規劃報告。

6-2 定義活動 專案工作分解結構圖(WBS) 如下圖：

6-2 定義活動 針對三年營運規劃書此一工作包，我們可以定義出以下幾個活動： 收集資料： 收集相關產業市場資訊 撰寫計畫書： 開始進行計劃書撰寫 審核計劃書： 請專家協助審閱計劃書內容 修正計劃書： 根據審閱意見，進行計劃書之修改 確認計劃書： 確認計劃書都已修正無誤

6-3 排序活動 活動與活動之間可能有些互有關聯，排時程之前，先要一一找出，定義好各自關係，以做為排程的基礎。

6-3 排序活動 活動邏輯關係 最常被使用的關係，是前後關係，稱為FS(Finish to Start) 關係。 當活動A 做完後，接下來活動B 才可以進行。

6-3 排序活動 活動邏輯關係 SS(Start to Start) 關係，代表的是兩個活動同時進行 。例如：吃早餐時，同時收聽晨間新聞。

6-3 排序活動 活動邏輯關係 FF(Finish to Finish) 關係，代表二個活動要同時完成，譬如：

6-3 排序活動 活動邏輯關係 SF(Start to Finish) 關係呢？就是活動A 開始後，活動B才算結束。

6-3 排序活動 提前與延後 為了要更貼近現實面，活動間關係還可以加上提前(Lead) 或是延後(Lag)。 譬如： 代表粉刷壁面結束3 天後，再開始進行貼壁紙的活動，因為需要等壁面都完全乾燥

6-3 排序活動 提前與延後 在接受同學報名結束前2 天，就開始製作旅遊手冊，以爭取時間，等報名截止人數確定後，在將分組名單加入手冊即可。提前與延後再配合活動關係，可以讓活動間關係變得更豐富。

6-3 排序活動 提前與延後 假設：活動A 需要4 天才可以完成，活動B 需要3 天。 活動A 在第一天開始，第四天結束。 FS-3 表示活動A 結束前3 天，活動B要開始。SS+1 表示活動A 開始1 天後，活動B 要開始。 FF 表示活動A 與活動B 要同時結束。

6-3 排序活動 提前與延後 承接上例，活動A 後來發現時間不夠，需要延長一天變成五天。 活動B 因為找到新方法，因此可以縮減一天，只需二天即可完成。 在不同活動關係下，會產生完全不一樣的時程。

6-4 估算活動資源 每一個活動需要的時間，會因排入資源的不同而有差異。 譬如一個活動，派6 個人一起工作，4 周可以完成。 如果因為資源有限，只有4 個人，那麼此活動，很顯然會需要6 周的時間，才足以完成。

6-4 估算活動資源 除了人數會影響活動所需時間之外，人員的經驗技術，也會有差別。 採用不同工具、使用不同方法，都會對活動時程預估，有重大影響。

6-4 估算活動資源 是不是我們都要用最好的人、最先進的設備以儘快完成專案呢?

6-4 估算活動資源 在專案規劃階段，我們就該針對各專案不同狀況，選擇最適當的方式來完成專案。 專案經理在必要時，可以和專案資助人一起討論，決定最適當方案。

6-4 估算活動資源 活動資源包括有人力、原料、設備與資金。 預估活動資源之前，我們需要有二份資料： 專案資源限制 專案資源行事曆

6-4 估算活動資源 專案資源限制1/2 沒有任何一個專案可以有無限的資源，專案管理的目的之一，就是要在有限的資源當中，發揮最大的效用。

6-4 估算活動資源 專案資源限制2/2 專案經理首先需要了解，專案當中有沒有哪些資源的限制 譬如： 專案成員有沒有人數的限制？ 有沒有哪些人員事先已經被指派到此專案？ 是否有先期協議，部份專案工作需由配合廠商負責？ 有沒有哪些機器設備有數量上限制？ 原料是否有固定配合廠商？ 原料價格是否公司事先已約定，無需再議？ 原料交貨期、數量是否有所限制？ 活動本身是否有先後關係、工作場所或是同時工作人數的限制？ 資源限制收集越齊全，對我們後續規劃越有幫助。

6-4 估算活動資源 專案資源行事曆 記載資源有空可資利用的時間。 特別針對稀有資源，許多專案都需要，資源的可使用時間，當然會嚴重影響到時程。 對已經確定需要的資源，早期掌握資源行事曆，可以更精確安排資源到各活動當中。

6-4 估算活動資源 資源安排 安排資源時有幾個考量點： 由最底層開始，底層活動安排完資源，再逐層累加上來 一次只考慮單一活動，且在正常狀況下 同時考量各種解決方案，決定最合適方式

6-4 估算活動資源 資源分解結構圖 專案活動都安排好資源後，逐一累加上去，專案需要的所有資源也就決定了，利用資源分解結構圖(RBS, Resource Breakdown Structure)完整呈現 資源分解結構圖以圖形方式，可以很清楚的表示專案所需要的各種資源情況，提供專案規劃時，對資源需求的通盤概念。

6-5 估算活動工期 活動資源決定後，接下來，就要預估在此資源條件下，活動需要多久時間可以完成，我們稱為活動工期(duration)。 如果此時專案成員已決定 優先請該活動的負責成員估算所需時間。經審核同意後，該負責估算成員，就該為自己的承諾負起如期，甚至超前完工的責任。 如果該部分活動是外包給廠商 請廠商提出時程表。 需經審核後，列入專案進行追蹤。 如果活動還沒有負責人 專案經理可以請對該活動較為熟悉的專案成員、顧問、客戶、其他專案關係人協助，預估出合理的工期。

6-5 估算活動工期 預估時有幾個必須注意的準則： 考慮單一活動即可，不要預期前一個相關活動的完成，會加速此活動的進行 依據已分派資源做為預估工期基礎 一天工作八小時，不考慮加班 積極型活動預估，採八成把握可以完成的工期，不需達100% 不需預先加緩衝時間，以應付意外狀況，那會是下一章風險預估範圍 預估時間單位要統一，不可以有些用週，有些用天，有些用時，容易混淆

6-6 發展時程 每一個活動的工期預估完後，依據活動與活動之間的先後排序，專案時程可以透過專案時程網絡圖(project schedule network diagram) 完整呈現。 以圖形方式，將專案所有活動，依照預先安排好的順序，有系統的呈現 專案活動由左邊開始，一直畫到右邊專案結束 以節點表示活動，箭頭表示關係，這種網絡圖又稱為節點圖示法(AON, Activity on Node)

6-6 發展時程 專案時程網絡圖 下圖為簡單的網絡圖，專案總共有A、B、C、D、E、F、G 八個活動 B 與C 活動都要結束後，活動E 才可以開始。 活動D 結束後，接著開始活動F。 活動G 需要等活動E 與F 都結束後，才可以開始。

6-6 發展時程 專案時程網絡圖 網絡圖不可以有循環活動，也不可以有選擇性流程 活動C 結束後，如果在狀況一下，執行活動E；在狀況二下，執行活動F。

6-6 發展時程 專案時程網絡圖 假設有一專案有A、B、C、D、E、F、G、H、I 共9 個活動，其前導活動如下表。 根據這份資料，我們可以畫出該專案之時程網絡圖如下： 專案時程網絡圖

6-6 發展時程 專案時程計算 網絡圖完成後，將每一個活動預估工期記載在活動節點上，依照活動順序累加下去，由左而右向前推進，就可以得到專案最終時程。 這種方式稱為前推法(forward pass)，可以計算出每一個活動的最早開始時間(ES, Early Start)，與最早可以完成的時間(EF, Early Finish)。

6-6 發展時程 專案時程計算 接續上一節的例題，我們把活動預估工期加上，成為下圖：

6-6 發展時程 專案時程計算 加入工期後的專案時程網絡圖： ES：early start 活動最早可以開始時間 ID： 活動的編號 EF：early finish 活動最早可以完成的時間 Du：duration 活動的預估工期

6-6 發展時程 專案時程計算1/2 活動A 預估工期為2 天，我們最早從第0 天開始，經過2 天，最早可以在第2 天完成。 活動B 與活動C 需要等活動A 結束後，才可以開始。因此，活動B 與活動C 最早可以開始時間，應該為第2 天。 活動B 預估工期為15 天，因此，最早可以完工日期為第17 天。 活動C 預估工期為10 天，因此，最早可以完工日期為第12 天。

6-6 發展時程 專案時程計算2/2 活動D 需要等活動B 與活動C 都結束後才可以開始，很明顯的，雖然活動C 比活動B 先結束，但是仍須等活動B 完成後，才可以進行下個活動。 最早可以開始時間應該為第17 天。 活動D 本身預估工期13天，所以，最早結束時間為第30 天。

6-6 發展時程 專案時程計算 依序向前推進，可以將整個時程計算出來，如下圖：

6-6 發展時程 關鍵路徑 關鍵路徑(critical path) 指的是專案中最長的那條路徑，它決定了專案的總時程。 在關鍵路徑上的活動，稱為關鍵活動(critical activity)。 任何一個關鍵活動延遲一天，專案時程就會延遲一天，完全沒有緩衝彈性。 在專案管理上，關鍵路徑上的活動，絕對要優先被照顧妥當，不容許有些許疏忽。

6-6 發展時程 關鍵路徑 找出關鍵路徑，可以從專案總時程往前推算，計算出每一個活動的最晚開始時間(LS, Late Start)，與最晚可以完成的時間(LF, Late Finish) 找出完全沒有延遲時間的活動，將這些活動路徑串連起來，就可以畫出專案的關鍵路徑出來，這種方法稱為後推法(backward pass)

6-6 發展時程 關鍵路徑 經過後推法計算後結果，網絡圖如下： LS：late start 活動最晚可以開始時間 LF：late finish 活動最晚可以完成的時間 SL：slack 活動可延遲時間

6-6 發展時程 關鍵路徑

6-6 發展時程 關鍵路徑

6-6 發展時程 關鍵路徑

6-6 發展時程 資源衝突 時程安排至此，表面上好像完成了。總時程有了，關鍵路徑也知道了，實際上，有很多專案的時程也就這樣確定了。 在資源未分派確定前，專案時程都不可以說是完成。

6-6 發展時程 資源衝突 譬如： 原本活動A 結束後，活動B 與活動C 可以同時併進。但是，如果活動B 與活動C 都需要小明，或是都需要動用到公司唯一一部機器時，就會造成所謂的資源衝突狀況。

6-6 發展時程 資源衝突 除非是能夠找到多餘的資源，避開衝突現象；否則就是要拉開活動A 與活動B 的執行時間，從併進變成順序進行，時程自然會拉長。 當資源分派到每一活動後，現今排程軟體都有提供資源分配表，可以查核資源是否有衝突，或是超過正常工作量。 當有資源超過正常100% 工作量時，我們就要進行資源撫平(resource leveling or resource smoothing)

6-6 發展時程 資源撫平 把資源使用狀況盡量安排平順，除了不超出既有資源數量以外，還要盡量平穩，避免有資源使用量忽高忽低，造成調度與管理上困難。 經過資源撫平調整後，專案時程往往會再往後延伸。

6-6 發展時程 時程縮短 專案時程規劃可以說是告一段落了 實務上，往往有很多時刻，專案時程依據專案範疇一路規劃下來，直到資源分派妥當，也做好資源撫平後，呈給老闆或是客戶。 老闆或客戶會告訴你，我們沒有那麼多時間給你，直接就將時程打八折。此時，需要將時程壓縮到大家都能同意的時間內

6-6 發展時程 時程縮短 在專案進行過程當中，也隨時有可能會因為以下原因，而被要求加速完成專案 專案進度已經明顯延誤 專案資源有更重要任務需要提前離開 爭取提前完工獎金 市場變化快速，需要早日進入市場搶先機

6-6 發展時程 時程壓縮有兩種方法： 快速跟進(fast tracking) 縮程法(crashing)

6-6 發展時程 快速跟進 基本上就是，把後面的活動盡可能往前，提早開始。 譬如：原來活動A 結束，接這活動B，然後活動C 如果沒有很強烈的依存關係，可以增加資源，讓活動B 在活動A 結束前就先搶時間開始。 這會需要增加成本，也會增加專案風險，對於時間的延誤，更沒有緩衝的空間

6-6 發展時程 縮程法 將專案活動重新檢視，看看是否可以藉由其他方式縮短活動工期，譬如： 只要能找到適合的替代方案，往往可以大幅縮減時程 增加人力 縮小範圍 降低品質 更換更有經驗的成員 增加機器設備 外包專業公司 加班⋯等等。 只要能找到適合的替代方案，往往可以大幅縮減時程 通常專案成本會增加、專案範圍可能縮減、或是專案品質會降低