My Awesome Project

Appearance

十大知识领域 ​

1. 项目管理流程 ​

Tips

项目管理的核心 = 十大知识领域 + 五大过程组

1.1 十大知识领域 ​

整-范-进-成-质资-沟-风-采-干
● 项目整合管理● 项目（人力）资源管理
● 项目范围管理● 项目沟通管理
● 项目进度（时间）管理● 项目风险管理
● 项目成本管理● 项目采购管理
● 项目质量管理● 项目干系人管理

1.2 五大过程组 ​

启动过程组 → 规划过程组 → 执行过程组 → 监控过程组 → 收尾过程组

1.3 十五矩阵 ​

知识领域启动过程组规划过程组执行过程组监控过程组收尾过程组
整合管理● 制定项目章程● 制定项目管理计划● 指导和管理项目工作
● 管理项目知识		● 监控项目工作
● 实施整体变更控制		● 结束项目或阶段
范围管理-● 规划范围管理
● 收集需求
● 定义范围
● 创建 WBS		-● 确认范围
● 控制范围		-
进度管理-● 规划进度管理
● 定义活动
● 排列活动顺序
● 估算活动持续时间
● 制定进度计划		-● 控制进度-
成本管理-● 规划成本管理
● 估算成本
● 制定预算		-● 控制成本-
质量管理-● 规划质量管理● 管理质量● 控制质量-
资源管理-● 规划资源管理
● 估算活动资源		● 获取资源
● 建设团队
● 管理团队		● 控制资源-
沟通管理-● 规划沟通管理● 管理沟通● 监督沟通-
风险管理-● 规划风险管理
● 识别风险
● 实施定性风险分析
● 实施定量风险分析
● 规划风险应对		● 实施风险应对● 监督风险-
采购管理-● 规划采购管理● 实施采购● 控制采购-
干系人管理● 识别干系人● 规划干系人参与● 管理干系人参与● 监督干系人参与-

2. 项目管理全流程 ​

2.1 项目整合管理 ​

整体管理主要是全局性的管理，这一块单独出题的概率不是很大，大家了解下本块的基础知识就好。

本块内容应该来说，对很多人不算难点，主要是把项目章程搞清楚，把初步的项目范围说明书包含内容知道，掌握变更控制流程，其余的内容常规学习就好。

项目的整体管理一般是在上午出题，在下午案例分析考试中也会涉及，论文也曾考过。

项目整合管理在项目管理的十大知识领域中处于核心位置，其功效是整合项目资源。

其中，制定项目章程、监控项目工作、实施整体变更控制等知识领域是本章的考核重点。

过程名输入工具和技术输出
制定项目章程
Develop Project Charter		1. 商业文件
2. 协议
3. 事业环境因素
4. 组织过程资产		1. 专家判断
2. 数据收集
3. 人际关系与团队技能
4. 会议		1. 项目章程
2. 假设日志
制定项目管理计划
Develop Project Management Plan		1. 项目章程
2. 其他过程的输出
3. 事业环境因素
4. 组织过程资产		1. 专家判断
2. 数据收集
3. 人际关系与团队技能
4. 会议		项目管理计划
指导和管理项目工作
Direct and Manage Project Work		1. 项目管理计划
2. 项目文件
3. 批准的变更请求
4. 事业环境因素
5. 组织过程资产		1. 专家判断
2. 项目管理信息系统
3. 会议		1. 可交付成果
2. 工作绩效数据
3. 变更请求
4. 项目管理计划更新
5. 项目文件更新
管理项目知识
Manage Project Knowledge		1. 项目管理计划
2. 项目文件
3. 可交付成果
4. 事业环境因素
5. 组织过程资产		1. 专家判断
2. 知识管理
3. 信息管理		1. 经验教训登记册
2. 项目管理计划更新
3. 组织过程资产更新
监控项目工作
Monitor and Control Project Work		1. 项目管理计划
2. 项目文件
3. 工作绩效信息
4. 协议
5. 事业环境因素
6. 组织过程资产		1. 专家判断
2. 数据分析
3. 会议		1. 工作绩效报告
2. 变更请求
3. 项目管理计划更新
4. 项目文件更新
实施整体变更控制
Perform Integrated Change Control		1. 项目管理计划
2. 项目文件
3. 工作绩效报告
4. 变更请求
5. 事业环境因素
6. 组织过程资产		1. 专家判断
2. 会议
3. 变更控制工具
4. 决策
5. 会议		1. 批准的变更请求
2. 项目管理计划更新
3. 项目文件更新
结束项目或阶段
Close Project or Phase		1. 项目章程
2. 项目管理计划
3. 项目文件
4. 验收的可交付成果
5. 商业文件
6. 协议
7. 组织过程资产		1. 专家判断
2. 数据分析
3. 会议		1. 最终产品、服务或成果移交
2. 项目文件更新
3. 组织过程资产更新

2.2 项目范围管理(☆) ​

范围管理确定在项目内包括什么工作和不包括什么工作，由此界定的项目范围在项目的全生命周期内可能因种种原因而变化，项目范围管理也要管理项目范围的这种变化。项目范围的变化也叫变更。对项目范围的管理，是通过 5 个管理过程来实现的。

范围管理的目的：做且只做所需的全部工作，已成功完成项目。

项目范围有时也包括产品范围。

范围基准 = 范围说明书 + WBS + WBS 词典

区分衡量依据
产品范围某项产品、服务或成果所具有的特性和功能需求文件
项目范围为交付具有规定特性与功能的产品、服务或成果而必须完成的工作项目管理计划

其输入输出工具表如下所示。

过程名输入工具和技术输出
规划范围管理
Plan Scope Management		1. 项目章程
2. 项目管理计划
3. 组织过程资产
4. 事业环境因素		1. 专家判断
2. 数据分析
3. 会议		1. 范围管理计划
2. 需求管理计划
收集需求
Collect Requirements		1. 项目章程
2. 项目管理计划
3. 项目文件
4. 商业文件
5. 协议
6. 事业环境因素
7. 组织过程资产		1. 专家判断
2. 数据收集
3. 数据分析
4. 决策
5. 数据表现
6. 人际关系与团队技能
7. 系统交互图
8. 原型法		1. 需求文件
2. 需求跟踪矩阵
定义范围
Define Scope		1. 项目章程
2. 项目管理计划
3. 项目文件
4. 事业环境因素
5. 组织过程资产		1. 专家判断
2. 数据分析
3. 决策
4. 人际关系与团队技能
5. 产品分析		1. 项目范围说明书
2. 项目文件更新
创建 WBS
Create WBS		1. 项目管理计划
2. 项目文件
3. 事业环境因素
4. 组织过程资产		1. 专家判断
2. 分解		1. 范围基准
2. 项目文件更新
控制范围
Control Scope		1. 项目管理计划
2. 项目文件
3. 工作绩效数据
4. 组织过程资产		1. 数据分析1. 工作绩效信息
2. 变更请求
3. 项目管理计划更新
4. 项目文件更新
确认范围
Validate Scope		1. 项目管理计划
2. 项目文件
3. 核实的可交付成果
4. 工作绩效数据		1. 检查
2. 决策		1. 验收的可交付成果
2. 工作绩效信息
3. 变更请求
4. 项目文件更新

