[IT项目管理]项目时间管理（本章节3w字爆肝）-CSDN博客

本文链接：https://blog.csdn.net/qq_74776071/article/details/144545216

七.项目时间管理

7.1 项目进度的重要性

为什么要重视项目进度：在项目进行的过程之中会遇到变故。但是不论项目中发生了什么，时间总是在流逝，就可能会导致项目不可以在规定的时间完成。

7.2可能影响项目进度的因素

有员工离职
个人的工作方式和文化之间的差异
个人对时间进度的态度
不同国家间的法定假日不同

7.3什么是项目时间管理

简单定义就是确保项目按时完成所需过程。

7.4项目时间管理主要的过程

计划进度管理

是指确定将用于计划，执行和控制项目进度的政策，流程和文档。这个过程的主要输出是一个进度管理计划。

举个例子：

计划进度管理

计划进度管理是指在项目管理中，制定用于计划、执行和控制项目进度的政策、流程和文档的过程。这个过程的核心目标是确保项目能够按时完成，并有效管理时间相关的资源和活动。计划进度管理的主要输出是一个进度管理计划，该计划详细说明了如何管理项目的时间安排和进度。

进度管理计划通常包括以下内容：

项目时间表：项目各个阶段和任务的起止日期。
进度管理方法：用于跟踪和控制项目进度的具体方法，如关键路径法（CPM）或关键链项目管理（CCPM）。
进度控制机制：如何监控项目进度，如何识别和解决进度偏差。
进度报告格式：项目进度报告的格式和频率。
变更管理流程：如何处理进度变更请求，包括评估、批准和实施变更的步骤。

例子

假设一家软件开发公司正在开发一个新的移动应用程序，项目经理需要制定一个进度管理计划，以确保项目能够按时完成。以下是一个详细的例子，帮助你理解计划进度管理的过程：

1. 确定项目时间表

项目经理首先与项目团队和客户开会，确定项目的总体时间框架：

项目启动日期：2023年5月1日
项目完成日期：2023年12月31日

项目经理将项目分为几个主要阶段，并为每个阶段设定具体的起止日期：

需求分析阶段：2023年5月1日 - 2023年5月31日
系统设计阶段：2023年6月1日 - 2023年6月30日
开发阶段：
- 前端开发：2023年7月1日 - 2023年8月15日
- 后端开发：2023年7月1日 - 2023年8月15日
测试阶段：
- 单元测试：2023年8月16日 - 2023年8月31日
- 集成测试：2023年9月1日 - 2023年9月15日
- 系统测试：2023年9月16日 - 2023年9月30日
部署阶段：2023年10月1日 - 2023年10月15日
用户验收测试和上线：2023年10月16日 - 2023年10月31日

2. 选择进度管理方法

项目经理决定使用**关键路径法（CPM）**来管理项目进度。CPM可以帮助项目经理识别项目的关键路径，即影响项目总工期的任务序列。

关键路径：
- 需求分析 -> 系统设计 -> 前端开发 -> 后端开发 -> 单元测试 -> 集成测试 -> 系统测试 -> 部署 -> 用户验收测试和上线

项目经理将重点关注关键路径上的任务，确保这些任务按时完成。

3. 制定进度控制机制

项目经理制定了以下进度控制机制：

每周进度会议：每周召开一次项目进度会议，团队成员汇报各自的任务进展和遇到的问题。
进度报告：每周提交一份详细的进度报告，包括已完成的任务、正在进行中的任务和遇到的问题。
进度偏差分析：如果某个任务进度落后于计划，项目经理将进行偏差分析，找出原因，并制定纠正措施。
里程碑评审：在每个主要阶段结束时，进行里程碑评审，确保阶段目标已经达成。

4. 确定进度报告格式

项目经理制定了进度报告的格式，包括以下内容：

项目名称和日期
项目负责人
本周完成的任务
正在进行中的任务
遇到的问题和风险
下周计划完成的任务
需要协调和支持的事项

5. 制定变更管理流程

项目经理制定了以下变更管理流程：

变更请求提交：任何进度变更请求都需要提交变更请求表（Change Request Form），包括变更内容、理由和影响。
变更评估：项目经理和项目团队评估变更请求的可行性和影响。
变更批准：变更请求经过评估后，由项目经理批准或拒绝。
变更实施：批准的变更请求由相应的团队成员实施。
变更记录：所有变更请求的评估结果、实施情况和验证结果都会被记录在变更管理数据库中。

6. 进度管理计划的实施和监控

在项目进行过程中，项目经理严格按照进度管理计划执行：

每周召开进度会议，跟踪项目进展。
定期提交进度报告，确保所有团队成员了解项目状态。
及时处理进度偏差，确保项目按时完成。

总结

通过制定详细的进度管理计划，项目经理能够有效地管理项目的时间安排和进度，确保项目按时完成。进度管理计划不仅包括项目时间表，还包括进度管理方法、进度控制机制、进度报告格式和变更管理流程。通过严格执行进度管理计划，项目团队可以更好地控制项目进度，减少进度偏差，提高项目的成功率。

定义活动（acitvity）

活动（activity）或任务（task）是工作的组成要素，通常出现在工作分解结构中。有预计的工期，成本和资源要求。逐个过程的主要输出是活动清单，活动属性，里程碑清单和更新的项目管理计划。

举个例子：

在项目管理中，活动（Activity）或任务（Task）是构成项目工作的基本单元，通常出现在工作分解结构（WBS）中。每个活动或任务都有预计的工期、成本和资源要求。在项目计划过程中，这些活动或任务会被详细定义和管理，其主要输出包括：

活动清单（Activity List）
活动属性（Activity Attributes）
里程碑清单（Milestone List）
更新的项目管理计划（Updated Project Management Plan）

以下是一个具体的例子，帮助你理解这些概念：

例子背景

假设一家公司正在开发一个在线学习平台，项目团队已经完成了工作分解结构（WBS），并确定了以下主要任务：

1.需求分析

2.系统设计

3.前端开发

4.后端开发

5.测试

6.部署

7.用户验收测试

8.上线

每个任务都有具体的活动组成，以下是详细的例子：

1. 需求分析

活动清单（Activity List）

1.1 用户需求调研
- 预计工期：2周
- 成本：$5,000（调研费用）
- 资源要求：
  - 1名业务分析师
  - 1名用户体验设计师
1.2 需求规格说明书编写
- 预计工期：3周
- 成本：$7,500（编写和审核费用）
- 资源要求：
  - 1名业务分析师
  - 1名项目经理

活动属性（Activity Attributes）

活动名称：用户需求调研
活动描述：与客户和最终用户进行访谈，收集需求并编写调研报告。
前置任务：无
后置任务：需求规格说明书编写
负责人：张伟（业务分析师）
里程碑：完成用户需求调研报告

里程碑清单（Milestone List）

里程碑1：完成用户需求调研（2023年5月15日）
里程碑2：完成需求规格说明书（2023年5月31日）

更新的项目管理计划

进度计划更新：将需求分析阶段的起止日期更新为2023年5月1日 - 2023年5月31日。
资源计划更新：分配1名业务分析师和1名用户体验设计师到需求分析任务。
预算更新：将需求分析阶段的预算更新为$12,500。

2. 系统设计

活动清单（Activity List）

2.1 系统架构设计
- 预计工期：2周
- 成本：$10,000（设计费用）
- 资源要求：
  - 1名系统架构师
  - 1名技术负责人
2.2 数据库设计
- 预计工期：2周
- 成本：$8,000（设计费用）
- 资源要求：
  - 1名数据库设计师
  - 1名后端开发人员

活动属性（Activity Attributes）

活动名称：系统架构设计
活动描述：设计系统的整体架构，包括技术选型、模块划分和接口设计。
前置任务：完成需求分析
后置任务：数据库设计
负责人：李强（系统架构师）
里程碑：完成系统架构设计

里程碑清单（Milestone List）

里程碑3：完成系统架构设计（2023年6月15日）
里程碑4：完成数据库设计（2023年6月30日）

更新的项目管理计划

进度计划更新：将系统设计阶段的起止日期更新为2023年6月1日 - 2023年6月30日。
资源计划更新：分配1名系统架构师和1名数据库设计师到系统设计任务。
预算更新：将系统设计阶段的预算更新为$18,000。

3. 前端开发

活动清单（Activity List）

3.1 用户界面设计
- 预计工期：2周
- 成本：$7,000（设计费用）
- 资源要求：
  - 1名UI设计师
  - 1名前端开发人员
3.2 前端功能开发
- 预计工期：4周
- 成本：$15,000（开发费用）
- 资源要求：
  - 2名前端开发人员

