【本章知識重點】
★ 依賴關係；
★ 網路圖及其繪製：（pdm, adm, gert）
★ 估算方法
★ 日曆
★ 約束條件：（強制日期/關鍵事件/里程碑）
★ 提前/滯後
★ pert /cpm /gert
★ 趕工/快速跟進：（兩者之間的定義與區別）
★ 資源平衡
★ 更新/修訂/重定基線
【電子筆記】
專案時間管理：為確保專案按時完成所要求的各項過程。
6.1 活動定義：確定產生各個專案可交付成果所必須進行的具體活動。
6.2 活動排序：確定各活動之間的依存關係，並形成文字記載。
6.3 活動所需時間估算：估算完成各項活動所需工時單位數。
6.4 進度制訂：分析活動順序、 活動所需時間與資源要求 ，以制訂專案進度。
6.5 進度控制：控制專案進度變化。
在某些專案中，特別是小專案中，活動排序，活動所需時間估算以及進度制訂之間關係往往密切到被視為乙個單一過程（例如它們可以由乙個個人在一段較短時間內完成）。但在本章中仍按不同過程進行介紹，因為每個過程所用的工具和技術各不相同。
作為專案計畫人員，我們不僅僅要知道專案時間管理的術語和簡單知識，更要學會做專案進度計畫的方法，學會作為專案團隊成員，如何將所有約束和選擇方案考慮到進度計畫中並指定進度計畫。
6.1 活動定義
活動定義涉及到確定為完成工作分解結構（wbs）規定的可交付成果與子可交付成果所必須進行的具體活動，並將其形成文字記載。此項過程暗含著所定義活動應保證實現專案目標的要求。
6.1.1 活動定義的投入
1. 工作分解結構（wbs）
工作分解結構是活動定義的主要投入。
2. 範圍說明書（scope statement）
範圍說明書中的專案論證和專案目標部分在活動定義中應坦率與直截了當的加以考慮。
3. 歷史資料（historical information）
專案活動定義時應當考慮歷史資料（過去的類似專案實際要求哪些活動）。
4. 制約因素（constraints）
指限制專案團隊選擇餘地的因素，使用所要求的最長的活動所需時間就是一例。
5. 假設（assumptions）
6. 專家判斷（expert judgement）
6.1.2 活動定義的工具與技術
1. 分解（de***position）
就活動定義過程而言，分解指把專案工作包進一步分解成更小的，更易於管理的部分，以提供更良好的管理控制。和範圍定義中所述的分解之間的主要區別是：這裡的最終產出是活動，而不是可交付成果。
工作分解結構和活動清單通常按先後順序制訂，工作分解結構是最終活動清單制訂的基礎。在某些應用領域，工作分解結構和活動清單同時制訂。
6. 樣板（templates）
以前專案的活動清單或其一部分，往往可用作新專案的樣板。樣板所列的活動還可包含技能資源以及所需時間的清單、風險的識別、預期的可交付成果、以及其它描述性資料。
6.1.3 活動定義的產出
1. 活動清單（activity list）
活動清單必須包括專案將要進行的所有活動。活動清單應安排成工作分解結構的延伸，以便既保證其內容完整，又不包括任何不必成為專案範圍一部分的活動。與工作分解結構一樣，活動清單應當包括每項活動的描述，以保證專案班子成員能理解該項工作應如何完成。
2. 輔助細節（supporting detail）
活動清單的輔助細節應記載在案並整理妥當，以便於其它專案管理過程使用。
輔助細節包括所有已確認假設與制約因素的文字記載。額外細節的數量因應用領域而異。
3. 工作分解結構更新（wbs updates）
以工作分解結構來確定需要進行哪些活動時，專案班子可能會發現某些可交付成果有所疏漏，或者發現可交付成果的描述有需要澄清或糾正之處。
所有此類更新都必須反映在工作分解結構以及其它相關的文字記載，例如成本估算之中。這些更新往往稱為細化，當專案採用新的或未經考驗的技術時，最容易出現此種情況。
6.2 活動排序
活動排序指識別與記載活動之間的邏輯關係。活動必須準確排序，只有這樣才能在以後制訂出符合實際、可以實現的進度。排序可以用電腦進行，也可以手工操作。
手工和自動操作還可以結合使用。對於較小專案，以及大專案早期階段詳細資料尚不具備時，手工操作往往更為有效。
6.2.1 活動排序的投入
1. 活動清單（activity list）
2. 產品描述（product description）
產品特徵往往會影響活動排序（例如乙個擬建廠區的平面布置，乙個軟體專案的子系統介面）。雖然這些影響常常明顯的反映在活動清單上，但一般仍應對產品描述進行審核，以確保其準確無誤。
3. 強制性依存關係（mandatory dependencies）
強制性依存關係指所從事工作性質中固有的依存關係。
它們往往涉及到一些實際的限制（例如：在施工專案中，在基礎完成之前，不可能進行上層建築的施工；在電子專案中，必須先製作原型機，然後才能進行測試）。
強制性依存關係又稱硬邏輯關係（hard logic）。
4. 可斟酌處理的依存關係（discretionary dependencies）
可斟酌處理的依存關係指由專案團隊所確定的依存關係。其使用宜謹慎從事（並要有完整的文字記載），因為它們可能會限制今後進度安排方案的選擇。可斟酌處理的依存關係通常根據以下方面的知識來定義：
某個具體應用領域內的「最佳方法」。
雖然也可採用其它可接受的排序方式，但希望採用某種具體排序的專案中的某些不尋常的方面。
可斟酌處理的依存關係也可稱為優先選用邏輯關係（preferred logic）、 優選邏輯關係（preferrential logic）或者軟邏輯關係（soft logic）。
5. 外部依存關係（external dependencies）
外部依存關係指涉及專案活動和非專案活動之間關係的依存關係。
例如軟體專案測試活動的進行，可能取決於由外部提供的硬體是否到位；施工專案的場地平整，可能要在環境聽證會之後才能動工。
6. 里程碑（milestones）
里程碑事件應成為活動排序的一部分，以保證滿足里程碑事件按期完成的要求。
6.2.2 活動排序的工具與技術
1. 優先順序圖法 （單代號網路圖）（pdm，precedence diagramming method）
這是一種（用方格或矩形）節點表示活動，並用表示依存關係的箭線將節點連線起來的一種專案網路圖的繪製法。
這種技術又稱活動的節點表示法（aon，activity-on-node），是大多數專案管理軟體包使用的方法。pdm可用手工或電腦完成。
pdm包括四種依存關係或先後關係：
完成對開始：後一活動的開始要等到前一活動的完成。
完成對完成：後一活動的完成要等到前一活動的完成。
開始對開始：後一活動的開始要等到前一活動的開始。
開始對完成：後一活動的完成要等到前一活動的開始。
在pdm中，完成對開始是最常用的邏輯關係型別。開始對完成關係很少用，通常僅有專門制訂進度的工程師才使用。在專案管理軟體使用開始對開始、完成對完成、和開始對完成關係，可以產生意想不到的結果，因為關於這些型別的關係如何應用，目前尚未取得一致看法。
2. 箭線圖法（雙代號網路圖）（adm，arrow diagramming method）
這是一種利用箭線表示活動，並在節點處將其連線起來，用節點表示其依存關係的一種專案網路圖的繪製法。
這種技術也叫活動箭線表示法（aoa，activity-on-arrow ） , 雖然其使用不如pdm那樣普遍，但仍然是某些應用領域所選用的技術。
adm只使用完成對開始依存關係，因此可能要使用虛工序才能正確地定義所有的邏輯關係。虛擬活動沒有歷時，不需要花費資源。
3. 條件繪圖法（conditional diagramming methods）
有些繪圖技術，例如圖形評審技術（gert）和系統動力學模型允許使用諸如迴路（例如，必須重複多次的試驗）或者有條件分枝（例如：只有檢查發現錯誤時才需要修改設計）這樣的非時序活動。pdm 和adm都不允許迴路或有條件分枝存在。
4. 網路樣板（***owrk templates）
可以利用標準化的網路加快專案網路圖的繪製。這些標準網路可以包括整個專案或其一部分。網路的一部分往往稱為子網路或者網路片段。
在專案包括若干相同或者幾乎相同的特徵時 （例如，高層辦公樓的樓層、藥品研製專案的臨床試驗、軟體開發專案的程式模組、或者開發專案的啟動階段），子網路就特別有用。
6.2.3 活動排序的產出
1. 專案網路圖（project ***work diagrams）
專案網路圖就是以圖的形式展示專案各活動（工序）之間的邏輯關係（依賴關係）。
1． pert：計畫評審技術（program evaluation and review technique）；
2． cpm：關鍵路徑法（critical patch method）
3． pdm：前導圖法 （precedence diagramming method）
2. 活動清單更新（activity list updates）
如同活動定義過程可以造成工作分解結構更新一樣，繪製專案網路圖時也會發現一項活動需要分解或者重新定義才能畫成其正確的邏輯關係的情況。
6.3 活動所需時間估算
活動所需時間估算就是根據關於專案範圍與資源的資訊估算所需時間 ，將其作為制訂進度所需投入的過程。
活動所需時間估算的投入一般來自專案班子中最熟悉某項具體活動性質的個人或集體。這項估算通常都是逐步細化與完善的，估算過程要考慮投入資料是否存在及其質量。因此，估算結果可以假定是逐步趨於準確，其質量優劣是已知的。
專案班子中最熟悉某項具體活動性質的個人或集體應當親自完成活動所需時間估計，或者至少對其進行審核。
估算完成某項活動所需工時單位數時，往往還要求考慮過程時間。大多數電腦日程安排軟體均以若干種不同的工時單位日曆來解決這個問題。
專案所需總時間也可用以下介紹的工具和技術進行估算，但以應用進度制訂的產出進行計算最為妥善。專案班子可將專案所需時間視為乙個概率分布（應用概率分析技術），或者視為乙個單點估計（應用確定性演算法技術）。
6.3.1 活動所需時間估算的投入
1. 活動清單（activity list）
2. 制約因素（constraints）
專案時間管理
專案管理 專案時間管理 05063 一 選擇 1.確定專案各個活動之間的依賴關係，並形成文件的專案過程是 b a 活動定義 b 活動排序 c 活動持續時間估計 d進度計畫制定 2.下列不屬於專案活動定義的輸出 結果 的是 c a 詳細依據 b 活動清單 c範圍說明 d更新的工作分解結構 3.下例專案...
專案時間管理
高等教育自學考試 實踐報告 題目 案例三案例九 考生姓名許瑾 准考證號 010 考核號 c68 考核教師 目錄案例三 專案經理的困擾2 問題1 小李應該為此專案產生的問題負責嗎2 問題2 試分析小李被撤換及失敗的原因有哪些?2 問題3 如果你是小李，面對這樣的問題你應該怎麼沒制定切實可行的專案計畫3...
專案時間管理
小張是負責某專案的專案經理。經過工作分解後，此專案的範圍已經明確，但是為了更好地對專案的開發過程進行有效監控，保證專案按期 保質完成，小張需要採用網路計畫技術對專案進度進行管理。經過分析，小張得到了一張表明工作先後關係及每項工作的初步時間估計的工作列表，如表22 1所示 表22 1 工作列表 問題1...