2.2.1 项目范围 & 产品范围 ​

  • 产品范围：

    • 表示产品、服务或结果的特性和功能。
    • 随着项目的开展，其产品特征会逐渐细化。
    • 以产品要求作为衡量标准。

  • 项目范围：

    • 为了完成具有规定特征和功能的产品、服务或结果，而必须完成的项目工作。
    • 项目范围在项目的早期被描述出来并随着项目的进展而更加详细。
    • 以项目管理计划、项目范围说明书、WBS、以及 WBS 字典作为衡量标准。

2.2.2 需求跟踪 ​

收集范围，会输出「需求跟踪矩阵（Requirement Traceability Matrix，简写 RTM）」，其表示需求和其他产品元素之间的联系链，将产品需求从其来源链接到能满足需求的可交付成果上。

实现项目需求，项目计划与产品实现之间的双向跟踪。

需求跟踪方式有两种：

  • 正向跟踪：检查每个需求是否都能在后继工作成果中找到对应点。
  • 逆向跟踪：检查设计文档、代码、测试用例等工作成果，是否都能在《需求规格说明书》中找到出处。

不论采用何种跟踪方式，都要建立与维护需求跟踪矩阵即表格。

需求跟踪矩阵保存了需求与后继工作成果的对应关系。

2.2.3 范围蔓延和镀金 ​

做项目，一定要在开始确定范围，最忌讳的是范围蔓延和范围镀金，这样会导致项目不受控制。

  • 范围蔓延：未经控制的范围扩大，客户不断提出新要求。
  • 范围镀金：项目实施人员尝试新技术，或自己做主为项目加上的格外功能。

(1) 范围蔓延原因

  • 模糊的或不完善的范围定义
  • 缺乏任何正式的范围或需求管理
  • 收集产品需求的过程是不一致的
  • 缺乏利益相关者的参与
  • 项目运行时间过长

(2) 控制范围蔓延

  • 实时跟踪项目进度、资源和绩效
  • 提供多种视图，使项目可视化
  • 团队可以共享所有与项目有关的信息
  • 创建一个变更控制流程来审查和批准变更
  • 可以访问强大的报告，以做出数据驱动的决策

2.2.4 项目范围说明书 ​

详细的项目范围说明书包括以下内容：

  • 项目的目标。
  • 产品范围描述。
  • 项目的可交付物。
  • 项目边界。
  • 产品验收标准。
  • 项目的约束条件。
  • 项目的假定。

2.2.5 工作分解结构 ​

WBS 是 Work Breakdown Structure 的缩写，中文含义是“工作分解结构”。

WBS 是组织、管理项目工作的主要依据和基础。这些项目管理工作包括：定义工作范围、定义项目组织、设定项目产品的质量和规格、估算和控制费用、估算时间周期和安排进度、明确项目相关各方的工作界面以便于责任划分和落实。

通过 WBS 把项目工作细分为更小、更易管理的工作单元，随着 WBS 层次的降低，意味着项目工作也越来越详细。

但是，WBS 分解的越细，那么对该工作的计划、管理和控制的能力就越强，然而大量的分解工作会导致生产效率降低、资源浪费、工作效率低下。

最底层的 WBS 单元叫做工作包，是进行范围、进度、成本管理的基础。

WBS 结构分为树型和列表型。

树型层次清晰，非常直观，结构性很强，但是不容易修改，适用于中小型项目。

列表型直观性差，适用于大型项目。

当一个项目的 WBS 分解完成后，项目相关人员对完成的 WBS 应该给予确认，并对此达成共识。

制定了 WBS 后，形成范围基线。

  • WBS 主要用途

    1. 工作分解结构是一个展现项目全貌，详细说明为完成项目所必须完成的各项工作计划工具。
    2. 工作分解结构是一个清晰地表示各项目工作之间的相互联系的结构设计工具。
    3. 工作分解结构是一个帮助项目经理和项目团队确定和有效地管理项目（特别在项目发生变更时）所涉及的工作的基本依据。
    4. 工作分解结构定义了里程碑事件，可以向高级管理层和客户报告项目完成情况，作为项目状况的报告工具

  • WBS 的分解步骤：

    1. 识别项目交付物和相关工作。
    2. 对 WBS 的结构进行组织。
    3. 对 WBS 进行分解。
    4. 对 WBS 中各级工作单元分配标识符或编号。
    5. 对当前的分解级别进行检验，以确保它们是必须的，而且是足够详细的。

  • 常用的分解 WBS 结构的方法有以下三种：

    1. 使用项目生命周期的阶段作为分解的第一层，而把项目可交付物安排在第二层。
    2. 把项目重要的可交付物作为分解的第一层。
    3. 把子项目安排在第一层，再分解子项目的 WBS。

  • 分解 WBS 的原则：

    1. 在各层次上保持项目的完整性，避免遗漏必要的组成部分。
    2. 一个工作单元只能从属于某个上层单元，避免变叉从属。
    3. 相同层次的工作单元应有相同性质。
    4. 工作单元应能分开不同的责任者和不同工作内容。
    5. 便于项目管理进行计划和控制的管理需要。
    6. 最低层工作应该具有可比性，是可管理的，可定量检查的。
    7. 应包括项目管理工作（因为管理是项目具体工作的一部分），包括分包出去的工作。
    8. WBS 的最低层次的工作单元是工作包。一个项目的 WBS 是否分解到工作包，跟项目的阶段、复杂程度和规模有关，一般来说早期，或复杂，或大规模的项目，其 WBS 的分解颗粒要大一些，粗一些。需要遵守 8/80 原则。

8/80 原则