活动属性（Activity Attributes）

活动名称：用户界面设计
活动描述：设计用户界面原型，并与客户确认。
前置任务：完成系统设计
后置任务：前端功能开发
负责人：王芳（UI设计师）
里程碑：完成用户界面设计

里程碑清单（Milestone List）

里程碑5：完成用户界面设计（2023年7月15日）
里程碑6：完成前端功能开发（2023年8月15日）

更新的项目管理计划

进度计划更新：将前端开发阶段的起止日期更新为2023年7月1日 - 2023年8月15日。
资源计划更新：分配2名前端开发人员和1名UI设计师到前端开发任务。
预算更新：将前端开发阶段的预算更新为$22,000。

总结

通过详细的活动清单、活动属性和里程碑清单，项目团队可以更好地管理和控制项目的进度、成本和资源。每个活动或任务都有明确的负责人、预计工期、成本和资源要求，确保项目能够按时、按预算完成。

这些输出不仅帮助项目团队跟踪项目进展，还为项目计划的更新提供了依据。通过不断更新项目管理计划，项目团队可以及时调整项目进度、资源分配和预算，确保项目目标的实现。

排序活动

是指识别和记录项目活动之间的关系。这个过程的主要输出包括项目的进度网络图和更新的项目文档。

举个例子：

排序活动的步骤

识别活动：

- 确定项目中的所有活动或任务，这些活动通常来自工作分解结构（WBS）。

确定依赖关系：

- 识别活动之间的依赖关系。常见的依赖关系类型包括：
  - 完成到开始（Finish-to-Start, FS）：前一个活动必须完成，后一个活动才能开始。
  - 开始到开始（Start-to-Start, SS）：前一个活动开始后，后一个活动才能开始。
  - 完成到完成（Finish-to-Finish, FF）：前一个活动完成后，后一个活动才能完成。
  - 开始到完成（Start-to-Finish, SF）：前一个活动开始后，后一个活动才能完成。

绘制进度网络图：

- 使用网络图（如前导图法或箭线图法）来表示活动之间的关系和依赖。

更新项目文档：

- 将排序活动的成果更新到项目文档中，包括进度计划、项目管理计划等。

例子

假设一家公司正在开发一个在线学习平台，项目团队已经完成了工作分解结构（WBS），并确定了以下主要任务：

1.需求分析

2.系统设计

3.前端开发

4.后端开发

5.测试

6.部署

7.用户验收测试

8.上线

项目团队需要对这些活动进行排序，确定它们之间的依赖关系，并绘制进度网络图。

1. 识别活动

项目团队已经识别了以下主要活动：

需求分析
系统设计
前端开发
后端开发
测试
部署
用户验收测试
上线

2. 确定依赖关系

项目团队确定了以下依赖关系：

需求分析必须在系统设计之前完成（FS）。
系统设计必须在前端开发和后端开发之前完成（FS）。
前端开发和后端开发可以并行进行（SS）。
前端开发和后端开发完成后，才能开始测试（FS）。
测试必须在部署之前完成（FS）。
部署必须在用户验收测试之前完成（FS）。
用户验收测试必须在上线之前完成（FS）。

3. 绘制进度网络图

项目团队使用前导图法（Precedence Diagramming Method, PDM）绘制了以下进度网络图：

取消自动换行

复制

需求分析 (FS) -> 系统设计 (FS) -> 前端开发 (FS) -> 测试 (FS) -> 部署 (FS) -> 用户验收测试 (FS) -> 上线

└-> 后端开发 (FS) -┘

需求分析完成后，才能开始系统设计。
系统设计完成后，前端开发和后端开发可以并行进行。
前端开发和后端开发都完成后，才能开始测试。
测试完成后，才能进行部署。
部署完成后，才能进行用户验收测试。
用户验收测试完成后，才能上线。

4. 更新项目文档

项目团队将排序活动的成果更新到项目文档中：

进度网络图：将上述网络图添加到项目进度计划中。
项目管理计划更新：
- 进度计划更新：根据网络图更新项目进度计划，明确各项任务的开始和结束日期。
- 资源计划更新：根据任务顺序和依赖关系，调整资源分配计划。
- 风险管理计划更新：识别潜在的进度风险，并制定相应的风险应对措施。

进度网络图示例

以下是上述依赖关系的进度网络图示例：

取消自动换行

复制

[需求分析] --FS--> [系统设计] --FS--> [前端开发] --FS--> [测试] --FS--> [部署] --FS--> [用户验收测试] --FS--> [上线]

└--> [后端开发] -FS-┘

FS 表示“完成到开始”依赖关系。
SS 表示“开始到开始”依赖关系（在本例中未使用）。

总结

通过排序活动，项目团队可以明确各项任务之间的依赖关系和顺序，绘制出项目的进度网络图，并更新项目文档。这不仅有助于制定合理的项目进度计划，还能帮助项目团队识别潜在的进度风险，并制定相应的风险应对措施。

在上述例子中，排序活动帮助项目团队确定了各项任务的具体顺序和依赖关系，确保项目能够按时、按计划进行。

估算活动资源

是指估算一个团队应该使用多少资源（resource）--人力，设备和原料来执行项目活动。这个过程的主要输出是活动资源需求，资源分解结构和更新的项目文档。

举个例子：

1）估算活动资源

估算活动资源是指在项目管理中，估算完成每个项目活动所需的各种资源，包括人力、设备和原料。这个过程的主要输出包括活动资源需求（Activity Resource Requirements）、资源分解结构（Resource Breakdown Structure, RBS）以及更新的项目文档。通过估算活动资源，项目团队可以明确每个任务所需的资源类型和数量，从而更有效地进行资源分配和管理。

以下是详细的解释，并附有一个具体的例子，帮助你更好地理解这个过程。

估算活动资源的步骤

识别活动：

- 确定项目中的所有活动或任务，这些活动通常来自工作分解结构（WBS）。

确定资源需求：

- 估算每个活动所需的资源类型和数量，包括：
  - 人力资源：如开发人员、测试人员、项目经理等。
  - 设备资源：如计算机、服务器、测试设备等。
  - 原料资源：如软件许可证、建筑材料等。

评估资源可用性：

- 评估组织内部或外部可用的资源，确保资源需求与资源可用性相匹配。

制定资源分解结构（RBS）：

- 将资源按类别和层次结构进行分解，形成资源分解结构。

更新项目文档：

- 将估算结果更新到项目文档中，包括项目计划、资源计划等。

例子

假设一家公司正在开发一个在线学习平台，项目团队已经完成了工作分解结构（WBS），并确定了以下主要任务：

1.需求分析

2.系统设计

3.前端开发

4.后端开发

5.测试

6.部署

7.用户验收测试

8.上线

项目团队需要对每个任务进行资源估算，以下是详细的例子：

1. 需求分析

活动资源需求（Activity Resource Requirements）

人力资源：
- 1名业务分析师（负责用户需求调研和需求规格说明书编写）
- 1名用户体验设计师（负责用户界面原型设计）
设备资源：
- 每人1台笔记本电脑
- 1台服务器用于存储和共享需求文档
原料资源：
- 需求分析软件许可证（如JIRA, Confluence）
- 办公用品（如纸张、笔）

资源分解结构（Resource Breakdown Structure, RBS）

取消自动换行

复制

解释

需求分析

├── 人力资源

│ ├── 业务分析师

│ └── 用户体验设计师

├── 设备资源

│ ├── 笔记本电脑

│ └── 服务器

└── 原料资源

├── 软件许可证

└── 办公用品

更新的项目文档

项目计划更新：
- 将需求分析的资源需求更新到项目计划中，包括人力资源、设备资源和原料资源。
资源计划更新：
- 分配1名业务分析师和1名用户体验设计师到需求分析任务。
- 预订所需的设备资源和原料资源。

2. 系统设计

活动资源需求（Activity Resource Requirements）

人力资源：
- 1名系统架构师（负责系统架构设计）
- 1名数据库设计师（负责数据库设计）
设备资源：
- 每人1台高性能笔记本电脑
- 1台服务器用于存储和共享设计文档
原料资源：
- 系统设计软件许可证（如Microsoft Visio, Lucidchart）
- 办公用品（如纸张、笔）

资源分解结构（Resource Breakdown Structure, RBS）

取消自动换行

复制

解释

系统设计

├── 人力资源

│ ├── 系统架构师

│ └── 数据库设计师

├── 设备资源

│ ├── 高性能笔记本电脑

│ └── 服务器

└── 原料资源

├── 软件许可证

└── 办公用品

更新的项目文档

