姬麻咩七淘

※專案排程(Project scheduling)：用來展示專案如何、何時交付定義在專案範疇的產品、服務或成果，也可做為管理利害關係人期望的工具，並為績效報告提供依據。

※排程方法：要徑法(Critical Path Method, CPM)或敏捷式(Agile approach)。

※將專案特定資料(活動規畫、日期期程、資源相依關係、限制條件)輸入排程工具，如Microsoft Project、Project LIBRE(Free)，建立專案的時程模型(Schedule Model)。

※新興的實務作法：高不確定性、不可預測性，難定義長期範疇，依優先等級改變修改原計畫。

§迭代排程(Iterative scheduling)：代辦清單、使用者故事、優先順序--產出漸進的價值給客戶。

§依據需要的排程(On-demand scheduling)：看版系統(Kanban)--源自精益生產(Lean Manufacturing)的限制理論與拉式排程(Pull-based)技術概念。<TOYOTA>用來限制團隊正在進行的工作，以權衡需求與團隊的交付量；著重於資源的可用性。

※裁適的考量：生命週期手法、資源可用性、專案維度(複雜度、不確定性)、科技支持度。

※在敏捷式/調適性環境的考慮因素：短週期進行工作審查、提供迅速的回饋。

※Note：活動清單(定意活動) --> 專案時程網路圖(排序活動) + 期程估算(估算活動期程) --(發展時程)--> 時程基準 + 專案行事曆 --(管制時程)--> 時程預測值

6.1 規劃時程管理(Plan Schedule Management) [規劃過程組]

建立「規劃、發展、管理與管制專案時程」相關政策、程序與文件的過程，為專案提供專案時程管理的工作指引與方向。執行一次或在事先訂好的時機點進行。

OUTPUT

1. 時程管理計畫書(Schedule management plan)：建立

※專案時程模型發展：方法論及工具

※發布與迭代的長度

※準確度層級

※衡量單位：工時、人日等

※組織程序連結：WBS提供框架，允許估算時有所應變

※專案時程模型維護：更新狀態、紀錄進展

※管制門檻；監視時程績效時所用的變異門檻

※績效量測之原則：實獲值管理規則、實際績效量測規則

※報告格式。

6.2 定義活動(Define Activities) [規劃過程組]

將工作包分解為活動(一個人的工作，最小單元)，提供：估計、排程、執行、監視及管制的基準。 整個專案期間都要執行。

T/T

2. 分解：活動清單、WBS、WBS說明表，可以依序發展或是並行發展。WBS及WBS說明表是活動清單的基礎。團隊成員參與分解，能獲得較好、較精準的成果。

3. 湧浪式規劃：迭代規畫的技術。近期階段以詳細方式規劃(活動，WBS的工作包細分)，未來工作以較高層級方式規劃(已知的詳細層級，WBS的規劃包)。

OUTPUT

1. 活動清單：包括專案所需的時程活動。含一個活動識別碼及每個活動足夠的工作範疇敘述，確保所有團員了解需要完成哪些工作。湧浪式或敏捷式專案會隨專案進展更新活動清單。

2. 活動屬性：每項活動所具有的多重屬性，用來擴充對活動的描述，故項目會越來越多、對活動描述越來越清楚。如一開始可能只有活動識別碼、活動名稱，之後漸漸加入活動代碼、活動描述、前項活動、接續活動、邏輯關係、資源需求等。也用來辨識工作地理位置、負責人，以及發展時程。

3. 里程碑清單：專案中一個重要的點或事件。(為狀態說明、未耗工時)

6.3 排序活動(Sequence Activities) [規劃過程組]

將工作的邏輯次序予以文件化，考量專案限制，獲得最大效率。 整個專案期間都要執行。

§邏輯關係：除了第一個與最後一個外，每一個活動接連結：至少一個「前項活動」、至少一個「後續活動」。

§可使用專案管理軟體或人工進行，將專案活動從清單轉換成圖形，做為建立時程基準的第一步。

T/T

1. 順序圖示法(Precedence diagramming methed, PDM)：以節點表示活動，並使用一種或多種邏輯關係來顯示順序。

※完成-開始(FS)：前項完成，後面才能開始，最常用。

※完成-完成(FF)：等到前面完成，後面才能完成，如A寫文章、B修改文章。

※開始-開始(SS)：前面開始後，後面才能開始，如A灌漿、B抹平。

※開始-完成(SF)：後面開始，前面才能結束，如A舊系統、B新系統，交接班的關係，最少用。

2. 相依性：

※強制相依關係(Mandatory Dependencies)：協議要求、自然性質、硬邏輯、硬相依。