WBS 中每个工作包的工作量应介于一个人工作 8 小时至 80 小时之间。小于 8 小时，没必要计划。大于 80 小时，不可能计划。

2.2.6 其他术语 ​

  • OBS

    Organization breakdown structure，组织分解结构。显示工作被分配到组织单元。

  • RBS

    Resource breakdown structure，资源分解结构。对项目将使用的资源按种类与形式进行划分的层次结构。

  • CBS

    Cost breakdown structure，成本分解结构。

  • RBS

    Risk breakdown structure，风险分解结构。按照风险类别说明已识别风险的层次结构。

  • CA

    Control Account，控制账户。一种管理控制点。在该控制点上，把范围、预算（资源计划）、实际成本和进度加以整合，并把它们与挣值相比较，以测量绩效。

  • WBS 字典

    在创建工作分解结构的过程中编制的，是工作分解结构的支持性文件，用来对工作分解结构中的控制账户和工作包做详细解释。解释的详细程度可以根据具体需要加以 。

    WBS 中包含的元素（包括工作包）细节通常在工作分解结构字典中加以描述。WBS 字典是 WBS 的配套文档，用来描述每个 WBS 元素。

2.3 项目进度管理(☆) ​

项目进度（时间）管理通常被认为是项目冲突的主要根源，没能有效地控制项目的进度是项目失败的直接表现，充分利用项目时间、有效地保障项目进度是项目团队走向成功的基本保证。

本块内容应该来说，是考试的重点。制定进度表的工具和技术建议都掌握，自由时差、总时差的计算要会，其余的知识点常规学习就好。

过程名输入工具和技术输出
规划进度管理
Plan Schedule Management		1. 项目章程
2. 项目管理计划
3. 事业环境因素
4. 组织过程资产		1. 专家判断
2. 数据分析
3. 会议		1. 进度管理计划新
定义活动
Define Activities		1. 项目管理计划
2. 事业环境因素
3. 组织过程资产		1. 专家判断
2. 分解
3. 滚动式规划
4. 会议		1. 活动清单
2. 活动属性
3. 里程碑清单
4. 变更请求
5. 项目管理计划更新
排列活动顺序
Sequence Activities		1. 项目管理计划
2. 项目文件
3. 事业环境因素
4. 组织过程资产		1. 紧前关系绘图法
2. 确定和整合依赖关系
3. 提前量和滞后量
4. 项目管理信息系统		1. 项目进度网络图
2. 项目文件更新
估算活动持续时间
Estimate Activity Durations		1. 项目管理计划
2. 项目文件
3. 事业环境因素
4. 组织过程资产		1. 专家判断
2. 类比估算
3. 参数估算
4. 三点估算
5. 自下而上估算
6. 数据分析
7. 决策
8. 会议		1. 持续估算时间
2. 估算依据
3. 项目文件更新
制定进度计划
Develop Schedule		1. 项目管理计划
2. 项目文件
3. 协议
4. 事业环境因素
5. 组织过程资产		1. 进度网络分析
2. 关键路径法
3. 资源优化
4. 数据分析
5. 提前量和滞后量
6. 进度压缩
7. 项目管理信息系统
8. 敏捷发布规划		1. 进度基准
2. 进度管理计划
3. 进度数据
4. 项目日历
5. 变更请求
6. 项目管理计划更新
7. 项目文件更新
控制进度
Control Schedule		1. 项目管理计划
2. 项目文件
3. 工作绩效数据
4. 组织过程资产		1. 数据分析
2. 关键路径法
3. 资源优化
4. 提前量和滞后量
5. 项目管理信息系统
6. 进度压缩		1. 工作绩效信息
2. 进度预测
3. 变更请求
4. 项目管理计划更新
5. 项目文件更新

2.3.1 进度的重要性 ​

  • 时间很容易被度量和记住。

  • 不管项目中发生了什么，时间总是在流逝。

  • 通常人们在比较计划和实际的项目完成时间时，并不考虑项目中经过审批的变更。

  • 个人的工作方式和文化差异也会造成进度上的冲突。

    • 一些人喜欢详细的进度，注重任务的完成。
    • 其他人喜欢保持事情的开放性和灵活性。
    • 公休假期、员工休假、员工不加班等情况，都会影响进度。

2.3.2 关键路径法 ​

关键路径法（critical path method，CPM），又称为关键路径分析（critical path analysis），是一种用来预测整个项目工期的网络图技术。

项目的关键路径（critical path）决定了项目最早完成时间的活动序列，是网络图的最长路径，其时差或者浮动时间最少。

时差（slack）或浮动时间（flot）指的是在不延误后继活动或者项目完成时间的情况下，任务可以推后的时间。

关键路径法用来计算进度模型中的关键路径、总浮动时间和自由浮动时间，或逻辑网络路径的进度灵活性大小。

2.3.3 最早最晚时间 ​

  • ES：最早开始时间（Earliest Start），是指某项活动能够开始的最早时间，只决定于项目计划，只要计划的条件满足了就可以开始的时间。
  • EF：最早结束时间（Earliest Finish），是指某项活动能够完成的最早时间。EF = ES+DU， DU 为活动持续时间，顺推法先知道开始时间。
  • LF：最迟结束时间（Latest Finish），是指为了使项目在要求完工时间内完成，某项活动必须完成的最迟时间。往往决定于相关方（客户或管理层）的限制。
  • LS：最迟开始时间（Latest Start），是指为了使项目在要求完工时间内完成，某项活动必须开始的最迟时间。其中 LS = LF -DU，DU 为持续时间，逆推法先知道结束时间。
  • DU：活动持续时间，指活动的工作时间段。

2.3.4 总浮动时间 TF ​

TF：总浮动时间（Total float time），指在不影响总工期的条件下，一个活动可以利用的机动时间。TF = LF - EF。

  • 关键路径上，总浮动时间一般为 0。
  • 总浮动时间一般为正值，最晚结束时间＞最早结束时间，即给定工期比计划工期长，正常。

如果出现了负值浮动时间，则表示：

  • 关键路径出现负的浮动时间意味着，如果不采取措施项目将延期。
  • 负值浮动时间分析是一种有助于找到推动延迟的进度回到正轨的方法的技术，从而找到保证工期的途径。
  • 为了使网络路径的总浮动时间为零或正值，可能需要调整活动持续时间（可增加资源或缩减范围时）、逻辑关系（针对选择性依赖关系时）、提前量和滞后量，或其他进度制约因素。

(1) 自由浮动时间 FF