项目计划更新：
- 将系统设计的资源需求更新到项目计划中，包括人力资源、设备资源和原料资源。
资源计划更新：
- 分配1名系统架构师和1名数据库设计师到系统设计任务。
- 预订所需的设备资源和原料资源。

3. 前端开发

活动资源需求（Activity Resource Requirements）

人力资源：
- 2名前端开发人员（负责用户界面开发）
设备资源：
- 每人1台高性能笔记本电脑
- 1台服务器用于代码存储和版本控制
原料资源：
- 前端开发软件许可证（如Visual Studio Code, Adobe Creative Cloud）
- 办公用品（如纸张、笔）

资源分解结构（Resource Breakdown Structure, RBS）

取消自动换行

复制

解释

前端开发

├── 人力资源

│ └── 前端开发人员

├── 设备资源

│ ├── 高性能笔记本电脑

│ └── 服务器

└── 原料资源

├── 软件许可证

└── 办公用品

更新的项目文档

项目计划更新：
- 将前端开发的资源需求更新到项目计划中，包括人力资源、设备资源和原料资源。
资源计划更新：
- 分配2名前端开发人员到前端开发任务。
- 预订所需的设备资源和原料资源。

4. 后端开发

活动资源需求（Activity Resource Requirements）

人力资源：
- 2名后端开发人员（负责服务器端逻辑和数据库开发）
设备资源：
- 每人1台高性能笔记本电脑
- 1台服务器用于代码存储和版本控制
原料资源：
- 后端开发软件许可证（如IntelliJ IDEA, MySQL Workbench）
- 办公用品（如纸张、笔）

资源分解结构（Resource Breakdown Structure, RBS）

取消自动换行

复制

解释

后端开发

├── 人力资源

│ └── 后端开发人员

├── 设备资源

│ ├── 高性能笔记本电脑

│ └── 服务器

└── 原料资源

├── 软件许可证

└── 办公用品

更新的项目文档

项目计划更新：
- 将后端开发的资源需求更新到项目计划中，包括人力资源、设备资源和原料资源。
资源计划更新：
- 分配2名后端开发人员到后端开发任务。
- 预订所需的设备资源和原料资源。

5. 测试

活动资源需求（Activity Resource Requirements）

人力资源：
- 2名测试人员（负责功能测试和用户验收测试）
设备资源：
- 每人1台笔记本电脑
- 1台服务器用于测试环境
原料资源：
- 测试软件许可证（如Selenium, JUnit）
- 办公用品（如纸张、笔）

资源分解结构（Resource Breakdown Structure, RBS）

取消自动换行

复制

解释

测试

├── 人力资源

│ └── 测试人员

├── 设备资源

│ ├── 笔记本电脑

│ └── 服务器

└── 原料资源

├── 软件许可证

└── 办公用品

更新的项目文档

项目计划更新：
- 将测试的资源需求更新到项目计划中，包括人力资源、设备资源和原料资源。
资源计划更新：
- 分配2名测试人员到测试任务。
- 预订所需的设备资源和原料资源。

总结

通过估算活动资源，项目团队可以明确每个任务所需的资源类型和数量，并制定详细的资源计划。这不仅有助于资源的有效分配和管理，还能提高项目的成功率。在上述例子中，估算活动资源帮助项目团队确定了每个任务所需的人力、设备和原料，并更新了项目文档，确保项目能够按时、按预算完成。

估算活动工期

是指估算完成单项活动所需的工作时间。这个过程的主要输出包括活动工期估算和更新项目文档。

举个例子：

估算活动工期的步骤

识别活动：

- 确定项目中的所有活动或任务，这些活动通常来自工作分解结构（WBS）。

确定活动资源：

- 明确每个活动所需的资源，包括人力、设备和原料等。资源的需求和可用性会直接影响活动的工期。

估算活动工期：

- 使用以下方法估算每个活动的工期：
  - 专家判断：依靠有经验的项目经理或专家的判断。
  - 类比估算：根据类似项目的历史数据来估算当前项目的工期。
  - 参数估算：使用数学模型或统计方法，根据已知参数（如工作量、资源数量）来估算工期。
  - 三点算：使用乐观时间（O）、最可能时间（M）和悲观时间（P）来计算期望工期，公式为 (O + 4M + P) / 6。

考虑资源可用性：

- 考虑资源的可用性和工作时间，例如工作日、加班时间、假期等。

更新项目文档：

- 将估算结果更新到项目文档中，包括项目进度计划、项目管理计划等。

例子

假设一家公司正在开发一个在线学习平台，项目团队已经完成了工作分解结构（WBS），并确定了以下主要任务：

1.需求分析

2.系统设计

3.前端开发

4.后端开发

5.测试

6.部署

7.用户验收测试

8.上线

项目团队需要对每个任务的工期进行估算，以下是详细的例子：

1. 需求分析

活动资源需求

人力资源：
- 1名业务分析师
- 1名用户体验设计师
设备资源：
- 每人1台笔记本电脑
- 1台服务器

活动工期估算

专家判断：
- 项目经理根据以往类似项目的经验，估算需求分析需要2周时间。
类比估算：
- 参考类似项目的历史数据，需求分析通常需要1.5到2周。
参数估算：
- 假设需求分析的工作量为80小时，业务分析师和用户体验设计师每周工作40小时，则工期为2周。
三点估算：
- 乐观时间（O）：1.5周
- 最可能时间（M）：2周
- 悲观时间（P）：2.5周
- 期望工期 = (1.5 + 4*2 + 2.5) / 6 = 2周

更新项目文档

项目进度计划更新：
- 将需求分析的工期更新为2周，并将其纳入项目进度计划。
项目文档更新：
- 更新需求分析的任务描述和工期。

2. 系统设计

活动资源需求

人力资源：
- 1名系统架构师
- 1名数据库设计师
设备资源：
- 每人1台高性能笔记本电脑
- 1台服务器

活动工期估算

专家判断：
- 项目经理根据以往类似项目的经验，估算系统设计需要3周时间。
类比估算：
- 参考类似项目的历史数据，系统设计通常需要2.5到3周。
参数估算：
- 假设系统设计的工作量为120小时，系统架构师和数据库设计师每周工作40小时，则工期为3周。
三点估算：
- 乐观时间（O）：2.5周
- 最可能时间（M）：3周
- 悲观时间（P）：3.5周
- 期望工期 = (2.5 + 4*3 + 3.5) / 6 = 3周

更新项目文档

项目进度计划更新：
- 将系统设计的工期更新为3周，并将其纳入项目进度计划。
项目文档更新：
- 更新系统设计的任务描述和工期。

3. 前端开发

活动资源需求

人力资源：
- 2名前端开发人员
设备资源：
- 每人1台高性能笔记本电脑
- 1台服务器

活动工期估算

专家判断：
- 项目经理根据以往类似项目的经验，估算前端开发需要4周时间。
类比估算：
- 参考类似项目的历史数据，前端开发通常需要3.5到4周。
参数估算：
- 假设前端开发的工作量为160小时，2名前端开发人员每周工作40小时，则工期为2周。
三点估算：
- 乐观时间（O）：3周
- 最可能时间（M）：4周
- 悲观时间（P）：5周
- 期望工期 = (3 + 4*4 + 5) / 6 = 4周

更新项目文档

项目进度计划更新：
- 将前端开发的工期更新为4周，并将其纳入项目进度计划。
项目文档更新：
- 更新前端开发的任务描述和工期。

4. 后端开发

活动资源需求

人力资源：
- 2名后端开发人员
设备资源：
- 每人1台高性能笔记本电脑
- 1台服务器

活动工期估算

专家判断：
- 项目经理根据以往类似项目的经验，估算后端开发需要4周时间。
类比估算：
- 参考类似项目的历史数据，后端开发通常需要3.5到4周。
参数估算：
- 假设后端开发的工作量为160小时，2名后端开发人员每周工作40小时，则工期为2周。
三点估算：
- 乐观时间（O）：3周
- 最可能时间（M）：4周
- 悲观时间（P）：5周
- 期望工期 = (3 + 4*4 + 5) / 6 = 4周

更新项目文档

项目进度计划更新：
- 将后端开发的工期更新为4周，并将其纳入项目进度计划。
项目文档更新：
- 更新后端开发的任务描述和工期。

5. 测试

活动资源需求

人力资源：
- 2名测试人员
设备资源：
- 每人1台笔记本电脑
- 1台服务器

活动工期估算