※刻意相依關係(Discretionary Dependencies)：優先的邏輯、軟邏輯、最佳實務。(最好這樣做，但商量後不這樣也沒關係，有可能產生風險)應有完整的記錄，因會產生任意的總浮時，並可能限制之後的排程選擇。採用快速跟進法時，這些關係應被審查及予以修正或移除。

※外部相依關係(External Dependencies)：專案活動與非專案活動之間的關係，在專案團隊的管制範圍外。

※內部相依關係(Internal Dependencies)：專案活動之間的次序關係，通常在專案團隊的管制範圍內。

3. 提前與延後(Leads and Lags)：

※提前：後續活動可提前開始的時間。

※延後：後續活動開始前的等待時間。

OUTPUT

1. 專案時程網路圖：呈現專案時程活動之邏輯關係(相依關係)的圖型。匯流(收斂)與分流(發散)的活動節點存在較大的風險。

6.4 估算活動期程(Estimate Activities Durations) [規劃過程組]

在已預估的資源內，估算完成個別活動所需工作時間量的過程，提供完成每個活動所需的時間。 整個專案期間都要執行。

§使用估算資訊：工作範疇、所需資源類型或技術水準、估算的資源數量、資源行事曆。

§可能影響預估的因素：期程的限制、投入的努力、資源形式、時程網路圖分析技術。

§由專案團隊中，對特定活動之工作內容本質「最熟悉的個人或團體」來進行估算。

§其他影響估算期程的因素：

○效益遞減規律(Law of Diminishing Returns)：當有多種投入時，單獨增加某一點投入，會很快達到一個高度，超過該點，增加投入能得到的產出會遞減。

○資源數量(Number of resources)：資源增加兩倍，不一定會使工作時間減半，反而有可能因風險產生額外期程。EX.人月神話、軟體業。

○科技的進步(Advances in technology)：可能影響期程與資源需求。