自由浮动时间就是指在不延误任何紧后活动最早开始日期或不违反进度制约因素的前提下，某进度活动可以推迟的时间量。

总浮动时间可能等于大于自由浮动时间，TF≥FF。

自由浮动时间计算如下所示：

  • 左图：FF0=ES1−EF0​​
  • 右图：FF0=min(ES1,ES2)−EF0​​

(2) 图形表示

按照《PMBOK 指南》的推荐，采用如下图的方式来标注活动的 ES、EF、DU、LF、LS 以及活动名称（ID）。

例如，现在有如下的网络图。

(3) 顺推法和倒推法

  • 顺推：自左向右计算最早时间，顺推遵循取最大值原则
  • 逆推：自右向左计算最晚时间，逆推遵循取最小值原则

(4) 计算案例

请计算下表所列活动的关键路径，并完成顺推计算最早时间和逆推计算最晚时间，计算所有活动的 TF 和活动 C 的自由浮动时间 FF。

编号活动描述持续时间前导活动
A开始装修2-
B刷门框2A
C刷屋顶3A
D刷墙4A
E刷第二遍墙2D
F结束装修2B\C\E

第一步，画出网络图，计算关键路径，列出所有可能的路径，比较其长度。

  • 路径 A→B→F 长度为 2+2+2 = 6
  • 路径 A→C→F 长度为 2+3+2 = 7
  • 路径 A→D→E→F 长度为 2+4+2+2 = 10

故关键路径为 A→D→E→F，长度为 10。

第二步，顺推计算最早时间，按照从第 0 天开始。

第三步，逆推计算最晚时间。

第四步，计算所有活动的 TF（TF=LF-EF）。

如果要计算 C 的 FF，FFC=ESF−EFC=8−5=3。

(6) 总结

  • 关键路径：总工期最长的 N 条路径。
  • 关键路径会在进度优化或项目实施过程中，经常发生改变。
  • 关键路径越多，意味着按时完工的风险越大，越难管理。
  • 如果关键路径的活动延误，或管理层要求提前完工，则浮动时间会出现负值。
  • 如果出现了负浮动时间，则需要尽快加以解决，如赶工、削减需求、快速跟进等。

2.3.5 计划评审技术 ​

计划评审技术（program evaluation and review technique，PERT）是在单个活动工期估计高度不确定的情况下，用来估计项目工期的技术。

PERT 使用概率时间估算（Probabilistic Time Estimate），是基于乐观的活动工期估算、最可能的活动工期估算和悲观的活动工期估算这三点来进行工期估算，而不是像 CPM 那样，使用一个特定的或者离散的工期估算。

  • 最乐观时间（Optimistic Time）：在平稳条件下完成过程所需的时间，用TOT_OT​O​​表示。
  • 最可能的时间（Most Likely Time）：在正常条件下完成该过程所需的时间，用TMT_MT​M​​表示。
  • 最悲观时间（Pessimistic Time）：在不利条件下完成该过程所需的时间，用TPT_PT​P​​表示。
(1) 计算公式 ​
基于三角分布 ​

期望持续时间 = (最悲观时间+最可能时间+最乐观时间) ÷ 3

基于 Beta 分布（PERT 技术） ​

期望持续时间=(最悲观时间+4× 最可能时间+最乐观时间)÷6

标准误差 ​

方差，即标准误差，指在概率论中是用来度量随机变量和其数学期望（即均值）之间的偏离程度。

标准误差=(最悲观时间-最乐观时间)÷6

正态分布 ​

根据中心极限定理，如果一个事物受到多种因素的影响，不管每个因素本身是什么分布，它们加总后，结果的平均值就是正态分布。

TE​​相当于平均值μ，δTE​​​​相当于方差δ。

根据正态分布图的特点，有如下结论：

  • 有 68.2% 的样本平均值会在总体平均值的 1 个标准误差的范围之内；
  • 有 95.4% 的样本平均值会在总体平均值的 2 个标准误差的范围之内；
  • 有 99.7% 的样本平均值会在总体平均值的 3 个标准误差的范围之内。
(2) 计算案例 ​
  1. 完成活动 A 悲观估计 36 天，最可能估计 21 天，乐观估计 6 天，求该活动的期望完成时间。
  1. 完成活动 A 悲观估计 36 天，最可能估计 21 天，乐观估计 6 天，计算标准差。
  1. 完成活动 A 悲观估计 36 天，最可能估计 21 天，乐观估计 6 天，活动 A 在 16 天到 26 天内完成的概率是多少？

根据正态分布，(16,26)(16, 26)(16,26)在正负一个标准差范围内，所以概率是 68.2%。

2.4 项目成本管理(☆) ​

成本管理的目的就是确保项目在批准的预算内完工。

成本的类别分为很多种，有直接成本和间接成本，固定成本和可变成本，项目成本和产品生命周期成本等。

名称定义例子
● 直接成本可以直接计入项目工作的成本独立型活动、支持型活动
● 间接成本不能直接计入项目工作的成本，而需由几个项目进行分摊的成本依附性活动、后勤成本等
■ 固定成本不随生产量或工作量的变动而变动的成本租金、基本工资等
■ 可变成本随生产量或工作量的变动而变动的成本奖励、加班费等
◆ 项目成本项目生命周期内的成本BAC、EAC 等
◆ 产品生命周期成本除项目成本外，还包括项目产品移交后的运行维护成本维修保养成本

其输入输出表如下所示。

过程名输入工具和技术输出
规划成本管理
Plan Cost Management		1. 项目章程
2. 项目管理计划
3. 事业环境因素
4. 组织过程资产		1. 专家判断
2. 数据分析
3. 会议		1. 成本管理计划
估算成本
Estimate Costs		1. 项目管理计划
2. 项目文件
3. 事业环境因素
4. 组织过程资产		1. 专家判断
2. 类比估算
3. 参数估算
4. 三点估算
5. 自下而上估算
6. 数据分析
备选方案分析、储备分析、质量成本
7. 决策		1. 成本估算
2. 估算依据
3. 项目文件更新
制定预算
Determine Budget		1. 项目管理计划
2. 项目文件
3. 商业文件
4. 协议
5. 事业环境因素
6. 组织过程资产		1. 专家判断
2. 成本汇总
3. 数据分析
4. 历史信息审核
5. 资源限制平衡
6. 融资		1. 成本基准
2. 项目资金需求
3. 项目文件更新
控制成本
Control Costs		1. 项目管理计划
2. 项目文件
3. 项目资金需求
4. 工作绩效数据
5. 组织过程资产		1. 专家判断
2. 数据分析
3. 完工尚需绩效指标
4. 项目关系信息系统		1. 工作绩效信息
2. 成本预测
3. 变更请求
4. 项目管理计划更新
5. 项目文件更新