专家判断：
- 项目经理根据以往类似项目的经验，估算测试需要3周时间。
类比估算：
- 参考类似项目的历史数据，测试通常需要2.5到3周。
参数估算：
- 假设测试的工作量为120小时，2名测试人员每周工作40小时，则工期为1.5周。
三点估算：
- 乐观时间（O）：2周
- 最可能时间（M）：3周
- 悲观时间（P）：4周
- 期望工期 = (2 + 4*3 + 4) / 6 = 3周

更新项目文档

项目进度计划更新：
- 将测试的工期更新为3周，并将其纳入项目进度计划。
项目文档更新：
- 更新测试的任务描述和工期。

总结

通过估算活动工期，项目团队可以明确每个任务需要多长时间才能完成，并更新项目文档。这不仅有助于制定合理的项目进度计划，还能帮助项目团队识别潜在的进度风险，并制定相应的风险应对措施。

在上述例子中，估算活动工期帮助项目团队确定了每个任务的工期，并更新了项目进度计划，确保项目能够按时、按计划进行。

6）制定进度

是指通过分析活动序列，活动资源估算和活动工期估算来创建项目进度，这个过程的主要输出包括一个进度基线，项目进度，进度数据，项目日历，更新的项目管理计划和更新的项目文件。

举个例子：

制定进度

制定进度是指在项目管理中，通过分析活动序列、活动资源估算和活动工期估算，来创建项目的进度计划。这个过程的主要输出包括进度基线（Schedule Baseline）、项目进度（Project Schedule）、进度数据（Schedule Data）、项目日历（Project Calendar），以及更新的项目管理计划和更新的项目文件。通过制定进度，项目团队可以明确项目的整体时间安排和里程碑，确保项目按时完成。

以下是详细的解释，并附有一个具体的例子，帮助你更好地理解这个过程。

制定进度的步骤

分析活动序列：

- 确定项目活动中各个任务的依赖关系和顺序。这通常通过进度网络图（Schedule Network Diagram）来表示。

活动资源估算：

- 估算每个活动所需的资源，包括人力、设备和原料等。资源的需求和可用性会直接影响活动的工期。

活动工期估算：

- 估算完成每个活动所需的工作时间。这可以通过专家判断、类比估算、参数估算或三点估算等方法进行。

创建项目进度计划：

- 综合以上信息，制定项目的进度计划，包括每个活动的开始和结束日期、关键路径和里程碑。

确定进度基线：

- 进度基线是经过批准的项目进度计划，作为项目时间管理的基准，用于衡量项目进度绩效。

更新项目文档：

- 将制定的进度计划更新到项目文档中，包括项目管理计划、项目进度计划等。

例子

假设一家公司正在开发一个在线学习平台，项目团队已经完成了以下工作：

工作分解结构（WBS）：确定了项目的所有主要任务和子任务。
活动资源估算：确定了每个任务所需的人力、设备和原料。
活动工期估算：估算了每个任务所需的工作时间。

现在，项目团队需要制定项目的进度计划，以下是详细的例子：

1. 分析活动序列

项目团队已经确定了以下主要任务和它们的依赖关系：

需求分析（FS）→ 系统设计（FS）→ 前端开发（FS）→ 测试（FS）→ 部署（FS）→ 用户验收测试（FS）→ 上线
系统设计（FS）→ 后端开发（FS）→ 测试（FS）

进度网络图

取消自动换行

复制

[需求分析] --FS--> [系统设计] --FS--> [前端开发] --FS--> [测试] --FS--> [部署] --FS--> [用户验收测试] --FS--> [上线]

└--> [后端开发] -FS-┘

FS 表示“完成到开始”依赖关系。

2. 活动资源估算

项目团队已经估算了每个任务所需的资源，例如：

需求分析：
- 人力资源：1名业务分析师，1名用户体验设计师
- 设备资源：每人1台笔记本电脑，1台服务器
系统设计：
- 人力资源：1名系统架构师，1名数据库设计师
- 设备资源：每人1台高性能笔记本电脑，1台服务器
前端开发：
- 人力资源：2名前端开发人员
- 设备资源：每人1台高性能笔记本电脑，1台服务器
后端开发：
- 人力资源：2名后端开发人员
- 设备资源：每人1台高性能笔记本电脑，1台服务器
测试：
- 人力资源：2名测试人员
- 设备资源：每人1台笔记本电脑，1台服务器

3. 活动工期估算

项目团队已经估算了每个任务的工期，例如：

需求分析：2周
系统设计：3周
前端开发：4周
后端开发：4周
测试：3周
部署：1周
用户验收测试：2周
上线：1周

4. 创建项目进度计划

项目团队使用项目管理软件（如Microsoft Project, Primavera, 或其他工具）创建项目进度计划：

项目开始日期：2023年5月1日
项目结束日期：2023年12月31日

项目进度计划

任务名称	开始日期	结束日期	工期	前置任务
需求分析	2023年5月1日	2023年5月14日	2周	无
系统设计	2023年5月15日	2023年6月4日	3周	需求分析
前端开发	2023年6月5日	2023年7月2日	4周	系统设计
后端开发	2023年6月5日	2023年7月2日	4周	系统设计
测试	2023年7月3日	2023年7月23日	3周	前端开发, 后端开发
部署	2023年7月24日	2023年7月30日	1周	测试
用户验收测试	2023年7月31日	2023年8月13日	2周	部署
上线	2023年8月14日	2023年8月20日	1周	用户验收测试

5. 确定进度基线

项目团队将上述进度计划作为进度基线，并获得项目发起人的批准。进度基线将作为项目时间管理的基准，用于衡量项目进度绩效。

6. 更新项目文档

项目团队将制定的进度计划更新到项目文档中：

项目管理计划更新：
- 更新项目进度计划，包括每个任务的开始和结束日期。
- 更新资源计划，包括人力资源、设备资源和原料资源。
项目文件更新：
- 更新项目进度网络图。
- 更新项目日历，包括工作日和节假日。

总结

通过制定进度，项目团队可以明确项目的整体时间安排和里程碑，确保项目按时完成。进度基线作为项目时间管理的基准，用于衡量项目进度绩效。通过更新项目文档，项目团队可以确保所有相关方都了解项目的进度计划，并及时发现和解决潜在的进度风险。

在上述例子中，制定进度帮助项目团队确定了每个任务的开始和结束日期，并更新了项目文档，确保项目能够按时、按计划进行。

1. 1. 控制进度

是指控制和管理项目进度的变更，这个过程的主要输出包括工作绩效信息，进度预测，变更请求，项目管理计划的更新，项目文档的更新和组织过程资产的更新。

举个例子：

7）控制进度

控制进度是指在项目管理过程中，对项目进度进行监控、分析和管理，以确保项目按计划进行，并在必要时采取纠正措施。这个过程的主要目标是识别进度偏差、分析其影响，并采取适当的措施来调整项目进度，以确保项目按时完成。控制进度的主要输出包括工作绩效信息、进度预测、变更请求、项目管理计划的更新、项目文档的更新以及组织过程资产的更新。

以下是详细的解释，并附有一个具体的例子，帮助你更好地理解这个过程。

控制进度的步骤

监控项目进度：

- 定期收集项目进度数据，包括已完成的任务、正在进行中的任务和未开始的任务。
- 使用项目管理工具（如Gantt图、进度网络图）来跟踪项目进度。

比较实际进度与计划进度：

- 将实际进度与项目进度计划进行比较，识别任何偏差。
- 确定哪些任务落后于计划，哪些任务提前完成。

分析进度偏差：

- 分析进度偏差的原因，例如资源不足、技术问题、需求变更等。
- 评估进度偏差对项目整体进度的影响。

制定和实施纠正措施：

- 根据进度偏差的分析结果，制定纠正措施，例如调整资源分配、重新安排任务顺序、加班等。
- 实施纠正措施，并监控其效果。

更新项目计划和文档：

- 根据纠正措施的结果，更新项目进度计划和其他相关项目文档。
- 确保所有相关方都了解最新的项目进度计划。

管理变更请求：

- 处理任何与进度相关的变更请求，例如客户要求提前交付日期或增加新功能。
- 评估变更请求的可行性和影响，并获得必要的批准。

更新组织过程资产：

- 将进度控制的经验教训更新到组织过程资产中，例如项目档案、经验教训数据库等。

例子

假设一家公司正在开发一个在线学习平台，项目团队已经制定了项目进度计划，并开始了项目执行。以下是控制进度的具体例子：

1. 监控项目进度

项目团队每周召开一次项目进度会议，收集以下进度数据：

已完成的任务：
- 需求分析（2周）
- 系统设计（3周）
正在进行中的任务：
- 前端开发（计划4周，已完成2周）
- 后端开发（计划4周，已完成2周）
未开始的任务：
- 测试（计划3周）
- 部署（计划1周）
- 用户验收测试（计划2周）
- 上线（计划1周）

