網(wǎng)站備案要關(guān)站嗎google網(wǎng)頁搜索
七.項目時間管理
7.1 項目進度的重要性
為什么要重視項目進度:在項目進行的過程之中會遇到變故。但是不論項目中發(fā)生了什么,時間總是在流逝,就可能會導致項目不可以在規(guī)定的時間完成。
7.2可能影響項目進度的因素
- 有員工離職
- 個人的工作方式和文化之間的差異
- 個人對時間進度的態(tài)度
- 不同國家間的法定假日不同
7.3什么是項目時間管理
簡單定義就是確保項目按時完成所需過程。
7.4項目時間管理主要的過程
- 計劃進度管理
是指確定將用于計劃,執(zhí)行和控制項目進度的政策,流程和文檔。這個過程的主要輸出是一個進度管理計劃。
舉個例子:
計劃進度管理
計劃進度管理是指在項目管理中,制定用于計劃、執(zhí)行和控制項目進度的政策、流程和文檔的過程。這個過程的核心目標是確保項目能夠按時完成,并有效管理時間相關(guān)的資源和活動。計劃進度管理的主要輸出是一個進度管理計劃,該計劃詳細說明了如何管理項目的時間安排和進度。
進度管理計劃通常包括以下內(nèi)容:
- 項目時間表:項目各個階段和任務(wù)的起止日期。
- 進度管理方法:用于跟蹤和控制項目進度的具體方法,如關(guān)鍵路徑法(CPM)或關(guān)鍵鏈項目管理(CCPM)。
- 進度控制機制:如何監(jiān)控項目進度,如何識別和解決進度偏差。
- 進度報告格式:項目進度報告的格式和頻率。
- 變更管理流程:如何處理進度變更請求,包括評估、批準和實施變更的步驟。
例子
假設(shè)一家軟件開發(fā)公司正在開發(fā)一個新的移動應(yīng)用程序,項目經(jīng)理需要制定一個進度管理計劃,以確保項目能夠按時完成。以下是一個詳細的例子,幫助你理解計劃進度管理的過程:
1.?確定項目時間表
項目經(jīng)理首先與項目團隊和客戶開會,確定項目的總體時間框架:
- 項目啟動日期:2023年5月1日
- 項目完成日期:2023年12月31日
項目經(jīng)理將項目分為幾個主要階段,并為每個階段設(shè)定具體的起止日期:
- 需求分析階段:2023年5月1日?-?2023年5月31日
- 系統(tǒng)設(shè)計階段:2023年6月1日?-?2023年6月30日
- 開發(fā)階段:
- 前端開發(fā):2023年7月1日?-?2023年8月15日
- 后端開發(fā):2023年7月1日?-?2023年8月15日
- 測試階段:
- 單元測試:2023年8月16日?-?2023年8月31日
- 集成測試:2023年9月1日?-?2023年9月15日
- 系統(tǒng)測試:2023年9月16日?-?2023年9月30日
- 部署階段:2023年10月1日?-?2023年10月15日
- 用戶驗收測試和上線:2023年10月16日?-?2023年10月31日
2.?選擇進度管理方法
項目經(jīng)理決定使用**關(guān)鍵路徑法(CPM)**來管理項目進度。CPM可以幫助項目經(jīng)理識別項目的關(guān)鍵路徑,即影響項目總工期的任務(wù)序列。
- 關(guān)鍵路徑:
- 需求分析?->?系統(tǒng)設(shè)計?->?前端開發(fā)?->?后端開發(fā)?->?單元測試?->?集成測試?->?系統(tǒng)測試?->?部署?->?用戶驗收測試和上線
項目經(jīng)理將重點關(guān)注關(guān)鍵路徑上的任務(wù),確保這些任務(wù)按時完成。
3.?制定進度控制機制
項目經(jīng)理制定了以下進度控制機制:
- 每周進度會議:每周召開一次項目進度會議,團隊成員匯報各自的任務(wù)進展和遇到的問題。
- 進度報告:每周提交一份詳細的進度報告,包括已完成的任務(wù)、正在進行中的任務(wù)和遇到的問題。
- 進度偏差分析:如果某個任務(wù)進度落后于計劃,項目經(jīng)理將進行偏差分析,找出原因,并制定糾正措施。
- 里程碑評審:在每個主要階段結(jié)束時,進行里程碑評審,確保階段目標已經(jīng)達成。
4.?確定進度報告格式
項目經(jīng)理制定了進度報告的格式,包括以下內(nèi)容:
- 項目名稱和日期
- 項目負責人
- 本周完成的任務(wù)
- 正在進行中的任務(wù)
- 遇到的問題和風險
- 下周計劃完成的任務(wù)
- 需要協(xié)調(diào)和支持的事項
5.?制定變更管理流程
項目經(jīng)理制定了以下變更管理流程:
- 變更請求提交:任何進度變更請求都需要提交變更請求表(Change?Request?Form),包括變更內(nèi)容、理由和影響。
- 變更評估:項目經(jīng)理和項目團隊評估變更請求的可行性和影響。
- 變更批準:變更請求經(jīng)過評估后,由項目經(jīng)理批準或拒絕。
- 變更實施:批準的變更請求由相應(yīng)的團隊成員實施。
- 變更記錄:所有變更請求的評估結(jié)果、實施情況和驗證結(jié)果都會被記錄在變更管理數(shù)據(jù)庫中。
6.?進度管理計劃的實施和監(jiān)控
在項目進行過程中,項目經(jīng)理嚴格按照進度管理計劃執(zhí)行:
- 每周召開進度會議,跟蹤項目進展。
- 定期提交進度報告,確保所有團隊成員了解項目狀態(tài)。
- 及時處理進度偏差,確保項目按時完成。
總結(jié)
通過制定詳細的進度管理計劃,項目經(jīng)理能夠有效地管理項目的時間安排和進度,確保項目按時完成。進度管理計劃不僅包括項目時間表,還包括進度管理方法、進度控制機制、進度報告格式和變更管理流程。通過嚴格執(zhí)行進度管理計劃,項目團隊可以更好地控制項目進度,減少進度偏差,提高項目的成功率。
- 定義活動(acitvity)
活動(activity)或任務(wù)(task)是工作的組成要素,通常出現(xiàn)在工作分解結(jié)構(gòu)中。有預計的工期,成本和資源要求。逐個過程的主要輸出是活動清單,活動屬性,里程碑清單和更新的項目管理計劃。
舉個例子:
在項目管理中,活動(Activity)或任務(wù)(Task)是構(gòu)成項目工作的基本單元,通常出現(xiàn)在工作分解結(jié)構(gòu)(WBS)中。每個活動或任務(wù)都有預計的工期、成本和資源要求。在項目計劃過程中,這些活動或任務(wù)會被詳細定義和管理,其主要輸出包括:
- 活動清單(Activity?List)
- 活動屬性(Activity?Attributes)
- 里程碑清單(Milestone?List)
- 更新的項目管理計劃(Updated?Project?Management?Plan)
以下是一個具體的例子,幫助你理解這些概念:
例子背景
假設(shè)一家公司正在開發(fā)一個在線學習平臺,項目團隊已經(jīng)完成了工作分解結(jié)構(gòu)(WBS),并確定了以下主要任務(wù):
1.需求分析
2.系統(tǒng)設(shè)計
3.前端開發(fā)
4.后端開發(fā)
5.測試
6.部署
7.用戶驗收測試
8.上線
每個任務(wù)都有具體的活動組成,以下是詳細的例子:
1. 需求分析
活動清單(Activity List)
- 1.1 用戶需求調(diào)研
- 預計工期:2周
- 成本:$5,000(調(diào)研費用)
- 資源要求:
- 1名業(yè)務(wù)分析師
- 1名用戶體驗設(shè)計師
- 1.2 需求規(guī)格說明書編寫
- 預計工期:3周
- 成本:$7,500(編寫和審核費用)
- 資源要求:
- 1名業(yè)務(wù)分析師
- 1名項目經(jīng)理
活動屬性(Activity Attributes)
- 活動名稱:用戶需求調(diào)研
- 活動描述:與客戶和最終用戶進行訪談,收集需求并編寫調(diào)研報告。
- 前置任務(wù):無
- 后置任務(wù):需求規(guī)格說明書編寫
- 負責人:張偉(業(yè)務(wù)分析師)
- 里程碑:完成用戶需求調(diào)研報告
里程碑清單(Milestone List)
- 里程碑1:完成用戶需求調(diào)研(2023年5月15日)
- 里程碑2:完成需求規(guī)格說明書(2023年5月31日)
更新的項目管理計劃
- 進度計劃更新:將需求分析階段的起止日期更新為2023年5月1日?-?2023年5月31日。
- 資源計劃更新:分配1名業(yè)務(wù)分析師和1名用戶體驗設(shè)計師到需求分析任務(wù)。
- 預算更新:將需求分析階段的預算更新為$12,500。
2. 系統(tǒng)設(shè)計
活動清單(Activity List)
- 2.1 系統(tǒng)架構(gòu)設(shè)計
- 預計工期:2周
- 成本:$10,000(設(shè)計費用)
- 資源要求:
- 1名系統(tǒng)架構(gòu)師
- 1名技術(shù)負責人
- 2.2 數(shù)據(jù)庫設(shè)計
- 預計工期:2周
- 成本:$8,000(設(shè)計費用)
- 資源要求:
- 1名數(shù)據(jù)庫設(shè)計師
- 1名后端開發(fā)人員
活動屬性(Activity Attributes)
- 活動名稱:系統(tǒng)架構(gòu)設(shè)計
- 活動描述:設(shè)計系統(tǒng)的整體架構(gòu),包括技術(shù)選型、模塊劃分和接口設(shè)計。
- 前置任務(wù):完成需求分析
- 后置任務(wù):數(shù)據(jù)庫設(shè)計
- 負責人:李強(系統(tǒng)架構(gòu)師)
- 里程碑:完成系統(tǒng)架構(gòu)設(shè)計
里程碑清單(Milestone List)
- 里程碑3:完成系統(tǒng)架構(gòu)設(shè)計(2023年6月15日)
- 里程碑4:完成數(shù)據(jù)庫設(shè)計(2023年6月30日)
更新的項目管理計劃
- 進度計劃更新:將系統(tǒng)設(shè)計階段的起止日期更新為2023年6月1日?-?2023年6月30日。
- 資源計劃更新:分配1名系統(tǒng)架構(gòu)師和1名數(shù)據(jù)庫設(shè)計師到系統(tǒng)設(shè)計任務(wù)。
- 預算更新:將系統(tǒng)設(shè)計階段的預算更新為$18,000。
3. 前端開發(fā)
活動清單(Activity List)
- 3.1 用戶界面設(shè)計
- 預計工期:2周
- 成本:$7,000(設(shè)計費用)
- 資源要求:
- 1名UI設(shè)計師
- 1名前端開發(fā)人員
- 3.2 前端功能開發(fā)
- 預計工期:4周
- 成本:$15,000(開發(fā)費用)
- 資源要求:
- 2名前端開發(fā)人員
活動屬性(Activity Attributes)
- 活動名稱:用戶界面設(shè)計
- 活動描述:設(shè)計用戶界面原型,并與客戶確認。
- 前置任務(wù):完成系統(tǒng)設(shè)計
- 后置任務(wù):前端功能開發(fā)
- 負責人:王芳(UI設(shè)計師)
- 里程碑:完成用戶界面設(shè)計
里程碑清單(Milestone List)
- 里程碑5:完成用戶界面設(shè)計(2023年7月15日)
- 里程碑6:完成前端功能開發(fā)(2023年8月15日)
更新的項目管理計劃
- 進度計劃更新:將前端開發(fā)階段的起止日期更新為2023年7月1日?-?2023年8月15日。
- 資源計劃更新:分配2名前端開發(fā)人員和1名UI設(shè)計師到前端開發(fā)任務(wù)。
- 預算更新:將前端開發(fā)階段的預算更新為$22,000。
總結(jié)
通過詳細的活動清單、活動屬性和里程碑清單,項目團隊可以更好地管理和控制項目的進度、成本和資源。每個活動或任務(wù)都有明確的負責人、預計工期、成本和資源要求,確保項目能夠按時、按預算完成。
這些輸出不僅幫助項目團隊跟蹤項目進展,還為項目計劃的更新提供了依據(jù)。通過不斷更新項目管理計劃,項目團隊可以及時調(diào)整項目進度、資源分配和預算,確保項目目標的實現(xiàn)。
- 排序活動
是指識別和記錄項目活動之間的關(guān)系。這個過程的主要輸出包括項目的進度網(wǎng)絡(luò)圖和更新的項目文檔。
舉個例子:
排序活動的步驟
1.
識別活動:
-
- 確定項目中的所有活動或任務(wù),這些活動通常來自工作分解結(jié)構(gòu)(WBS)。
2.
確定依賴關(guān)系:
-
- 識別活動之間的依賴關(guān)系。常見的依賴關(guān)系類型包括:
- 完成到開始(Finish-to-Start, FS):前一個活動必須完成,后一個活動才能開始。
- 開始到開始(Start-to-Start, SS):前一個活動開始后,后一個活動才能開始。
- 完成到完成(Finish-to-Finish, FF):前一個活動完成后,后一個活動才能完成。
- 開始到完成(Start-to-Finish, SF):前一個活動開始后,后一個活動才能完成。
- 識別活動之間的依賴關(guān)系。常見的依賴關(guān)系類型包括:
3.
繪制進度網(wǎng)絡(luò)圖:
-
- 使用網(wǎng)絡(luò)圖(如前導圖法或箭線圖法)來表示活動之間的關(guān)系和依賴。
4.
更新項目文檔:
-
- 將排序活動的成果更新到項目文檔中,包括進度計劃、項目管理計劃等。
例子
假設(shè)一家公司正在開發(fā)一個在線學習平臺,項目團隊已經(jīng)完成了工作分解結(jié)構(gòu)(WBS),并確定了以下主要任務(wù):
1.需求分析
2.系統(tǒng)設(shè)計
3.前端開發(fā)
4.后端開發(fā)
5.測試
6.部署
7.用戶驗收測試
8.上線
項目團隊需要對這些活動進行排序,確定它們之間的依賴關(guān)系,并繪制進度網(wǎng)絡(luò)圖。
1. 識別活動
項目團隊已經(jīng)識別了以下主要活動:
- 需求分析
- 系統(tǒng)設(shè)計
- 前端開發(fā)
- 后端開發(fā)
- 測試
- 部署
- 用戶驗收測試
- 上線
2. 確定依賴關(guān)系
項目團隊確定了以下依賴關(guān)系:
- 需求分析必須在系統(tǒng)設(shè)計之前完成(FS)。
- 系統(tǒng)設(shè)計必須在前端開發(fā)和后端開發(fā)之前完成(FS)。
- 前端開發(fā)和后端開發(fā)可以并行進行(SS)。
- 前端開發(fā)和后端開發(fā)完成后,才能開始測試(FS)。
- 測試必須在部署之前完成(FS)。
- 部署必須在用戶驗收測試之前完成(FS)。
- 用戶驗收測試必須在上線之前完成(FS)。
3. 繪制進度網(wǎng)絡(luò)圖
項目團隊使用前導圖法(Precedence?Diagramming?Method,?PDM)繪制了以下進度網(wǎng)絡(luò)圖:
取消自動換行
復制
需求分析 (FS) -> 系統(tǒng)設(shè)計 (FS) -> 前端開發(fā) (FS) -> 測試 (FS) -> 部署 (FS) -> 用戶驗收測試 (FS) -> 上線
???????????????????????????? └-> 后端開發(fā) (FS) -┘
- 需求分析完成后,才能開始系統(tǒng)設(shè)計。
- 系統(tǒng)設(shè)計完成后,前端開發(fā)和后端開發(fā)可以并行進行。
- 前端開發(fā)和后端開發(fā)都完成后,才能開始測試。
- 測試完成后,才能進行部署。
- 部署完成后,才能進行用戶驗收測試。
- 用戶驗收測試完成后,才能上線。
4. 更新項目文檔
項目團隊將排序活動的成果更新到項目文檔中:
- 進度網(wǎng)絡(luò)圖:將上述網(wǎng)絡(luò)圖添加到項目進度計劃中。
- 項目管理計劃更新:
- 進度計劃更新:根據(jù)網(wǎng)絡(luò)圖更新項目進度計劃,明確各項任務(wù)的開始和結(jié)束日期。
- 資源計劃更新:根據(jù)任務(wù)順序和依賴關(guān)系,調(diào)整資源分配計劃。
- 風險管理計劃更新:識別潛在的進度風險,并制定相應(yīng)的風險應(yīng)對措施。
進度網(wǎng)絡(luò)圖示例
以下是上述依賴關(guān)系的進度網(wǎng)絡(luò)圖示例:
取消自動換行
復制
[需求分析] --FS--> [系統(tǒng)設(shè)計] --FS--> [前端開發(fā)] --FS--> [測試] --FS--> [部署] --FS--> [用戶驗收測試] --FS--> [上線]
????????????????????????????? └--> [后端開發(fā)] -FS-┘
- FS?表示“完成到開始”依賴關(guān)系。
- SS?表示“開始到開始”依賴關(guān)系(在本例中未使用)。
總結(jié)
通過排序活動,項目團隊可以明確各項任務(wù)之間的依賴關(guān)系和順序,繪制出項目的進度網(wǎng)絡(luò)圖,并更新項目文檔。這不僅有助于制定合理的項目進度計劃,還能幫助項目團隊識別潛在的進度風險,并制定相應(yīng)的風險應(yīng)對措施。
在上述例子中,排序活動幫助項目團隊確定了各項任務(wù)的具體順序和依賴關(guān)系,確保項目能夠按時、按計劃進行。
- 估算活動資源
是指估算一個團隊應(yīng)該使用多少資源(resource)--人力,設(shè)備和原料來執(zhí)行項目活動。這個過程的主要輸出是活動資源需求,資源分解結(jié)構(gòu)和更新的項目文檔。
舉個例子:
1)估算活動資源
估算活動資源是指在項目管理中,估算完成每個項目活動所需的各種資源,包括人力、設(shè)備和原料。這個過程的主要輸出包括活動資源需求(Activity?Resource?Requirements)、資源分解結(jié)構(gòu)(Resource?Breakdown?Structure,?RBS)以及更新的項目文檔。通過估算活動資源,項目團隊可以明確每個任務(wù)所需的資源類型和數(shù)量,從而更有效地進行資源分配和管理。
以下是詳細的解釋,并附有一個具體的例子,幫助你更好地理解這個過程。
估算活動資源的步驟
1.
識別活動:
-
- 確定項目中的所有活動或任務(wù),這些活動通常來自工作分解結(jié)構(gòu)(WBS)。
2.
確定資源需求:
-
- 估算每個活動所需的資源類型和數(shù)量,包括:
- 人力資源:如開發(fā)人員、測試人員、項目經(jīng)理等。
- 設(shè)備資源:如計算機、服務(wù)器、測試設(shè)備等。
- 原料資源:如軟件許可證、建筑材料等。
- 估算每個活動所需的資源類型和數(shù)量,包括:
3.
評估資源可用性:
-
- 評估組織內(nèi)部或外部可用的資源,確保資源需求與資源可用性相匹配。
4.
制定資源分解結(jié)構(gòu)(RBS):
-
- 將資源按類別和層次結(jié)構(gòu)進行分解,形成資源分解結(jié)構(gòu)。
5.
更新項目文檔:
-
- 將估算結(jié)果更新到項目文檔中,包括項目計劃、資源計劃等。
例子
假設(shè)一家公司正在開發(fā)一個在線學習平臺,項目團隊已經(jīng)完成了工作分解結(jié)構(gòu)(WBS),并確定了以下主要任務(wù):
1.需求分析
2.系統(tǒng)設(shè)計
3.前端開發(fā)
4.后端開發(fā)
5.測試
6.部署
7.用戶驗收測試
8.上線
項目團隊需要對每個任務(wù)進行資源估算,以下是詳細的例子:
1. 需求分析
活動資源需求(Activity Resource Requirements)
- 人力資源:
- 1名業(yè)務(wù)分析師(負責用戶需求調(diào)研和需求規(guī)格說明書編寫)
- 1名用戶體驗設(shè)計師(負責用戶界面原型設(shè)計)
- 設(shè)備資源:
- 每人1臺筆記本電腦
- 1臺服務(wù)器用于存儲和共享需求文檔
- 原料資源:
- 需求分析軟件許可證(如JIRA,?Confluence)
- 辦公用品(如紙張、筆)
資源分解結(jié)構(gòu)(Resource Breakdown Structure, RBS)
取消自動換行
復制
解釋
需求分析
├── 人力資源
│?? ├── 業(yè)務(wù)分析師
│?? └── 用戶體驗設(shè)計師
├── 設(shè)備資源
│?? ├── 筆記本電腦
│? ?└── 服務(wù)器
└── 原料資源
??? ├── 軟件許可證
??? └── 辦公用品
更新的項目文檔
- 項目計劃更新:
- 將需求分析的資源需求更新到項目計劃中,包括人力資源、設(shè)備資源和原料資源。
- 資源計劃更新:
- 分配1名業(yè)務(wù)分析師和1名用戶體驗設(shè)計師到需求分析任務(wù)。
- 預訂所需的設(shè)備資源和原料資源。
2. 系統(tǒng)設(shè)計
活動資源需求(Activity Resource Requirements)
- 人力資源:
- 1名系統(tǒng)架構(gòu)師(負責系統(tǒng)架構(gòu)設(shè)計)
- 1名數(shù)據(jù)庫設(shè)計師(負責數(shù)據(jù)庫設(shè)計)
- 設(shè)備資源:
- 每人1臺高性能筆記本電腦
- 1臺服務(wù)器用于存儲和共享設(shè)計文檔
- 原料資源:
- 系統(tǒng)設(shè)計軟件許可證(如Microsoft?Visio,?Lucidchart)
- 辦公用品(如紙張、筆)
資源分解結(jié)構(gòu)(Resource Breakdown Structure, RBS)
取消自動換行
復制
解釋
系統(tǒng)設(shè)計
├── 人力資源
│?? ├── 系統(tǒng)架構(gòu)師
│?? └── 數(shù)據(jù)庫設(shè)計師
├── 設(shè)備資源
│?? ├── 高性能筆記本電腦
│?? └── 服務(wù)器
└── 原料資源
??? ├── 軟件許可證
??? └── 辦公用品
更新的項目文檔
- 項目計劃更新:
- 將系統(tǒng)設(shè)計的資源需求更新到項目計劃中,包括人力資源、設(shè)備資源和原料資源。
- 資源計劃更新:
- 分配1名系統(tǒng)架構(gòu)師和1名數(shù)據(jù)庫設(shè)計師到系統(tǒng)設(shè)計任務(wù)。
- 預訂所需的設(shè)備資源和原料資源。
3. 前端開發(fā)
活動資源需求(Activity Resource Requirements)
- 人力資源:
- 2名前端開發(fā)人員(負責用戶界面開發(fā))
- 設(shè)備資源:
- 每人1臺高性能筆記本電腦
- 1臺服務(wù)器用于代碼存儲和版本控制
- 原料資源:
- 前端開發(fā)軟件許可證(如Visual?Studio?Code,?Adobe?Creative?Cloud)
- 辦公用品(如紙張、筆)
資源分解結(jié)構(gòu)(Resource Breakdown Structure, RBS)
取消自動換行
復制
解釋
前端開發(fā)
├── 人力資源
│?? └── 前端開發(fā)人員
├── 設(shè)備資源
│?? ├── 高性能筆記本電腦
│?? └── 服務(wù)器
└── 原料資源
??? ├── 軟件許可證
??? └── 辦公用品
更新的項目文檔
- 項目計劃更新:
- 將前端開發(fā)的資源需求更新到項目計劃中,包括人力資源、設(shè)備資源和原料資源。
- 資源計劃更新:
- 分配2名前端開發(fā)人員到前端開發(fā)任務(wù)。
- 預訂所需的設(shè)備資源和原料資源。
4. 后端開發(fā)
活動資源需求(Activity Resource Requirements)
- 人力資源:
- 2名后端開發(fā)人員(負責服務(wù)器端邏輯和數(shù)據(jù)庫開發(fā))
- 設(shè)備資源:
- 每人1臺高性能筆記本電腦
- 1臺服務(wù)器用于代碼存儲和版本控制
- 原料資源:
- 后端開發(fā)軟件許可證(如IntelliJ?IDEA,?MySQL?Workbench)
- 辦公用品(如紙張、筆)
資源分解結(jié)構(gòu)(Resource Breakdown Structure, RBS)
取消自動換行
復制
解釋
后端開發(fā)
├── 人力資源
│?? └── 后端開發(fā)人員
├── 設(shè)備資源
│?? ├── 高性能筆記本電腦
│?? └── 服務(wù)器
└── 原料資源
??? ├── 軟件許可證
??? └── 辦公用品
更新的項目文檔
- 項目計劃更新:
- 將后端開發(fā)的資源需求更新到項目計劃中,包括人力資源、設(shè)備資源和原料資源。
- 資源計劃更新:
- 分配2名后端開發(fā)人員到后端開發(fā)任務(wù)。
- 預訂所需的設(shè)備資源和原料資源。
5. 測試
活動資源需求(Activity Resource Requirements)
- 人力資源:
- 2名測試人員(負責功能測試和用戶驗收測試)
- 設(shè)備資源:
- 每人1臺筆記本電腦
- 1臺服務(wù)器用于測試環(huán)境
- 原料資源:
- 測試軟件許可證(如Selenium,?JUnit)
- 辦公用品(如紙張、筆)
資源分解結(jié)構(gòu)(Resource Breakdown Structure, RBS)
取消自動換行
復制
解釋
測試
├── 人力資源
│?? └── 測試人員
├── 設(shè)備資源
│?? ├── 筆記本電腦
│?? └── 服務(wù)器
└── 原料資源
??? ├── 軟件許可證
??? └── 辦公用品
更新的項目文檔
- 項目計劃更新:
- 將測試的資源需求更新到項目計劃中,包括人力資源、設(shè)備資源和原料資源。
- 資源計劃更新:
- 分配2名測試人員到測試任務(wù)。
- 預訂所需的設(shè)備資源和原料資源。
總結(jié)
通過估算活動資源,項目團隊可以明確每個任務(wù)所需的資源類型和數(shù)量,并制定詳細的資源計劃。這不僅有助于資源的有效分配和管理,還能提高項目的成功率。在上述例子中,估算活動資源幫助項目團隊確定了每個任務(wù)所需的人力、設(shè)備和原料,并更新了項目文檔,確保項目能夠按時、按預算完成。
- 估算活動工期
是指估算完成單項活動所需的工作時間。這個過程的主要輸出包括活動工期估算和更新項目文檔。
舉個例子:
估算活動工期的步驟
1.
識別活動:
-
- 確定項目中的所有活動或任務(wù),這些活動通常來自工作分解結(jié)構(gòu)(WBS)。
2.
確定活動資源:
-
- 明確每個活動所需的資源,包括人力、設(shè)備和原料等。資源的需求和可用性會直接影響活動的工期。
3.
估算活動工期:
-
- 使用以下方法估算每個活動的工期:
- 專家判斷:依靠有經(jīng)驗的項目經(jīng)理或?qū)<业呐袛唷?/li>
- 類比估算:根據(jù)類似項目的歷史數(shù)據(jù)來估算當前項目的工期。
- 參數(shù)估算:使用數(shù)學模型或統(tǒng)計方法,根據(jù)已知參數(shù)(如工作量、資源數(shù)量)來估算工期。
- 三點算:使用樂觀時間(O)、最可能時間(M)和悲觀時間(P)來計算期望工期,公式為?(O?+?4M?+?P)?/?6。
- 使用以下方法估算每個活動的工期:
4.
考慮資源可用性:
-
- 考慮資源的可用性和工作時間,例如工作日、加班時間、假期等。
5.
更新項目文檔:
-
- 將估算結(jié)果更新到項目文檔中,包括項目進度計劃、項目管理計劃等。
例子
假設(shè)一家公司正在開發(fā)一個在線學習平臺,項目團隊已經(jīng)完成了工作分解結(jié)構(gòu)(WBS),并確定了以下主要任務(wù):
1.需求分析
2.系統(tǒng)設(shè)計
3.前端開發(fā)
4.后端開發(fā)
5.測試
6.部署
7.用戶驗收測試
8.上線
項目團隊需要對每個任務(wù)的工期進行估算,以下是詳細的例子:
1. 需求分析
活動資源需求
- 人力資源:
- 1名業(yè)務(wù)分析師
- 1名用戶體驗設(shè)計師
- 設(shè)備資源:
- 每人1臺筆記本電腦
- 1臺服務(wù)器
活動工期估算
- 專家判斷:
- 項目經(jīng)理根據(jù)以往類似項目的經(jīng)驗,估算需求分析需要2周時間。
- 類比估算:
- 參考類似項目的歷史數(shù)據(jù),需求分析通常需要1.5到2周。
- 參數(shù)估算:
- 假設(shè)需求分析的工作量為80小時,業(yè)務(wù)分析師和用戶體驗設(shè)計師每周工作40小時,則工期為2周。
- 三點估算:
- 樂觀時間(O):1.5周
- 最可能時間(M):2周
- 悲觀時間(P):2.5周
- 期望工期?=?(1.5?+?4*2?+?2.5)?/?6?=?2周
更新項目文檔
- 項目進度計劃更新:
- 將需求分析的工期更新為2周,并將其納入項目進度計劃。
- 項目文檔更新:
- 更新需求分析的任務(wù)描述和工期。
2. 系統(tǒng)設(shè)計
活動資源需求
- 人力資源:
- 1名系統(tǒng)架構(gòu)師
- 1名數(shù)據(jù)庫設(shè)計師
- 設(shè)備資源:
- 每人1臺高性能筆記本電腦
- 1臺服務(wù)器
活動工期估算
- 專家判斷:
- 項目經(jīng)理根據(jù)以往類似項目的經(jīng)驗,估算系統(tǒng)設(shè)計需要3周時間。
- 類比估算:
- 參考類似項目的歷史數(shù)據(jù),系統(tǒng)設(shè)計通常需要2.5到3周。
- 參數(shù)估算:
- 假設(shè)系統(tǒng)設(shè)計的工作量為120小時,系統(tǒng)架構(gòu)師和數(shù)據(jù)庫設(shè)計師每周工作40小時,則工期為3周。
- 三點估算:
- 樂觀時間(O):2.5周
- 最可能時間(M):3周
- 悲觀時間(P):3.5周
- 期望工期?=?(2.5?+?4*3?+?3.5)?/?6?=?3周
更新項目文檔
- 項目進度計劃更新:
- 將系統(tǒng)設(shè)計的工期更新為3周,并將其納入項目進度計劃。
- 項目文檔更新:
- 更新系統(tǒng)設(shè)計的任務(wù)描述和工期。
3. 前端開發(fā)
活動資源需求
- 人力資源:
- 2名前端開發(fā)人員
- 設(shè)備資源:
- 每人1臺高性能筆記本電腦
- 1臺服務(wù)器
活動工期估算
- 專家判斷:
- 項目經(jīng)理根據(jù)以往類似項目的經(jīng)驗,估算前端開發(fā)需要4周時間。
- 類比估算:
- 參考類似項目的歷史數(shù)據(jù),前端開發(fā)通常需要3.5到4周。
- 參數(shù)估算:
- 假設(shè)前端開發(fā)的工作量為160小時,2名前端開發(fā)人員每周工作40小時,則工期為2周。
- 三點估算:
- 樂觀時間(O):3周
- 最可能時間(M):4周
- 悲觀時間(P):5周
- 期望工期?=?(3?+?4*4?+?5)?/?6?=?4周
更新項目文檔
- 項目進度計劃更新:
- 將前端開發(fā)的工期更新為4周,并將其納入項目進度計劃。
- 項目文檔更新:
- 更新前端開發(fā)的任務(wù)描述和工期。
4. 后端開發(fā)
活動資源需求
- 人力資源:
- 2名后端開發(fā)人員
- 設(shè)備資源:
- 每人1臺高性能筆記本電腦
- 1臺服務(wù)器
活動工期估算
- 專家判斷:
- 項目經(jīng)理根據(jù)以往類似項目的經(jīng)驗,估算后端開發(fā)需要4周時間。
- 類比估算:
- 參考類似項目的歷史數(shù)據(jù),后端開發(fā)通常需要3.5到4周。
- 參數(shù)估算:
- 假設(shè)后端開發(fā)的工作量為160小時,2名后端開發(fā)人員每周工作40小時,則工期為2周。
- 三點估算:
- 樂觀時間(O):3周
- 最可能時間(M):4周
- 悲觀時間(P):5周
- 期望工期?=?(3?+?4*4?+?5)?/?6?=?4周
更新項目文檔
- 項目進度計劃更新:
- 將后端開發(fā)的工期更新為4周,并將其納入項目進度計劃。
- 項目文檔更新:
- 更新后端開發(fā)的任務(wù)描述和工期。
5. 測試
活動資源需求
- 人力資源:
- 2名測試人員
- 設(shè)備資源:
- 每人1臺筆記本電腦
- 1臺服務(wù)器
活動工期估算
- 專家判斷:
- 項目經(jīng)理根據(jù)以往類似項目的經(jīng)驗,估算測試需要3周時間。
- 類比估算:
- 參考類似項目的歷史數(shù)據(jù),測試通常需要2.5到3周。
- 參數(shù)估算:
- 假設(shè)測試的工作量為120小時,2名測試人員每周工作40小時,則工期為1.5周。
- 三點估算:
- 樂觀時間(O):2周
- 最可能時間(M):3周
- 悲觀時間(P):4周
- 期望工期?=?(2?+?4*3?+?4)?/?6?=?3周
更新項目文檔
- 項目進度計劃更新:
- 將測試的工期更新為3周,并將其納入項目進度計劃。
- 項目文檔更新:
- 更新測試的任務(wù)描述和工期。
總結(jié)
通過估算活動工期,項目團隊可以明確每個任務(wù)需要多長時間才能完成,并更新項目文檔。這不僅有助于制定合理的項目進度計劃,還能幫助項目團隊識別潛在的進度風險,并制定相應(yīng)的風險應(yīng)對措施。
在上述例子中,估算活動工期幫助項目團隊確定了每個任務(wù)的工期,并更新了項目進度計劃,確保項目能夠按時、按計劃進行。
6)制定進度
是指通過分析活動序列,活動資源估算和活動工期估算來創(chuàng)建項目進度,這個過程的主要輸出包括一個進度基線,項目進度,進度數(shù)據(jù),項目日歷,更新的項目管理計劃和更新的項目文件。
舉個例子:
制定進度
制定進度是指在項目管理中,通過分析活動序列、活動資源估算和活動工期估算,來創(chuàng)建項目的進度計劃。這個過程的主要輸出包括進度基線(Schedule?Baseline)、項目進度(Project?Schedule)、進度數(shù)據(jù)(Schedule?Data)、項目日歷(Project?Calendar),以及更新的項目管理計劃和更新的項目文件。通過制定進度,項目團隊可以明確項目的整體時間安排和里程碑,確保項目按時完成。
以下是詳細的解釋,并附有一個具體的例子,幫助你更好地理解這個過程。
制定進度的步驟
1.
分析活動序列:
-
- 確定項目活動中各個任務(wù)的依賴關(guān)系和順序。這通常通過進度網(wǎng)絡(luò)圖(Schedule?Network?Diagram)來表示。
2.
活動資源估算:
-
- 估算每個活動所需的資源,包括人力、設(shè)備和原料等。資源的需求和可用性會直接影響活動的工期。
3.
活動工期估算:
-
- 估算完成每個活動所需的工作時間。這可以通過專家判斷、類比估算、參數(shù)估算或三點估算等方法進行。
4.
創(chuàng)建項目進度計劃:
-
- 綜合以上信息,制定項目的進度計劃,包括每個活動的開始和結(jié)束日期、關(guān)鍵路徑和里程碑。
5.
確定進度基線:
-
- 進度基線是經(jīng)過批準的項目進度計劃,作為項目時間管理的基準,用于衡量項目進度績效。
6.
更新項目文檔:
-
- 將制定的進度計劃更新到項目文檔中,包括項目管理計劃、項目進度計劃等。
例子
假設(shè)一家公司正在開發(fā)一個在線學習平臺,項目團隊已經(jīng)完成了以下工作:
- 工作分解結(jié)構(gòu)(WBS):確定了項目的所有主要任務(wù)和子任務(wù)。
- 活動資源估算:確定了每個任務(wù)所需的人力、設(shè)備和原料。
- 活動工期估算:估算了每個任務(wù)所需的工作時間。
現(xiàn)在,項目團隊需要制定項目的進度計劃,以下是詳細的例子:
1. 分析活動序列
項目團隊已經(jīng)確定了以下主要任務(wù)和它們的依賴關(guān)系:
- 需求分析(FS)→?系統(tǒng)設(shè)計(FS)→?前端開發(fā)(FS)→?測試(FS)→?部署(FS)→?用戶驗收測試(FS)→?上線
- 系統(tǒng)設(shè)計(FS)→?后端開發(fā)(FS)→?測試(FS)
進度網(wǎng)絡(luò)圖
取消自動換行
復制
[需求分析] --FS--> [系統(tǒng)設(shè)計] --FS--> [前端開發(fā)] --FS--> [測試] --FS--> [部署] --FS--> [用戶驗收測試] --FS--> [上線]
???????????????????????????? └--> [后端開發(fā)] -FS-┘
- FS?表示“完成到開始”依賴關(guān)系。
2. 活動資源估算
項目團隊已經(jīng)估算了每個任務(wù)所需的資源,例如:
- 需求分析:
- 人力資源:1名業(yè)務(wù)分析師,1名用戶體驗設(shè)計師
- 設(shè)備資源:每人1臺筆記本電腦,1臺服務(wù)器
- 系統(tǒng)設(shè)計:
- 人力資源:1名系統(tǒng)架構(gòu)師,1名數(shù)據(jù)庫設(shè)計師
- 設(shè)備資源:每人1臺高性能筆記本電腦,1臺服務(wù)器
- 前端開發(fā):
- 人力資源:2名前端開發(fā)人員
- 設(shè)備資源:每人1臺高性能筆記本電腦,1臺服務(wù)器
- 后端開發(fā):
- 人力資源:2名后端開發(fā)人員
- 設(shè)備資源:每人1臺高性能筆記本電腦,1臺服務(wù)器
- 測試:
- 人力資源:2名測試人員
- 設(shè)備資源:每人1臺筆記本電腦,1臺服務(wù)器
3. 活動工期估算
項目團隊已經(jīng)估算了每個任務(wù)的工期,例如:
- 需求分析:2周
- 系統(tǒng)設(shè)計:3周
- 前端開發(fā):4周
- 后端開發(fā):4周
- 測試:3周
- 部署:1周
- 用戶驗收測試:2周
- 上線:1周
4. 創(chuàng)建項目進度計劃
項目團隊使用項目管理軟件(如Microsoft?Project,?Primavera,?或其他工具)創(chuàng)建項目進度計劃:
- 項目開始日期:2023年5月1日
- 項目結(jié)束日期:2023年12月31日
項目進度計劃
任務(wù)名稱 | 開始日期 | 結(jié)束日期 | 工期 | 前置任務(wù) |
需求分析 | 2023年5月1日 | 2023年5月14日 | 2周 | 無 |
系統(tǒng)設(shè)計 | 2023年5月15日 | 2023年6月4日 | 3周 | 需求分析 |
前端開發(fā) | 2023年6月5日 | 2023年7月2日 | 4周 | 系統(tǒng)設(shè)計 |
后端開發(fā) | 2023年6月5日 | 2023年7月2日 | 4周 | 系統(tǒng)設(shè)計 |
測試 | 2023年7月3日 | 2023年7月23日 | 3周 | 前端開發(fā), 后端開發(fā) |
部署 | 2023年7月24日 | 2023年7月30日 | 1周 | 測試 |
用戶驗收測試 | 2023年7月31日 | 2023年8月13日 | 2周 | 部署 |
上線 | 2023年8月14日 | 2023年8月20日 | 1周 | 用戶驗收測試 |
5. 確定進度基線
項目團隊將上述進度計劃作為進度基線,并獲得項目發(fā)起人的批準。進度基線將作為項目時間管理的基準,用于衡量項目進度績效。
6. 更新項目文檔
項目團隊將制定的進度計劃更新到項目文檔中:
- 項目管理計劃更新:
- 更新項目進度計劃,包括每個任務(wù)的開始和結(jié)束日期。
- 更新資源計劃,包括人力資源、設(shè)備資源和原料資源。
- 項目文件更新:
- 更新項目進度網(wǎng)絡(luò)圖。
- 更新項目日歷,包括工作日和節(jié)假日。
總結(jié)
通過制定進度,項目團隊可以明確項目的整體時間安排和里程碑,確保項目按時完成。進度基線作為項目時間管理的基準,用于衡量項目進度績效。通過更新項目文檔,項目團隊可以確保所有相關(guān)方都了解項目的進度計劃,并及時發(fā)現(xiàn)和解決潛在的進度風險。
在上述例子中,制定進度幫助項目團隊確定了每個任務(wù)的開始和結(jié)束日期,并更新了項目文檔,確保項目能夠按時、按計劃進行。
-
-
- 控制進度
-
是指控制和管理項目進度的變更,這個過程的主要輸出包括工作績效信息,進度預測,變更請求,項目管理計劃的更新,項目文檔的更新和組織過程資產(chǎn)的更新。
舉個例子:
7)控制進度
控制進度是指在項目管理過程中,對項目進度進行監(jiān)控、分析和管理,以確保項目按計劃進行,并在必要時采取糾正措施。這個過程的主要目標是識別進度偏差、分析其影響,并采取適當?shù)拇胧﹣碚{(diào)整項目進度,以確保項目按時完成??刂七M度的主要輸出包括工作績效信息、進度預測、變更請求、項目管理計劃的更新、項目文檔的更新以及組織過程資產(chǎn)的更新。
以下是詳細的解釋,并附有一個具體的例子,幫助你更好地理解這個過程。
控制進度的步驟
1.
監(jiān)控項目進度:
-
- 定期收集項目進度數(shù)據(jù),包括已完成的任務(wù)、正在進行中的任務(wù)和未開始的任務(wù)。
- 使用項目管理工具(如Gantt圖、進度網(wǎng)絡(luò)圖)來跟蹤項目進度。
2.
比較實際進度與計劃進度:
-
- 將實際進度與項目進度計劃進行比較,識別任何偏差。
- 確定哪些任務(wù)落后于計劃,哪些任務(wù)提前完成。
3.
分析進度偏差:
-
- 分析進度偏差的原因,例如資源不足、技術(shù)問題、需求變更等。
- 評估進度偏差對項目整體進度的影響。
4.
制定和實施糾正措施:
-
- 根據(jù)進度偏差的分析結(jié)果,制定糾正措施,例如調(diào)整資源分配、重新安排任務(wù)順序、加班等。
- 實施糾正措施,并監(jiān)控其效果。
5.
更新項目計劃和文檔:
-
- 根據(jù)糾正措施的結(jié)果,更新項目進度計劃和其他相關(guān)項目文檔。
- 確保所有相關(guān)方都了解最新的項目進度計劃。
6.
管理變更請求:
-
- 處理任何與進度相關(guān)的變更請求,例如客戶要求提前交付日期或增加新功能。
- 評估變更請求的可行性和影響,并獲得必要的批準。
7.
更新組織過程資產(chǎn):
-
- 將進度控制的經(jīng)驗教訓更新到組織過程資產(chǎn)中,例如項目檔案、經(jīng)驗教訓數(shù)據(jù)庫等。
例子
假設(shè)一家公司正在開發(fā)一個在線學習平臺,項目團隊已經(jīng)制定了項目進度計劃,并開始了項目執(zhí)行。以下是控制進度的具體例子:
1. 監(jiān)控項目進度
項目團隊每周召開一次項目進度會議,收集以下進度數(shù)據(jù):
- 已完成的任務(wù):
- 需求分析(2周)
- 系統(tǒng)設(shè)計(3周)
- 正在進行中的任務(wù):
- 前端開發(fā)(計劃4周,已完成2周)
- 后端開發(fā)(計劃4周,已完成2周)
- 未開始的任務(wù):
- 測試(計劃3周)
- 部署(計劃1周)
- 用戶驗收測試(計劃2周)
- 上線(計劃1周)
2. 比較實際進度與計劃進度
項目團隊將實際進度與計劃進度進行比較,發(fā)現(xiàn)以下偏差:
- 前端開發(fā):
- 計劃完成時間:2023年7月2日
- 實際完成時間:預計2023年7月9日(落后1周)
- 后端開發(fā):
- 計劃完成時間:2023年7月2日
- 實際完成時間:預計2023年7月9日(落后1周)
3. 分析進度偏差
項目團隊分析進度偏差的原因:
- 前端開發(fā):
- 原因:一名前端開發(fā)人員因病請假,導致開發(fā)進度落后。
- 后端開發(fā):
- 原因:技術(shù)問題導致開發(fā)進度延遲。
4. 制定和實施糾正措施
項目團隊制定以下糾正措施:
- 前端開發(fā):
- 安排其他前端開發(fā)人員加班,彌補請假人員的工作量。
- 重新安排任務(wù)優(yōu)先級,確保關(guān)鍵任務(wù)按時完成。
- 后端開發(fā):
- 增加一名后端開發(fā)人員,協(xié)助解決技術(shù)問題。
- 安排技術(shù)專家進行技術(shù)指導,加快問題解決速度。
項目團隊實施糾正措施,并監(jiān)控其效果:
- 前端開發(fā):
- 通過加班和重新安排任務(wù),前端開發(fā)進度恢復正常,預計可以按時完成。
- 后端開發(fā):
- 通過增加人員和專家指導,后端開發(fā)進度恢復正常,預計可以按時完成。
5. 更新項目計劃和文檔
項目團隊更新項目進度計劃和其他相關(guān)項目文檔:
- 項目進度計劃更新:
- 將前端開發(fā)和后端開發(fā)的預計完成時間更新為2023年7月9日。
- 項目管理計劃更新:
- 更新資源計劃,增加一名后端開發(fā)人員。
- 更新風險登記冊,記錄技術(shù)問題的風險和解決方案。
6. 管理變更請求
項目團隊處理以下變更請求:
- 客戶要求增加一個新功能:
- 項目團隊評估變更請求的可行性和影響。
- 評估結(jié)果顯示,增加新功能需要額外的時間和資源。
- 項目團隊與客戶協(xié)商,調(diào)整項目范圍和進度計劃。
7. 更新組織過程資產(chǎn)
項目團隊將進度控制的經(jīng)驗教訓更新到組織過程資產(chǎn)中:
- 經(jīng)驗教訓:
- 在項目初期,應(yīng)制定更詳細的資源備份計劃,以應(yīng)對人員請假或離職的情況。
- 應(yīng)加強技術(shù)問題管理,及時識別和解決技術(shù)問題,避免影響項目進度。
總結(jié)
通過控制進度,項目團隊可以及時識別和解決進度偏差,確保項目按時完成??刂七M度不僅包括監(jiān)控和比較實際進度與計劃進度,還包括分析偏差原因、制定和實施糾正措施,以及管理變更請求。通過更新項目計劃和文檔,項目團隊可以確保所有相關(guān)方都了解最新的項目進度計劃,并及時發(fā)現(xiàn)和解決潛在的進度風險。
在上述例子中,控制進度幫助項目團隊識別了前端開發(fā)和后端開發(fā)的進度偏差,并采取了有效的糾正措施,確保項目能夠按時完成。
7.5計劃進度管理
在項目時間管理中的第一部就是制定在整個生命周期進度如何管理的計劃。項目進度源于啟動項目的基本文檔。項目章程中經(jīng)常提到項目的計劃開始和結(jié)束日期,它可以作為更加詳細的進度起始點。
7.6定義活動(identify activity)
-
-
- 定義活動的產(chǎn)出
- 活動清單(activity list)
- 定義活動的產(chǎn)出
-
活動清單是包含在項目進度中的活動列表。
-
-
-
- 活動屬性(activity attribute)
-
-
活動屬性提供了與進度相關(guān)的更多信息
-
-
-
- 里程碑(milestone)
-
-
是項目中一個通常沒有工期的重要事件。需要一些活動和大量的工作來完成一個里程碑。但是里程碑本身更像是一個標志來幫助識別相關(guān)的活動中。
-
-
-
- 項目管理計劃的更新
-
-
7.7排序活動
- 依賴(dependency)
依賴或關(guān)系(relation)與項目活動或任務(wù)的排序相關(guān)。例如:一個特定的活動是否必須在另外活動開始前完成?項目團隊是否能夠同時并行做幾個活動?能否有交叉?界定這些活動之間的關(guān)系或者依賴對于開發(fā)和管理項目進度有重要影響。
- 依賴的分類
- 強制依賴(mandatory dependency)
強制依賴是項目工作中內(nèi)在的一種關(guān)系,某些時候被稱為硬邏輯。例如:在寫代碼之前,你不可以測試代碼。
- 自由依賴(discretionary dependency)
自由依賴是由項目團隊定義的項目活動之間的關(guān)系。例如:項目團隊可能遵循好的實踐,在用戶簽署同一所有分析工作之前,項目團隊不會開始新的信息系統(tǒng)的詳細設(shè)計。已有依賴有時后叫做軟邏輯,應(yīng)該謹慎使用。
- 外部依賴(external dependency)
涉及項目和非項目活動之間的關(guān)系。例如:新的操作系統(tǒng)和其他軟件的安裝依賴于外部供應(yīng)商交付的新硬件。
7.8網(wǎng)絡(luò)圖(network diagram)
1)什么是網(wǎng)絡(luò)圖
網(wǎng)絡(luò)圖是表示活動排序的首選技術(shù)。一個網(wǎng)絡(luò)圖(network diagram)是項目活動之間的邏輯關(guān)系或者循序的示意性表示
2)網(wǎng)格圖的格式
1>網(wǎng)格圖的格式使用的是AOA法(activity-on-arrow)
A = 1:表示活動A的工期為1天。對于D和A活動來說,A活動必須在D活動之前完成。
箭線圖法(arrow diagramming method,ADM):這是一種網(wǎng)絡(luò)圖技術(shù)。在該圖活動用箭頭表示,并將節(jié)點連接起來,表示活動的序列。
節(jié)點(node):可以表示為一個活動的開始和結(jié)束,第一個節(jié)點表示項目的開始,最后一個節(jié)點表示項目的結(jié)束。
如果有工期估計,那就放在活動字母或者名字附近。
2>(或者)箭線圖法(arrow diagramming method,ADM)
3>前導圖法(precedence diagramming method,PDM)
1》什么時候使用前導圖(FS,SS,SF,FF)
PDM也是一種網(wǎng)絡(luò)圖技術(shù),前導圖使用方框表示活動,它在特定類型的時間關(guān)系時特別有用。
PDM?在以下幾種情況下特別有用:
1.?活動之間存在復雜的依賴關(guān)系時
- 當項目中的活動之間存在多種依賴關(guān)系時,PDM?可以清晰地展示這些關(guān)系。PDM?支持四種主要的依賴關(guān)系類型:
- 完成到開始(Finish-to-Start, FS):?一個活動必須在另一個活動完成之后才能開始。
- 完成到完成(Finish-to-Finish, FF):?一個活動必須在另一個活動完成之后才能完成。
- 開始到開始(Start-to-Start, SS):?一個活動必須在另一個活動開始之后才能開始。
- 開始到完成(Start-to-Finish, SF):?一個活動必須在另一個活動開始之后才能完成。
- 當項目需要精確控制這些依賴關(guān)系時,PDM?提供了更直觀和詳細的表示方式。
2.?需要詳細的時間管理時
- PDM?允許在節(jié)點之間定義時間延遲(lag)和提前量(lead),這對于需要精確控制活動時間間隔的項目非常有用。例如,某些活動可能需要在另一個活動完成一段時間后才能開始,這時可以使用延遲時間。
3.?資源分配和優(yōu)化時
- PDM?可以幫助項目經(jīng)理更好地進行資源分配和優(yōu)化。通過清晰地展示活動之間的關(guān)系,項目經(jīng)理可以更容易地識別出潛在的瓶頸和資源沖突,從而進行有效的資源調(diào)度。
4.?項目復雜且規(guī)模較大時
- 對于復雜且規(guī)模較大的項目,PDM?提供了一種結(jié)構(gòu)化的方法來組織和展示項目活動。這種方法可以幫助團隊成員更好地理解項目進度和任務(wù)之間的關(guān)系,從而提高項目的整體效率和成功率。
5.?需要詳細的進度報告和分析時
- PDM?生成的進度網(wǎng)絡(luò)圖可以用于詳細的進度報告和分析。通過?PDM,項目經(jīng)理可以更準確地跟蹤項目進度,識別出進度偏差,并采取相應(yīng)的糾正措施。
總結(jié)
前導圖法(PDM)在以下情況下特別有用:
- 活動之間存在復雜的依賴關(guān)系。
- 需要詳細的時間管理,包括延遲和提前量。
- 需要進行資源分配和優(yōu)化。
- 項目復雜且規(guī)模較大。
- 需要詳細的進度報告和分析。
通過使用?PDM,項目經(jīng)理可以更有效地規(guī)劃和控制項目進度,確保項目按時、按預算、按質(zhì)量完成。
2》前導圖的方框表示
-
- 完成到開始(Finish-to-Start, FS):?一個活動必須在另一個活動完成之后才能開始。
- 完成到完成(Finish-to-Finish, FF):?一個活動必須在另一個活動完成之后才能完成。
- 開始到開始(Start-to-Start, SS):?一個活動必須在另一個活動開始之后才能開始。
- 開始到完成(Start-to-Finish, SF):?一個活動必須在另一個活動開始之后才能完成。
3》前導圖法要注意的點
- 多數(shù)的項目管理軟件使用前導圖法
- 前導圖法避免了虛活動(虛活動[dummy acitvity]:沒有工期而且沒有資源,但是有時需要AOA網(wǎng)絡(luò)圖上用虛活動表示活動之間的邏輯關(guān)系,它們是用虛的箭頭表示的,工期估算為0)的需要
- 前導圖法表示了任務(wù)之間的不同依賴,而AOA網(wǎng)絡(luò)圖只使用了完成-開始依賴。
- 資源分解結(jié)構(gòu)(resource breakdown structure)
資源分解結(jié)構(gòu)是一種層次結(jié)構(gòu),可以按照種類和類型確定項目的資源。資源的種類包括分析員,程序員和測試員。這些信息將有助于確定資源成本,獲取資源等方面。
- 估算活動工期
- 什么時候估算活動的工期
與關(guān)鍵干系人一起定義活動,決定活動之間的依賴并估計需要的資源之后,項目時間管理中的下一個過程是估算活動的工期。
- 工期(duration)
工期包括活動上花費的實際時間和占用時間。(工期的花費應(yīng)該比實際工作花費時間多,比如:即使花費一個工作周或者5個工作日來做實際的工作,工期估計也可能是兩周,因為多余的時間需要用來獲取外部的信息。分配給任務(wù)的人員或資源也將影響任務(wù)的工期估計。)
- 人工量(effort)
有的人往往會把工期和人工量混淆,人工量是指完成一個任務(wù)所需的總工作量,通常以工作天數(shù)或工作小時數(shù)來衡量。人工量只考慮實際執(zhí)行工作的時間,不包括等待時間或其他非工作時間。
例如,完成一個任務(wù)可能需要5個工作日的人工量,這意味著一個人需要連續(xù)工作5天,或者兩個人各工作2.5天。
- 甘特圖(Gantt chart)
-
- 什么是甘特圖
甘特圖提供了一種顯示項目進度信息的標準格式。
-
- 在甘特圖上增加里程碑
Notice:SMART準則是認為里程碑應(yīng)該是:
- 明確的(special)
- 可度量的(measurable)
- 可分配的(assignable)
- 現(xiàn)實的(realistic)
- 有時間限制的(time-framed)
- 使用跟蹤甘特圖來比較計劃和實際的日期
1》跟蹤甘特圖示例
- 跟蹤甘特圖需要知道的一些概念
基線日期(baseline date)
基線日期是指活動的計劃進度日期。
跟蹤甘特圖Tracking Gantt Chart)
是一個比較計劃和實際項目進度信息的甘特圖。
進度基線(schedule baseline)
整個經(jīng)過審批的計劃進度被稱為進度基線。
任務(wù)的表示法
跟蹤甘特圖上的雙橫線,上面的橫條代表基線工期。如果說上下的橫條長度不相同,那么說明實際的進度和計劃的進度不同。如果上面的橫條比下面的橫條短說明,實際使用的工期超出了計劃的工期。
偏移的里程碑(slipped milestone)
在跟蹤甘特圖上的白色菱形表示了一個偏移的里程碑。意味著里程碑活動的實際完成時間比原來的計劃短。
右邊的橫條的百分比
代表著每個任務(wù)完成工作的百分比。
6)關(guān)鍵路徑法(critical path method,CPM)
是一種網(wǎng)絡(luò)圖技術(shù),用來預測整個項目的工期,這種重要的工具,將幫助你防止項目進度的超期。
7)使用關(guān)鍵路徑分析來保持進度均衡
Key:求關(guān)鍵路勁就是求最長的工期的那條路徑
如圖:就是B-E-H-J這條路徑。
8)抓住關(guān)鍵路徑(時間最長的那條)
關(guān)鍵路徑意味著什么:即使關(guān)鍵路徑是最長的,但是它也表示完成的項目的最短的時間。如果關(guān)鍵路徑上的一個或著多個活動比計劃的長,那么整個項目進度將被延后,除非項目經(jīng)理采用正確的行動。
-
- 使用關(guān)鍵路徑分析來保持進度均衡
- 幫助項目經(jīng)理進行項目進度平衡的技術(shù)
- 使用關(guān)鍵路徑分析來保持進度均衡
- 確定自由時差
- 每個項目活動的總時差
-
- 幾個基本概念
-
自由時差(free slack)/自由浮動時間(free float)
是一個活動在不延誤緊接活動的最早開始時間的情況下可以被拖延的時間。
最早開始時間(early start date)
是基于項目網(wǎng)絡(luò)邏輯可以開始的最早的可能時間。
總時差(total slack)/總浮動時差(total float)
是一個活動從它最早的開始時間開始,在沒有拖延計劃項目完成日期的情況下被耽擱的時間。
最早完成時間(early finish date)
基于項目網(wǎng)絡(luò)邏輯最早可能的完成時間。
最晚開始時間(late start time)
是一個活動在不延遲項目完成時間的最晚可能開始的時間。
最晚完成時間(late finish time)
是一個活動在不延遲項目完成時間的情況下的最晚可能完成時間。
3>幫助項目經(jīng)理計算自由時差和總時差的方法
-
-
-
-
- 正推法(forward pass)
-
-
-
用來確定每個活動的最早開始和最早完成時間,一個活動的最早完成時間。
舉個例子:
正推法(Forward Pass)解釋與例子
正推法(Forward Pass)?是關(guān)鍵路徑法(CPM)中用于計算每個活動的**最早開始時間(ES)和最早完成時間(EF)**的技術(shù)。通過正推法,我們可以確定項目中最快的完成時間,并識別出關(guān)鍵路徑。以下是正推法的詳細解釋和例子。
1.?正推法的基本概念
- 最早開始時間(ES):一個活動最早可以開始的時間。
- 最早完成時間(EF):一個活動最早可以完成的時間。
- 活動持續(xù)時間(Duration):完成一個活動所需的時間。
正推法從項目的開始節(jié)點(通常是第一個活動)開始,逐步計算每個活動的最早開始和最早完成時間,直到項目的結(jié)束節(jié)點。
2.?正推法的計算步驟
1.
確定項目的開始時間:
-
- 通常,項目從時間0開始,即所有第一個活動的最早開始時間(ES)為0。
2.
計算最早完成時間(EF):
-
- 對于每個活動,最早完成時間(EF)等于最早開始時間(ES)加上活動的持續(xù)時間(Duration)。
- 公式:
EF=ES+DurationEF=ES+Duration
3.
確定后續(xù)活動的最早開始時間(ES):
-
- 一個活動的最早開始時間(ES)等于其所有前置活動的最早完成時間(EF)中的最大值。
- 公式:
ES=max?(EFpredecessors)ES=max(EFpredecessors?)
4.重復步驟2和3,直到所有活動的ES和EF都被計算出來。
3.?例子
假設(shè)我們有以下項目活動:
活動 | 前置活動 | 持續(xù)時間(天) |
A | - | 3 |
B | A | 4 |
C | A | 2 |
D | B, C | 5 |
E | D | 2 |
我們使用正推法來計算每個活動的ES和EF。
步驟1:確定項目的開始時間
- 項目從時間0開始,因此活動A的最早開始時間(ES)為0。
步驟2:計算活動A的EF
- 活動A的持續(xù)時間為3天。
- 因此,活動A的最早完成時間(EF)為:
EFA=ESA+DurationA=0+3=3EFA?=ESA?+DurationA?=0+3=3
步驟3:計算活動B和C的ES和EF
- 活動B和C的前置活動都是A,因此它們的ES等于A的EF。
- 活動B:
- ESB=EFA=3ESB?=EFA?=3
- EFB=ESB+DurationB=3+4=7EFB?=ESB?+DurationB?=3+4=7
- 活動C:
- ESC=EFA=3ESC?=EFA?=3
- EFC=ESC+DurationC=3+2=5EFC?=ESC?+DurationC?=3+2=5
- 活動B:
步驟4:計算活動D的ES和EF
- 活動D的前置活動是B和C,因此它的ES等于B和C的EF中的最大值。
- ESD=max?(EFB,EFC)=max?(7,5)=7ESD?=max(EFB?,EFC?)=max(7,5)=7
- EFD=ESD+DurationD=7+5=12EFD?=ESD?+DurationD?=7+5=12
步驟5:計算活動E的ES和EF
- 活動E的前置活動是D,因此它的ES等于D的EF。
- ESE=EFD=12ESE?=EFD?=12
- EFE=ESE+DurationE=12+2=14EFE?=ESE?+DurationE?=12+2=14
步驟6:總結(jié)
- 活動A:ES?=?0,?EF?=?3
- 活動B:ES?=?3,?EF?=?7
- 活動C:ES?=?3,?EF?=?5
- 活動D:ES?=?7,?EF?=?12
- 活動E:ES?=?12,?EF?=?14
4.?關(guān)鍵路徑的識別
- 通過正推法,我們可以看到活動E的最早完成時間(EF)為14天。
- 關(guān)鍵路徑是花費時間最長的路徑,即A-B-D-E,總時間為14天。
5.?總結(jié)
正推法通過逐步計算每個活動的最早開始和最早完成時間,幫助我們確定項目的最短完成時間,并識別出關(guān)鍵路徑。在本例中,關(guān)鍵路徑為A-B-D-E,總時間為14天。
-
-
-
-
- 逆推法(backward pass)
-
-
-
可以用來確定最晚開始和最晚完成時間。
舉個例子:
逆推法(Backward Pass)解釋與例子
逆推法(Backward Pass)?是關(guān)鍵路徑法(CPM)中用于計算每個活動的**最晚開始時間(LS)和最晚完成時間(LF)**的技術(shù)。通過逆推法,我們可以確定在不延誤項目完成時間的情況下,每個活動可以最晚開始和完成的時間。以下是逆推法的詳細解釋和例子。
1.?逆推法的基本概念
- 最晚完成時間(LF):在不延誤項目完成時間的情況下,一個活動最晚必須完成的時間。
- 最晚開始時間(LS):在不延誤項目完成時間的情況下,一個活動最晚可以開始的時間。
- 活動持續(xù)時間(Duration):完成一個活動所需的時間。
逆推法從項目的結(jié)束節(jié)點(通常是最后一個活動)開始,逐步計算每個活動的最晚完成和最晚開始時間,直到項目的開始節(jié)點。
2.?逆推法的計算步驟
1.
確定項目的計劃完成時間:
-
- 通常,項目計劃完成時間等于正推法計算出的最早完成時間(EF),即項目的最早完成時間。
2.
計算最晚開始時間(LS):
-
- 對于每個活動,最晚開始時間(LS)等于最晚完成時間(LF)減去活動的持續(xù)時間(Duration)。
- 公式:
LS=LF?DurationLS=LF?Duration
3.
確定前置活動的最晚完成時間(LF):
-
- 一個活動的前置活動的最晚完成時間(LF)等于該活動的最晚開始時間(LS)。
- 公式:
LFpredecessors=LSLFpredecessors?=LS
4.重復步驟2和3,直到所有活動的LS和LF都被計算出來。
3.?例子
我們使用與正推法相同的項目活動:
活動 | 前置活動 | 持續(xù)時間(天) |
A | - | 3 |
B | A | 4 |
C | A | 2 |
D | B, C | 5 |
E | D | 2 |
通過正推法,我們已經(jīng)計算出每個活動的最早開始時間(ES)和最早完成時間(EF),以及項目的總工期為14天?,F(xiàn)在我們使用逆推法來計算每個活動的最晚開始時間(LS)和最晚完成時間(LF)。
步驟1:確定項目的計劃完成時間
- 項目的計劃完成時間等于正推法計算出的最早完成時間(EF),即14天。
步驟2:計算活動E的LS和LF
- 活動E是最后一個活動,因此它的最晚完成時間(LF)等于項目的計劃完成時間。
- LFE=14LFE?=14
- 活動E的持續(xù)時間為2天,因此:
- LSE=LFE?DurationE=14?2=12LSE?=LFE??DurationE?=14?2=12
步驟3:計算活動D的LS和LF
- 活動D的前置活動是E,因此活動D的最晚完成時間(LF)等于E的最晚開始時間(LS)。
- LFD=LSE=12LFD?=LSE?=12
- 活動D的持續(xù)時間為5天,因此:
- LSD=LFD?DurationD=12?5=7LSD?=LFD??DurationD?=12?5=7
步驟4:計算活動B和C的LS和LF
- 活動B和C的前置活動都是D,因此它們的最晚完成時間(LF)等于D的最晚開始時間(LS)。
- 活動B:
- LFB=LSD=7LFB?=LSD?=7
- LSB=LFB?DurationB=7?4=3LSB?=LFB??DurationB?=7?4=3
- 活動C:
- LFC=LSD=7LFC?=LSD?=7
- LSC=LFC?DurationC=7?2=5LSC?=LFC??DurationC?=7?2=5
- 活動B:
步驟5:計算活動A的LS和LF
- 活動A的前置活動是B和C,因此它最晚完成時間(LF)等于B和C的最晚開始時間(LS)中的最小值。
- LFA=min?(LSB,LSC)=min?(3,5)=3LFA?=min(LSB?,LSC?)=min(3,5)=3
- 活動A的持續(xù)時間為3天,因此:
- LSA=LFA?DurationA=3?3=0LSA?=LFA??DurationA?=3?3=0
步驟6:總結(jié)
- 活動A:LS?=?0,?LF?=?3
- 活動B:LS?=?3,?LF?=?7
- 活動C:LS?=?5,?LF?=?7(最晚可以從第五條開始,通過兩天到7)
- 活動D:LS?=?7,?LF?=?12
- 活動E:LS?=?12,?LF?=?14
4.?關(guān)鍵路徑的識別
- 通過逆推法,我們可以看到活動A、B、D、E的最晚完成時間(LF)等于最早完成時間(EF),這意味著這些活動是關(guān)鍵路徑上的活動。
- 關(guān)鍵路徑為A-B-D-E,總時間為14天。
5.?總結(jié)
逆推法通過逐步計算每個活動的最晚開始和最晚完成時間,幫助我們確定在不延誤項目完成時間的情況下,每個活動可以最晚開始和完成的時間。在本例中,關(guān)鍵路徑為A-B-D-E,總時間為14天。
-
- 使用關(guān)鍵路徑來縮短項目的進度
- 哪些人希望縮短項目的進度
- 使用關(guān)鍵路徑來縮短項目的進度
干系人往往希望縮短項目的進度。一個項目工作的結(jié)果是認為項目團隊至少需要10個月來完成項目,而發(fā)起人往往會希望在8~9個月內(nèi)完成任務(wù)。(發(fā)起人往往不會要求項目團隊花費比他們自己建議時間更長的工期)
-
-
- 項目經(jīng)理怎么制定項目進度
-
項目經(jīng)理通過定義活動,確定排序,和估算每個任務(wù)的資源和工期,來盡可能好地制定項目進度。
-
-
- 趕工(crashing)
-
趕工是一種為了以最少的成本最大限度地壓縮工期,而成本與進度之間進行均衡的技術(shù)。
1》例子
1. 項目背景
假設(shè)我們有一個軟件開發(fā)項目,項目經(jīng)理已經(jīng)使用關(guān)鍵路徑法(CPM)確定了項目的關(guān)鍵路徑和每個活動的持續(xù)時間。項目經(jīng)理希望在不顯著增加成本的情況下,盡可能縮短項目的總工期。
1.1 項目活動表
活動 | 前置活動 | 正常持續(xù)時間(天) | 正常成本(萬元) | 趕工持續(xù)時間(天) | 趕工成本(萬元) |
A | - | 5 | 10 | 3 | 15 |
B | A | 3 | 6 | 2 | 8 |
C | A | 4 | 8 | 3 | 10 |
D | B, C | 6 | 12 | 4 | 16 |
E | D | 2 | 4 | 1 | 6 |
F | D | 3 | 6 | 2 | 8 |
G | E, F | 4 | 8 | 3 | 10 |
1.2 項目網(wǎng)絡(luò)圖
取消自動換行
復制
A (5) -> B (3) -> D (6) -> E (2) -> G (4)
?????? \-> C (4) -/
??????????????? \-> F (3) -/
- 關(guān)鍵路徑:?A?->?B?->?D?->?E?->?G,總工期為?20?天。
2. 趕工分析
2.1 確定關(guān)鍵路徑
首先,項目經(jīng)理需要確定項目的關(guān)鍵路徑。在本例中,關(guān)鍵路徑為?A?->?B?->?D?->?E?->?G,總工期為?20?天。
2.2 計算趕工成本和趕工時間
接下來,項目經(jīng)理需要計算每個活動的趕工成本和趕工時間。
- 活動 A:
- 正常持續(xù)時間:?5?天
- 趕工持續(xù)時間:?3?天
- 正常成本:?10?萬元
- 趕工成本:?15?萬元
- 趕工成本增加:?5?萬元
- 趕工時間減少:?2?天
- 趕工成本率:?5?萬元?/?2?天?=?2.5?萬元/天
- 活動 B:
- 趕工成本率:?(8?-?6)?/?(3?-?2)?=?2?萬元/天
- 活動 C:
- 趕工成本率:?(10?-?8)?/?(4?-?3)?=?2?萬元/天
- 活動 D:
- 趕工成本率:?(16?-?12)?/?(6?-?4)?=?2?萬元/天
- 活動 E:
- 趕工成本率:?(6?-?4)?/?(2?-?1)?=?2?萬元/天
- 活動 F:
- 趕工成本率:?(8?-?6)?/?(3?-?2)?=?2?萬元/天
- 活動 G:
- 趕工成本率:?(10?-?8)?/?(4?-?3)?=?2?萬元/天
2.3 選擇趕工活動
項目經(jīng)理需要選擇趕工成本率最低的活動進行趕工,以最小化成本增加。
- 趕工活動 A:
- 趕工時間:?2?天
- 趕工成本:?5?萬元
趕工活動?A?后,關(guān)鍵路徑的持續(xù)時間減少到?18?天。
2.4 繼續(xù)趕工
接下來,項目經(jīng)理繼續(xù)選擇趕工成本率最低的活動進行趕工。
- 趕工活動 B:
- 趕工時間:?1?天
- 趕工成本:?2?萬元
趕工活動?B?后,關(guān)鍵路徑的持續(xù)時間減少到?17?天。
- 趕工活動 C:
- 趕工時間:?1?天
- 趕工成本:?2?萬元
趕工活動?C?后,關(guān)鍵路徑的持續(xù)時間減少到?16?天。
- 趕工活動 D:
- 趕工時間:?2?天
- 趕工成本:?4?萬元
趕工活動?D?后,關(guān)鍵路徑的持續(xù)時間減少到?14?天。
- 趕工活動 E:
- 趕工時間:?1?天
- 趕工成本:?2?萬元
趕工活動?E?后,關(guān)鍵路徑的持續(xù)時間減少到?13?天。
- 趕工活動 F:
- 趕工時間:?1?天
- 趕工成本:?2?萬元
趕工活動?F?后,關(guān)鍵路徑的持續(xù)時間減少到?12?天。
- 趕工活動 G:
- 趕工時間:?1?天
- 趕工成本:?2?萬元
趕工活動?G?后,關(guān)鍵路徑的持續(xù)時間減少到?11?天。
2.5 趕工結(jié)果
- 總趕工時間:?9?天
- 總趕工成本:?5?+?2?+?2?+?4?+?2?+?2?+?2?=?19?萬元
3. 總結(jié)
通過趕工技術(shù),項目經(jīng)理成功地將項目的總工期從?20?天壓縮到?11?天,總成本增加了?19?萬元。趕工過程中,項目經(jīng)理優(yōu)先選擇趕工成本率最低的活動進行趕工,以最小化成本增加。
4. 注意事項
- 關(guān)鍵路徑:?趕工活動應(yīng)優(yōu)先選擇關(guān)鍵路徑上的活動,因為只有關(guān)鍵路徑上的活動延遲才會影響項目的總工期。
- 趕工成本:?趕工成本率是選擇趕工活動的重要指標,應(yīng)優(yōu)先選擇趕工成本率最低的活動。
- 資源限制:?在趕工過程中,應(yīng)考慮資源的可用性,避免資源沖突。
- 風險評估:?趕工可能會增加項目的風險,例如人員疲勞、質(zhì)量下降等,應(yīng)進行風險評估和管理。
5. 結(jié)論
趕工是一種有效的項目管理技術(shù),可以在不顯著增加成本的情況下,最大限度地壓縮項目的總工期。通過合理選擇趕工活動和優(yōu)化資源分配,項目經(jīng)理可以在項目進度和成本之間取得平衡,確保項目按時、按預算、按質(zhì)量完成。
2》趕工的優(yōu)點
可以縮短項目完成的時間
3》趕工的缺點
會提高項目的成本。
-
-
- 快速跟進(fast tracking)
-
包括并行執(zhí)行那些通常以順序方式執(zhí)行的活動。
-
- 更新關(guān)鍵路徑數(shù)據(jù)的重要性
除了在項目開始的時候找出關(guān)鍵路徑外,重要的是用實際的數(shù)據(jù)來更新進度。在項目團隊完成活動后,項目經(jīng)理應(yīng)該記錄下這些活動的實際工期,他也應(yīng)該記錄下正在進行或者將要開展的活動的修訂估算,這些修訂通常會造成項目的關(guān)鍵路徑的改變,導致產(chǎn)生了一個新的項目完成工期。積極主動的項目經(jīng)理和他的團隊會緊緊把握變更,從而可以做出改變,并且讓干系人知道和參與主要的項目決定。
-
- 關(guān)鍵鏈調(diào)度(Critical Chain Project Management, CCPM)
- 關(guān)鍵鏈調(diào)度技術(shù)是干嘛的
- 關(guān)鍵鏈調(diào)度(Critical Chain Project Management, CCPM)
關(guān)鍵鏈技術(shù)旨在通過優(yōu)化資源分配和縮短項目工期來提高項目成功率。CCPM?是由以色列物理學家、企業(yè)管理顧問?艾利·高德拉特(Eliyahu M. Goldratt)?在其約束理論(Theory?of?Constraints,?TOC)的基礎(chǔ)上發(fā)展而來的。
2>約束理論(theory of constraints,TOC)
TOC的核心思想是:任何系統(tǒng)都存在至少一個約束因素,限制了系統(tǒng)整體性能的提升。TOC的目標是通過識別和管理這些約束因素,持續(xù)改進系統(tǒng)性能,最終實現(xiàn)系統(tǒng)目標(如利潤最大化、效率提升等)。
約束理論是是用來解決達到或者滿足項目完成時間的技術(shù)。
3>舉個例子
1. 項目背景
假設(shè)我們有一個軟件開發(fā)項目,項目經(jīng)理需要完成以下五個任務(wù):
任務(wù) | 前置任務(wù) | 正常持續(xù)時間(天) | 所需資源 |
A | - | 5 | 開發(fā)人員 |
B | A | 3 | 測試人員 |
C | A | 4 | 開發(fā)人員 |
D | B, C | 6 | 開發(fā)人員 |
E | D | 2 | 測試人員 |
- 目標:?在最短的時間內(nèi)完成所有任務(wù),并確保項目按時交付。
2. 傳統(tǒng)關(guān)鍵路徑法(CPM)分析
首先,項目經(jīng)理使用傳統(tǒng)的關(guān)鍵路徑法(CPM)來分析項目。
2.1 繪制項目網(wǎng)絡(luò)圖
取消自動換行
復制
A (5) -> B (3) -> D (6) -> E (2)
?????? \-> C (4) -/
- 關(guān)鍵路徑:?A?->?B?->?D?->?E,總工期為?16?天。
2.2 資源依賴關(guān)系
在傳統(tǒng)的?CPM?分析中,只考慮了任務(wù)之間的邏輯依賴關(guān)系,而沒有考慮資源依賴關(guān)系。
- 資源沖突:
- 任務(wù)?A?和?C?同時需要開發(fā)人員。
- 任務(wù)?B?和?E?同時需要測試人員。
3. 應(yīng)用關(guān)鍵鏈調(diào)度技術(shù)(CCPM)
CCPM?不僅考慮了任務(wù)之間的邏輯依賴關(guān)系,還考慮了資源依賴關(guān)系,并通過緩沖管理來應(yīng)對不確定性。
3.1 識別關(guān)鍵鏈
- 資源依賴:
- 任務(wù)?A?和?C?都需要開發(fā)人員,因此它們之間存在資源依賴關(guān)系。
- 任務(wù)?B?和?E?都需要測試人員,因此它們之間也存在資源依賴關(guān)系。
- 調(diào)整關(guān)鍵路徑:
- 由于任務(wù)?A?和?C?都需要開發(fā)人員,因此它們不能同時進行。
- 假設(shè)任務(wù)?A?先于任務(wù)?C?進行。
- 關(guān)鍵鏈:?A?->?C?->?D?->?E,總工期為?17?天。
3.2 消除安全時間
在傳統(tǒng)的項目管理中,每個任務(wù)通常都會設(shè)置一定的安全時間。例如:
- 任務(wù)?A?的安全時間:?1?天
- 任務(wù)?B?的安全時間:?1?天
- 任務(wù)?C?的安全時間:?1?天
- 任務(wù)?D?的安全時間:?2?天
- 任務(wù)?E?的安全時間:?1?天
CCPM?建議消除每個任務(wù)的安全時間,將這些安全時間集中起來,作為緩沖。
3.3 設(shè)置緩沖
- 項目緩沖(Project Buffer):
- 項目緩沖?=?所有任務(wù)安全時間總和?/?2?=?(1?+?1?+?1?+?2?+?1)?/?2?=?3?天
- 項目緩沖放置在項目結(jié)束處。
- 接駁緩沖(Feeding Buffer):
- 接駁緩沖?=?非關(guān)鍵鏈任務(wù)安全時間總和?/?2?=?(1)?/?2?=?0.5?天
- 接駁緩沖放置在非關(guān)鍵鏈與關(guān)鍵鏈的連接處。
- 資源緩沖(Resource Buffer):
- 確保開發(fā)人員和測試人員在需要時可用。
3.4 項目計劃
- 關(guān)鍵鏈:?A?(5)?->?C?(4)?->?D?(6)?->?E?(2)
- 項目緩沖:?3?天
- 總工期:?17?天(關(guān)鍵鏈)?+?3?天(項目緩沖)?=?20?天
- 接駁緩沖:
- 放置在任務(wù)?B?和?D?之間,長度為?0.5?天。
4. 項目執(zhí)行
- 任務(wù) A:?開始執(zhí)行,開發(fā)人員開始工作。
- 任務(wù) C:?任務(wù)?A?完成后,開發(fā)人員立即開始執(zhí)行任務(wù)?C。
- 任務(wù) B:?任務(wù)?A?完成后,測試人員開始執(zhí)行任務(wù)?B。
- 任務(wù) D:?任務(wù)?C?完成后,開發(fā)人員立即開始執(zhí)行任務(wù)?D。
- 任務(wù) E:?任務(wù)?D?完成后,測試人員立即開始執(zhí)行任務(wù)?E。
- 緩沖管理:
- 項目經(jīng)理定期檢查緩沖的消耗情況。
- 如果任務(wù)?B?延遲?0.5?天,接駁緩沖可以吸收這個延遲,不會影響關(guān)鍵鏈。
- 如果任務(wù)?D?延遲超過?3?天,項目緩沖可以吸收這個延遲。
5. 總結(jié)
通過關(guān)鍵鏈調(diào)度技術(shù)(CCPM),項目經(jīng)理成功地將項目的總工期從?16?天延長到?20?天,但通過緩沖管理,可以有效應(yīng)對項目中的不確定性,避免項目延期。
CCPM?的優(yōu)勢在于:
- 考慮了資源依賴:?避免了資源沖突,提高了資源利用率。
- 縮短項目工期:?通過消除安全時間、集中設(shè)置緩沖,縮短了項目工期。
- 應(yīng)對不確定性:?通過緩沖管理,有效應(yīng)對項目中的不確定性。
6. 結(jié)論
關(guān)鍵鏈調(diào)度技術(shù)(CCPM)是一種有效的項目管理方法,可以幫助項目經(jīng)理更好地管理項目資源,縮短項目工期,提高項目成功率。通過合理應(yīng)用?CCPM,項目經(jīng)理可以更有效地管理項目,實現(xiàn)項目目標。
-
- 多任務(wù)
-
-
- 多任務(wù)有時候并不是好事
-
盡管有的人認為自己擅長多任務(wù),但是當你想要按時完成一個項目的時候,多任務(wù)反而不是一個好事了。多任務(wù)發(fā)生在一個資源在同一時間用于多個任務(wù)的時候,這種情形經(jīng)常發(fā)生在項目中。人們被委派到一個項目中的多個任務(wù)或者多個項目中的不同項目中。如圖的情況,員工為了讓多方都滿意,斷斷續(xù)續(xù)地分別完成部分任務(wù),這樣方便他們匯報進度,但是本來10天可以完成地任務(wù)1反而到了第20天才可以提交。
2>什么時候使用多任務(wù)是好的?
盡管多任務(wù)處理在某些情況下會導致效率降低,但在以下幾種情況下,多任務(wù)處理可能是有效的:
1.任務(wù)簡單且相互獨立:
-
- 當任務(wù)簡單且不需要深度思考和集中注意力時,多任務(wù)處理可以提高效率。例如,一邊煮飯一邊聽在線課程,或者在等待電腦安裝軟件時處理郵件。這些任務(wù)之間沒有明顯的沖突,可以并行處理。
2.任務(wù)之間有明顯的等待時間:
-
- 當一個任務(wù)需要等待某個外部事件(如等待文件上傳、等待同事回復等)時,可以利用等待時間處理其他任務(wù)。例如,在等待代碼編譯時可以處理一些簡單的文檔工作。
3.任務(wù)可以并行進行:
-
- 當任務(wù)之間沒有資源沖突,且可以并行進行時,多任務(wù)處理可以提高整體效率。例如,同時進行數(shù)據(jù)錄入和文件整理,這些任務(wù)可以由不同的資源或在不同的時間段進行。
4.任務(wù)優(yōu)先級較低:
-
- 當某些任務(wù)優(yōu)先級較低,且不會對項目關(guān)鍵路徑產(chǎn)生影響時,可以考慮多任務(wù)處理。例如,處理一些日常事務(wù)或非緊急的郵件。
3>什么時候避免多任務(wù)處理?
1.任務(wù)復雜且需要深度思考:
-
- 當任務(wù)復雜且需要深度思考和集中注意力時,多任務(wù)處理會導致效率降低。例如,編寫復雜的代碼、設(shè)計系統(tǒng)架構(gòu)等。
2.任務(wù)之間有明顯的資源沖突:
-
- 當多個任務(wù)需要同一個資源(如員工)時,多任務(wù)處理會導致任務(wù)切換成本增加,最終導致效率降低。例如,同一個員工同時處理多個項目中的多個任務(wù)。
3.任務(wù)對項目進度有重大影響:
-
- 當任務(wù)對項目關(guān)鍵路徑有重大影響時,多任務(wù)處理可能導致項目進度延誤。例如,關(guān)鍵路徑上的任務(wù)如果被多任務(wù)處理,可能會導致整個項目延期。
4>建議
1.任務(wù)優(yōu)先級排序:?對任務(wù)進行優(yōu)先級排序,優(yōu)先處理重要且緊急的任務(wù)。
2.合理分配資源:?根據(jù)任務(wù)的特點,合理分配資源,避免資源沖突。
3.避免頻繁切換:?盡量減少任務(wù)切換的頻率,降低切換成本。
4.使用項目管理工具:?使用項目管理工具來跟蹤任務(wù)進度,避免多任務(wù)處理導致的進度延誤。
?14)關(guān)鍵鏈調(diào)度的緩沖(buffer)
1>緩沖的定義
使用關(guān)鍵鏈調(diào)度的時候,一個用來提高項目完成時間的關(guān)鍵概念是改變?nèi)藗儗椖窟M行估算的方法。許多人增加了安全措施或者緩沖(buffer)。即完成任務(wù)的時間加在考慮各種因素的一個估算時間上。這些因素包括多任務(wù)的負面影響,分心的事項和中斷,擔心減少估算,墨菲定律(Murphy’s law)。(是一個用來應(yīng)對不確定性、提高項目按時完成概率的概念。它通過在項目計劃中預留額外的時間或資源,來應(yīng)對各種可能影響項目進度的因素。)
-
-
- 緩沖的例子
-
假設(shè)有一個項目,需要完成三個任務(wù):
- 任務(wù)1:?預計完成時間10天
- 任務(wù)2:?預計完成時間10天
- 任務(wù)3:?預計完成時間10天
傳統(tǒng)估算方法
在傳統(tǒng)項目管理中,員工可能會這樣估算每個任務(wù)的時間:
- 任務(wù)1:?10天?+?2天(多任務(wù)影響)?+?1天(分心)?+?2天(擔心減少估算)?+?1天(墨菲定律)?=?16天
- 任務(wù)2:?10天?+?2天?+?1天?+?2天?+?1天?=?16天
- 任務(wù)3:?10天?+?2天?+?1天?+?2天?+?1天?=?16天
總時間:16天?+?16天?+?16天?=?48天
在這個例子中,員工為了應(yīng)對各種不確定因素,在每個任務(wù)的估算時間中都加入了6天的緩沖時間,導致總時間被夸大到48天。
關(guān)鍵鏈調(diào)度方法(省略過多的緩沖,統(tǒng)一放到項目的末尾)
關(guān)鍵鏈調(diào)度方法認為,過多的緩沖會導致項目進度被延誤,因此建議將緩沖集中到項目關(guān)鍵路徑的末尾,而不是分散到每個任務(wù)中。
具體做法如下:
1去除每個任務(wù)中的緩沖:
-
- 去除每個任務(wù)估算時間中的安全時間,只保留最合理的、最有可能完成的時間。例如,去除多任務(wù)影響、分心事項、擔心減少估算和墨菲定律的影響。
- 任務(wù)1:?10天
- 任務(wù)2:?10天
- 任務(wù)3:?10天
2.在項目末尾添加集中緩沖:
-
- 將去除的緩沖時間集中到項目末尾,作為項目的總緩沖時間。例如,將每個任務(wù)中去除的6天緩沖時間集中到項目末尾。
- 總緩沖時間:6天(任務(wù)1)?+?6天(任務(wù)2)?+?6天(任務(wù)3)?=?18天
- 項目總時間:10天(任務(wù)1)?+?10天(任務(wù)2)?+?10天(任務(wù)3)?+?18天(總緩沖)?=?48天
- 看起來總時間沒有變化,但關(guān)鍵區(qū)別在于,緩沖時間被集中到項目末尾,而不是分散到每個任務(wù)中。
3.集中緩沖的優(yōu)勢:
-
- 提高效率:?去除每個任務(wù)中的緩沖,可以減少任務(wù)切換成本(因為在每個項目后加緩沖會導致員工希望開始下個任務(wù),但是上個項目還沒完成,想要多任務(wù)地完成上個任務(wù),導致了工期的厭惡延誤),提高工作效率。
- 降低風險:?集中緩沖可以更好地應(yīng)對項目中的不確定性,因為緩沖時間集中在一個地方,而不是分散到每個任務(wù)中。
- 靈活應(yīng)對:?集中緩沖可以更靈活地應(yīng)對項目中的變化,例如任務(wù)延誤、資源不足等。
- 什么時候使用緩沖
1.項目復雜且不確定性高:
-
- 當項目復雜且不確定性高時,緩沖可以幫助項目團隊更好地應(yīng)對各種可能出現(xiàn)的意外情況。(任務(wù)簡單的時候可以使用多任務(wù)。)
2.項目資源有限:
-
- 當項目資源有限時,緩沖可以幫助項目團隊更有效地利用資源,避免資源沖突。
3.項目時間緊迫:
-
- 當項目時間緊迫時,緩沖可以幫助項目團隊更好地管理時間,確保項目按時完成。
-
- 墨菲定律(Murphy’s law)
- 什么是墨菲定律
- 墨菲定律(Murphy’s law)
墨菲定律說的是"任何可能出錯的事情,最終都會出錯。"。關(guān)鍵鏈調(diào)度去掉了單個任務(wù)的緩沖,但是創(chuàng)建了項目緩沖(project buffer)[將子任務(wù)所需要的緩沖時間統(tǒng)一加到項目末尾。]。它是在項目完工日期之前增加的附加時間。
2>墨菲定律在項目管理中的意義
在項目管理中,墨菲定律提醒我們:
- 不確定性是常態(tài):?項目過程中總會有各種意外情況發(fā)生,例如資源短缺、人員變動、技術(shù)問題等。
- 風險不可避免:?即使我們做了充分的準備,仍然無法完全避免所有風險。
- 做好準備:?我們需要為可能出現(xiàn)的錯誤和意外做好準備,而不是抱有僥幸心理。
7.9計劃評審技術(shù)(program evaluation and review technique,PERT)
1)什么是計劃評審技術(shù)(PERT)
計劃評審技術(shù)是另外一個項目時間管理的技術(shù)(program evaluation and review technique,PERT)是在單個工期高度不確定的情況下用來估計項目工期的技術(shù)。PERT也將關(guān)鍵路徑法(CPM)應(yīng)用到了加權(quán)的平均工期中,CPM方法成熟后也使用網(wǎng)絡(luò)圖,人們把這種圖叫做PERT圖。
-
-
- PERT使用的是什么方法估計時間的?(概率時間估算[probabilistic time estimate])
-
PERT使用的是概率時間估算的方法,它是基于樂觀的活動工期估算,最可能的活動工期估算和悲觀的活動工期估算這三點來進行工期估算的,而不是一個特定的或者離散的工期估算。
-
-
- PERT加權(quán)平均估算(PERT weighted average)的公式
-
- PERT加權(quán)平均 = (樂觀時間 + 4 * 最可能時間 + 悲觀時間)/? 6