2.4.1 什么是成本 ​

  • 会计师通常将成本定义为实现一个特定目标而牺牲或放弃的资源。
  • “成本”为“交换中所放弃的东西”。

2.4.2 错误感知 ​

  • 很多 IT 项目的原始成本估算很低，只是以非常模糊的项目需求为基础进行估算的，所以自然会发生成本超支。
  • 许多 IT 专业人员认为成本估算与自己无关，是会计师的工作。相反，良好的成本估算是一项艰巨的、所有 IT 项目专业人员都应当具备和必须掌握的重要技能。

2.4.3 成本基准 ​

成本预算涉及将项目成本估算随时间分配给个体材料资源或单个工作项，这些个体材料资源或工作项是以项目工作分解结构为基础的，最终输出成本基准。

成本基准包括：

  1. 经过批准
  2. 按时间段分配
  3. 不包括管理储备
  4. 变更需要 CCB
  5. 用作与实际结果比较的依据

2.4.4 挣值管理 ​

挣值管理（Earned Value Management，EVM）是一种综合了项目范围、时间和成本数据的项目绩效测量技术。

给定成本执行基线，项目经理和他的团队可以通过输入实际的信息，并将其与基线比较，从而判断项目目前在多大程度上满足了范围、时间和成本目标。

基线是最初项目计划加上被批准的变更。

挣值管理涉及计算项目 WBS 中每项活动或概要活动的值：

  • 计划值（预算）（Planned Value，PV），是在给定时间内计划花费在某个活动上的已批准总成本估算的部分。
  • 实际成本（Actual Cost，AC），是在给定时间内，完成一项活动所产生的直接成本和间接成本的总和。
  • 挣值（Earned Value，EV），是实际完成工作的估算值。
  • 完成百分比（Rate of Performance，RP），是实际完成工作与在项目或活动周期给定时间内已完成计划工作的比率。
  • 成本偏差（Cost Variance，CV），挣值去掉实际成本后的值（CV ＞ 0，成本结余；CV ＜ 0，成本超支）。
  • 进度偏差（Schedule Variance，SV），挣值去掉预算后的值（SV ＞ 0，进度超前；SV ＜ 0，进度落后）。
  • 完工预算（BAC，Budget at Completion）：为将要执行的工作所建立的全部预算的总和。
  • 完工估算（EAC，Estimate at Completion）：完成所有工作所需的预期总成本，等于截至目前的实际成本加上完工尚需估算。
  • 完工尚需估算（ETC，Estimate to Completion）：完成所有剩余项目工作的预计成本。

挣值公式


  • 成本偏差（cost variance，CV）是挣值减去实际成本。

    • 如果成本偏差是一个负数，那么就意味着执行工作所用的成本高于计划成本，
    • 如果成本偏差是一个正数，则意味着执行工作所用的成本低于计划成本。

  • 进度偏差（schedule variance，SV）是挣值减去计划值。

    • 负的进度偏差意味着执行工作用时比计划用时长，
    • 而正的进度偏差则意味着执行工作用时比计划用时短。

  • 成本绩效指数（cost performance index，CPI）是挣值与实际成本的比值，可以用来估算完成项目的预计成本。

    • 如果成本绩效指数等于 1 或 100%，那么预算成本和实际成本相等，或者说成本与预测完全相同。
    • 如果该指数小于 1 或 100%，则项目超出预算。
    • 如果该指数大于 1 或者 100%，则说明项目在预算范围内。

  • 进度绩效指数（schedule performance index，SPI）是挣值与计划值的比值，可以用来估算完成项目的预计时间。

    • 与成本绩效指数相类似，进度执行指数为 1 或者 100%，意味着项目进度符合进度计划。
    • 如果进度执行指数大于 1 或 100%，则项目超前于进度计划。
    • 如果该指数小于 1 或 100%，则项目进度落后于进度计划。

Tips

通常负的成本和进度偏差表明在那些领域存在问题，项目花费成本比计划的更多，用时比计划的更长。

同样，成本绩效指数和进度执行指数小于 1 或 100%，也说明存在问题。

成本性能指标用来计算 EAC——估算迄今为止基于性能完成一个项目的成本。

同样，进度执行指数可以用来计算完成一个项目估计的时间。

2.5 项目质量管理(☆) ​

项目质量管理包括把组织的质量政策应用于规划、管理、控制箱项目和产品质量要求，以满足干系人目标的过程。

项目质量管理要兼顾项目管理和项目可交付成果两个方面。

过程名输入工具和技术输出
规划质量管理
Plan Quality Management		1. 项目章程
2. 项目管理计划
3. 项目文件
4. 事业环境因素
5. 组织过程资产		1. 专家判断
2. 数据收集
3. 数据分析
4. 会议
5. 数据表现		1. 质量管理计划
2. 质量测量指标
3. 项目管理计划更新
4. 项目文件更新
管理质量
Manage Quality		1. 项目管理计划
2. 项目文件
3. 事业环境因素
4. 组织过程资产		1. 数据收集
2. 数据分析
3. 决策
4. 数据表现
5. 审计
6. 面向 X 的设计
7. 问题加爵
8. 质量改进方法		1. 质量报告
2. 测试与评估文件
3. 变更请求
4. 项目管理计划更新
5. 项目文件更新
控制质量
Control Quality		1. 项目管理计划
2. 项目文件
3. 批准的变更请求
4. 可交付成果
5. 工作绩效数据
6. 事业环境因素
7. 组织过程资产		1. 数据收集
2. 数据分析
3. 检查
4. 测试/产品评估
5. 数据表现
6. 会议		1. 质量控制测量结果
2. 核实的可交付成果
3. 工作绩效信息
4. 变更请求
5. 项目管理计划更新
6. 项目文件更新

2.6 项目资源管理 ​

项目经理既是项目团队的领导者也是管理者，应该负责建设高绩效团队。