○團隊成員的積極性(Motivation of staff)：

   ●學生症候群(Student Syndrome)：又稱拖延症候群，在最後期限的最後一刻才致力工作。

   ●帕金森定律(Parkson's Law)：工作擴大去填滿可用時間。(早就做完，最後才講)

T/T

2. 類比估算法(Analogus estimating)：使用過去類似性質的專案，粗估，正確性較低。

3. 參數估算法(Parametric estimating)：依據歷史數據與專案參數使用演算法，ex. 工時 = 藍圖數 * 歷史參數(小時/藍圖)，依基礎資料的成熟度產生較高的準確度。

4. 三點估算法(Three-point estimating)：三角分布：tE = tM(最可能值，Most) + tO(最樂觀值，Optimistic) +tP(最悲觀值，Pessimistic) / 3

5. 由下而上估算法(Buttom-up estimating)：將WBS較低階層組件的期程、或成本的估計值予以累加，得到一個總和。較為準確。

6. 資料分析：

※風險除備分析(Reserve Analysis)：

§應變儲備(Contingency Reserve)：時程風險儲備，因應時程的不確定性。與已知的未知(Known-unknown)關聯，如成員生病、出現bug。為估算活動期程的百分比或固定時間，納入時程基準中。 。

§管理儲備(Management Reserve)：處理未知的未知(Unknown-unknown)的風險，不包含在時程基準內，但屬於整體專案期程之一部份，使用時需以變更申請來修改時程基準。

OUTPUT

1. 期程估算(Duration estimate)：完成專案活動、階段或專案所需的可能時間量化評量。不包含延後，但可包括一個可能的結果範圍。

2. 估算基礎：估算是如何發展的依據文件，假設事項與限制條件文件、可能的估算值範圍、最終估算值的信心水準、影響估算值的個別風險文件。

※範例：一專案樂觀估計值80天，最可能是100天，悲觀值140天，專案信心水準如何描述？

平均值 = (P + 4*M + O) / 6 = (140 + 4*100 + 80) / 6 =103

標準差 = (P - O) / 6 = (140 - 80) / 6 = 10

→ 平均值103天，正負誤差10天，信心水準在68.26%

→ 平均值103天，正負誤差20天，信心水準在95.46%

→ 平均值103天，正負誤差30天，信心水準在99.73%

6.5 發展時程(Develop Schedule) [規劃過程組]

分析活動順序、期程、資源需求與時程限制條件等，建立時程模型。 整個專案期間都要執行。

§基於最佳的可得資訊，時程模型可用來決定專案活動與里程碑的預定開始日期與完成日期。

§發展時程需要審查與調整期程估算、資源估算與時程儲備，以建立可用來追蹤時程基準的專案時程。

§活動的開始及結束日期決定後，負責的專案成員審查被分配到的活動，確認與資源行事歷或其他專案沒有衝突。

§確認是否存在邏輯關係衝突，在時程被基準化前確認是否需要資源撫平。

§修正與維護專案時程模型→6.6管制時程。

T/T

1. 時程網路分析(Schedule network analysis)：一種綜合性、產生專案「時程模型」的技術。如要徑法(下2)、資源優化技術(下3)、建模技術。

2. 要徑法(Critical Path Method, CPM)：用來估算專案的最短期程，使用前推法(Forward)、後推法(Backward)找出每個活動的最早開始(ES)、最早結束(EF)、最晚開始(LS)、最晚結束(LF)日期。

※要徑(Critical Path，CP)：專案時程網路圖中最長的路徑。該專案可能的最短完成期程。總浮時(LS-ES或LF-EF, Total float)通常為0。

※總浮時為正：由於時程限制條件，後推法算出的最晚完成日期較前推法最早完成日期晚所造成。

※總浮時為負：期程與邏輯關係違反了最晚日期的限制。負浮時分析有助於找到可能得加速方式，使延遲的時程重回正軌。

※自由浮時(Free Float)：接續活動的ES - 1 - 本活動的EF (最現實，因別人不想動ES)

3. 資源優化(Resource optimization)：調整活動的開始和完成日期，使其等於或少於可用的資源。

※資源撫平(Resource Leveling)：延長時程，將資源需求與可行的供給取得平衡(如一項資源在同時間分配給兩個活動)，通常使要徑提高，而浮時可以用來撫平資源。

※資源平滑(Resource Smoothing)：對時程內活動調整，使專案資源需求不超過預定資源限制。不變動要徑，活動只在原浮時內延遲，可能無法將所有資源最佳化。

4. 資料分析：

※假設情境分析法：評量專案時程在不利的情況下之可行性、儲備應變及回應計畫，以處理意外狀況的影響。

※模擬：大專案用，蒙地卡羅分析，呈現完成日期及機率分布。

6. 時程壓縮(Schedule Compression)：在不改變專案範疇的前提下，縮短或加速專案期程，並符合時程限制、滿足強制日期或其他時程目標。當錯過限制條件或原定完成日期時，浮時為負值。只用於要徑上的活動。

※趕工縮時法(Crashing)：高成本、花錢有效、加人加班。

※快速跟進法(Fast Tracking)：高風險、不花錢、活動重疊，可能導致重工、增加協調及品質風險。

8. 敏捷發布規劃：規劃發布時程(通常為3-6個月)，同時決定在此發布內要做幾次跌代或衝刺(Sprint)。

OUTPUT

1. 時程基準：由適當的關係利害人核準的專案時程模型。用來與實際成果比較之基礎，只能透過正式的變更管制過程來變更。

2. 專案時程：時程模型的產出，由圖形呈現：甘特圖(Gantt Charts，即長條圖，水平軸為時間刻度)、里程碑圖(Milestone Charts)、專案時程網路圖(無時間刻度-純邏輯圖、有時間刻度-邏輯長條圖)。

3. 時程資料：至少包含時程里程碑、排定的活動、活動屬性、假設及限制條件。支援時程細節的資訊：資源直方圖、備選時程方案、現金流預測、訂單與交付時程。

4. 專案行事曆：甘特圖變種，定義各個活動可運用的工作天與班次。(誰在哪天要上班)

6.6 管制時程(Control Schedule) [監視與管制過程組]

監視專案活動現況以更新專案進度，以及管理時程基準變更的過程。 整個專案期間都要執行。

§判斷專案目前狀態；影響造成時程變更的因素；考慮必要的時程儲備；判斷專案時程是否已經變更；實際變更時予以管理。

§敏捷式：執行回顧審查(Retrspective Reviews)，視需要予以校正、精進過程；重新調查待辦清單的優先性；確認每一次迭代可交付成果的產出、確認及允收情況；若有時程變更對其進行管理。

§外包時：向承包商與供應商了解里程碑狀態更新；時程的狀態審查與現地勘查，確保承包商報告的正確性與完整性。

T/T

1. 資料分析

※迭代燃盡圖(Iteration burndown chart)：追蹤迭代待辦清單內的剩餘工作，可計算出趨勢線，預測迭代完成後可能的變異從而採取適當行動。

※趨勢分析：檢視專案績效是改進或惡化。

※變異分析：檢是變異的原因與程度預測，決定是否採取矯正措施或預防措施。

2. 要徑法：沿著要徑比較實際進展，可以決定時程現狀。要徑產生的變異，會直接衝擊專案結束日期。評估要徑上的活動進度可以識別時程風險。

OUTPUT

2. 時程預測值(Schedule Forecasts)：在預測時間點依據當時的資訊與知識，對專案未來的狀況與事件進行預測與預估，且未來期望的績效是根據現況所提出的糾正或預防措施。