2. 比较实际进度与计划进度

项目团队将实际进度与计划进度进行比较，发现以下偏差：

前端开发：
- 计划完成时间：2023年7月2日
- 实际完成时间：预计2023年7月9日（落后1周）
后端开发：
- 计划完成时间：2023年7月2日
- 实际完成时间：预计2023年7月9日（落后1周）

3. 分析进度偏差

项目团队分析进度偏差的原因：

前端开发：
- 原因：一名前端开发人员因病请假，导致开发进度落后。
后端开发：
- 原因：技术问题导致开发进度延迟。

4. 制定和实施纠正措施

项目团队制定以下纠正措施：

前端开发：
- 安排其他前端开发人员加班，弥补请假人员的工作量。
- 重新安排任务优先级，确保关键任务按时完成。
后端开发：
- 增加一名后端开发人员，协助解决技术问题。
- 安排技术专家进行技术指导，加快问题解决速度。

项目团队实施纠正措施，并监控其效果：

前端开发：
- 通过加班和重新安排任务，前端开发进度恢复正常，预计可以按时完成。
后端开发：
- 通过增加人员和专家指导，后端开发进度恢复正常，预计可以按时完成。

5. 更新项目计划和文档

项目团队更新项目进度计划和其他相关项目文档：

项目进度计划更新：
- 将前端开发和后端开发的预计完成时间更新为2023年7月9日。
项目管理计划更新：
- 更新资源计划，增加一名后端开发人员。
- 更新风险登记册，记录技术问题的风险和解决方案。

6. 管理变更请求

项目团队处理以下变更请求：

客户要求增加一个新功能：
- 项目团队评估变更请求的可行性和影响。
- 评估结果显示，增加新功能需要额外的时间和资源。
- 项目团队与客户协商，调整项目范围和进度计划。

7. 更新组织过程资产

项目团队将进度控制的经验教训更新到组织过程资产中：

经验教训：
- 在项目初期，应制定更详细的资源备份计划，以应对人员请假或离职的情况。
- 应加强技术问题管理，及时识别和解决技术问题，避免影响项目进度。

总结

通过控制进度，项目团队可以及时识别和解决进度偏差，确保项目按时完成。控制进度不仅包括监控和比较实际进度与计划进度，还包括分析偏差原因、制定和实施纠正措施，以及管理变更请求。通过更新项目计划和文档，项目团队可以确保所有相关方都了解最新的项目进度计划，并及时发现和解决潜在的进度风险。

在上述例子中，控制进度帮助项目团队识别了前端开发和后端开发的进度偏差，并采取了有效的纠正措施，确保项目能够按时完成。

7.5计划进度管理

在项目时间管理中的第一部就是制定在整个生命周期进度如何管理的计划。项目进度源于启动项目的基本文档。项目章程中经常提到项目的计划开始和结束日期，它可以作为更加详细的进度起始点。

7.6定义活动(identify activity)

1. 1. 定义活动的产出
    1. 活动清单(activity list)

活动清单是包含在项目进度中的活动列表。

1. 1. 1. 活动属性(activity attribute)

活动属性提供了与进度相关的更多信息

1. 1. 1. 里程碑(milestone)

是项目中一个通常没有工期的重要事件。需要一些活动和大量的工作来完成一个里程碑。但是里程碑本身更像是一个标志来帮助识别相关的活动中。

1. 1. 1. 项目管理计划的更新

7.7排序活动

依赖（dependency）

依赖或关系（relation）与项目活动或任务的排序相关。例如：一个特定的活动是否必须在另外活动开始前完成？项目团队是否能够同时并行做几个活动？能否有交叉？界定这些活动之间的关系或者依赖对于开发和管理项目进度有重要影响。

依赖的分类

强制依赖（mandatory dependency）

强制依赖是项目工作中内在的一种关系，某些时候被称为硬逻辑。例如：在写代码之前，你不可以测试代码。

自由依赖（discretionary dependency）

自由依赖是由项目团队定义的项目活动之间的关系。例如：项目团队可能遵循好的实践，在用户签署同一所有分析工作之前，项目团队不会开始新的信息系统的详细设计。已有依赖有时后叫做软逻辑，应该谨慎使用。

外部依赖（external dependency）

涉及项目和非项目活动之间的关系。例如：新的操作系统和其他软件的安装依赖于外部供应商交付的新硬件。

7.8网络图（network diagram）

1）什么是网络图

网络图是表示活动排序的首选技术。一个网络图（network diagram）是项目活动之间的逻辑关系或者循序的示意性表示

2）网格图的格式

1>网格图的格式使用的是AOA法（activity-on-arrow）

A = 1：表示活动A的工期为1天。对于D和A活动来说，A活动必须在D活动之前完成。

箭线图法（arrow diagramming method，ADM）：这是一种网络图技术。在该图活动用箭头表示，并将节点连接起来，表示活动的序列。

节点（node）：可以表示为一个活动的开始和结束，第一个节点表示项目的开始，最后一个节点表示项目的结束。

如果有工期估计，那就放在活动字母或者名字附近。

2>(或者)箭线图法（arrow diagramming method,ADM）

3>前导图法（precedence diagramming method,PDM）

1》什么时候使用前导图(FS,SS,SF,FF)

PDM也是一种网络图技术，前导图使用方框表示活动，它在特定类型的时间关系时特别有用。

PDM 在以下几种情况下特别有用：

1. 活动之间存在复杂的依赖关系时

当项目中的活动之间存在多种依赖关系时，PDM 可以清晰地展示这些关系。PDM 支持四种主要的依赖关系类型：
- 完成到开始（Finish-to-Start, FS）: 一个活动必须在另一个活动完成之后才能开始。
- 完成到完成（Finish-to-Finish, FF）: 一个活动必须在另一个活动完成之后才能完成。
- 开始到开始（Start-to-Start, SS）: 一个活动必须在另一个活动开始之后才能开始。
- 开始到完成（Start-to-Finish, SF）: 一个活动必须在另一个活动开始之后才能完成。
当项目需要精确控制这些依赖关系时，PDM 提供了更直观和详细的表示方式。

2. 需要详细的时间管理时

PDM 允许在节点之间定义时间延迟（lag）和提前量（lead），这对于需要精确控制活动时间间隔的项目非常有用。例如，某些活动可能需要在另一个活动完成一段时间后才能开始，这时可以使用延迟时间。

3. 资源分配和优化时

PDM 可以帮助项目经理更好地进行资源分配和优化。通过清晰地展示活动之间的关系，项目经理可以更容易地识别出潜在的瓶颈和资源冲突，从而进行有效的资源调度。

4. 项目复杂且规模较大时

对于复杂且规模较大的项目，PDM 提供了一种结构化的方法来组织和展示项目活动。这种方法可以帮助团队成员更好地理解项目进度和任务之间的关系，从而提高项目的整体效率和成功率。

5. 需要详细的进度报告和分析时

PDM 生成的进度网络图可以用于详细的进度报告和分析。通过 PDM，项目经理可以更准确地跟踪项目进度，识别出进度偏差，并采取相应的纠正措施。

总结

前导图法（PDM）在以下情况下特别有用：

活动之间存在复杂的依赖关系。
需要详细的时间管理，包括延迟和提前量。
需要进行资源分配和优化。
项目复杂且规模较大。
需要详细的进度报告和分析。

通过使用 PDM，项目经理可以更有效地规划和控制项目进度，确保项目按时、按预算、按质量完成。

2》前导图的方框表示

- 完成到开始（Finish-to-Start, FS）: 一个活动必须在另一个活动完成之后才能开始。
- 完成到完成（Finish-to-Finish, FF）: 一个活动必须在另一个活动完成之后才能完成。
- 开始到开始（Start-to-Start, SS）: 一个活动必须在另一个活动开始之后才能开始。
- 开始到完成（Start-to-Finish, SF）: 一个活动必须在另一个活动开始之后才能完成。

3》前导图法要注意的点

多数的项目管理软件使用前导图法
前导图法避免了虚活动（虚活动[dummy acitvity]：没有工期而且没有资源，但是有时需要AOA网络图上用虚活动表示活动之间的逻辑关系，它们是用虚的箭头表示的，工期估算为0）的需要
前导图法表示了任务之间的不同依赖，而AOA网络图只使用了完成-开始依赖。

资源分解结构（resource breakdown structure）

资源分解结构是一种层次结构，可以按照种类和类型确定项目的资源。资源的种类包括分析员，程序员和测试员。这些信息将有助于确定资源成本，获取资源等方面。