过程名输入工具和技术输出
规划资源管理
Plan Resource Management		1. 项目章程
2. 项目管理计划
3. 项目文件
4. 事业环境因素
5. 组织过程资产		1. 专家判断
2. 组织理论
3. 会议
4. 数据表现		1. 资源管理计划
2. 团队章程
3. 项目管理计划更新
4. 项目文件更新
估算活动资源
Estimate Activity Resources		1. 项目管理计划
2. 项目文件
3. 事业环境因素
4. 组织过程资产		1. 专家判断
2. 自下而上估算
3. 类比估算
4. 参数估算
5. 数据分析
6. 项目管理信息系统
7. 会议		1. 资源需求
2. 估算依据
3. 资源分解结构
4. 项目文件更新
获取资源
Acquire Resources		1. 项目管理计划
2. 项目文件
3. 事业环境因素
4. 组织过程资产		1. 决策
2. 预分派
3. 虚拟团队
4. 招募		1. 物质资源分派单
2. 项目团队派工单
3. 资源日历
4. 变更请求
5. 项目管理计划更新
6. 项目文件更新
建设团队
Develop Team		1. 项目管理计划
2. 项目文件
3. 事业环境因素
4. 组织过程资产		1. 集中办公
2. 虚拟团队
3. 沟通技术
4. 认可与奖励
5. 培训
6. 个人与团队评估
7. 会议		1. 团队绩效评价
2. 变更请求
3. 项目管理计划更新
4. 项目文件更新
5. 事业环境因素更新
6. 组织过程资产更新
管理团队
Develop Team		1. 项目管理计划
2. 项目文件
3. 工作绩效报告
4. 团队绩效评价
5. 事业环境因素
6. 组织过程资产		1. 人机关系与团队技能
2. 项目管理信息系统		1. 变更请求
2. 项目管理计划更新
3. 项目文件更新
控制资源
Control Resources		1. 项目管理计划
2. 项目文件
3. 工作绩效数据
4. 协议
5. 组织过程资产		1. 数据分析
2. 问题解决
3. 人际关系与团队技能
4. 项目管理信息系统		1. 工作绩效信息
2. 变更请求
3. 项目管理计划更新
4. 项目文件更新

2.6.1 激励理论 ​

影响人们如何工作以及如何更好地工作的心理因素包括动机、影响力和权力以及有效性。

  • 内在激励（intrinsic motivation）使人们根据自己的个人兴趣爱好而参与某一活动。
  • 外在激励（extrinsic motivation）使人们为了获得报酬或者避免处罚而去做某些事情。
马斯洛的需求层次理论 ​
赫兹伯格的“激励-保健”理论 ​

赫兹伯格保健因素和激励因素

保健因素激励因素
更高的工资成就
更多的监督赏识
更吸引人的环境工作本身
计算机或其他需要设备的配备责任
健康福利晋升
培训成长

保健因素如果不满足，员工就会产生不满情绪，但是如果满足了也不能激励员工更卖力地工作。 激励因素：成就、赏识、工作本身、责任、晋升和成长。

麦克利兰的“获得-需求”理论 ​

人的特殊需求可以通过后天的经历来获得（或学到）和塑造。

  • 成就（achievement）需求：具有高成就需求（nAch）的人努力避免低风险和高风险的处境来提高他们实现价值的机会。
  • 归属（affiliation）需求：具有高归属需求（nAff）的人渴望和睦的人际关系和需要获得他人的赏识。
  • 权力（power）需求：具有权力需求（nPow）的人渴望拥有个人权力或制度权力。

主题统觉测试（TAT）是根据麦克利兰的需求分类对不同人的个人需求进行测试的工具。 在测试时间受试者展示一系列主题模糊、含义不明的图片，然后要求受试者根据每一幅画面内容自由地讲述和阐发他所看到的画面。这一测试的假定是，当受试者在讲述故事时，他已经把自己的需求投射到故事中去了。

2.6.2 责任分配矩阵 ​

责任分配矩阵（Responsibility Assignment Matrix）：将 WBS 中描述的项目工作与 OBS 中负责实施的人员相匹配的矩阵。

RACI 表（RACI chart）：表示项目干系人的 4 种角色。

  • 责任人（responsibility）：谁执行这个任务？
  • 批准人（accountability）：谁签署的任务或对这个任务负全责？
  • 审核人（consultation）：谁拥有完成这个任务所需的必要信息？
  • 告知人（informed）：谁需要被通知任务状态和结果？

2.6.3 组件项目团队 ​

与组建项目团队相关的重要内容：人力资源分配、人力资源负荷和人力资源平衡。 一旦人员被分配到项目中，项目经理可以使用两种技术来帮助他们最有效地使用项目人员：资源负荷&资源平衡。

Note

刘邦问群臣：我为什么会取得胜利，项羽为什么会失败？

大臣高起等人说：“您派有才能的人攻占城池与战略要地，给立大功的人加官封爵，所以能成大事业。而项羽恰恰相反，将士打了胜仗，他也不给奖励，心胸狭小，容不下有才能的人，所以他才失败。”

刘邦听了点点头说：“你们说的有道理，不过我最重要的取胜法宝是善于用人。要说运筹帷幄之中，决胜千里之外，我不如张良；要说镇守国家，安抚百姓，供应军饷，不让粮道断绝，我不如萧何；要说统领百万大军，攻无不克战无不胜，我不如韩信。这三个人，都是当代的人中之杰啊。我能用他们之所长，这才是我取得天下的根本原因。

2.7 项目沟通管理 ​

过程名输入工具和技术输出
规划沟通管理
Plan Communication Management		1. 项目章程
2. 项目管理计划
3. 项目文件
4. 事业环境因素
5. 组织过程资产		1. 专家判断
2. 沟通需求分析
3. 沟通技术
4. 沟通模型
5. 沟通方法
6. 人际关系与团队技能
7. 数据表现		1. 沟通管理计划
2. 项目管理计划更新
3. 项目文件更新
管理沟通
Manage Communications		1. 项目管理计划
2. 项目文件
3. 工作绩效报告
4. 事业环境因素
5. 组织过程资产		1. 沟通技术
2. 沟通方法
3. 沟通技能
4. 项目管理信息系统
5. 人机关系与团队技能
6. 项目管理信息系统
7. 会议		1. 项目沟通记录
2. 项目管理计划更新
3. 项目文件更新
4. 组织过程资产更新
监督沟通
Monitor Communications		1. 项目管理计划
2. 项目文件
3. 工作绩效数据
4. 事业环境因素
5. 组织过程资产		1. 专家判断
2. 项目管理信息系统
3. 数据分析
4. 人际关系与团队技能
5. 会议		1. 工作绩效信息
2. 变更请求
3. 项目管理计划更新
4. 项目文件更新

2.7.1 书面沟通 5C 原则 ​

书面沟通是一种正式且标准的沟通方式，使用书面沟通时，一定要注意 5C 原则：

  • 正确的语法和拼写（Cottect grammar and spelling）
  • 简介的表述和无多余文字（Concise expression and elimination of excess word）
  • 清晰的目的和表述（Clear purpose and exxpression directed to needs of the reader）
  • 连贯的思维逻辑（Coherent logical flow of ideas）
  • 受控的语句和想法承接（Controlling flow of words and ideas）

2.7.2 沟通能力要求 ​

项目经理的大多数时间都用在与团队成员和其他干系人的沟通上，有效的沟通能在各种各样的项目干系人之间架起桥梁。这就要求项目经理具有如下的沟通能力：

  • 通过多种方法培养完善的技能
  • 创建、维护和遵循沟通计划和进度计划
  • 不断地以可预见的方式进行沟通
  • 寻求了解项目干系人的沟通需求
  • 以简练、清晰、完整、简单、相关和经过裁剪的方式进行沟通
  • 包含重要的正面和负面信息
  • 合并反馈渠道
  • 人际关系技能

2.8 项目风险管理 ​

过程名输入工具和技术输出
规划风险管理
Plan Risk Management		1. 项目章程
2. 项目管理计划
3. 项目文件
4. 协议
5. 事业环境因素
6. 组织过程资产		1. 专家判断
2. 数据分析
3. 会议		1. 风险管理计划
识别风险
Identify Risk		1. 项目管理计划
2. 项目文件
3. 协议
4. 采购文档
5. 事业环境因素
6. 组织过程资产		1. 专家判断
2. 数据收集
3. 数据分析
4. 人际关系与团队技能
5. 提申清单
6. 会议		1. 风险登记册
2. 风险报告
3. 项目文件更新
实施定性风险分析
Perform Qualitative Risk Analysis		1. 项目管理计划
2. 项目文件
3. 事业环境因素
4. 组织过程资产		1. 专家判断
2. 数据收集
3. 数据分析
4. 人际关系与团队技能
5. 风险分类
6. 数据表现
7. 会议		1. 项目文件更新
实施定量风险分析
Perform Quantitative Risk Analysis		1. 项目管理计划
2. 项目文件
3. 事业环境因素
4. 组织过程资产		1. 专家判断
2. 数据收集
3. 数据分析
4. 不确定性表达方式		1. 项目文件更新
规划风险应对
Plan Risk Response		1. 项目管理计划
2. 项目文件
3. 事业环境因素
4. 组织过程资产		1. 专家判断
2. 数据收集
3. 人际关系与团队技能
4. 威胁应对策略
5. 机会应对策略
6. 整体项目风险应对策略
7. 数据分析
8. 决策		1. 变更请求
2. 项目管理计划更新
3. 项目文件更新
监督风险
Monitor Risk		1. 项目管理计划
2. 项目文件
3. 工作绩效数据
4. 工作绩效报告		1. 数据分析
2. 审计
3. 会议		1. 工作绩效信息
2. 变更请求
3. 项目管理计划更新
4. 项目文件更新
实施风险应对
Perform Risk Response		1. 项目管理计划
2. 项目文件
3. 组织过程资产		1. 专家判断
2. 人际关系与团队技能
3. 项目管理信息系统		1. 变更请求
2. 项目文件更新

2.9 项目采购管理 ​

项目采购管理包括从项目团队外部采购或获取所需产品、服务或成果的各个过程。

项目组织既可以是甲方，也可以是乙方。

项目采购管理围绕协议来进行，协议是买卖双方之间具有约束力的法律文件。

项目经理通常无权签署协议，需要组织中具有相关职权的领导进行执行。

过程名输入工具和技术输出
规划采购管理
Plan Procurement Management		1. 项目章程
2. 商业文件
3. 项目管理计划
4. 项目文件
5. 事业环境因素
6. 组织过程资产		1. 专家判断
2. 数据收集
3. 数据分析
4. 供方选择标准
5. 会议		1. 采购管理计划
2. 采购策略
3. 招标文件
4. 采购工作说明书
5. 供方选择标准
6. 自制与外购决策
7. 独立成本估算
8. 变更请求
9. 项目文件更新
10. 组织过程资产更新
实施采购
Conduct Procurements		1. 项目管理计划
2. 项目文件
3. 采购文档
4. 卖方建议书
5. 事业环境因素
6. 组织过程资产		1. 专家判断
2. 广告
3. 投标人会议
4. 数据分析
5. 人际关系与团队技能		1. 选定的卖方
2. 协议
3. 变更请求
4. 项目管理计划更新
5. 项目文件更新
6. 组织过程资产更新
控制采购
Control Procurements		1. 项目管理计划
2. 项目文件
3. 协议
4. 采购文档
5. 批准的变更请求
6. 工作绩效数据
7. 事业环境因素
8. 组织过程资产		1. 专家判断
2. 索赔管理
3. 数据分析
4. 检查
5. 审计		1. 采购关闭
2. 工作绩效信息
3. 采购文档更新
4. 变更请求
5. 项目管理计划更新
6. 项目文件更新
7. 组织过程资产更新

2.10 项目干系人管理 ​

把干系人满意度作为一个关键的项目目标加以识别和管理。

过程名输入工具和技术输出
规划采购管理
Plan Procurement Management		1. 项目章程
2. 商业文件
3. 项目管理计划
4. 项目文件
5. 事业环境因素
6. 组织过程资产		1. 专家判断
2. 数据收集
3. 数据分析
4. 供方选择标准
5. 会议		1. 采购管理计划
2. 采购策略
3. 招标文件
4. 采购工作说明书
5. 供方选择标准
6. 自制与外购决策
7. 独立成本估算
8. 变更请求
9. 项目文件更新
10. 组织过程资产更新
实施采购
Conduct Procurements		1. 项目管理计划
2. 项目文件
3. 采购文档
4. 卖方建议书
5. 事业环境因素
6. 组织过程资产		1. 专家判断
2. 广告
3. 投标人会议
4. 数据分析
5. 人际关系与团队技能		1. 选定的卖方
2. 协议
3. 变更请求
4. 项目管理计划更新
5. 项目文件更新
6. 组织过程资产更新
控制采购
Control Procurements		1. 项目管理计划
2. 项目文件
3. 协议
4. 采购文档
5. 批准的变更请求
6. 工作绩效数据
7. 事业环境因素
8. 组织过程资产		1. 专家判断
2. 索赔管理
3. 数据分析
4. 检查
5. 审计		1. 采购关闭
2. 工作绩效信息
3. 采购文档更新
4. 变更请求
5. 项目管理计划更新
6. 项目文件更新
7. 组织过程资产更新