估算活动工期

什么时候估算活动的工期

与关键干系人一起定义活动，决定活动之间的依赖并估计需要的资源之后，项目时间管理中的下一个过程是估算活动的工期。

工期（duration）

工期包括活动上花费的实际时间和占用时间。（工期的花费应该比实际工作花费时间多，比如：即使花费一个工作周或者5个工作日来做实际的工作，工期估计也可能是两周，因为多余的时间需要用来获取外部的信息。分配给任务的人员或资源也将影响任务的工期估计。）

人工量（effort）

有的人往往会把工期和人工量混淆，人工量是指完成一个任务所需的总工作量，通常以工作天数或工作小时数来衡量。人工量只考虑实际执行工作的时间，不包括等待时间或其他非工作时间。

例如，完成一个任务可能需要5个工作日的人工量，这意味着一个人需要连续工作5天，或者两个人各工作2.5天。

甘特图（Gantt chart）

1. 什么是甘特图

甘特图提供了一种显示项目进度信息的标准格式。

1. 在甘特图上增加里程碑

Notice:SMART准则是认为里程碑应该是：

明确的（special）
可度量的（measurable）
可分配的（assignable）
现实的（realistic）
有时间限制的（time-framed）
1. 使用跟踪甘特图来比较计划和实际的日期

1》跟踪甘特图示例

跟踪甘特图需要知道的一些概念

基线日期（baseline date）

基线日期是指活动的计划进度日期。

跟踪甘特图Tracking Gantt Chart）

是一个比较计划和实际项目进度信息的甘特图。

进度基线（schedule baseline）

整个经过审批的计划进度被称为进度基线。

任务的表示法

跟踪甘特图上的双横线，上面的横条代表基线工期。如果说上下的横条长度不相同，那么说明实际的进度和计划的进度不同。如果上面的横条比下面的横条短说明，实际使用的工期超出了计划的工期。

偏移的里程碑（slipped milestone）

在跟踪甘特图上的白色菱形表示了一个偏移的里程碑。意味着里程碑活动的实际完成时间比原来的计划短。

右边的横条的百分比

代表着每个任务完成工作的百分比。

6）关键路径法（critical path method，CPM）

是一种网络图技术，用来预测整个项目的工期，这种重要的工具，将帮助你防止项目进度的超期。

7）使用关键路径分析来保持进度均衡

Key:求关键路劲就是求最长的工期的那条路径

如图：就是B-E-H-J这条路径。

8）抓住关键路径（时间最长的那条）

关键路径意味着什么：即使关键路径是最长的，但是它也表示完成的项目的最短的时间。如果关键路径上的一个或着多个活动比计划的长，那么整个项目进度将被延后，除非项目经理采用正确的行动。

1. 使用关键路径分析来保持进度均衡
  1. 帮助项目经理进行项目进度平衡的技术
确定自由时差
每个项目活动的总时差
1. 1. 几个基本概念

自由时差（free slack）/自由浮动时间(free float)

是一个活动在不延误紧接活动的最早开始时间的情况下可以被拖延的时间。

最早开始时间（early start date）

是基于项目网络逻辑可以开始的最早的可能时间。

总时差（total slack）/总浮动时差（total float）

是一个活动从它最早的开始时间开始，在没有拖延计划项目完成日期的情况下被耽搁的时间。

最早完成时间（early finish date）

基于项目网络逻辑最早可能的完成时间。

最晚开始时间（late start time）

是一个活动在不延迟项目完成时间的最晚可能开始的时间。

最晚完成时间（late finish time）

是一个活动在不延迟项目完成时间的情况下的最晚可能完成时间。

3>帮助项目经理计算自由时差和总时差的方法

1. 1. 1. 1. 正推法(forward pass)

用来确定每个活动的最早开始和最早完成时间，一个活动的最早完成时间。

举个例子：

正推法（Forward Pass）解释与例子

正推法（Forward Pass）是关键路径法（CPM）中用于计算每个活动的**最早开始时间（ES）和最早完成时间（EF）**的技术。通过正推法，我们可以确定项目中最快的完成时间，并识别出关键路径。以下是正推法的详细解释和例子。

1. 正推法的基本概念

最早开始时间（ES）：一个活动最早可以开始的时间。
最早完成时间（EF）：一个活动最早可以完成的时间。
活动持续时间（Duration）：完成一个活动所需的时间。

正推法从项目的开始节点（通常是第一个活动）开始，逐步计算每个活动的最早开始和最早完成时间，直到项目的结束节点。

2. 正推法的计算步骤

确定项目的开始时间：

- 通常，项目从时间0开始，即所有第一个活动的最早开始时间（ES）为0。

计算最早完成时间（EF）：

- 对于每个活动，最早完成时间（EF）等于最早开始时间（ES）加上活动的持续时间（Duration）。
- 公式：
  EF=ES+DurationEF=ES+Duration

确定后续活动的最早开始时间（ES）：

- 一个活动的最早开始时间（ES）等于其所有前置活动的最早完成时间（EF）中的最大值。
- 公式：
  ES=max⁡(EFpredecessors)ES=max(EFpredecessors)

4.重复步骤2和3，直到所有活动的ES和EF都被计算出来。

3. 例子

假设我们有以下项目活动：

活动	前置活动	持续时间（天）
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的持续时间为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

步骤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：总结

活动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. 关键路径的识别

通过正推法，我们可以看到活动E的最早完成时间（EF）为14天。
关键路径是花费时间最长的路径，即A-B-D-E，总时间为14天。

5. 总结

正推法通过逐步计算每个活动的最早开始和最早完成时间，帮助我们确定项目的最短完成时间，并识别出关键路径。在本例中，关键路径为A-B-D-E，总时间为14天。

1. 1. 1. 1. 逆推法（backward pass）

可以用来确定最晚开始和最晚完成时间。

举个例子：

逆推法（Backward Pass）解释与例子

逆推法（Backward Pass）是关键路径法（CPM）中用于计算每个活动的**最晚开始时间（LS）和最晚完成时间（LF）**的技术。通过逆推法，我们可以确定在不延误项目完成时间的情况下，每个活动可以最晚开始和完成的时间。以下是逆推法的详细解释和例子。

1. 逆推法的基本概念

最晚完成时间（LF）：在不延误项目完成时间的情况下，一个活动最晚必须完成的时间。
最晚开始时间（LS）：在不延误项目完成时间的情况下，一个活动最晚可以开始的时间。
活动持续时间（Duration）：完成一个活动所需的时间。

逆推法从项目的结束节点（通常是最后一个活动）开始，逐步计算每个活动的最晚完成和最晚开始时间，直到项目的开始节点。

2. 逆推法的计算步骤

确定项目的计划完成时间：

- 通常，项目计划完成时间等于正推法计算出的最早完成时间（EF），即项目的最早完成时间。

计算最晚开始时间（LS）：

- 对于每个活动，最晚开始时间（LS）等于最晚完成时间（LF）减去活动的持续时间（Duration）。
- 公式：
  LS=LF−DurationLS=LF−Duration

确定前置活动的最晚完成时间（LF）：

- 一个活动的前置活动的最晚完成时间（LF）等于该活动的最晚开始时间（LS）。
- 公式：
  LFpredecessors=LSLFpredecessors=LS

4.重复步骤2和3，直到所有活动的LS和LF都被计算出来。

3. 例子

我们使用与正推法相同的项目活动：

活动	前置活动	持续时间（天）
A	-	3
B	A	4
C	A	2
D	B, C	5
E	D	2

通过正推法，我们已经计算出每个活动的最早开始时间（ES）和最早完成时间（EF），以及项目的总工期为14天。现在我们使用逆推法来计算每个活动的最晚开始时间（LS）和最晚完成时间（LF）。

步骤1：确定项目的计划完成时间

项目的计划完成时间等于正推法计算出的最早完成时间（EF），即14天。

步骤2：计算活动E的LS和LF

活动E是最后一个活动，因此它的最晚完成时间（LF）等于项目的计划完成时间。
- LFE=14LFE=14
活动E的持续时间为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的持续时间为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

步骤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的持续时间为3天，因此：
- LSA=LFA−DurationA=3−3=0LSA=LFA−DurationA=3−3=0

步骤6：总结

活动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. 关键路径的识别

通过逆推法，我们可以看到活动A、B、D、E的最晚完成时间（LF）等于最早完成时间（EF），这意味着这些活动是关键路径上的活动。
关键路径为A-B-D-E，总时间为14天。

5. 总结