3. 典型案例 ​

3.1 案例一 ​

案例描述 ​

Kim 正在召开一个项目组首次会议，讨论她所负责的 IT 升级项目的工作分解结构。 公司正在优先开发几个因特网应用软件，这个 IT 升级项目要编制并实施一个计划，让公司所有员工的 IT 设备在 9 个月内达到新的公司标准。 该新标准规定每个台式机或笔记本电脑的最低配置要求，包括处理器型号、内存大小、硬盘容量、网络接口类型以及安装的软件等。

Kim 知道要进行升级，他们必须首先为公司 2000 多名员工列出一个所有现有硬件、网络和软件的清单。

Kim 和其他干系人一块制定了项目章程和初步的范围说明书。项目章程包括项目的粗略成本和进度估算，以及关键干系人的签字；初步的范围说明书对项目范围相关的软件、硬件和网络需求以及其他信息提供了初始的界定。

Kim 召集项目团队人员和其他干系人开会是为了进一步对项目范围进行界定。项目会涉及哪些工作？由谁做？如何才能避免可能的范围蔓延？她想通过这次会议征集大家对这些问题的看法。

公司首席执行官 Walter Schmidt 擅长于这一类大型项目管理，他使用一种新的项目管理系统使每个人对项目的状态和进度进行全面和细致的了解。

Kim 知道好的 WBS 是范围、时间、和成本绩效的基础，但她并不清楚怎样着手建立 WBS 或分配成本。

思考一下 ​

如果你是 Kim，你会如何做呢？

解决方案 ​

首先，参考公司和其他来源的创建指南，找到了一个 WBS 绘制的参考样例，并绘制了如下 WBS。

Kim 召开了一个会议，她和项目组全部 12 名成员进行了会晤。她回顾了项目章程和初步的范围说明书，介绍了管理项目的基本方法同时回顾了样例 WBS。Kim 为提出的问题一一做出了自信的回答她让每一个项目领导带领他的组员开始撰写详细的范围说明书以及他们负责的 WBS 和 WBS 字典。参与会议的每一个人都在分享各自的经验以及提问。Kim 看到项目的良好开端。

3.2 案例二 ​

案例描述 ​

Sue Johnson 是一个咨询公司的项目经理，公司签订了一个合同，给当地一个学院提供新的在线注册系统。这个系统必须在 5 月 1 号之前投入运行，从而让学生能够在秋季学期注册时使用。如果系统不能按时完成，合同中有一个严格的惩罚条款。如果项目进展顺利而且满足进度，那么 Sue 和她的团队就会因为工作好而获得丰厚的奖金。Sue 知道满足进度、范围、成本和质量要求是她的责任。她和她的团队设计了详细的进度表和网络图来管理项目。 计划项目的进度是较容易的，但是按计划执行项目就比较困难了。管理人员和解决进度冲突是两个大的挑战。客户的许多雇员休假没有计划，要重新安排项目评审会议。这些变化使得项目组很难遵循计划的系统进度，因为 Sue 必须让他们的客户在系统开发生命周期的各个阶段都签字。项目组的一个高级程序员辞职了，她知道要一个新人接手需要附加的时间来保持进度。虽然还处于项目的早期阶段，但是 Sue 知道项目已经落后了。那么她将怎么样来达到 5 月 1 日的上限时间呢？ 现在是 3 月 15 日，再过一个半月新的在线注册系统就要启用了。但项目目前是一片混乱，苏认为她能处理好所有在项目进行过程中出现的冲突，不向其上司或大学校长承认事情进展得不顺利。她花了大量的时间来准备项目的进度计划，并且她认为自己的项目管理软件使用得很好，可以跟上项目的状态。事实上，项目中有 5 位主要的程序员都使自己的任务在软件上每周自动更新，并说一切按预定计划进行。他们很少注意实际的计划，而且憎恨填写状态信息。苏并没有核实他们所做的大部分工作，检查它们是不是真正的完成了。另外，注册办公室主任对项目不感兴趣，将管理权限责任授权给他的一个文员，而该文员对整个注册过程并不理解。当苏和她的团队开始测试新系统时，她才发现她的团队使用的是去年的课程数据。由于大学在秋季将从过去的学期制转向半学期制，使用去年的课程数据会导致一些问题。他们怎么能把这个需求漏掉呢？ 当苏为了寻求帮助而和她的经理一起步入会议室时，她害羞地低垂着脑袋。她通过惨痛的教训知道了控制进度是多么的困难。为了核实关键可交付成果是否满足了客户的需求，苏希望她能多花一些时间与关键的项目干系人进行面对面的沟通，尤其是她这边的程序员与校方注册办公室的代表之间的沟通。

思考一下 ​

从 IT 项目管理的角度分析本案例失败的原因，Sue 要怎么做来解决问题？

解决方案 ​

失败的原因：

  1. 没有做好严密的项目干系人管理，没有定义项目干系人的影响力和兴趣程度；
  2. 没有做好项目人力资源管理和风险管理；
  3. 没有做好沟通管理，项目人员和项目经理没有实际上的沟通；同时出现问题时，苏没有及时向上级部门汇报情况，这属于违反了项目经理的职业道德；
  4. 没有做好项目质量管理和项目评估。

解决方案：

  1. 在项目的一开始，做好项目的项目的干系人管理，分析和定义实际的干系人和潜在的干系人，并定义他们的影响力和兴趣程度，从而准备好项目干系人管理策略；
  2. 做好项目管理的人力资源管理计划和项目的风险程度评估，并做好风险应急计划，对于可能存在的人事变更，提早做好准备；
  3. 通过定义干系人，而制定好详细的沟通管理计划，确定好何时何地，和谁一起，报告内容和形式，以及汇报频率；多与项目成员沟通并指导他们；
  4. 理解并满足项目干系人的需求，是质量管理的一个基本标准， 所以苏应该先做好项目的需求管理，才能更有效的经行项目的质量管理，同时严格要求项目成员完成每周的项目评估报告，这样苏才能明确知道项目的实际情况。

Released under the MIT License.

Copyright © 2019-present Evan You