逆推法通过逐步计算每个活动的最晚开始和最晚完成时间，帮助我们确定在不延误项目完成时间的情况下，每个活动可以最晚开始和完成的时间。在本例中，关键路径为A-B-D-E，总时间为14天。

1. 使用关键路径来缩短项目的进度
  1. 哪些人希望缩短项目的进度

干系人往往希望缩短项目的进度。一个项目工作的结果是认为项目团队至少需要10个月来完成项目，而发起人往往会希望在8~9个月内完成任务。（发起人往往不会要求项目团队花费比他们自己建议时间更长的工期）

1. 1. 项目经理怎么制定项目进度

项目经理通过定义活动，确定排序，和估算每个任务的资源和工期，来尽可能好地制定项目进度。

1. 1. 赶工（crashing）

赶工是一种为了以最少的成本最大限度地压缩工期，而成本与进度之间进行均衡的技术。

1》例子

1. 项目背景

假设我们有一个软件开发项目，项目经理已经使用关键路径法（CPM）确定了项目的关键路径和每个活动的持续时间。项目经理希望在不显著增加成本的情况下，尽可能缩短项目的总工期。

1.1 项目活动表

活动	前置活动	正常持续时间（天）	正常成本（万元）	赶工持续时间（天）	赶工成本（万元）
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 项目网络图

取消自动换行

复制

A (5) -> B (3) -> D (6) -> E (2) -> G (4)

\-> C (4) -/

\-> F (3) -/

关键路径: A -> B -> D -> E -> G，总工期为 20 天。

2. 赶工分析

2.1 确定关键路径

首先，项目经理需要确定项目的关键路径。在本例中，关键路径为 A -> B -> D -> E -> G，总工期为 20 天。

2.2 计算赶工成本和赶工时间

接下来，项目经理需要计算每个活动的赶工成本和赶工时间。

活动 A:
- 正常持续时间: 5 天
- 赶工持续时间: 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 选择赶工活动

项目经理需要选择赶工成本率最低的活动进行赶工，以最小化成本增加。

赶工活动 A:
- 赶工时间: 2 天
- 赶工成本: 5 万元

赶工活动 A 后，关键路径的持续时间减少到 18 天。

2.4 继续赶工

接下来，项目经理继续选择赶工成本率最低的活动进行赶工。

赶工活动 B:
- 赶工时间: 1 天
- 赶工成本: 2 万元

赶工活动 B 后，关键路径的持续时间减少到 17 天。

赶工活动 C:
- 赶工时间: 1 天
- 赶工成本: 2 万元

赶工活动 C 后，关键路径的持续时间减少到 16 天。

赶工活动 D:
- 赶工时间: 2 天
- 赶工成本: 4 万元

赶工活动 D 后，关键路径的持续时间减少到 14 天。

赶工活动 E:
- 赶工时间: 1 天
- 赶工成本: 2 万元

赶工活动 E 后，关键路径的持续时间减少到 13 天。

赶工活动 F:
- 赶工时间: 1 天
- 赶工成本: 2 万元

赶工活动 F 后，关键路径的持续时间减少到 12 天。

赶工活动 G:
- 赶工时间: 1 天
- 赶工成本: 2 万元

赶工活动 G 后，关键路径的持续时间减少到 11 天。

2.5 赶工结果

总赶工时间: 9 天
总赶工成本: 5 + 2 + 2 + 4 + 2 + 2 + 2 = 19 万元

3. 总结

通过赶工技术，项目经理成功地将项目的总工期从 20 天压缩到 11 天，总成本增加了 19 万元。赶工过程中，项目经理优先选择赶工成本率最低的活动进行赶工，以最小化成本增加。

4. 注意事项

关键路径: 赶工活动应优先选择关键路径上的活动，因为只有关键路径上的活动延迟才会影响项目的总工期。
赶工成本: 赶工成本率是选择赶工活动的重要指标，应优先选择赶工成本率最低的活动。
资源限制: 在赶工过程中，应考虑资源的可用性，避免资源冲突。
风险评估: 赶工可能会增加项目的风险，例如人员疲劳、质量下降等，应进行风险评估和管理。

5. 结论

赶工是一种有效的项目管理技术，可以在不显著增加成本的情况下，最大限度地压缩项目的总工期。通过合理选择赶工活动和优化资源分配，项目经理可以在项目进度和成本之间取得平衡，确保项目按时、按预算、按质量完成。

2》赶工的优点

可以缩短项目完成的时间

3》赶工的缺点

会提高项目的成本。

1. 1. 快速跟进（fast tracking）

包括并行执行那些通常以顺序方式执行的活动。

1. 更新关键路径数据的重要性

除了在项目开始的时候找出关键路径外，重要的是用实际的数据来更新进度。在项目团队完成活动后，项目经理应该记录下这些活动的实际工期，他也应该记录下正在进行或者将要开展的活动的修订估算，这些修订通常会造成项目的关键路径的改变，导致产生了一个新的项目完成工期。积极主动的项目经理和他的团队会紧紧把握变更，从而可以做出改变，并且让干系人知道和参与主要的项目决定。

1. 关键链调度（Critical Chain Project Management, CCPM）
  1. 关键链调度技术是干嘛的

关键链技术旨在通过优化资源分配和缩短项目工期来提高项目成功率。CCPM 是由以色列物理学家、企业管理顾问艾利·高德拉特（Eliyahu M. Goldratt）在其约束理论（Theory of Constraints, TOC）的基础上发展而来的。

2>约束理论(theory of constraints,TOC)

TOC的核心思想是：任何系统都存在至少一个约束因素，限制了系统整体性能的提升。TOC的目标是通过识别和管理这些约束因素，持续改进系统性能，最终实现系统目标（如利润最大化、效率提升等）。

约束理论是是用来解决达到或者满足项目完成时间的技术。

3>举个例子

1. 项目背景

假设我们有一个软件开发项目，项目经理需要完成以下五个任务：

任务	前置任务	正常持续时间（天）	所需资源
A	-	5	开发人员
B	A	3	测试人员
C	A	4	开发人员
D	B, C	6	开发人员
E	D	2	测试人员

目标: 在最短的时间内完成所有任务，并确保项目按时交付。

2. 传统关键路径法（CPM）分析

首先，项目经理使用传统的关键路径法（CPM）来分析项目。

2.1 绘制项目网络图

取消自动换行

复制

A (5) -> B (3) -> D (6) -> E (2)

\-> C (4) -/

关键路径: A -> B -> D -> E，总工期为 16 天。

2.2 资源依赖关系

在传统的 CPM 分析中，只考虑了任务之间的逻辑依赖关系，而没有考虑资源依赖关系。

资源冲突:
- 任务 A 和 C 同时需要开发人员。
- 任务 B 和 E 同时需要测试人员。

3. 应用关键链调度技术（CCPM）

CCPM 不仅考虑了任务之间的逻辑依赖关系，还考虑了资源依赖关系，并通过缓冲管理来应对不确定性。

3.1 识别关键链

资源依赖:
- 任务 A 和 C 都需要开发人员，因此它们之间存在资源依赖关系。
- 任务 B 和 E 都需要测试人员，因此它们之间也存在资源依赖关系。
调整关键路径:
- 由于任务 A 和 C 都需要开发人员，因此它们不能同时进行。
- 假设任务 A 先于任务 C 进行。
关键链: A -> C -> D -> E，总工期为 17 天。

3.2 消除安全时间

在传统的项目管理中，每个任务通常都会设置一定的安全时间。例如：

任务 A 的安全时间: 1 天
任务 B 的安全时间: 1 天
任务 C 的安全时间: 1 天
任务 D 的安全时间: 2 天
任务 E 的安全时间: 1 天

CCPM 建议消除每个任务的安全时间，将这些安全时间集中起来，作为缓冲。

3.3 设置缓冲

项目缓冲（Project Buffer）:
- 项目缓冲 = 所有任务安全时间总和 / 2 = (1 + 1 + 1 + 2 + 1) / 2 = 3 天
- 项目缓冲放置在项目结束处。
接驳缓冲（Feeding Buffer）:
- 接驳缓冲 = 非关键链任务安全时间总和 / 2 = (1) / 2 = 0.5 天
- 接驳缓冲放置在非关键链与关键链的连接处。
资源缓冲（Resource Buffer）:
- 确保开发人员和测试人员在需要时可用。

3.4 项目计划

关键链: A (5) -> C (4) -> D (6) -> E (2)
项目缓冲: 3 天
总工期: 17 天（关键链） + 3 天（项目缓冲） = 20 天
接驳缓冲:
- 放置在任务 B 和 D 之间，长度为 0.5 天。

4. 项目执行

任务 A: 开始执行，开发人员开始工作。
任务 C: 任务 A 完成后，开发人员立即开始执行任务 C。
任务 B: 任务 A 完成后，测试人员开始执行任务 B。
任务 D: 任务 C 完成后，开发人员立即开始执行任务 D。
任务 E: 任务 D 完成后，测试人员立即开始执行任务 E。
缓冲管理:
- 项目经理定期检查缓冲的消耗情况。
- 如果任务 B 延迟 0.5 天，接驳缓冲可以吸收这个延迟，不会影响关键链。
- 如果任务 D 延迟超过 3 天，项目缓冲可以吸收这个延迟。

5. 总结

通过关键链调度技术（CCPM），项目经理成功地将项目的总工期从 16 天延长到 20 天，但通过缓冲管理，可以有效应对项目中的不确定性，避免项目延期。

CCPM 的优势在于：

考虑了资源依赖: 避免了资源冲突，提高了资源利用率。
缩短项目工期: 通过消除安全时间、集中设置缓冲，缩短了项目工期。
应对不确定性: 通过缓冲管理，有效应对项目中的不确定性。

6. 结论

关键链调度技术（CCPM）是一种有效的项目管理方法，可以帮助项目经理更好地管理项目资源，缩短项目工期，提高项目成功率。通过合理应用 CCPM，项目经理可以更有效地管理项目，实现项目目标。

1. 多任务

1. 1. 多任务有时候并不是好事

尽管有的人认为自己擅长多任务，但是当你想要按时完成一个项目的时候，多任务反而不是一个好事了。多任务发生在一个资源在同一时间用于多个任务的时候，这种情形经常发生在项目中。人们被委派到一个项目中的多个任务或者多个项目中的不同项目中。如图的情况，员工为了让多方都满意，断断续续地分别完成部分任务，这样方便他们汇报进度，但是本来10天可以完成地任务1反而到了第20天才可以提交。

2>什么时候使用多任务是好的？

尽管多任务处理在某些情况下会导致效率降低，但在以下几种情况下，多任务处理可能是有效的：

1.任务简单且相互独立:

- 当任务简单且不需要深度思考和集中注意力时，多任务处理可以提高效率。例如，一边煮饭一边听在线课程，或者在等待电脑安装软件时处理邮件。这些任务之间没有明显的冲突，可以并行处理。

2.任务之间有明显的等待时间:

- 当一个任务需要等待某个外部事件（如等待文件上传、等待同事回复等）时，可以利用等待时间处理其他任务。例如，在等待代码编译时可以处理一些简单的文档工作。

3.任务可以并行进行:

- 当任务之间没有资源冲突，且可以并行进行时，多任务处理可以提高整体效率。例如，同时进行数据录入和文件整理，这些任务可以由不同的资源或在不同的时间段进行。

4.任务优先级较低:

- 当某些任务优先级较低，且不会对项目关键路径产生影响时，可以考虑多任务处理。例如，处理一些日常事务或非紧急的邮件。

3>什么时候避免多任务处理？

1.任务复杂且需要深度思考:

- 当任务复杂且需要深度思考和集中注意力时，多任务处理会导致效率降低。例如，编写复杂的代码、设计系统架构等。

2.任务之间有明显的资源冲突:

- 当多个任务需要同一个资源（如员工）时，多任务处理会导致任务切换成本增加，最终导致效率降低。例如，同一个员工同时处理多个项目中的多个任务。

3.任务对项目进度有重大影响:

- 当任务对项目关键路径有重大影响时，多任务处理可能导致项目进度延误。例如，关键路径上的任务如果被多任务处理，可能会导致整个项目延期。

4>建议

1.任务优先级排序: 对任务进行优先级排序，优先处理重要且紧急的任务。

2.合理分配资源: 根据任务的特点，合理分配资源，避免资源冲突。

3.避免频繁切换: 尽量减少任务切换的频率，降低切换成本。

4.使用项目管理工具: 使用项目管理工具来跟踪任务进度，避免多任务处理导致的进度延误。

14）关键链调度的缓冲（buffer）

1>缓冲的定义

使用关键链调度的时候，一个用来提高项目完成时间的关键概念是改变人们对项目进行估算的方法。许多人增加了安全措施或者缓冲(buffer)。即完成任务的时间加在考虑各种因素的一个估算时间上。这些因素包括多任务的负面影响，分心的事项和中断，担心减少估算，墨菲定律（Murphy’s law）。(是一个用来应对不确定性、提高项目按时完成概率的概念。它通过在项目计划中预留额外的时间或资源，来应对各种可能影响项目进度的因素。)

1. 1. 缓冲的例子

假设有一个项目，需要完成三个任务：

任务1: 预计完成时间10天
任务2: 预计完成时间10天
任务3: 预计完成时间10天

传统估算方法

在传统项目管理中，员工可能会这样估算每个任务的时间：

任务1: 10天 + 2天（多任务影响） + 1天（分心） + 2天（担心减少估算） + 1天（墨菲定律） = 16天
任务2: 10天 + 2天 + 1天 + 2天 + 1天 = 16天
任务3: 10天 + 2天 + 1天 + 2天 + 1天 = 16天

总时间：16天 + 16天 + 16天 = 48天

在这个例子中，员工为了应对各种不确定因素，在每个任务的估算时间中都加入了6天的缓冲时间，导致总时间被夸大到48天。

关键链调度方法（省略过多的缓冲，统一放到项目的末尾）

关键链调度方法认为，过多的缓冲会导致项目进度被延误，因此建议将缓冲集中到项目关键路径的末尾，而不是分散到每个任务中。

具体做法如下：

1去除每个任务中的缓冲:

- 去除每个任务估算时间中的安全时间，只保留最合理的、最有可能完成的时间。例如，去除多任务影响、分心事项、担心减少估算和墨菲定律的影响。
- 任务1: 10天
- 任务2: 10天
- 任务3: 10天

2.在项目末尾添加集中缓冲:

- 将去除的缓冲时间集中到项目末尾，作为项目的总缓冲时间。例如，将每个任务中去除的6天缓冲时间集中到项目末尾。
- 总缓冲时间：6天（任务1） + 6天（任务2） + 6天（任务3） = 18天
- 项目总时间：10天（任务1） + 10天（任务2） + 10天（任务3） + 18天（总缓冲） = 48天
- 看起来总时间没有变化，但关键区别在于，缓冲时间被集中到项目末尾，而不是分散到每个任务中。

3.集中缓冲的优势:

- 提高效率: 去除每个任务中的缓冲，可以减少任务切换成本（因为在每个项目后加缓冲会导致员工希望开始下个任务，但是上个项目还没完成，想要多任务地完成上个任务，导致了工期的厌恶延误），提高工作效率。
- 降低风险: 集中缓冲可以更好地应对项目中的不确定性，因为缓冲时间集中在一个地方，而不是分散到每个任务中。
- 灵活应对: 集中缓冲可以更灵活地应对项目中的变化，例如任务延误、资源不足等。
  1. 什么时候使用缓冲

1.项目复杂且不确定性高:

- 当项目复杂且不确定性高时，缓冲可以帮助项目团队更好地应对各种可能出现的意外情况。（任务简单的时候可以使用多任务。）

2.项目资源有限:

- 当项目资源有限时，缓冲可以帮助项目团队更有效地利用资源，避免资源冲突。

3.项目时间紧迫:

- 当项目时间紧迫时，缓冲可以帮助项目团队更好地管理时间，确保项目按时完成。

1. 墨菲定律（Murphy’s law）
  1. 什么是墨菲定律

墨菲定律说的是"任何可能出错的事情，最终都会出错。"。关键链调度去掉了单个任务的缓冲，但是创建了项目缓冲（project buffer）[将子任务所需要的缓冲时间统一加到项目末尾。]。它是在项目完工日期之前增加的附加时间。

2>墨菲定律在项目管理中的意义

在项目管理中，墨菲定律提醒我们：

不确定性是常态: 项目过程中总会有各种意外情况发生，例如资源短缺、人员变动、技术问题等。
风险不可避免: 即使我们做了充分的准备，仍然无法完全避免所有风险。
做好准备: 我们需要为可能出现的错误和意外做好准备，而不是抱有侥幸心理。

7.9计划评审技术（program evaluation and review technique,PERT）

1）什么是计划评审技术（PERT）

计划评审技术是另外一个项目时间管理的技术（program evaluation and review technique,PERT）是在单个工期高度不确定的情况下用来估计项目工期的技术。PERT也将关键路径法（CPM）应用到了加权的平均工期中，CPM方法成熟后也使用网络图，人们把这种图叫做PERT图。