PMP知识图谱

PMP的知识图谱，总结了项目整合管理、项目范围管理、项目进度管理、项目成本管理、项目质量管理等 。

基础知识

• 项目特点
  • 独特性
    • 产品
    • 服务
    • 成果
  • 临时性
    • 目标达成
    • 无法达成
    • 资源不足
    • 法律其他
  • 创造商业价值
    • 有形
      • 货币资产
      • 股东权益
    • 无形
      • 商誉
      • 品牌认知度
  • 项目驱动变革
    • 当前状态
    • 未来状态
• 项目启动背景
  • 符合法规、法律或社会要求
    • 有毒材料
    • 市政工程
  • 满足相关方的要求或需求
    • 卫生教育
  • 创造、改进或修复产品、过程或服务
    • 实施六西格玛
    • 市政工程修复
  • 执行、变更业务或技术战略
    • 经费变更
    • 降低生成版本
• 项目管理模式
  • 独立项目
    • 不包括在项目组合或项目集中
  • 项目集
    • 一组相互关联且被协调关联的项目、子项目集和项目集活动
      • 获得分别管理所无法获得的利益
    • 项目集和项目管理的重点在于以“正确”的方式开展项目集和项目
  • 项目组合
    • 为实现战略目录而组合在一起管理的项目、项目集、子项目组合和运营工作
    • 项目组合管理注重于开展“正确”的项目集和项目
• 项目与运营
• 阶段关口
  • 审查依据
    • 项目商业论证
    • 项目章程
    • 项目管理计划
    • 效益管理计划
  • 作出决定
    • 进入下一个阶段
    • 整改后进入下一个阶段
    • 结束项目
    • 停留在当前阶段
    • 重复阶段或某个要素
  • 五大过程组
    • 启动
    • 规划
    • 执行
    • 监控
    • 收尾
• 项目管理过程组
• 项目生命周期
  • 预测型（瀑布）生命周期
    • 在生命周期的早期阶段确定项目范围、时间和成本。对任何范围的变更都要进行仔细管理。
  • 迭代型生命周期
    • 迭代方法是通过一系列重复的循环的活动来开发产品。
  • 增量型生命周期
    • 通过在预定的时间区间内渐进增加产品功能的一系列迭代来产出可交付成果。
  • 适应型（敏捷）生命周期
    • 详细范围在迭代开始之前就得到了定义和批准。适应型生命周期也称为敏捷或变更驱动型生命周期。
  • 混合型生命周期
    • 预测型生命周期和适应型生命周期的组合。
• 项目管理数据和信息
• 商业文件
  • 项目商业论证
    • 文档化的经济可行性报告，用来对尚缺乏充分定义的所选方案的收益进行有效性论证，是启动后续项目管理活动的依据。
    • 商业论证列出了项目启动的目标和理由。它有助于在项目结束时根据项目目标衡量项目是否成功。
    • 在项目启动之前通过商业论证，可能会作出继续/终止项目的决策。
  • 项目效益管理计划
    • 对创造、提高和保持项目效益的过程进行定义的书面文件。
  • 说明
    • 项目发起人通常负责项目商业论证文件的制定和维护。
    • 项目经理负责提供建议和见解，使项目商业论证、项目管理计划、项目章程和项目效益管理计划中的成功标准相一致，并与组织的目的和目标保持一致。
• 需求评估
  • 需求评估通常是在商业论证之前进行，包括了解业务的目的和目标、问题及机会，并提出处理建议。需求评估结果可能会在商业论证文件中进行总结。
    • 识别问题或机会
      • 识别待解决的问题或待寻求的机会的过程。
    • 评估当前状态
      • 检查所分析的当前环境以了解组织内部或外部的重要因素的过程，这些重要因素可能是问题或机会的原因。
    • 确定将来状态
      • 确定现有的能力中存在的差距，以及为了达到所期望的将来状态而需要提出一系列变更的过程，以解决分析中存在的问题或抓住分析中出现的机会。
    • 确定可行选项和提供建议
      • 应用各种分析技术来检查可能的解决方案的过程，这些解决方案可以满足商业目的和目标，并确定哪些选项是组织所追求的最佳方案。
    • 引导产品路线图开发
      • 支持产品路线图开发的过程。产品路线图在高层级上描绘了产品的哪些方面计划在项目组合、项目集，或者一个或多个项目迭代或发布的过程中交付，以及这些方面交付的潜在顺序。
    • 组合商业论证
      • 综合经过深入研究和分析的信息，以支持选择最佳的项目组合组件、项目集或项目，从而打成商业目的和目标的过程。
    • 支持章程开发
      • 利用在需要评估和商业论证开发工作中获得的商业分析知识、经验和产品信息，与发起人实体和相关方资源协作开发章程的过程。
• 项目效益管理计划
  • 目标效益
    • 例如预计通过项目实施可以创造的有形价值和无形价值；财务价值体现为净现值；
  • 目标效益战略一致性
    • 例如项目效益与组织业务战略的一致程度；
  • 实现效益的时限
    • 例如阶段效益、短期效益、长期效益和持续效益
  • 效益责任人
    • 例如在计划确定的整个时限内负责监督、记录和报告已实现效益的负责人
  • 测量指标
    • 例如用于显示已实现效益的直接测量值和间接测量值
  • 假设
    • 例如预计存在或显而易见的因素
  • 风险
    • 例如实现效益的风险
• 事业环境因素
  • 事业环境因素（EEFs）是指项目团队不能控制的，将对项目产生影响、限制或指令作用的各种条件。这些条件可能来自于组织的内部和（或）外部。事业环境因素是很多项目管理过程，尤其是大多数规划过程的输入。这些因素可能会提高或限制项目管理的灵活性，并可能对项目结果产生积极或消极的影响。
    • 组织内部的事业环境因素
      • 组织文化、结构和治理
        • 例如包括愿景、使命、价值观、信念、文化规范、领导风格、等级制度和职权关系、组织风格、德道和行为规范。
      • 设施和资源的地理分布
        • 例如包括工厂位置、虚拟团队、共享系统和云计算。
      • 基础设施
        • 例如包括现有设施、设备、组织通讯渠道、信息技术硬件、可用性和功能。
      • 信息技术软件
        • 例如包括进度计划软件工具、配置管理系统、进入其他在线自动化系统的网络界面和工作授权系统。
      • 资源可用性
        • 例如包括合同和采购制约因素、获得批准的供应商和分包商以及合作协议。
      • 员工能力
        • 例如包括现有人力资源的专业知识、技能、能力和特定知识。
    • 组织外部的事业环境因素
      • 市场条件
        • 例如包括竞争对手、市场份额、品牌认知度和商标。
      • 社会和文化影响和问题
        • 例如包括政治氛围、行为规范、道德和信念。
      • 法律限制
        • 例如包括与安全、数据保护、商业行为、雇佣和采购有关的国家或地方法律法规。
      • 商业数据库
        • 例如包括标杆对照成果、标准化的成本估算数据、行业风险研究资料和风险数据库。
      • 学术研究
        • 例如包括行业研究、出版物和标杆对照成果。
      • 政府或行业标准
        • 例如包括与产品、生成、环境、质量和工艺有关的监督机构条例和标准。
      • 财务考虑因素
        • 例如包括货币汇率、利率、通货膨胀率、关税和地理位置。
      • 物理环境因素
        • 例如包括工作环境、天气和制约因素。
• 组织过程资产
  • 组织过程资产是执行组织所特有并使用的计划、过程、政策、程序和知识库，会影响对具体项目的管理。
  • 组织过程资产包括来自任何（或所有）项目执行组织的，可用于执行或治理项目的任何工件、实践或知识，还包括来自组织以往项目的经验和历史信息。
  • 组织过程资产可能还包括完成的进度计划、风险数据和挣值数据。
  • 组织过程资产是许多项目管理过程的输入。
  • 由于组织过程资产存在于组织内部，在整个项目期间，项目团队成员可对组织过程资产进行必要的更新和增补。
  • 分类
    • 过程、政策和程序
      • 第一类资产的更新通常不是项目工作的一部分，而是由项目管理办公室（PMO）或项目以外的其他职能部门完成。更新工作仅须遵循与过程、政策和程序更新相关的组织政策。有些组织鼓励团队剪裁项目的模板、生命周期和核对单。在这种情况下，项目管理团队应根据项目需求裁剪这些资产。
      • 组织用于执行项目工作的流程与程序
        • 启动和规划
          • 指南和标准，用于裁剪组织标准流程和程序以满足项目的特定要求
          • 特定的组织标准，例如政策（如人力资源政策、健康与安全策略、安保与保密政策、质量政策、采购政策和环境政策）
          • 产品和项目生命周期，以及方法和程序（如项目管理方法、评估指标、过程审计、改进目标、核对单、组织内部使用的标准化的过程定义）
          • 模板（如项目管理计划、项目文件、项目登记册、报告格式、合同模板、风险分类、风险描述模板、概率与影响的定义、概率和影响矩阵，以及相关方登记册模板）
          • 预先批准的供应商清单和各种合同协议类型（如总价合同、成本补偿合同和工料合同）
    • 组织知识库
      • 第二类资产是在整个项目期间结合项目信息而更新的。例如，整个项目期间会持续更新与财务绩效、经验教训、绩效指标和问题以及缺陷相关的信息。
      • 组织用来存取信息的知识库
        • 配置管理知识库，包括软件和硬件组件版本以及所有执行组织的标准、政策、程序和任何项目文件的基准
        • 财务数据库，包括人工时、实际成本、预算和成本超支等方面的信息
        • 历史信息与经验教训知识库（如项目记录与文件、完整的项目收尾信息与文件、关于以往项目选择决策的结果及以往项目绩效的信息，以及从风险管理活动中获取的信息）
        • 问题与缺陷管理数据库，包括问题与缺陷的状态、控制信息、解决方案以及相关行动的结果
        • 测量指标数据库，用来收集与提供过程和产品的测量数据
        • 以往项目的档案（如范围、成本、进度与绩效测量基准，项目日历，项目进度网络图，风险登记册，风险报告以及相关方登记册）
• 组织治理框架
  • 项目治理框架向项目经理和团队提供管理项目的结构、流程、决策模式和工具，同时对项目进行支持和控制，已实现项目的成功交付。
  • 项目治理由项目组合、项目集或发起组织来定义，并要与之相适应，但需要与组织治理分开。项目治理需要干系人的参与，需要依据书面政策、流程和标准，需要规定职责和职权。
    • 项目成功标注和可交付成果验收标准
    • 协调项目治理和组织战略的指南
    • 用于识别、升级和解决项目期间的问题的流程
    • 项目生命周期方法
    • 项目团队、组织团体和外部干系人之间的关系
    • 阶段关口或阶段审查流程
    • 项目组织图，其中定义了项目角色
    • 对超出项目经理权限的预算、范围、质量和进度变更的审批流程
    • 信息沟通的流程和程序
    • 保证内部关系人遵守项目过程要求的流程
    • 项目决策流程
• 组织结构类型
• 项目管理办公室
  • Project Management Office（PMO）
    • 分类
      • 支持性
        • 资源库
          • 最佳实践
          • 培训
          • 经验教训
      • 控制型
        • 支持
        • 服从
          • 方法论
          • 模板工具
          • 治理
      • 指令型
        • 直接管控
        • 项目经理
          • 指定
          • 汇报
    • 支持者
      • 项目审计
        • 遵守程度
      • 制定管理
        • 组织过程资产
      • 管理
        • 共享资源
      • 协调
        • 跨项目沟通
    • 决策者
      • 提出建议
      • 知识传递
        • 领导
      • 终止项目
• 项目相关方
  • 相关方是指可能影响项目决策、活动或结果的个人、群体或组织，以及会受或自认为会受项目决策、活动或结果影响的个人、群体或组织。项目相关方可能来自项目内部或外部，可能主动或被动参与项目，甚至完全不了解项目。项目相关方可能对项目施加积极或消极影响，也可能受项目的积极或消极影响。
    • 内部相关方
      • 发起人
      • 资源经理
      • 项目管理办公室（PMO）
      • 项目组合指导委员会
      • 项目集经理
      • 其他项目的项目经理
      • 团队成员
    • 外部相关方
      • 客户
      • 最终用户
      • 供应商
      • 股东
      • 监管机构
      • 竞争者
  • 发起人
    • 发起人是为项目提供资源和支持的个人或团体，负责为成功创造条件。从提出初始概念到项目收尾，发起人一直都在推动项目的进展，包括游说更高层的管理人员，以获得组织的支持，并宣传项目给组织带来的利益。在整个启动过程中，发起人始终领导着项目，直到项目正式批准。发起人对制定项目初步范围与章程也起着重要的作用。对于那些超出项目经理控制范围的事项，将向上汇报给发起人。发起人可能还参与其他重要事项，如果范围变更审批、阶段末评审，以及当风险很大时对项目是否继续进行作出决定。项目发起人还要保证项目结束后项目可交付成果能够顺利移交给相关组织。
    • 注意：不要轻易麻烦发起人
• 项目经理
  • 角色和定义
    • 职能经理
      • 专注于对某个职能领域或业务部门的管理监督
    • 运营经理
      • 负责保证业务运营的高效性
    • 项目经理
      • 是由执行组织委派，领导团队实现项目目标的个人
  • PM影响
    • 项目
      • 实现
        • 项目目标
        • 相关方期望
      • 沟通
    • 组织
      • 互动
        • 其他项目经理
      • 配合发起人
        • 政治问题
        • 战略问题
      • 知识管理
        • 学习
        • 转移整合
      • 报告
        • 职能经理
        • 项目集等
    • 跨领域
      • 传播项目管理方法
    • 专业学科
      • 传递
      • 整合
      • 知识
    • 行业
      • 关注
      • 应用
      • 新趋势
  • PMI人才三角
• 权力分类
  • 人身
    • 参照
    • 专家
    • 魅力
  • 职位
    • 正式
    • 奖励
    • 处罚
    • 加压
  • 复合
    • 信息
    • 情景
  • 人际
    • 关系
    • 迎合
    • 愧疚
    • 说服
    • 回避
• 领导力风格
  • 放任型
    • 例如，允许团队自主决策和设定目标，又被称为“无为而治”
  • 交易型
    • 例如，关注目标、反馈和成就以确定奖励，例外管理
  • 服务型
    • 例如，作出服务承诺，处处先为他人着想；关注他人的成长、学习、发展、自主性和福祉；关注人际关系、团队与合作；服务优先于领导
  • 变革型
    • 例如，通过理想化特质和行为、鼓舞性激励、促进创新和创造，以及个人关怀提高追随者的能力
  • 魅力型
    • 例如，能够激励他人；精神饱满、热情洋溢、充满自信；说服力强
  • 交互型
    • 例如，结合了交易型、变革型和魅力型领导的特点
  • 马斯洛需求层次理论
    • • 生理需求
        • 这些是指基本的身体需求，如口渴时喝水或饿了吃东西。根据马斯洛的说法，其中一些需求涉及我们努力满足身体对体内平衡的需求;也就是说，在不同的身体系统中保持一致的水平（例如，保持98.6°的体温）。 马斯洛认为生理需求是我们最基本的需求。如果有人缺乏不止一种需求，他们可能会首先尝试满足这些生理需求。例如，如果某人非常饿，除了食物之外，很难专注于其他任何事情。生理需求的另一个例子是需要充足的睡眠。
      • 安全需求
        • 一旦人们的生理需求得到满足，下一个需求就是一个安全的环境。即使在童年早期，我们的安全需求也很明显，因为儿童需要安全和可预测的环境，当这些需求得不到满足时，通常会做出恐惧或焦虑的反应。马斯洛指出，在生活在发达国家的成年人中，安全需求在紧急情况（例如战争和灾难）中更为明显，但这种需求也可以解释为什么我们倾向于喜欢熟悉的东西，或者为什么我们做一些事情，比如购买保险和为储蓄账户供款。
      • 不成功的领导
      • 爱与归属感-社交需求
        • 根据马斯洛的说法，等级制度中的下一个需求包括感到被爱和被接受。这种需求既包括浪漫关系，也包括与朋友和家人的联系。它还包括我们需要感到自己属于一个社会群体。重要的是，这种需求包括感受到被爱和感受到对他人的爱。 自马斯洛时代以来，研究人员一直在探索爱和归属感需求如何影响幸福感。例如，拥有社会关系与更好的身体健康有关，相反，感到孤立（即归属感未得到满足）会对健康和福祉产生负面影响。
      • 尊重需求
        • 我们的自尊需求包括自我感觉良好的愿望。根据马斯洛的说法，尊重需求包括两个组成部分。首先是感到自信和自我感觉良好。第二个组成部分包括感到被他人重视;也就是说，感觉我们的成就和贡献得到了别人的认可。当人们的尊重需求得到满足时，他们会感到自信，并将自己的贡献和成就视为有价值和重要。然而，当他们的自尊需求没有得到满足时，他们可能会经历心理学家阿尔弗雷德·阿德勒（Alfred Adler）所说的“自卑感”。
      • 一般的领导
      • 自我实现
        • 自我实现是指感到满足，或感觉我们正在发挥自己的潜力。自我实现的一个独特特征是，每个人看起来都不一样。对于一个人来说，自我实现可能涉及帮助他人;对于另一个人来说，它可能涉及艺术或创意领域的成就。从本质上讲，自我实现意味着感觉我们正在做我们认为我们应该做的事情。根据马斯洛的说法，实现自我实现是相对罕见的，他著名的自我实现个体的例子包括亚伯拉罕林肯，阿尔伯特爱因斯坦和特蕾莎修女。
        • 成功的领导

十大知识领域

• 项目整合管理
  • 概述说明
    • 项目整合管理包括对隶属于项目管理过程组的各个过程和项目管理活动进行识别、定义、组合、统一和协调的各个过程。
      • 资源分配
      • 平衡竞争性需求
      • 研究各种备选方法
      • 为实现项目目标而裁剪过程
      • 管理各个项目管理知识领域之间的依赖关系
  • 制定项目章程
    • 项目章程是编写一份正式批准项目并授权项目经理在项目活动中使用组织资源文件的过程。本过程的主要作用是，明确项目与组织战略目标之间的直接联系，确立项目的正式地位，并展示组织对项目的承诺。
    • 项目章程在项目执行组织与需求组织之间建立起伙伴关系。在执行外部项目时，通常需要用正式的合同来达成合作协议。这种情况下，可能仍要用项目章程来建立组织内部的合作关系，以确保正确交付合同内容。项目章程一旦被批准，就标志着项目的正式启动。在项目中，应尽早确认并任命项目经理，最好在制定项目章程时就任命，且总应在规划开始之前任命。项目章程可由发起人编制，或者由项目经理与发起机构合作编制。通过这种合作，项目经理可以更好地了解项目目的、目标和预期效益，以便更有效地向项目活动分配资源。项目章程授权项目经理规划、执行和控制项目。
    • 项目由项目以外的机构来启动，如发起人、项目集或项目管理办公室（PMO）、项目组合治理委员会主席或其授权代表。项目启动者或发起人应该具有一定的职权，能为项目获取资金并提供资源。项目可能因内部经营需要或外部影响而启动，故通常需要编制需求分析、可行性研究、商业论证或有待项目处理的情况的描述。通过编制项目章程，来确认项目符合组织战略和日常运营的需要。不要把项目章程看做合同，因为其中未承诺报酬或金钱或用于交换的对价。
    • ITTO
      • 输入
        • 商业文件
          • 商业论证
            • 虽然商业文件是在项目之前制定的，但需要定期审核。
            • 经批准的商业论证或类似文件是最常用于制定项目章程的商业文件。商业论证从商业视角描述必要的信息，并且据此决定项目的期望结果是否值得所需投资。高于项目级别的经理和高管们通常使用该文件作为决策的依据。一般情况下，商业论证会包含商业需求和成本效益分析，以论证项目的合理性并确定项目边界。
          • 效益管理计划
        • 协议
          • 协议用于定义启动项目的初衷。协议有多种形式，包括合同、谅解备忘录（MOUs）、服务水平协议（SLA）、协议书、意向书、口头协议、电子邮件或其他书面协议。为外部客户做项目时，通常就以何用的形式出现。
        • 事业环境因素
        • 组织过程资产
          • 能够影响制定项目章程过程的组织过程资产包括（但不限于）
            • 组织的标准政策、流程和程序
            • 项目组合、项目集和项目的治理框架（用于提供指导和制定决策的治理职能和过程）
            • 监督和报告方法
            • 模板（如项目章程模板）
            • 历史信息与经验教训知识库（如项目记录与文件、关于以往项目选择决策的结果及以往项目绩效的信息）
      • 工具与技术
        • 专家判断
          • 专家判断是指基于应用领域、知识领域、学科和行业等的专业知识而做出的，关于当前活动的合理判断，这些专业知识可来自具有专业学历、知识、技能、经验或培训经历的任何小组或个人。
          • 获取渠道包括（但不限于）
            • 组织内的其他部门（FM）
            • 顾问
            • 相关方，包括客户或发起人
            • 专业与技术协会
            • 行业协会
            • 主题专家（SME）
              • 主题专家指精通某一领域或主题的专家。
            • 项目管理办公室（PMO）
        • 数据收集
          • 头脑风暴
            • 用于在短时间内获得大量创意，适用于团队环境，需要引导者进行引导。
            • 头脑风暴由两个部分构成：创意产生和创意分析。
            • 制定项目章程时可通过头脑风暴向相关方、主题专家和团队成员收集数据、解决方案或创意。
            • 补充：延迟评价，追求数量。
          • 焦点小组
            • 焦点小组召集相关方和主题专家讨论项目风险、成功标准和其他议题，比一对一访谈更有利于互动交流。
            • 焦点小组是召集预定的相关方和主题专家，了解他们对所讨论的产品、服务或成果的期望和态度。有一位受过训练的主持人引导大家进行互动式讨论。焦点小组往往比“一对一”的访谈更热烈。
          • 访谈
            • 访谈是指通过与相关方直接交谈来了解高层级需求、假设条件、制约因素、审批标准以及其他信息。
            • 访谈是通过与相关方直接交谈，来获取信息的正式或非正式的方法。访谈的典型做法是想被访者提出假设和即兴的问题，并记录他们的回答。访谈经常是一个访谈者或一个被访谈者之间的“一对一”谈话，但也可以包括多个访谈者和/或多个被访谈者。访谈有经验的项目参与者、发起人和其他高管，以及主题专家，有助于识别和定义所需产品可交付成果的特征和功能。访谈也可用于获取机密信息。
        • 人际关系与团队技能
          • 冲突管理
            • 冲突管理有助于相关方就目标、成功标准、高层级需求、项目描述、总体里程碑和其他内容达成一致意见。
          • 引导
            • 引导是指有效引导团队活动成功以打成决定、解决方案或结论的能力。引导者确保参与者有效参与，互相理解，考虑所有意见，按既定决策流程全力支持得到的结论或结果，以及所达成的行动计划和协议在之后得到合理执行。
          • 会议管理
            • 会议管理包括准备议程、确保邀请每个关键相关方群体的代表，以及准备和发送后续的会议纪要和行动计划。
        • 会议
          • 在制定项目章程的过程中，与关键相关方举行会议的目的是识别项目目标、成功标准、主要可交付成果、高层级需求、总体里程碑和其他概述信息。
          • 补充：六顶思考帽
            • • 蓝色思考帽
                • 蓝色思考帽负责控制和调节思维过程。负责控制各种思考帽的使用顺序，规划和管理整个思考过程，并负责做出结论。
              • 白色思考帽
                • 白色是中立而客观的。戴上白色思考帽，人们思考的是关注客观的事实和数据。
              • 红色思考帽
                • 红色是情感的色彩。戴上红色思考帽，人们可以表现自己的情绪，人们还可以表达直觉、感受、预感等方面的看法。
              • 黄色思考帽
                • 黄色代表价值与肯定。戴上黄色思考帽，人们从正面考虑问题，表达乐观的、满怀希望的、建设性的观点。
              • 黑色思考帽
                • 戴上黑色思考帽，人们可以运用否定、怀疑、质疑的看法，合乎逻辑的进行批判，尽情发表负面的意见，找出逻辑上的错误。
              • 绿色思考帽
                • 绿色代表茵茵芳草，象征勃勃生机。绿色思考帽寓意创造力和想象力。具有创造性思考、头脑风暴、求异思维等功能。
      • 输出
        • 项目章程
          • 项目章程是由启动者或发起人发布的，正式批准项目成立，并授权项目经理使用组织资源开展项目活动的文件。它记录了关于项目和项目预期交付的产品、服务或成果的高层级信息。
            • 项目目的
            • 可测量的项目目标和相关的成功标准
            • 项目目标
            • 高层级需求
            • 高层级项目描述、边界定义以及主要可交付成果
            • 项目范围
            • 整体项目风险
              • 项目风险
            • 总体里程碑进度计划
              • 项目进度
            • 预先批准的财务资源
              • 项目成本
            • 关键相关方名单
              • 项目相关方
            • 高层级基准
            • 项目审批要求（例如，用什么标准评价项目成功，由谁对项目成功下结论，由谁来签署项目结束）
            • 项目退出标准（例如，在何种条件下才能关闭或取消项目或阶段）
            • 项目目标
            • 委派的项目经理及其职责和职权
            • 发起人或其他批准项目章程的人员的姓名和职权
            • 职权职责
          • 项目章程确保相关方在总体上就主要可交付成果、里程碑以及每个项目参与者的角色和职责达成共识。
        • 假设日志
          • 通常，在项目启动之前编制商业论证时，识别高层级的战略和运营假设条件与制约因素。这些假设条件与制约因素应纳入项目章程。较低层级的活动和任务假设条件在项目期间随着诸如定义技术规范、估算、进度和风险等活动的开展而生成。假设日志用于记录整个项目生命周期中的所有假设条件和制约因素。
            • 假设条件
              • 在制定计划时，不需要验证即可视为正确、真实或确定的因素。同时还应描述如果这些因素不成立，可能造成的潜在影响。在项目规划过程中，项目团队应该经常识别、记录并确认假设条件。
            • 制约因素
              • 对项目或过程的执行有影响的限制性因素。需要列举并描述与项目范围有关且会影响项目执行的各种内外部制约或限制条件，例如，客户或执行组织事先确定的预算、强制性日期或进度里程碑。如果项目时根据协议实施的，那么合同条款通常也是制约因素。
  • 制定项目管理计划
    • 概述制定项目管理计划是定义、准备和协调项目计划的所有组成部分，并把它们整合为一份综合项目管理计划的过程。本过程的主要作用是，生成一份综合文件，用于确定所有项目工作的基础及其执行方式，它仅开展一次货仅在项目的预定义点开展。
    • 项目管理计划与项目文件
    • 制定项目管理计划的原则
      • 项目管理计划确定项目的执行、监控和收尾方式，会因项目所在的应用领域和复杂程度差异而异。
      • 项目管理计划需要主要相关方的批准
      • 在确定基准之前，可能要对项目管理计划进行多次更新，且这些更新无需遵循正式流程
      • 在执行和监控过程中提出必要的变更请求，并报实施整体变更控制过程审批
      • 所有项目相关方的参与，项目经理起总负责和整合的作用
    • ITTO
      • 输入
        • 项目章程
          • 项目团队把项目章程作为初始项目规划的起始点。项目章程所包含的信息种类数量因项目的复杂程度和已知的信息而异。在项目章程中至少应该定义项目的高层级信息，供将来在项目管理计划的各个组成部分中进一步细化。
        • 其他过程的输出
          • 创建项目管理计划需要整合诸多过程的数据。其他规划过程所输出的子计划和基准都是本过程的输入。此外，对于这些子计划和基准的变更都可能导致对项目管理计划的相应的更新。
        • 事业环境因素
        • 组织过程资产
      • 工具与技术
        • 专家判断
        • 数据收集
          • 头脑风暴
          • 核对单
            • 很多组织基于自身经验制定了标准化的核对单，或者采用所在行业的核对单。核对单可以指导项目经理制定计划或帮助检查项目管理计划是否包含所需全部信息。
          • 焦点小组
          • 访谈
        • 人际关系与团队技能
          • 冲突管理
          • 引导
          • 会议管理
        • 会议
          • 本过程中，可以通过会议讨论项目方法，确定为达成项目目标而采用的工作执行方式，以及制定项目监控方式。
          • Kick-Off Meeting 项目开工会
            • 项目开工会议通常意味着规划阶段结束和执行阶段开始，旨在传达项目目标、获得团队对项目的承诺，以及阐明每个相关方的角色和职责。开工会议可能在不同时间点举行，具体取决于项目的特征
              • 对于小型项目，通常由同一个团队开展项目规划和执行。这种情况下，项目在启动之后很快就会开工（规划过程组），因为执行团队参与了规划。
              • 对于大型项目，通常由项目管理团队开展大部分规划工作。在初始规划工作完成、开发（执行）阶段开始时，项目团队其他成员才参与进来。这种情况下，将随同执行过程组的相关过程召开开工会议。
            • 对于多阶段项目，通常在每个阶段开始时都要举行一次开工会议。
      • 输出
        • 项目管理计划
          • 计划专项
            • 实体计划
              • 项目管理计划
              • 成本基准
              • 进度基准
              • 范围基准
                • 基准Baseline 特殊版本的项目计划 高层管理层（发起人）和主要项目相关方批准 计划用于指导实施，内容更新与时俱进 用来测量绩效，计划变更需要严格的审批手续 基准的变更，只有CCB才有权批准，PM无权 当前基准指最新版本的项目计划（范围、进度、成本）
              • 更新必须经过变更程序
            • 程序计划
              • 风险管理计划
              • 变更管理计划
              • 成本管理计划
              • 质量管理计划
              • 范围管理计划
              • 需求管理计划
              • 进度管理计划
              • 变更管理计划
              • 采购管理计划
              • 除非程序本身有问题才能变更，且变更必须经过变更程序
            • 综合计划
              • 资源管理计划
              • 沟通管理计划
              • 相关方参与计划
              • 原则要变更单可以直接更新
  • 指导与管理项目工作
    • 指导与管理项目工作是为实现项目目标而领导和执行项目管理计划中所确定的工作，并实施已批准变更的过程。本过程的主要作用是，对项目工作和可交付成果开展综合管理，以提供项目成功的可能性。
    • ITTO
      • 输入
        • 项目管理计划
          • 项目管理计划的任何组件都可用作本过程的输入
        • 项目文件
          • 变更日志
          • 经验教训登记册
          • 里程碑清单
          • 项目沟通记录
          • 项目进度计划
          • 需求跟踪矩阵
          • 风险登记册
          • 风险报告
        • 批准的变更请求
          • 批准的变更请求是实施整体变更控制过程的输出，包括项目经理审查和批准的变更请求，必要时可经变更控制委员会（CCB）审查和批准。批准的变更请求可能是纠正措施、预防措施或缺陷补救，并由项目团队纳入项目进度计划付诸实施，可能对项目或项目管理计划的任一领域产生影响，还可能导致修正正式受控的项目管理计划组件或项目文件。
        • 事业环境因素
        • 组织过程资产
      • 工具与技术
        • 专家判断
        • 项目管理信息系统
          • 作为事业环境因素的一部分，本系统也可用于自动收集和报告关键绩效指标KPI
        • 会议
      • 输出
        • 可交付成果
          • 可交付成果是在某一过程、阶段或项目完成时，必须产出的任何独特并可核实的产品、成果或服务能力。它通常是项目结果，并可包括项目管理计划的组成部分。
          • 可拆分为：可交付物+成果
        • 工作绩效数据
          • 工作绩效数据是在执行项目工作的过程中，从每个正在执行的活动中收集到的原始观察结果和测量值。数据通常是最低层次的细节，将交由其他过程从中提炼出信息。在工作执行过程中收集数据，再交由控制过程做进一步分析。
            • 例如，工作绩效数据包括已完成的工作、关键绩效指标（KPI）、技术绩效测量结果、进度活动的实际开始日期和完成日期、已完成的故事点、可交付成果状态、进度进展情况、变更请求的数据量、缺陷的数量、实际发生的成本、实际持续时间等。
        • 问题日志
          • 在整个项目生命周期中，项目经理通常会遇到问题、差距、不一致或意外冲突。项目经理需要采取某些行动加以处理，以免影响项目绩效。问题日志是一种记录和跟进所有问题的项目文件。
            • 所需记录和跟进的内容可能包括
              • 问题类型
              • 问题提出者和提出时间
              • 问题描述
              • 问题优先级
              • 由谁负责解决问题
              • 目标解决日期
              • 问题状态
              • 最终解决情况
          • 问题日志可以帮助项目经理有效跟进和管理问题，确保它们得到调查和解决。作为本过程的输出，问题日志被首次创建，尽管在项目期间任何时候都可能发生问题。在整个项目生命周期应该随同监控活动更新问题日志。
          • 补充：问题VS风险
            • 问题：发生概率为0%或100%，为确定值。
            • 风险：发生概率为0%至100%之间，但不包含。
        • 变更请求
          • 变更请求是关于修改任何文件、可交付成果或基准的正式提议。如果在开展项目工作时发现问题，就可提出变更请求，对项目政策或程序、项目或产品范围、项目成本或预算、项目进度计划、项目或产品结果的质量进行修改。其他变更请求包括必要的预防措施或纠正措施，用来防止以后的不利后果。任何项目相关方都可以提出变更请求，应该通过实施整体变更控制过程对变更请求进行审查和处理。变更请求源自项目内部或外部，是可选或由法律（合同）强制的。
            • 变更请求可能包括
              • 纠正措施
              • 预防措施
              • 缺陷补救
              • 更新
        • 项目管理计划更新
          • 任何组件
        • 项目文件更新
          • 活动清单
          • 假设日志
          • 经验教训登记册
          • 需求文件
          • 风险登记册
          • 相关方登记册
        • 组织过程资产更新
  • 项目管理知识
    • 管理项目知识是使用现有知识并生成新知识，以实现项目目标，并且帮助组织学习的过程。本过程的主要作用是，利用已有的组织知识来创造或改进项目成果，并且使当前项目创造和知识可用于支持组织运营和未来的项目或阶段。
    • 知识筐理贯穿顶目全过程
      • 知识通常分为“显性知识”（易使用文字、图片和数字进行编撰的知识）和“隐性知识”（个体知识以及难以明确表达的知识，如信念、洞察力、经验和“诀窍”）两种。知识管理指管理显性和隐性知识，旨在重复使用现有知识并生成新知识。有助于达成这两个目的的关键活动是知识分享和知识集成（不同领域的知识、情境知识和项目管理知识）
      • 一种常见的误解是，知识管理只是将知识记录下来用于分享；另一种常见的误解是，知识管理只是在项目结束时总结经验教训，以供未来使用。这样的话，只有经编撰的显性知识可以得到分享。因为显性知识缺乏情境，可作不同解读，所以，虽易分享，但无法确保正确理解或应用。隐性知识虽蕴含情境，却很难编撰。它存在于专家个人的思想中，或者存在于社会团体和情境中，通常由人际交流和互动来分享。
      • 从组织的角度看，知识管理指的是确保项目团队和其他相关方的技能、经验和专业知识在项目开始之前、开展期间和结束之后得到运用。因为知识存在于人们的思想中，且无法强迫人们分享自己的知识或关注他们的知识，所以，知识管理最重要的环节就是营造一种相互信任的分为，激励人们分享知识或关注他人的知识。如果不激励人们分享知识或关注他们知识，即便最好的知识管理工具和技术也无法发挥作用。在实践中，联合使用知识管理工具和技术（用于人际互动）以及信息管理工具和技术（用于编撰显性知识）来分享知识。
        • 随时记录
    • ITTO
      • 输入
        • 项目管理计划
          • 所有组件
        • 项目文件
          • 经验教训登记册
            • 经验教训登记册提供了有效的知识管理实践。
          • 项目团队派工单
            • 项目团队派工单说明了项目已具有的能力和经验以及可能缺乏的知识。
          • 资源分解结构
            • 各种不同类型的资源（人），缺少哪些知识。
          • 供方选择标准
          • 相关方登记册
            • 相关方登记册包含已识别的相关方的详细情况，有助千了解他们可能拥有的知识。
        • 可交付成果
        • 事业环境因素
        • 组织过程资产
      • 工具与技术
        • 专家判断
        • 知识管理
          • 知识管理工具和技术将员工联系起来，使他们能够合作生成新知识、分享隐性知识，以及集成不同成员所拥有的知识。适用于项目的工具和技术取决于项目的性质，尤其是创新程度、项目复杂性，以及团队的多元化（包括学科背景多元化）程度。
            • 人际交往，包括非正式的社交和在线社交。可以进行开放式提问（如“谁知道．．．．．．？”）的在线论坛有助千与专家进行知识分享对话
            • 实践社区（有时称为“兴趣社区” 或“社区" ) 和特别兴趣小组
            • 会议，包括使用通信技术进行互动的虚拟会议
            • 工作跟随和跟随指导
          • 可以通过面对面和（或）虚拟方式来应用所有这些工具和技术。通常，面对面互动最有利于建立知识管理所需的信任关系，一旦信任关系建立，可以用虚拟互动来维护这种信任关系。
        • 信息管理
          • 信息管理工具和技术用于创建人们与知识之间的联系，可以有效促进简单、明确的显性知识的分享
            • 编撰显性知识的方法
            • 经验教训登记册
            • 图书馆服务
            • 信息收集，例如搜索网络和阅读已发表的文章
            • 项目管理信息系统（PMIS）
              • 项目管理信息系统通常包括文档管理系统。
          • 通过增加互动要素，如“与我联系”的功能，使用户能够与经验教训发帖者联系，并向其寻求与特定项目和情境有关的建议。这样一来，就能够强化信息管理工具和技术的使用。
        • 人际关系与团队技能
          • 积极倾听
            • 反馈
              • 收到
                • 回应
              • 总结
                • 复述
                • 理解
            • 倾听二层次
              • 内容
              • 情绪
                • 高层次
            • 消除障碍
              • 环境
                • 地点
                • 时间
              • 其他
                • 文化
                • 专业
          • 引导
          • 领导力
            • 以身作则：理念沟通，言行一致
              • 第一项承诺 明确自己的价值观，找到自己的声音。
              • 第二项承诺 使行动与共同的价值观保持一致，为他人树立榜样。
            • 共启愿景：展望未来，感召他人
              • 第三项承诺 展望未来，想象令人激动的崇高的各种可能。
              • 第四项承诺 诉诸共同愿景，感召他人为共同的愿景奋斗。
            • 挑战现状：寻找机会，努力探索
              • 第五项承诺 通过捕捉创意和从外部获取创新方法来猎寻改进的机会。
              • 第六项承诺 进行尝试和冒险，不断取得小小的成功，从实践中学习。
            • 使众人行：促进合作，善于分享
              • 第七项承诺 通过建立信任和增进关系来促进协作。
              • 第八项承诺 通过增强自主意识和发展能力来增强他人的实力。
            • 激励人心：表彰贡献，庆祝胜利
              • 第九项承诺 通过表彰个人的卓越表现来认可他人的贡献。
              • 第十项承诺 通过创造一种集体主义精神来庆祝价值的实现和胜利。
          • 人际交往
          • 政治意识
      • 输出
        • 经验教训登记册
          • 经验教训登记册可以包含情况的类别和描述，经验教训登记册还可以包括与情况相关的影响、建议和行动方案。经验教训登记册可以记录遇到的挑战、问题、意识到的风险和机会，或其他适用的内容。
          • 经验教训登记册在项目早期创建，作为本过程的输出。因此，在整个项目期间，它可以作为很多过程的输入，也可以作为输出而不断更新。参与工作的个人和团队也参与记录经验教训。可以通过视频、图片、音频会其他合适的方式进行记录知识，确保有效吸取经验教训。
          • 在项目或阶段结束时，把相关信息归入经验教训知识库，成为组织过程资产的一部分。
        • 项目管理计划更新
          • 任何组件
        • 组织过程资产更新
          • 所有项目都会产生新知识。有些知识应该被编撰，并在管理项目知识过程中被嵌入可交付成果。或者被用于改进过程和程序。本过程中，也可以首次编撰或使用现有知识，例如，关于新程序的现有想法在本项目中试用并获得成功。
          • 可在本过程中更新任一组织过程资产。
  • 监控项目工作
    • 监控项目工作时跟踪、审查和报告整体项目进展，以实现项目管理计划中确定的绩效目标的过程。本过程的主要作用是，让相关方了解项目的当前状态并认可为处理绩效问题而采取的行动，以及通过成本和进度预测，让相关方了解未来项目状态。
    • 监督是贯穿于整个项目的项目管理活动之一，包括收集测量和分析测量结果，以及预测趋势，以便推动过程改进。持续的监督使项目管理团队能洞察项目的健康状况，并识别须特别关注的任何方面。控制包括制定纠正或预防措施重新规划，并跟踪行动计划的实施过程，以确保它们能有效解决问题。
    • 监控项目工作过程关注内容
      • 把项目的实际绩效与项目管理计划进行比较
      • 定期评估项目绩效，决定是否需要采取纠正或预防措施，并推荐必要措施
      • 检查单个项目风险的状态
      • 在整个项目期间，维护一个准确且及时更新的信息库，以反映项目产品及相关文件的情况
      • 为状态报告、进展测量和预测提供信息
      • 做出预测，以更新当前的成本和进度信息
      • 监督已批准变更的实施情况
      • 如果项目时项目集的一部分，还应向项目集管理层报告项目进展和状态
      • 确保项目与商业需求保持一致
    • 补充：监控项目工作的数据流向图
    • ITTO
      • 输入
        • 项目管理计划
          • 任何组件
        • 项目文件
          • 假设日志
          • 估算依据
          • 成本预测
            • 成本预测基于项目以往的绩效，用于确定项目是否仍在处于预算的公差区间内，并识别任何必要的变更。
          • 问题日志
            • 问题日志用于记录和监督由谁负责在目标日期内解决特定问题。
          • 经验教训登记册
            • 经验教训登记册可能包含应对偏差的有效方式以及纠正措施和预防措施。
          • 里程碑清单
          • 质量报告
            • 质量报告包含质量管理问题，针对过程、项目和产品的改善建议，纠正措施建议（含括 返工、缺陷（漏洞）补救、100%检查等），以及在控制质量过程中发现的情况的概述。
          • 风险登记册
            • 风险登记册提供在项目执行过程中发生的各种威胁和机会的相关信息。
          • 风险报告
            • 风险报告提供关于整体项目风险和单个风险的信息。
          • 进度预测
            • 进度预测基于项目以往的绩效，用于确定项目是否确定项目是否仍处于进度的公差区间内，并识别任何必要的变更。
        • 工作绩效信息
          • 在工作执行过程中收集工作绩效数据，再交由控制过程做进一步分析。将工作绩效数据与项目管理计划组件、项目文件和其他项目变量比较之后生成工作绩效信息。通过这种比较可以了解项目的执行情况。
            • 例如，关于成本的工作绩效数据可能包含已支出的资金，但必须与预算、已执行的工作、用于完成工作的资源以及资金使用计划比较之后才能有用。这些附加信息为确定项目是否符合预算或是否存在偏差提供了相应的情境；还有助于了解偏差的严重程度。通过与项目管理计划中的偏差临界值进行比较，就可以确定是否需要采取预防或纠正措施。对工作绩效数据和附加信息进行综合分析，可以为项目决策提供可靠的基础。
        • 协议
          • 采购协议中包括条款和条件，也可包括其他条目，如买方就卖方应实施的工作或应交付的产品所做的规定。如果项目将部分工作外包出去，项目经理需要监督承包商的工作，确保所有协议都符合项目的特定要求，以及组织的采购政策。
        • 事业环境因素
        • 组织过程资产
      • 工具与技术
        • 专家判断
        • 数据分析
          • 备选方案分析
            • 备选方案分析用于在出现偏差时选择要执行的纠正措施或纠正措施和预防措施的组合。
          • 成本效益分析
            • 成本效益分析有助于在项目出现偏差时确定最节约成本的纠正措施
          • 挣值分析
            • 挣值分析对范围、进度和成本绩效进行了综合分析。
          • 根本原因分析
            • 根本原因分析关注识别问题的主要原因。它可用于识别出现偏差的原因以及项目经理为达成项目目标应重点关注的领域。
          • 趋势分析
            • 趋势分析根据以往结果预测未来绩效，它可以预测项目的进度延误，提前让项目经理意识到，按照既定趋势发展，后期进度可能出现的问题。应该在足够早的项目时间进行趋势分析，使项目团队有时间分析和纠正任何异常。可以根据趋势分析的结果，提出必要的预防措施建议。
          • 偏差分析
            • 偏差分析审查目标绩效与实际绩效之间的差异（或偏差），可涉及持续时间估算、成本估算、资源使用、资源费率、技术绩效和其他测量指标。
            • 可以在每个知识领域，针对特定变量，开展偏差分析。在监控项目工作过程中，通过偏差分析对成本、时间、技术和资源偏差进行综合分析，以了解项目的总体偏差情况。这样就便于采取合适的预防或纠正措施。
        • 决策
        • 会议
      • 输出
        • 工作绩效报告
          • 工作绩效信息可以用实体或电子形式加以合并、记录和分发。基于工作绩效信息，以实体或电子形式编制工作绩效报告，以制定决策、采取行动或引起关注。根据项目沟通管理计划，通过沟通过程向项目相关方发送工作绩效报告。
          • 工作绩效报告的示例包括状态报告和进展报告。工作绩效报告可以包含挣值图表和信息、趋势线和预测、储备燃尽图、缺陷直方图、合同绩效信息和风险情况概述。可以表现为有助于引起关注、制定决策和采取行动的仪表指示图、热点报告、信号灯图或其他形式。
        • 变更请求
        • 项目管理计划更新
          • 任何组件
        • 项目文件更新
          • 成本预测
          • 问题日志
          • 经验教训登记册
          • 风险登记册
          • 进度预测
  • 实施整体变更控制
    • 实施整体变更控制是审查所有变更请求、批准变更，管理对可交付成果、项目文件和项目管理计划的变更，并对变更处理结果进行沟通的过程。本过程审查对项目文件、可交付成果或项目管理计划的所有变更请求，并决定对变更请求的处置方案。本过程的主要作用是确保对项目中已记录在案的变更做综合评审。如果不考虑变更对整体项目目标或计划的影响就开展变更，往往会加剧整体项目风险。
    • 变更控制委员会（CCB）
      • 实施整体变更控制过程贯穿项目始终，项目经理对此承担最终责任。变更请求可能影响项目范围、产品范围以及任一项目管理计划组件或任一项目文件。在整个项目生命周期的任何时间，参与项目的任何相关方都可以提出变更请求。变更控制的实施程度，取决于项目所在应用领域、项目复杂程度、合同要求，以及项目所处的背景与环境。
      • 在基准确定之前，变更无需正式受控于实施整体变更控制过程。一旦确定了项目基准，就必须通过本过程来处理变更请求。依照常规，每个项目的配置管理计划应规定哪些项目工件受控于配置控制程序。对配置要素的任何变更都应该提出变更请求，并经过正式控制。
      • 尽管也可以口头提出，但所有变更请求都必须以书面形式记录，并纳入变更管理和（或）配置管理系统中。在批准变更之前，可能需要了解变更对进度的影响和对成本的影响。在变更请求可能影响任一项目基准的情况下，都需要开展正式的整体变更控制过程。每项记录在案的变更请求都必须由一位责任人批准、推迟或否决，这个责任人通常是项目发起人或项目经理。应该在项目管理计划或组织程序中指定这位责任人，必要时，应该由变更控制委员会（CCB）来开展实施整体变更控制过程。CCB是一个正式组成的团体，负责审查、评价、批准、推迟或否决项目变更，以及记录和传达变更处理决定。
    • 补充：变更专题
      • 变更流程图
      • 变更
        • 预防变更
          • 充分收集需求
          • 相关方支持参与
        • 内部变更
          • 非增值变更
            • 拒绝
          • 增值变更
            • 首先分析影响
            • 沟通相关方（如需要）
            • 提出变更请求
              • 相关方
              • 项目经理
        • 收尾变更
          • 建议另立新项目
          • 或遵从变更流程
          • 有缺陷必须修复
        • 标准变更
          • 提出
            • 提出变更请求
              • 书面
              • 口头
                • 补书面
          • 处理
            • 全面分析影响
            • 制定变更方案
            • 相关方沟通
              • 取消变更
              • 继续变更
            • 提交CCB批准
              • 未批准
                • 记录
                • 通知
              • 批准
                • 实施
          • 实施
            • 更新项目管理计划和项目文件
            • 更新变更日志
            • 通知相关方
            • 实施变更
            • 跟踪变更
            • 总结经验教训
    • ITTO
      • 输入
        • 项目管理计划
          • 变更管理计划
            • 变更管理计划为管理变更控制过程提供指导，并记录变更控制委员会（CCB）的角色和职责。
          • 配置管理计划
            • 配置管理计划描述项目的配置项、识别应记录和更新的配置项，以便保持项目产品的一致性和有效性。
          • 范围基准
          • 进度基准
          • 成本基准
        • 项目文件
          • 估算依据
          • 需求跟踪矩阵
          • 风险报告
        • 工作绩效报告
        • 变更请求
          • 很多过程都会输出变更请求。变更请求可能包含纠正措施、预防措施、缺陷补救，以及对正式受控的项目文件或可交付成果的更新，以反映修改或增加的意见或内容。变更可能影响项目基准，也可能不影响项目基准，而只影响相对于基准的项目绩效。变更决定通常由项目经理做出。
          • 对于会影响项目基准的变更，通常应该在变更请求中说明执行变更的成本、所需的计划日期修改、资源需求以及相关的风险。这种变更应由CCB（如有）和客户或发起人审批，除非他们本身就是CCB的成员。只有经批准的变更才能纳入修改后的基准。
        • 事业环境因素
        • 组织过程资产
      • 工具与技术
        • 专家判断
        • 变更控制工具
          • 为了便于开展配置和变更管理，可以使用一些手动或自动化的工具。配置控制重点关注可交付成果及各个过程的技术规范，而变更控制则着眼于识别、记录、批准或否决对项目文件、可交付成果或基准的变更。
          • 工具的选择应基于项目相关方的需要，包括考虑组织和环境情况和（或）制约因素。
          • 工具应支持的配置管理活动
            • 识别配置项
              • 识别与选择配置项，从而为定义与核实产品配置、标记产品和文件、管理变更和明确责任提供基础。
            • 记录并报告配置项状态
              • 关于各个配置项的信息记录和报告。
            • 进行配置项核实与审计
              • 通过配置核实与审计，确保项目的配置项组成的正确性，以及相应的变更都被登记、评估、批准、跟踪和正确实施，从而确保配置文件所规定的功能要求都已实现。
          • 工具应支持的变更管理活动
            • 识别变更
              • 识别并选择过程或项目文件的变更项。
            • 记录变更
              • 将变更记录为合适的变更请求。
            • 做出变更决定
              • 审查变更，批准、否决、推迟对项目文件、可交付成果或基准的变更或做出其他决定。
            • 跟踪变更
              • 确认变更被登记、评估、批准、跟踪并向相关方传达最终结果。也可以使用工具来管理变更请求和后续的决策，同时还要格外关注沟通，以帮助变更控制委员会的成员履行职责，以及向相关方传达决定。
          • 补充内容
            • 软件项目中可能遇到的问题
              • 找不到某个文件的历史版本;
              • 开发人员使用错误的程序版本；
              • 开发人员未经授权修改代码或文档；
              • 人员流动，交接工作不彻底；
              • 无法重新编译软件的某个历史版本；
              • 因协同开发,或者异地开发,版本变更混乱导致整个项目失败;
              • ......
            • 常见的软件配置项
              • 需求规格说明书
              • 设计规格说明书
              • 源代码
              • 测试计划
              • 测试用例
              • 用户手册
              • ......
            • 软件配置管理的主要功能
              • 版本控制
                • 采用相应的流程和工具，对软件开发过程中产生的各种文件的版本进行管理。是软件配置管理的核心内容。
              • 变更管理
                • 为防止开发人员对软件的随意变更而进行的管理上的审核过程，包括变更请求、变更评估、变更批准/拒绝、变更实现。
              • 其它
                • 配置审计、配置状态统计等。
        • 数据分析
          • 备选方案分析
            • 该技术用于评估变更请求，并决定哪些请求可接受、应否决或需修改。
          • 成本效益分析
            • 该分析有助于确定变更请求是否值得投入相关成本。
        • 决策
          • 投票
            • 投票是一种为达成某种期望结果，而对多个未来行动方案进行评估的集体决策技术和过程。本技术用于生成、归类和排序产品需求。
            • 投票技术包括
              • 一致同意
                • 每个人都同意某个行动方案。
              • 大多数同意
                • 获得群体中超过50%人员的支持，就能做出决策。把参与决策的小组人数定为奇数，可防止因平局而无法达成决策。
              • 相对多数同意
                • 根据群体中相对多数人的意见做出决策，即便未能获得大多数人的支持。通常在候选项超过两个时使用。
          • 独裁型决策制定
            • 采用这种方法，将由一个人负责为整个集体制定决策。
          • 多标准决策分析
            • 该技术借助决策矩阵，用系统分析方法建立诸如风险水平、不确定性和价值收益等多种标准，以对众多创意进行评估和排序。
        • 会议
          • 与变更控制委员会（CCB）一起召开变更控制会。变更控制委员会负责审查变更请求，并做出批准、否决或推迟的决定。大部分变更会对时间、成本、资源或风险产生一定的影响，因此，评估变更的影响也是会议的基本工作。此外，会议上可能还要讨论并提议所请求变更的备选方案。最后，将会议决定传达给提出变更请求的责任人或小组。
          • CCB也可以审查配置管理活动。应该明确规定变更控制委员会的角色和职责，并经相关方一致同意后，记录在变更管理计划中。CCB的决定都应记录在案，并向相关方传达，以便其知晓并采取后续行动。
      • 输出
        • 批准的变更请求
          • 由项目经理、CCB或指定的团队成员，根据变更管理计划处理变更请求，做出批准、推迟或否决的决定。批准的变更请求应通过指导与管理项目工作过程加以实施。对于推迟或否决的变更请求，应通知提出变更请求的个人或小组。
          • 以项目文件更新的形式，在变更日志中记录所有变更请求的处理情况。
        • 项目管理计划更新
          • 任何组件
          • 项目管理计划的任一正式受控的组成部分，都可通过本过程进行变更。对基准的变更，只能基于最新版本的基准且针对将来的情况，而不能变更以往的绩效。这有助于保护基准和历史绩效数据的严肃性和完整性。
        • 项目文件更新
          • 变更日志
          • 正式受控的任一项目文件都可在本过程变更，通常在本过程更新的一种项目文件是变更日志。变更日志用于记录项目期间发生的变更。
  • 结束项目或阶段
    • 结束项目或阶段是终结项目、阶段或合同的所有活动的过程。本过程的主要作用是，存档项目或阶段信息，完成计划的工作，释放组织团队资源以展开新的工作。
    • 在结束项目时，项目经理需要回顾项目管理计划，确保所有项目工作都已完成以及项目目标均已实现。
    • 项目或阶段行政收尾所需的必要活动包括（但不限于）
      • 为达到阶段或项目的完工或退出标准所必须的行动和活动
        • 确保所有文件和可交付成果都已是最新版本，且所有问题都已得到解决
        • 确认可交付成果已交付给客户并已获得客户的正式验收
        • 确保所有成本都已记入项目成本账
        • 关闭项目账户
        • 重新分配人员
        • 处理多余的项目材料
        • 重新分配项目设施、设备和其他资源
        • 根据组织政策编制详尽的最终项目报告
      • 为关闭项目合同协议或项目阶段合同协议所必须开展的活动
        • 确认卖方的工作已通过正式验收
        • 最终处置未决索赔
        • 更新记录以反映最后的结果
        • 存档相关信息供未来使用
      • 为完成下列工作所必须开展的活动
        • 收集项目或阶段记录
        • 审计项目成败
        • 管理知识分享和传递
        • 总结经验教训
        • 存档项目信息以供组织未来使用
      • 为向下一个阶段，或者向生产和（或）运营部门移交项目的产品、服务或成果所必须开展的行动和活动
      • 收集关于改进或更新组织政策和程序的建议，并将它们发送给相应的组织部门
      • 测量相关方的满意程度
        • 如果项目在完工前就提前终止，结束项目或阶段过程还需要制定程序，来调查和记录提前终止的原因为了实现上述目的，项目经理应该引导所有合适的相关方参与本过程
    • 补充：项目收尾流程
    • ITTO
      • 输入
        • 项目章程
          • 项目章程记录了项目成功标准、审批要求，以及由谁来签署项目结束。
        • 项目管理计划
          • 所有组件
        • 项目文件
          • 假设日志
          • 估算依据
          • 变更日志
          • 问题日志
          • 经验教训登记册
          • 里程碑清单
          • 项目沟通记录
          • 质量控制测量结果
          • 质量报告
          • 需求文件
          • 风险登记册
          • 风险报告
        • 验收的可交付成果
          • 在分阶段实施的项目或被取消的项目中，可能会包括未全部完成的可交付成果或中间可交付成果。
        • 商业文件
          • 商业论证
            • 商业论证记录了作为项目依据的商业需求和成本效益分析，确定项目是否达到经济可行性研究的预期结果。
          • 效益管理计划
            • 效益管理计划概述了项目的目标效益，用于测量项目是否达到了计划的效益。
        • 协议
          • 先外后内
        • 采购文档
        • 组织过程资产
      • 工具与技术
        • 专家判断
        • 数据分析
          • 文件分析
            • 经验教训
          • 回归分析
            • 分析项目结果的不同变量之间的相互关系，以提高未来项目的绩效
          • 趋势分析
            • 最小二乘法
          • 偏差分析
            • 偏差分析可通过比较计划目标与最终结果来改进组织的测量指标
        • 会议
          • 收尾报告会
          • 客户总结会
          • 经验教训总结会
          • 庆祝会
      • 输出
        • 项目文件更新
          • 经验教训登记册
          • 在项目活动中产生的各种文件并标记为最终版本（各版本计划、风险影响评价等）
        • 最终产品、服务或成果移交
          • 项目交付的产品、服务或成果可转交给另一团队或组织，并由其在整个生命周期中进行运营、维护和支持
        • 最终报告（总结项目绩效）
          • 目标达成情况（范围、质量、成本、进度等）
          • 商业需求达成情况（预期效益、业务需求）
          • 管理过程总结（风险或问题及其解决情况）
        • 组织过程资产更新
          • 运营和支持文件，用来将完成的项目或阶段可交付成果移交给他人（如运营部门或下一阶段）的正式文件。
          • 确认范围过程所产生的客户验收文件，以及合同协议（如果有的话），以确保在达到全部项目要求之后才正式关闭项目。
          • 如果项目在完工前提前终止，则需要在正式的收尾文件中说明项目终止的原因，并规定正式程序，把该项目的已完成和未完成的可交付成果移交他人。
          • 经验教训知识库
• 项目范围管理
  • 概述说明
    • 产品范围VS项目范围
      • 产品范围
        • 某项产品、服务或成果所具有的特征和功能。
      • 项目范围
        • 为交付具有规定特性与功能的产品、服务或成果而必须完成的工作。项目范围有时也包括产品范围。
      • ITTO
        • 输入
        • 工具与技术
        • 输出
    • 从预测型方法到适应型或敏捷型方法，项目生命周期可以处于这个连续区间内的任何位置。在预测型生命周期中，在项目开始时就对项目可交付成果进行定义，对任何范围变化都要进行渐进管理。而在适应型或敏捷型生命周期中，通过多次迭代来开发可交付成果，并在每次迭代开始时定义和批准详细的范围。
    • 采用适应型生命周期，旨在应对大量变更，需要相关方持续参与项目；因此，应将适应型项目的整体范围分解为一系列拟实现的需求和拟执行的工作（有时称为产品未完项）。在一个迭代开始时，团队将努力确定产品未完项中，哪些最优先项应在下一次迭代中交付。在每次迭代中，都会重复开展三个过程：收集需求、定义范围和创建WBS。相反，在预测型项目中，这些过程在项目开始时开展，并在必要时通过实施整体变更控制过程进行更新。
  • 规范范围管理
    • 规划范围管理是为记录如何定义、确认和控制项目范围及产品范围，而创建范围管理计划的过程。本过程的主要作用是，在整个项目期间对如何管理范围提供指南和方向。
    • ITTO
      • 输入
        • 项目章程
        • 项目管理计划
          • 质量管理计划
          • 项目生命周期描述
          • 开发方法
        • 事业环境因素
        • 组织过程资产
      • 工具与技术
        • 专家判断
        • 数据分析
          • 备选方案分析
        • 会议
      • 输出
        • 范围管理计划
          • 范围管理计划是项目管理计划的组成部分，描述将如何定义、制定、监督、控制和确认项目范围。范围管理计划要对将用于下列工作的管理过程做出规定。
        • 需求管理计划
          • 需求管理计划是项目管理计划的组成部分，描述将如何分析、记录和管理项目和产品需求。根据《从业者商业分析：实践指南》【7】，有些组织称之为“商业分析计划”。
  • 收集需求
    • 收集需求是为实现目标而确定、记录并管理相关方的需要和需求的过程。本过程的主要作用是，为定义产品范围和项目范围奠定基础，且仅开展一次或仅在项目的预定义点开展。
    • ITTO
      • 输入
        • 项目章程（高层级需求）
        • 项目管理计划
          • 范围管理计划
          • 需求管理计划
          • 相关方参与计划
            • 从相关方参与计划中了解相关方的沟通需求和参与程度，以便评估并适应相关方对需求活动的参与程度
        • 项目文件
          • 假设日志
          • 经验教训登记册
          • 相关方登记册
            • 相关方登记册也记录了相关方对项目的主要需求和期望
        • 商业文件
          • 商业论证
          • 相关方需求要与商业论证（初心）里面的目标保持一致
        • 协议
        • 事业环境因素
        • 组织过程资产
      • 工具与技术
        • 专家判断
        • 数据收集
          • 头脑风暴
            • 头脑风暴是一种用来产生和收集对项目需求与产品需求的多种创意的技术
          • 访谈
            • 访谈是通过与相关方直接交谈，来获取信息的正式或非正式的方法。访谈的典型做法是向被访者提出预设和即兴的问题，并记录他们的回答。访谈经常是一个访谈者和一个被访者之间的“一对一”谈话，但也可以包括多个访谈者和/或多个被访者。访谈有经验的项目参与者、发起人和其他高管，以及主题专家，有助于识别和定义所需产品可交付成果的特征和功能。访谈也可用于获取机密信息
          • 焦点小组
            • 焦点小组是召集预定的相关方和主题专家，了解他们对所讨论的产品、服务或成果的期望和态度。由一位受过训练的主持人引导大家进行互动式讨论。焦点小组往往比“一对一”的访谈更热烈
          • 问卷调查
            • 问卷调查是指设计一系列书面问题，向众多受访者快速收集信息。问卷调查方法非常适用于以下情况：受众多样化，需要快速完成调查，受访者地理位置分散，并且适合开展统计分析。
          • 标杆对照
            • 标杆对照将实际或计划的产品、过程和实践，与其他可比组织的实践进行比较，以便识别最佳实践，形成改进意见，并为绩效考核提供依据。标杆对照所采用的可比组织可以是内部的，也可以是外部的。
        • 数据分析
          • 文件分析
            • 文件分析包括审核和评估任何相关的文件信息。在此过程中，文件分析用于通过分析现有文件，识别与需求相关的信息来获取需求。有助于获取相关需求的文件很多。
            • 可供分析的文件包括（但不限于）
              • 协议
              • 商业计划
        • 决策
          • 投票
            • 投票是一种为达成某种期望结果，而对多个未来行动方案进行评估的集体决策技术和过程。本技术用于生成、归类和排序产品需求。
            • 投票技术示例
              • 一致同意
                • 每个人都同意某个行动方案。
              • 大多数同意
                • 获得群体中超过50%人员的支持，就能做出决策。把参与决策的小组人数定为奇数，可防止因平局而无法达成决策。
              • 相对多数同意
                • 根据群体中相对多数人的意见做出决策，即便未能获得大多数人的支持。通常在候选项超过两个时使用。
          • 独裁型决策制定
            • 采用这种方法，将由一个人负责为整个集体制定决策。
          • 多标准决策分析
            • 该技术借助决策矩阵，用系统分析方法建立诸如风险水平、不确定性和价值收益等多种标准，以对众多创意进行评估和排序。
        • 数据表现
          • 亲和图
            • 用来对大量创意进行分组的技术,以便进一步审查和分析。
          • 思维导图
            • 把从头脑风暴中获得的创意整合成一张图,用以反映创意之间的共性与差异,激发新创意。
            • 思维导图绘制内容
              • 中心主题
                • 形式
                  • 图像
                • 位置
                  • 中央
                • 大小
                  • 适宜
                • 颜色
                  • 三色
              • 线条
                • 类型
                  • 主干
                    • 连线
                      • 中心主题
                    • 由粗到细
                  • 支干
                    • 连接
                      • 主干
                      • 下级支干
                    • 细线
                  • 连接线
                    • 跨越
                • 颜色
                  • 同一主干
                    • 同色
              • 图像
                • 突出
                  • 重点
                • 强化
                  • 记忆
                • 建议
                  • 动感
                  • 多色
                  • 立体
              • 文字
                • 关键字
                  • 动词
                  • 名词
                  • 其他
                • 方向
                  • 左向右
                • 颜色
                  • 黑色
                  • 线条
        • 人际关系与团队技能
          • 名义小组技术
            • 名义小组技术是用于促进头脑风暴的一种技术，通过投票排列最有用的创意，以便进一步开展头脑风暴或优先排序。
            • 名义小组技术是一种结构化的头脑风暴形式，由四个步骤组成
              • 向集体提出一个问题或难题。每个人在沉思后写出自己的想法。
              • 主持人在活动挂图上记录所有人的想法。
              • 集体讨论各个想法，直到全体成员达成一个明确的共识。
              • 个人私下投票决出各种想法的优先排序，通常采用5分制，1分最低，5分最高。为减少想法数量、集中关注想法，可进行数轮投票。每轮投票后，都将清点选票，得分最高者被选出。
          • 观察/交谈
            • 观察和交谈是指直接察看个人在各自的环境中如何执行工作（或任务）和实施流程。当产品使用者难以或不愿清晰说明他们的需求时，就特别需要通过观察来了解他们的工作细节。观察，也称为“工作跟随”，通常由旁站观察者观察业务专家如何执行工作，但也可以由“参与观察者”来观察，通过实际执行一个流程或程序，来体验该流程或程序是如何实施的，以便挖掘隐藏的需求。
          • 引导
            • 引导与主题研讨会结合使用，把主要相关方召集在一起定义产品需求。研讨会可用于快速定义跨职能需求并协调相关方的需求差异。因为具有群体互动的特点，有效引导的研讨会有助于参与者之间建立信任、改进关系、改善沟通，从而有利于相关方达成一致意见。此外，与分别召开会议相比，研讨会能够更早发现并解决问题。
            • 适合采用引导技能的情境包括（但不限于）
              • 联合应用设计或开发（JAD）
                • JAD会议适用于软件开发行业。这种研讨会注重把业务主题专家和开发团队集中在一起，以收集需求和改进软件开发过程。
                • Joint Application Design Or Development
              • 质量功能展开（QFD）
                • 制造行业则采用QFD这种引导技能来帮助确定新产品的关键特征。QFD从收集客户需要（又称“客户声音”）开始，然后客观地对这些需要进行分类和排序，并为实现这些需要而设定目标。
                • Quality Function Display
              • 用户故事
                • 用户故事是对所需功能的简短文字描述，经常产生于需求研讨会。用户故事描述哪个相关方将从功能中受益（角色），他需要实现什么（目标），以及他期望获得什么利益（动机）。
                • 参与者一起创建关于相关方需求的故事，故事包括
                  • 角色?想要什么?为什么想?
                    • 用户故事通常按照此格式来表达：作为一个<角色>，我想要<活动>，以便于<商业价值>
                    • 举例：作为一个“网站管理员”，我想要“统计每天有多少人访问了我的网站”，以便于“我的赞助商了解我的网站会给他们带来什么收益。”
                  • 哪个相关方从功能中受益（角色）
                  • 需要实现什么（目标）
                  • 获得的收益（动机/商业价值）
                • 用户故事，广泛应用于敏捷方法中
        • 系统交互图
        • 原型法
          • 原型法是指在实际制造预期产品之前，先造出该产品的模型，并据此征求对需求的早期反馈。原型包括微缩产品、计算机生成的二维和三维模型、实体模型或模拟。因为原型是有形的实物，它使得相关方可以体验最终产品的模型，而不是仅限于讨论抽象的需求描述。原型法支持渐进明细的理念，需要经历从模型创建、用户体验、反馈收集到原型修改的反复循环过程。在经过足够的反馈循环之后，就可以通过原型获得足够的需求信息，从而进入设计或制造阶段。
          • 故事板是一种原型技术，通过一系列的图像或图示来展示顺序或导航路径。故事板用于各种行业的各种项目中，如电影、广告、教学设计，以及敏捷和其他软件开发项目。在软件开发中，故事板使用实体模型来展示网页、屏幕或其他用户界面的导航路径。
      • 输出
        • 需求文件
          • 需求文件描述各种单一需求将如何满足与项目相关的业务需求。一开始可能只有高层级的需求，然后随着有关需求信息的增加而逐步细化。只有明确的（可测量和可测试的）、可跟踪的、完整的、相互协调的，且主要相关方愿意认可的需求，才能作为基准。需求文件的格式多种多样，既可以是一份按相关方和优先级分类列出全部需求的简单文件，也可以是一份包括内容提要、细节描述和附件等的详细文件。
            • 业务需求
              • 整个组织的高层级需要，例如，解决业务问题或抓住业务机会，以及实施项目的原因。
            • 相关方需求
              • 相关方或相关方群体的需要。
            • 解决方案需求
              • 为满足业务需求和相关方需求，产品、服务或成果必须具备的特性、功能和特征。解决方案需求又进一步分为功能需求和非功能需求
            • 功能需求
              • 功能需求描述产品应具备的功能，例如，产品应该执行的行动、流程、数据和交互。
            • 非功能需求
              • 非功能需求是对功能需求的补充，是产品正常运行所需的环境条件或质量要求，例如，可靠性、保密性、性能、安全性、服务水平、可支持性、保留或清除等。
            • 过渡和就绪需求
              • 这些需求描述了从“当前状态”过渡到“将来状态”所需的临时能力，如数据转换和培训需求。
            • 项目需求
              • 项目需要满足的行动、过程或其他条件，例如里程碑日期、合同责任、制约因素等。
            • 质量需求
              • 用于确认项目可交付成果的成功完成或其他项目需求的实现的任何条件或标准，例如测试、认证、确认等。
        • 需求跟踪矩阵
          • 将需求与业务目标或项目目标相联系，确保每个需求都具有商业价值。
          • 需求跟踪矩阵提供了在整个项目生命周期中跟踪需求的一种方法，有助于确保需求文件中被批准的每项需求在项目结束的时候都能交付。
          • 需求跟踪矩阵还为管理产品范围变更提供了框架。
  • 定义范围
    • 定义范围是制定项目和产品详细描述的过程。本过程的主要作用是，描述产品、服务或成果的边界和验收标准。
    • ITTO
      • 输入
        • 项目章程
          • 项目章程中包含对项目的高层级描述、产品特征和审批要求。
        • 项目管理计划
          • 范围管理计划
            • 其中记录了如何定义、确认和控制项目范围
        • 项目文件
          • 假设日志
            • 假设日志识别了有关产品、项目、环境、相关方以及会影响项目和产品范围的假设条件和制约因素。
          • 需求文件
            • 需求文件识别了应纳入范围的需求。
          • 风险登记册
            • 风险登记册包含了可能影响项目范围的应对策略，例如缩小或改变项目和产品范围，以规避或缓解风险。
        • 事业环境因素
        • 组织过程资产
      • 工具与技术
        • 专家判断
        • 数据分析
          • 备选方案分析
        • 决策
          • 多标准决策分析
        • 人际关系与团队技能
          • 引导
        • 产品分析
          • 产品分析可用于定义产品和服务，包括针对产品或服务提问并回答，以描述要交付的产品的用途、特征及其他方面。
          • 每个应用领域都有一种或几种普遍公认的方法，用以把高层级的产品或服务描述转变为有意义的可交付成果。
          • 首先获取高层级的需求，然后将其细化到最终产品设计所需的详细程度。
      • 输出
        • 项目范围说明书
          • 项目范围说明书是对项目范围、主要可交付成果、假设条件和制约因素的描述。它记录了整个范围，包括项目和产品范围；详细描述了项目的可交付成果；还代表项目相关方之间就项目范围所达成的共识。为便于管理相关方的期望，项目范围说明书可明确指出哪些工作不属于本项目范围。
          • 项目范围说明书使项目团队能进行更详细的规划，在执行过程中指导项目团队的工作，并为评价变更请求或额外工作是否超过项目边界提供基准。
          • 项目范围说明书描述要做和不要做的工作的详细程度，决定着项目管理团队控制整个项目范围的有效程度。
          • 详细的项目范围说明书包括内容（可能直接列出或参引其他文件）
            • 产品范围描述
              • 逐步细化在项目章程和需求文件中所述的产品、服务或成果的特征。
            • 可交付成果
              • 为完成某一过程、阶段或项目而必须产出的任何独特并可核实的产品、成果或服务能力，可交付成果也包括各种辅助成果，如项目管理报告和文件。对可交付成果的描述可略可详。
            • 验收标准
              • 可交付成果通过验收前必须满足的一系列条件。
            • 项目的除外责任
              • 识别排除在项目之外的内容。明确说明哪些内容不属于项目范围，有助于管理相关方的期望及减少范围蔓延。
        • 项目文件更新
          • 假设日志
          • 需求文件
          • 需求跟踪矩阵
          • 相关方登记册
  • 创建WBS
    • 创建工作分解结构（WBS）是把项目可交付成果和项目工作分解成较小、更易于管理的组件的过程。本过程的主要作用是，为所要交付的内容提供架构，它仅开展一次或仅在项目的预定义点开展。
    • ITTO
      • 输入
        • 项目管理计划
          • 范围管理计划
        • 项目文件
          • 项目范围说明书
          • 需求文件
        • 事业环境因素
        • 组织过程资产
      • 工具与技术
        • 专家判断
        • 分解
          • 时间：以项目生命周期的各阶段作为分解的第二层，把产品和项目可交付成果放在第三层
          • 结构：以主要可交付成果作为分解的第二层
          • 工作包
            • 工作包是WBS最低层的工作，可对其成本和持续时间进行估算和管理(80小时)
            • 每个工作包都是控制账户的一部分，而控制账户则是一个管理控制点。在该控制点上，把范围、预算和进度加以整合，并与挣值相比较，以测量绩效。
            • 规划包，其是一种低于控制账户而高于工作包的工作分解结构组件。
      • 输出
        • 范围基准
          • 项目范围说明书
            • 包括对项目范围、主要可交付成果、假设条件和制约因素的描述
          • WBS
            • WBS是对项目团队为实现项目目标、创建所需可交付成果而需要实施的全部工作范围的层级分解
          • 工作包
            • WBS最低层的组成部分称为工作包，其中包括计划的工作。工作包对相关活动进行归类，以便对工作安排进、进行估算、开展监督与控制。
          • 规划包
            • 一种低于控制账户而高于工作包的工作分解结构组件，工作内容已知，但详细的进度活动未知。
          • WBS
          • WBS词典
            • WBS词典是针对WBS中的每个组件，详细描述可交付成果、活动和进度信息的文件。
            • WBS词典对WBS提供支持，其中大部分信息由其他过程创建，然后在后期添加到词典中。
            • WBS词典中的内容可能包括（但不限于）
              • 账户编码标识
              • 工作描述
              • 假设条件和制约因素
              • 负责的组织
              • 进度里程碑
              • 相关的进度活动
              • 所需资源
              • 成本估算
              • 质量要求
              • 验收标准
        • 项目文件更新
          • 假设日志
          • 需求文件
  • 确认范围
    • 确认范围是正式验收已完成的项目可交付成果的过程。本过程的主要作用是，使验收过程具有客观性；同时通过确认每个可交付成果，来提高最终产品、服务或成果获得验收的可能性。
    • 由客户或发起人审查从控制质量过程输出的核实的可交付成果，确认这些可交付成果已经圆满完成并通过正式验收。本过程对可交付成果的确认和最终验收，需要依据：从项目范围管理知识领域的各规划过程获得的输出（如需求文件或范围基准），以及从其他知识领域的各执行过程获得的工作绩效数据。
    • 确认范围过程与控制质量过程的不同之处在于，前者关注可交付成果的验收，而后者关注可交付成果的正确性及是否满足质量要求。控制质量过程通常先于确认范围过程，但二者也可同时进行。
    • ITTO
      • 输入
        • 项目管理计划
          • 范围管理计划
          • 需求管理计划
          • 范围基准
            • 用范围基准与实际结果比较，以决定是否有必要进行变更、采取纠正措施或预防措施。
        • 项目文件
          • 经验教训登记册
            • 在项目早期获得的经验教训可以运用到后期阶段，以提高验收可交付成果的效率与效果。
          • 质量报告
            • 质量报告的内容可包括由团队管理或需上报的全部质量保证事项、改进建议，以及在控制质量过程中发现的情况的概述。在验收产品之前，需要查看所有这些内容。
          • 需求文件
            • 将需求与实际结果比较，以决定是否有必要进行变更、采取纠正措施或预防措施。
          • 需求跟踪矩阵
            • 需求跟踪矩阵含有与需求相关的信息，包括如何确认需求。
        • 核实的可交付成果
          • 核实的可交付成果是指已经完成，并被控制质量过程检查为正确的可交付成果。
          • 补充：项目管理的成果线
            • 可交付成果
              • 指导与管理项目工作
            • 核实的可交付成果
              • 控制质量
                • 内部
                  • QC
                • 依据
                  • 质量测量指标
                  • 测试与评估文件
            • 验收的可交付成果
              • 确认范围
                • 外部
                  • 客户
                  • 发起人
                • 依据
                  • 范围基准
                  • 需求文件
            • 移交的可交付成果
              • 结束项目或阶段
                • 形式验收
              • 最终验收不通过?
                • 原因
                  • 确认范围环节
                  • 控制质量环节
        • 工作绩效数据
      • 工具与技术
        • 检查
          • 检查是指开展测量、审查与确认等活动，来判断工作和可交付成果是否符合需求和产品验收标准。检查有时也被称为审查、产品审查和巡检等。在某些应用领域，这些术语具有独特和具体的含义。
        • 决策
          • 可用于本过程的决策技术包括(但不限于)投票。当由项目团队和其他相关方进行验收时，使用投票来形成结论。
      • 输出
        • 验收的可交付成果
          • 符合验收标准的可交付成果应该由客户或发起人正式签字批准。应该从客户或发起人那里获得正式文件，证明相关方对项目可交付成果的正式验收。这些文件将提交给结束项目或阶段过程
        • 工作绩效信息
          • 工作绩效信息包括项目进展信息，例如，哪些可交付成果已经被验收，哪些未通过验收以及原因。这些信息应该被记录下来并传递给相关方。
        • 变更请求
          • 对已经完成但未通过正式验收的可交付成果及其未通过验收的原因，应该记录在案。可能需要针对这些可交付成果提出变更请求，开展缺陷补救。变更请求应该由实施整体变更控制过程进行审查与处理。
        • 项目文件更新
          • 经验教训登记册
          • 需求文件
          • 需求跟踪矩阵
  • 控制范围
    • 控制范围是监督项目和产品的范围状态，管理范围基准变更的过程。本过程的主要作用是，在整个项目期间保持对范围基准的维护，且需要在整个项目期间开展。
    • 控制项目范围确保所有变更请求、推荐的纠正措施或预防措施都通过实施整体变更控制过程进行处理。在变更实际发生时，也要采用控制范围过程来管理这些变更。控制范围过程应该与其他控制过程协调开展。未经控制的产品或项目范围的扩大（未对时间、成本和资源做相应调整）被称为范围蔓延。变更不可避免，因此在每个项目上，都必须强制实施某种形式的变更控制。
      • 范围蔓延
        • 范围镀金（主动）
          • 镀金指的是，项目成员自行添加功能到项目中，比如某人发现某个功能加到软件上会很新颖，有卖点，结果自行添加进去。这种行为方式造成了项目的镀金行为
        • 范围潜变（被动）
          • 范围潜变是指客户不断提出小的、不易察觉的范围改变，如果不加控制，累计起来导致项目严重偏离既定的范围基准，导致项目失控和失败。
    • ITTO
      • 输入
        • 项目管理计划
          • 范围管理计划
          • 需求管理计划
          • 变更管理计划
          • 配置管理计划
          • 范围基准
            • 用范围基准与实际结果比较，以决定是否有必要进行变更、采取纠正措施或预防措施。
          • 绩效测量基准
            • 使用挣值分析时，将绩效测量基准与实际结果比较，以决定是否有必要进行变更、采取纠正措施或预防措施。
        • 项目文件
          • 经验教训登记册
            • 在项目早期获得的经验教计川可以运用到后期阶段，以改进范围控制。
          • 需求文件
            • 需求文件用于发现任何对商定的项目或产品范围的偏离。
          • 需求跟踪矩阵
            • 需求跟踪矩阵有助于探查任何变更或对范围基准的任何偏离对项目目标的影响，它还可以提供受控需求的状态。
        • 工作绩效数据
        • 组织过程资产
      • 工具与技术
        • 数据分析
          • 偏差分析
            • 偏差分析用于将基准与实际结果进行比较，以确定偏差是否处于临界值区间内或是否有必要采取纠正或预防措施。
          • 趋势分析
            • 趋势分析旨在审查项目绩效随时间的变化情况，以判断绩效是正在改善还是正在恶化。确定偏离范围基准的原因和程度，并决定是否需要采取纠正或预防措施，是项目范围控制的重要工作。
      • 输出
        • 工作绩效信息
          • 本过程产生的工作绩效信息是有关项目和产品范围实施情况（对照范围基准）的、相互关联且与各种背景相结合的信息，包括收到的变更的分类、识别的范围偏差和原因、偏差对进度和成本的影响，以及对将来范围绩效的预测。
        • 变更请求
          • 分析项目绩效后，可能会就范围基准和进度基准，或项目管理计划的其他组成部分提出变更请求。变更请求需要经过实施整体变更控制过程的审查和处理。
        • 项目管理计划更新
          • 范围管理计划
          • 范围基准
          • 进度基准
          • 成本基准
          • 绩效测量基准
        • 项目文件更新
          • 经验教训登记册
          • 需求文件
          • 需求跟踪矩阵
• 项目进度管理
  • 概述说明
  • 规划进度管理
    • 规划进度管理是为规划、编制、管理、执行和控制项目进度而制定政策、程序和文档的过程。本过程的主要作用是，为如何在整个项目期间管理项目进度提供指南和方向。
    • ITTO
      • 输入
        • 项目章程
          • 项目章程中规定的总体里程碑进度计划会影响项目的进度管理。
        • 项目管理计划
          • 范围管理计划
            • 范围管理计划描述如何定义和制定范范围，并提供有关如何制定进度计划的信息。
          • 开发方法
            • 产品开发方法有助于定义进度计划方法、估算技术、进度计划编制工具以及用来控制进度的技术。
        • 事业环境因素
        • 组织过程资产
      • 工具与技术
        • 专家判断
          • 应征求具备专业知识或在以往类似项目中接受过相关培训的个人或小组的意见
            • 进度计划的编制、管理和控制
            • 进度计划方法(如预测型或适应型生命周期)
            • 进度计划软件
            • 项目所在的特定行业
        • 数据分析
          • 适用于本过程的数据分析技术包括(但不限于)备选方案分析。备选方案分析可包括确定采用哪些进度计划方法，以及如何将不同方法整合到项目中；此外，它还可以包括确定进度计划的详细程度、滚动式规划的持续时间，以及审查和更新频率。管理进度所需的计划详细程度与更新计划所需的时间量之间的平衡，应针对各个项目具体而言。
        • 会议
          • 项目团队可能举行规划会议来制定进度管理计划。参会人员可能包括项目经理、项目发起人、选定的项目团队成员、选定的相关方、进度计划或执行负责人，以及其他必要人员。
      • 输出
        • 进度管理计划
          • 项目进度模型制定
            • 需要规定用于制定项目进度模型的进度规划方法论和工具。
          • 进度计划的发布和迭代长度
            • 使用适应型生命周期时，应指定固定时间的发布时段、阶段和迭代固定时间段指项目团队稳定地朝着目标前进的持续时间，它可以推动团队先处理基本功能，然后在时间允许的情况下再处理其他功能，从而尽可能减少范围蔓延。
          • 准确度
            • 活动及项目的工期估算应该准确到什么程度，允许有多大的误差。
          • 计量单位
          • 组织程序链接
            • 项目的进度管理应该如何与执行组织的管理系统衔接。
          • 项目进度模型维护
            • 需要规定在项目执行期间，将如何在进度模型中更新项目状态，记录项目进展。
          • 控制临界值
            • 可能需要规定偏差临界值，用于监督进度绩效。它是在需要采取某种措施前，允许出现的最大差异。临界值通常用偏离基准计划中的参数的某个百分数来表示。
          • 绩效测量规则
            • 需要规定用于绩效测量的挣值管理(EVM) 规则或其他测量规则。例如， 进度管理理计划可能规定：确定完成百分比的规则； EVM技术，进度绩效测量指标， 如进度偏差(SV) 和进度绩效指数(SPI) ， 用来评价偏离原始进度基准的程度。
          • 报告格式
            • 需要规定各种进度报告的格式和编制频率。
  • 定义活动
    • 定义活动是识别和记录为完成项目可交付成果而须采取的具体行动的过程。本过程的主要作用是，将工作包分解为进度活动，作为对项目工作进行进度估算、规划、执行、监督和控制的基础。
    • ITTO
      • 输入
        • 项目管理计划
          • 进度管理计划
            • 进度管理计划定义进度计划方法、滚动式规划的持续时间，以及管理工作所需的详细程度。
          • 范围基准
            • 在定义活动时，需明确考虑范围基准中的项目WBS、可交付成果、制约因素和假设条件。
        • 事业环境因素
        • 组织过程资产
      • 工具与技术
        • 专家判断
        • 分解
          • 分解是一种把项目范围和项目可交付成果逐步划分为更小、更便于管理的组成部分的技术。活动表示完成工作包所需的投入。定义活动过程的最终输出是活动而不是可交付成果，可交付成果是创建WBS过程的输出。
          • WBS、WBS词典和活动清单可依次或同时编制，其中WBS和WBS词典是制定最终活动清单的基础。WBS中的每个工作包都需分解成活动，以便通过这些活动来完成相应的可交付成果。让团队成员参与分解过程，有助于得到更好、更准确的结果。
        • 滚动式规划
          • 滚动式规划是一种迭代式的规划技术，即详细规划近期要完成的工作，同时在较高层级上粗略规划远期工作。它是一种渐进明细的规划方式，适用于工作包、规划包以及采用敏捷或瀑布式方法的发布规划。因此，在项目生命周期的不同阶段，工作的详细程度会有所不同。在早期的战略规划阶段，信息尚不够明确，工作包只能分解到已知的详细水平；而后，随着了解到更多的信息，近期即将实施的工作包就可以分解到具体的活动。
        • 会议
      • 输出
        • 活动清单
          • 活动清单包含项目所需的进度活动。对于使用滚动式规划或敏捷技术的项目，活动清单会在项目进展过程中得到定期更新。活动清单包括每个活动的标识及工作范围详述，使项目团队成员知道需要完成什么工作。
        • 活动属性
          • 活动属性是指每项活动所具有的多重属性，用来扩充对活动的描述，活动属性随时间演进。在项目初始阶段，活动属性包括唯一活动标识（ID）、WBS标识和活动标签或名称；在活动属性编制完成时，活动属性可能包括活动描述、紧前活动、紧后活动、逻辑关系、提前量和滞后量、资源需求、强制日期、制约因素和假设条件。活动属性可用于识别开展工作的地点、编制开展活动的项目日历，以及相关的活动类型。活动属性还可用于编制进度计划。根据活动属性，可在报告中以各种方式对计划进度活动进行选择、排序和分类。
        • 里程碑清单
          • 里程碑是项目中的重要时点或事件，里程碑清单列出了所有项目里程碑，并指明每个里程碑是强制性的（如合同要求的）还是选择性的（如根据历史信息确定的）。里程碑的持续时间为零，因为它们代表的是一个重要时间点或事件。
        • 变更请求
        • 项目管理计划更新
          • 进度基准
          • 成本基准
  • 排列活动顺序
    • 排列活动顺序是识别和记录项目活动之间的关系的过程，本过程的主要作用是定义工作之间的逻辑顺序，以便在既定的所有项目制约因素下获得最高的效率。
    • ITTO
      • 输入
        • 项目管理计划
          • 进度管理计划
          • 范围基准
        • 项目文件
          • 活动属性
            • 活动属性中可能描述了事件之间的必然顺序或确定的紧前或紧后关系，以及定义的提前量与滞后量，和活动之间的逻辑关系。
          • 活动清单
            • 活动清单列出了项目所需的、待排序的全部进度活动，这些活动的依赖关系和其他制约因素会对活动排序产生影响。
          • 假设日志
            • 假设日志所记录的假设条件和制约因素可能影响活动排序的方式、活动之间的关系，以及对提前量和滞后量的需求，并且有可能生成一个会影响项目进度的风险。
          • 里程碑清单
            • 里程碑清单中可能已经列出特定里程碑的实现日期，这可能影响活动排序的方式。
        • 事业环境因素
        • 组织过程资产
      • 工具与技术
        • 紧前关系绘图法
          • 紧前关系绘图法（PDM）是创建进度模型的一种技术，用节点表示活动，用一种或多种逻辑关系连接活动，以显示活动的实施顺序。
          • PDM包括四种依赖关系或逻辑关系。紧前活动是在进度计划的逻辑路径中，排在非开始活动前面的活动。紧后活动是在进度计划的逻辑路径中，排在某个活动后面的活动。
          • PDM关系
            • 完成到开始（FS）
              • 只有紧前活动完成，紧后活动才能开始的逻辑关系。例如，只有完成装配PC硬件（紧前活动），才能开始在PC上安装操作系统（紧后活动）
            • 完成到完成（FF）
              • 只有紧前活动完成，紧后活动才能完成的逻辑关系。例如，只有完成文件的编写（紧前活动），才能完成文件的编辑（紧后活动）
            • 开始到开始（SS）
              • 只有紧前活动开始，紧后活动才能开始的逻辑关系。例如，开始地基浇灌（紧前活动）之后，才能开始混凝土的找平（紧后活动）
            • 开始到完成（SF）
              • 只有紧前活动开始，紧后活动才能完成的逻辑关系。例如，只有启动新的应付账款系统（紧前活动），才能关闭旧的应付账款系统（紧后活动）
        • 确定和整合依赖关系
          • 强制性依赖关系
            • 强制性依赖关系是法律或合同要求的或工作乍的内在性质决定的依赖关系，强制性依赖关系往往与客观限制有关。例如，在建筑项目中，只有在地基建成后，才能建立地面结构；在电子项目中，必须先把原型制造出来，然后才能对其进行测试。强制性依赖关系又称硬逻辑关系或硬依赖关系，技术依赖关系可能不是强制性的在活动排序过程中，项目团队应明确哪些关系是强制性依赖关系，不应把强制性依赖关系和进度计划编制工具中的进度制约因素相混淆。
          • 选择性依赖关系
            • 选择性依赖关系有时又称首选逻辑关系、优优先逻辑关系或软逻辑关系。即便还有其他依赖关系可用，选择性依赖关系应基于具体应用领域的最佳实践或项目的某些特殊性质对活动顺序的要求来创建。例如，根据普遍公认的最佳实践在建造期间，应先完成卫生管道工程，才能开始电气工程。这个顺序并不是强制性要求，两个工程可以同时（并行）开展工作，但如按先后顺序进行可以降低整体项目风险。应该对选择性依赖关系进行全面记录，因为它们会影响总浮动时间，并限制后续的进度安排。如果打算进行快速跟进，则应当审查相应的选择性依赖关系，并考虑是否需要调整或去除。在排列活动顺序过程中，项目团队应明确哪些依赖关系属于选择性依赖关系。
          • 外部依赖关系
            • 外部依赖关系是项目活动与非项目活动之间的依赖关系，这些依赖关系往往不在项目团队的控制范围内。例如，软件项目的测试活动取决于外部硬件的到货；建筑项目的现场准备，可能要在政府的环境听证会之后才能开始。在排列活动顺序过程中，项目管理团队应明确哪些依赖关系属于外部依赖关系。
          • 内部依赖关系
            • 内部依赖关系是项目活动之间的紧前关系，通常在项目团队的控制之中。例如，只有机器组装完毕，团队才能对其测试，这是一个内部的强制性依赖关系。在排列活动顺序过程中，项目管理团队应明确哪些依赖关系属于内部依赖关系。
        • 提前量和滞后量
        • 项目管理信息系统
      • 输出
        • 项目进度网络图
          • 带汇聚和分支的活动受到多个活动的影响或能够影响多个活动，因此存在更大的风险。I活动被称为“路径汇聚””，因为它拥有多个紧前活动，而K活动被称为“路径分支”，因为它拥有多个紧后活动。
        • 项目文件更新
          • 活动属性
          • 活动清单
          • 假设日志
          • 里程碑清单
  • 估算活动持续时间
    • 估算活动持续时间是根据资源估算的结果，估算完成单项活动所需工作时段数的过程。本过程的主要作用是，确定完成每个活动所需花费的时间量。
    • 估算活动持续时间依据的信息包括：工作范围、所需资源类型与技能水平、估算的资源数量和资源日历，而可能影响持续时间估算的其他因素包括对持续时间受到的约束、相关人力投入、资源类型（如固定持续时间、固定人力投入或工作、固定资源数量）以及所采用的进度网络分析技术。应该由项目团队中最熟悉具体活动的个人或小组提供持续时间估算所需的各种输入，对持续时间的估算也应该渐进明细，取决于输入数据的数量和质量。例如，在工程与设计项目中，随着数据越来越详细，越来越准确，持续时间估算的准确性和质量也会越来越高。
    • 在本过程中，应该首先估算出完成活动所需的工作量和计划投入该活动的资源数量，然后结合项目日历和资源日历，据此估算出完成活动所需的工作时段数（活动持续时间）。在许多情况下，预计可用的资源数量以及这些资源的技能熟练程度可能会决定活动的持续时间，更改分配到活动的主导性资源通常会影响持续时间，但这不是简单的“直线”或线性关系。有时候，因为工作的特性（即受到持续时间的约束、相关人力投入或资源数量），无论资源分配如何（如24小时应力测试），都需要花预定的时间才能完成工作。
    • 估算持续时间时需要考虑的其他因素
      • 收益递减规律
        • 在保持其他因素不变的情况下，增加一个用于确定单位产出所需投入的因素（如资源）会最终达到一个临界点，在该点之后的产出或输出会随着增加这个因素而递减。
      • 资源数量
        • 增加资源数量，使其达到初始数量的两倍不一定能缩短一半的时间，因为这样做可能会因风险而造成持续时间增加；在某些情况下，如果增加太多活动资源，可能会因知识传递、学习曲线、额外合作等其他相关因素而造成持续时间增加。
      • 技术进步
        • 在确定持续时间估算时，这个因素也可能发挥重要作用。例如，通过采购最新技术，制造工厂可以提高产量，而这可能会影响持续时间和资源需求。
      • 员工激励
        • 项目经理还需要了解“学生综合征”（即拖延症）和帕金森定律，前者指出，人们只有在最后一刻，即快到期限时才会全力以赴；后者指出，只要还有时间，工作就会不断扩展，直到用完所有的时间。
    • 应该把活动持续时间估算所依据的全部数据与假设都记录在案。
    • ITTO
      • 输入
        • 项目管理计划
          • 进度管理计划
          • 范围基准
        • 项目文件
          • 活动属性
          • 活动清单
          • 假设日志
          • 经验教训登记册
          • 里程碑清单
          • 项目团队派工单
            • 将合适的人员分派到团队，为项目配备人员。
          • 资源分解结构
            • 资源分解结构按照资源类别和资源类型，提供了已识别资源的层级结构。
          • 资源日历
            • 资源日历中的资源可用性、资源类型和资源性质，都会影响进度活动的持续时间。资源日历规定了在项目期间特定的项目资源何时可用及可用多久。
          • 资源需求
            • 估算的活动资源需求会对活动持续时间产生影响。对于大多数活动来说，所分配的资源能否达到要求，将对其持续时间有显著影响。例如，向某个活动新增资源或分配低技能资源，就需要增加沟通、培训和协调工作，从而可能导致活动效率或生产率下降，由此需要估算更长的持续时间。
          • 风险登记册
            • 单个项目风险可能影响资源的选择和可用性。风险登记册的更新包括在项目文件更新中
        • 事业环境因素
        • 组织过程资产
      • 工具与技术
        • 专家判断
        • 类比估算
          • 类比估算是一种使用相似活动或项目的历史数据，来估算当前活动或项目的持续时间或成本的技术。类比估算以过去类似项目的参数值（如持续时间、预算、规模、重量和复杂性等）为基础，来估算未来项目的同类参数或指标。在估算持续时间时，类比估算技术以过去类似项目的实际持续时间为依据，来估算当前项目的持续时间。这是一种粗略的估算方法，有时需要根据项目复杂性方面的已知差异进行调整，在项目详细信息不足时，就经常使用类比估算来估算项目持续时间。
          • 相对于其他估算技术，类比估算通常成本较低、耗时较少，但准确性也较低。类比估算可以针对整个项目或项目中的某个部分进行，或可以与其他估算方法联合使用。如果以往活动是本质上而不是表面上类似，并且从事估算的项目团队成员具备必要的专业知识，那么类比估算就最为可靠。
        • 参数估算
          • 参数估算是一种基于历史数据和项目参数，使用某种算法来计算成本或持续时间的估算技术。它是指利用历史数据之间的统计关系和其他变量（如建筑施工二中的平方英尺），来估算诸如成本、预算和持续时间等活动参数。
          • 把需要实施的工作量乘以完成单位工作量所需的工时，即可计算出持续时间。例如，对于设计项目，将图纸的张数乘以每张图纸所需的工时；或者对于电缆铺设项目，将电缆的长度乘以铺设每米电缆所需的工时。如果所用的资源每小时能够铺设25米电缆，那么铺设1000米电缆的持续时间是40小时（1000米除以25米/小时）
          • 参数估算的准确性取决于参数模型的成熟度和基础数据的可靠性。且参数进度估算可以针对整个项目或项目中的某个部分，并可以与其他估算方法联合使用。
        • 三点估算
          • 计划评审技术(PERT) ， 又名三点估算法(Program Evaluation and Review Technique)
          • 通过考虑估算中的不确定性和风险，可以提高持续时间估算的准确性。使用三点估算有助于界定活动持续时间的近似区间
            • 最可能时间（tM）。基于最可能获得的资源、最可能取得的资源生：产率、对资源可用时间的现实预计、资源对其他参与者的可能依赖关系及可能发生的各种干扰等，所估算的活动持续时间。
            • 最乐观时间（t0）。基于活动的最好情况所估算的活动持续时间。
            • 最悲观时间（tP）。基于活动的最差情况所估算的持续时间。
            • 基于持续时间在三种估算值区间内的假定分布情况，可计算期望持续时间tE。
            • 计算方式
              • 第一步：计算期望时间
                • 基于贝塔分布：te=(to+4tw+tp)/6
                • 基于三角分布：tg=(to+ty+tp)/3
              • 第二步：计算标准差
                • 标准差Sigma：o=(tp-to)/6
                • 方差：o2=[(tp-to)/6]2
          • 历史数据不充分或使用判断数据时，使用三角分布，基于三点的假定分布估算出期望持续时间，并说明期望持续时间的不确定区间。
        • 自下而上估算
          • 自下而上估算是一种估算项目持续时间或成本的方法，通过从下到上逐层汇总WBS组成部分的估算而得到项目估算。如果无法以合理的可信度对活动持续时间进行估算，则应将活动中的工作进一步细化，然后估算具体的持续时间，接着再汇总这些资源需求估算，得到每个活动的持续时间。活动之间可能存在或不存在会影响资源利用的依赖关系；如果存在，就应该对相应的资源使用方式加以说明，并记录在活动资源需求中。
        • 数据分析
          • 备选方案分析
            • 备选方案分析用于比较不同的资源能力或技能水平、进度压缩技术、不同工具（手动和自动），以及关于资源的创建、租赁和购买决策。这有助于团队权衡资源、成本和持续时间变量，以确定完成项目工作的最佳方式。
          • 储备分析
            • 应急储备是包含在进度基准中的一段持续时间，用来应对已经接受的已识别风险。应急储备与“已知一未知”风险相关，需要加以合理估算，用于完成未知的工作量。应急储备可取活动持续时间估算值的某一百分比或某一固定的时间段，亦可把应急储备从各个活动中剥离出来并汇总。随着项目信息越来越明确，可以动用、减少或取消应急储备，应该在项目进度文件中清楚地列出应急储备。
            • 也可以估算项目进度管理所需要的管理储备量。管理储备是为管理控制的目的而特别留出的项目预算，用来应对项目范围中不可预见的工作。管理储备用来应对会影响项目的“未知-未知”风险，它不包括在进度基准中，但属于项目总持续时间的一部分。依据合同条款，使用管理储备可能需要变更进度基准。
        • 决策
          • 适用于本过程的决策技术包括（但不限于）投票。举手表决是从投票方法衍生出来的一种形式，经常用于敏捷项目中。采用这种技术时，项目经理会让团队成员针对某个决定示意支持程度，举拳头表示不支持，伸五个手指表示完全支持，伸出三个以下手指的团队成员有机会与团队讨论其反对意见。项目经理会不断进行举手表决，直到整个团队达成共识（所有人都伸出三个以上手指）或同意进入下一个决定。
        • 会议
          • 项目团队可能会召开会议来估算活动持续时间。如果采用敏捷方法，则有必要举行冲刺或迭代计划会议，以讨论按优先级排序的产品未完项（用户故事），并决定团队在下一个迭代中会致力于解决哪个未完项。然后团队将用户故事分解为按小时估算的底层级任务，然后根据团队在持续时间（迭代）方面的能力确认估算可行。该会议通常在迭代的第一天举行，参会者包括产品负责人、开发团队和项目经理，会议结果包括迭代未完项、假设条件、关注事项、风险、依赖关系、决定和行动。
      • 输出
        • 持续时间估算
          • 持续时间估算是对完成某项活动、阶段或项目所需的工作时段数的定量评估，其中并不包括任何滞后量，但可指出一定的变动区间。
        • 估算依据
          • 持续时间估算所需的支持信息的数量和种类，因应用领域而异。不论其详细程度如何，支持性生文件都应该清晰、完整地说明持续时间估算是如何得出的。
          • 持续时间估算的支持信息可包括
            • 关于估算依据的文件（如估算是如何编制的）
            • 关于全部假设条件的文件
            • 关于各种已知制约因素的文件
            • 对估算区间的说明（如“±10%"），以指出预期持续时间的所在区间
            • 对最终估算的置信水平的说明
            • 有关影响估算的单个项目风险的文件
        • 项目文件更新
          • 活动属性
          • 假设日志
          • 经验教训登记册
  • 制定进度计划
    • 制定进度计划是分析活动顺序持续时间、资源需求和进度制约因素，创建进度模型，从而落实项目执行和监控的过程。本过程的主要作用是，为完成项目活动而制定具有计划日期的进度模型。
    • ITTO
      • 输入
        • 项目管理计划
          • 进度管理计划
          • 范围基准
        • 项目文件
          • 活动属性
          • 活动清单
          • 假设日志
          • 估算依据
          • 持续时间估算
          • 经验教训登记册
          • 里程碑清单
          • 项目进度网络图
          • 项目团队派工单
            • 项目团队派工单明确了分配到每个活动的资源。
          • 资源日历
            • 资源日历规定了在项目期间的资源可用性。
          • 资源需求
            • 活动资源需求明确了每个活动所需的资源类型和数量，用于创建进度模型。
          • 风险登记册
            • 风险登记册中的所有已识别的会影响进度模型的风险的详细信息及特征。进度储备则通过预期或平均风险影响程度，反映了与进度有关的风险信息。
        • 协议
          • 在制定如何执行项目工作以履行合同承诺的详细信息时，供应商为项目进度提供了输入。
        • 事业环境因素
        • 组织过程资产
      • 工具与技术
        • 进度网络分析
          • 进度网络分析是创建项目进度模型的一种综合技术，它采用了其他几种技术，例如关键路径法、资源优化技术和建模技术。
          • 其他分析包括（但不限于）
            • 当多个路径在同一时间点汇聚或分叉时，评估汇C总进度储备的必要性，以减少出现进度落后的可能性。
            • 审查网络，看看关键路径是否存在高风险活动或具有较多提前量的活动，是否需要使用进度储备或执行风险应对计划来降低关键路径的风险。
          • 进度网络分析是一个反复进行的过程，一直持续到创建出可行的进度模型。
        • 关键路径法
          • 关键路径法用于在进度模型中估算项目最短工期，确定逻辑网络路径的进度灵活性大小。这种进度网络分析技术在不考虑任何资源限制的情况下，沿进度网络路径使用顺推与逆推法，计算出所有活动的最早开始、最早结束、最晚开始和最晚法完成日期。
          • 关键路径是项目中时间最长的活动顺序，决定着可能的项目最短工期。最长路径的总浮动时间最少，通常为零。由此得到的最早和最晚的开始和结束日期并不一定就是项目进度计划，而只是把既定的参数（活动持续时间、逻辑关系、提前量、滞后量和其他已知的制约因素）输入进度模型后所得到的一种结果，表明活动可以在该时段内实施。关键路径法用来计算进度模型中的关键路径、总浮动时间和自由浮动时间，或逻辑网络路径的进度灵活性大小。
          • 在任一网络路径上，进度活动可以从最早开始日期推迟或拖延的时间，而不至于延误项目完成日期或违反进度制约因素，就是总浮动时间或进度灵活性。正常情况下，关键路径的总浮动时间为零。在进行紧前关系绘图法排序的过程中，取决于所用的制约因素，关键路径的总浮动时间可能是正值、零或负值。总浮动时间为正值，是由于逆推计算所使用的进度制约因素要晚于顺推计算所得出的最早完成日期；总浮动时间为负值，是由于持续时间和逻辑关系违反了对最晚日期的制约因素。负值浮动时间分析是一种有助于找到推动延迟的进度回到正轨的方法的技术。进度网络图可能有多条次关键路径。许多软件允许用户自行定义用于确定关键路径的参数。为了使网络路径的总浮动时间为零或正值，可能需要调整活动持续时间（可增加资源或缩减范围时）、逻辑关系（针对选择性依赖关系时）、提前量和滞后量，或其他进度制约因素。一旦计算出总浮动时间和自由浮动时间，自由浮动时间就是指在不延误任何紧后活动最早开始日期或不违反进度制约因素的前提下，某进度活动可以推迟的时间量。
          • 正推法和逆推法
            • 最早开始时间ES（指向该活动的所有紧前活动未完成前，该活动不能开始），最早完工时间EF=ES+d（活动历时），采用正推法得到。
            • 最迟完工时间LF（从该活动出发的所有紧后活动开始前，该活动必须完成），最迟开始时间LS=LF-d，采用逆推法得到。
          • 总浮时和自由浮时
            • 总时差TF=LF-EF或者LS-ES_，活动在不延误项目完成日期或违反进度制约因素的前提下，某进度活动可以推迟的总时间量（最早开始时间可以推迟的量），TF为0的路径为CP（关键路径）o
            • 自由时差FF=紧后ES-EF，活动在不延误其紧后进度活动最早开始日期的前提下，某进度活动可以推迟的时间量（最早结束时间可以延后的量）。
        • 资源优化
          • 资源平滑
            • 对进度模型中的活动进行调整，从而使项目资源需求不超过预定的资源限制的一种技术。相对于资源平衡而言，资源平滑不会改变项目关键路径，完工日期也不会延迟。也就是说，活动只在其自由和总浮动时间内延迟，但资源平滑技术可能无法实现所有资源的优化。
          • 资源平衡
            • 为了在资源需求与资源供给之间取得平衡，根据资源制约因素对开始日期和完成日期进行调整的一种技术。如果共享资源或关键资源只在特定时间可用，数量有限，或被过度分配，如一个资源在同一时段内被分配至两个或多个活动，就需要进行资源平衡。也可以为保持资源使用量处于均衡水平而进行资源平衡。资源平衡往往导致关键路径改变。因此，在项目进度计划期间，关键路径可能发生变化。
        • 数据分析
          • 假设情景分析
            • 假设情景分析是对各种情景进行评估，预测它们对项目目标的影响（积极或消极的）。假设情景分析就是对“如果情景X出现，情况会怎样?”这样的问题进行分析，即基于已有的进度计划，考虑各种各样的情景。例如，推迟某主要部件的交货日期，延长某设计工作的时间，或加入外部因素（如罢工或许可证申请流程变化等）可以根据假设情景分析的结果，评估项目进度计划在不同条件下的可行性，以及为应对意外情况的影响而编制进度储备和应对计划。
          • 模拟
            • 模拟是把单个项目风险和不确定性的其他来源模型化的方法，以评估它们对项目目标的潜在影响。最常见的模拟技术是蒙特卡罗分析，它利用风险和其他不确定资源计算整个项目可能的进度结果。模拟包括基于多种不同的活动假设、制约因素、风险、问题或情景，使用概率分布和不确定性的其他表现形式，来计算出多种可能的工作包持续时间。
        • 提前量和滞后量
        • 进度压缩
          • 进度压缩技术是指在不缩减项目范围的前提下，缩短或加快进度工期，以满足进度制约因素、强制日期或其他进度目标。负值浮动时间分析是一种有用的技术。关键路径是浮动时间最少的方法。在违反制约因素或强制日期时，总浮动时间可能变成负值。
          • • 赶工
              • 通过增加资源，以最小的成本代价来压缩进度工期的一种技术。赶工的例子包括：批准加班、增加额外资源或支付加急费用，来加快关键路径上的活动。赶工只适用于那些通过增加资源就能缩短持续时间的，且位于关键路径上的活动。但赶工并非总是切实可行的，因它可能导致风险和/或成本的增加。
            • 快速跟进
              • 一种进度压缩技术，将正常情况下按顺序进行的活动或阶段改为至少是部分并行开展。例如，在大楼的建筑图纸尚未全部完成前就开始建地基。快速跟进可能造成返工和风险增加，所以它只适用于能够通过并行活动来缩短关键路径上的项目工期的情况。以防进度加快而使用提前量通常增加相关活动之间的协调工作，并增加质量风险。快速跟进还有可能增加项目成本。
        • 项目管理信息系统
        • 敏捷发布规划
      • 输出
        • 进度基准
          • 进度基准是经过批准的进度模型，只有通过正式的变更控制程序才能进行变更，用作与实际结果进行比较的依据。经相关方接受和批准，进度基准包含基准开始日期和基准结束日期。在监控过程中，将用实际开始和完成日期与批准的基准日期进行比较，以确定是否存在偏差。进度基准是项目管理计划的组成部分。
        • 项目进度计划
          • 工作进展是通过截止日期或状态日期表示的。针对一个简单的项目，进度计划的三种形式：（1）里程碑进度计划，也叫里程碑图；（2）概括性进度计划，也叫横道图；（3）详细进度计划，也叫项目进度关联横道图。
        • 进度数据
          • 项目进度模型中的进度数据是用以描述和控制进度计划的信息集合。进度数据至少包括进度里程碑、进度活动、活动属性，以及已知的全部假设条件与制约因素，而所需的其他数据因应用领域而异。
          • 经常可用作支持细节的信息包括（但不限于）
            • 按时段计列的资源需求，往往以资源直方图表示；
            • 备选的进度计划，如最好情况或最坏情况下的进度计划、经资源平衡或未经资源平衡的进度计
            • 划、有强制日期或无强制日期的进度计划；
            • 使用的进度储备。
          • 进度数据还可包括资源直方图、现金流预测，以及订购与交付进度安排等其他相关信息。
        • 项目日历
          • 在项目日历中规定可以开展进度活动的可用工作日和工作班次，它把可用于开展进度活动的时间段（按天或更小的时间单位）与不可用的时间段区分开来。在一个进度模型中，可能需要采用不止一个项目日历来编制项目进度计划，因为有些活动需要不同的工作时段。因此，可能需要对项目日历进行更新。
        • 变更请求
        • 项目管理计划更新
          • 进度管理计划
          • 成本基准
        • 项目文件更新
          • 活动属性
          • 假设日志
          • 持续时间估算
          • 经验教训登记册
          • 资源需求
          • 风险登记册
  • 控制进度
    • 控制进度是监督项目状态，以更新项目进度和管理进度基准变更的过程。本过程的主要作用是在整个项目期间保持对进度基准的维护，且需要在整个项目期间开展。
    • ITTO
      • 输入
        • 项目管理计划
          • 进度管理计划
          • 进度基准
          • 范围基准
          • 绩效测量基准
        • 项目文件
          • 经验教训登记册
            • 在项目早期获得的经验教训可以运用到后期阶段，以改进进度控制。
          • 项目日历
            • 在一个进度模型中，可能需要不止一个项目日历来预测项目进度，因为有些活动需要不同的工作时段。
          • 项目进度计划
            • 项目进度计划是最新版本的项目进度计划，其中图示了截至指定日期的更新情况、已完活动和已开始活动。
          • 资源日历
            • 资源日历显示了团队和物质资源的可用性。
          • 进度数据
            • 在控制进度过程中需要对进度数据进行审查和更新。
        • 工作绩效数据
          • 工作绩效数据包含关于项目状态的数据，例如哪些活动已经开始，它们的进展如何（如实际持续时间、剩余持续时间和实际完成百分比），哪些活动已经完成
        • 组织过程资产
      • 工具与技术
        • 数据分析
          • 挣值分析
          • 迭代燃尽图
            • 这类图用于追踪迭代未完项中尚待完成的工作。它基于迭代规划中确定的工作，分析与理想燃尽图的偏差。可使用预测趋势线来预测迭代结束时可能出现的偏差，以及在迭代期间应该采取的合理行动。在燃尽图中，先用对角线表示理想的燃尽情况，再每天画出实际剩余工作，最后基于剩余工作计算出趋势线以预测完成情况。
          • 绩效审查
            • 绩效审查是指根据进度基准，测量、对比和分析进度绩效，如实际开始和完成日期、已完成百分比，以及当前工作的剩余持续时间。
          • 趋势分析
            • 趋势分析检查项目绩效随时间的变化情况，以确定绩效是在改善还是在恶化。图形分析技术有助于理解截至目前的绩效，并与未来的绩效目标（表示为完工日期）进行对比。
          • 偏差分析
            • 偏差分析关注实际开始和完成日期与计划的偏离，实际持续时间与计划的差异，以及浮动时间的偏差。它包括确定偏离进度基准的原因与程度，评估这些偏差对未来工作的影响，以及确定是否需要采取纠正或预防措施。例如，非关键路径上的某个活动发生较长时间的延误，可能不会对整体项目进度产生影响；而某个关键或次关键活动的稍许延误，却可能需要立即采取行动。
          • 假设情景分析
            • 假设情景分析基于项目风险管理过程的输出，对各种不同的情景进行评估，促使进度模型符合项目管理计划和批准的基准。
        • 关键路径法
        • 项目管理信息系统
        • 资源优化
        • 提前量和滞后量
        • 进度压缩
      • 输出
        • 工作绩效信息
          • 工作绩效信息包括与进度基准相比较的项目工作执行情况。可以在工作包层级和控制账户层级，计算开始和完成日期的偏差以及持续时间的偏差。对于使用挣值分析的项目，进步偏差（SV）和进度绩效指数（SP）将记录在工作绩效报告中。
        • 进度预测
          • 进度更新即进度预测，指根据已有的信息和知识，对项目未来的情况和事件进行的估算或预计。随着项目执行，应该基于工作绩效信息，更新和重新发布预测。这些信息基于项目的过去绩效，并取决于纠正或预防措施所期望的未来绩效，可能包括挣值绩效指数，以及可能在未来对项目造成影响的进度储备信息。
        • 变更请求
        • 项目管理计划更新
          • 进度管理计划
          • 进度基准
          • 成本基准
          • 绩效测量基准
        • 项目文件更新
          • 假设日志
          • 估算依据
          • 经验教训登记册
          • 项目进度计划
          • 资源日历
          • 风险登记册
          • 进度数据
• 项目成本管理
  • 概述说明
  • 规划成本管理
    • 规划成本管理是确定如何估算、预算、管理、监督和控制项目成本的过程。本过程的主要作用是，在整个项目期间为如何管理项目成本提供指南和方向。
    • ITTO
      • 输入
        • 项目章程
        • 项目管理计划
          • 进度管理计划
          • 风险管理计划
        • 事业环境因素
        • 组织过程资产
      • 工具与技术
        • 专家判断
        • 数据分析
        • 会议
      • 输出
        • 成本管理计划
          • 成本管理计划是项目管理计划的组成部分，描述将如何规划、安排和控制项目成本。成本管理过程及其工具与技术应记录在成本管理计划中。
          • 需要在成本管理计划中规定的内容
            • 计量单位
              • 需要规定每种资源的计量单位，例如用于测量时间的人时数、人天数或周数，用于计量数量的米、升、吨、千米或立方码，或者用货币表示的总价。
            • 精确度
              • 根据活动范围和项目规模，设定成本估算向上或向下取整的程度（例如995.59美元取整为1，000美元）
            • 准确度
              • 为活动成本估算规定一个可接受的区间（如±10%），其中可能包括一定数量的应急储备。
          • 组织程序链接
            • 工作分解结构为成本管理计划提供了框架，以便据此规范地开展成本估算、预算和控制。在项目成本核算中使用的WBS组成部分，称为控制账户（CA），每个控制账户都有唯一的编码或账号，直接与执行组织的会计制度相联系。
          • 控制临界值
            • 可能需要规定偏差临界值，用于监督成本绩效。它是在需要采取某种措施前，允许出现的最大差异，通常用偏离基准计划的百分数来表示。
          • 绩效测量规则
            • 需要规定用于绩效测量的挣值管理（EVM）规则。例如，成本管理计划应该：定义WBS中用于绩效测量的控制账户；确定拟用的EVM技术（如加权里程碑法、固定公式法、完成百分比法等）；规定跟踪方法，以及用于计算项目完工估算（EAC）的EVM公式，该公式计算出的结果可用于验证通过自下而上方法得出的完工估算。
          • 报告格式
            • 需要规定各种成本报告的格式和编制频率。
          • 其他细节
            • 关于成本管理活动的其他细节包括（但不限于）：对战略筹资方案的说明；处理汇率波动的程序；记录项目成本的程序。
  • 估算成本
    • 估算成本是对完成项目工作所需资源成本进行近似估算的过程。本过程的主要作用是，确定项目所需的资金。
    • 估算成本的原则
      • 成本估算是对完成活动所需资源可能成本的量化评估；
      • 估算应该由最熟悉活动或工作包的人来进行；
      • 通常用某种货币单位（如美元、欧元、日元等）进行成本估算，但有时也可采用其他计量单位，如人时数或人天数，以消除通货膨胀的影响，便于成本比较。估算时需要识别和分析备选成本方案；
      • 在启动阶段可得出项目的粗略量级估算（Rough Order of Magnitude，ROM），其区间为-25%到+75%；之后，随着信息越来越详细，确定性估算的区间可缩小至-5%到+10%；
      • 估算的额度务必附上相应的估算依据。
    • ITTO
      • 输入
        • 项目管理计划
          • 成本管理计划
          • 质量管理计划
          • 范围基准
        • 项目文件
          • 经验教训登记册
            • 项目早期与制定成本估算有关的经验教训可以运用到项目后期阶段，以提高成本估算的准确度和精确度。
          • 项目进度计划
            • 进度计划包括项目可用的团队和实物资源的类型、数量和可用时间长短。如果资源成本取决于使用时间的长短，并且成本出现季节波动，则持续时间估算会对成本估算产生影响。进度计划还为包含融资成本（包括利息）的项目提供有用信息。
          • 资源需求
            • 资源需求明确了每个工作包或活动所需的资源类型和数量。
          • 风险登记册
            • 风险登记册包含了已识别并按优先顺序排列的单个项目风险的详细信息，及针对这些风险采取的应对措施。风险登记册还提供了可用于估算成本的详细信息。
        • 事业环境因素
        • 组织过程资产
      • 工具与技术
        • 专家判断
        • 类比估算
        • 参数估算
        • 自下而上估算
        • 三点估算
        • 数据分析
          • 备选方案分析
            • 备选方案分析是一种对已识别的可选方案进行评估的技术，用来决定选择哪种方案或使用何种方法来执行项目工作。例如评估购买和制造可交付成果分别对成本、进度、资源和质量的影响。
          • 储备分析
            • 为应对成本的不确定性，成本估算中可以包括应急储备（有时称为“应急费用”应急储备是包含在成本基准内的一部分预算，用来应对已识别的风险；应急储备还通常是预算的一部分，用来应对那些会影响项目的“已知-未知”风险。例如，可以预知有些项目可交付成果需要返工，却不知道返工的工作量是多少。可以预留应急储备来应对这些未知数量的返工工作。小至某个具体活动，大到整个项目，任何层级都可有其应急储备。应急储备可取成本估算值的某一百分比、某个固定值，或者通过定量分析来确定；
            • 而随着项目信息越来越明确，可以动用、减少或取消应急储备。应该在成本文件中清楚地列出应急储备。应急储备是成本基准的一部分，也是项目整体资金需求的一部分。
          • 质量成本
        • 项目管理信息系统
        • 决策
          • 投票
      • 输出
        • 成本估算
          • 成本估算包括对完成项目工作可能需要的成本、应对已识别风险的应急储备，以及应对计划外工作的管理储备的量化估算。成本估算可以是汇总的或详细分列的。成本估算应覆盖项目所使用的全部资源，包括（但不限于）直接人工、材料、设备、服务、设施、信息技术，以及一些特殊的成本种类，如融资成本（包括利息）、通货膨胀补贴、汇率或成本应急储备。如果间接成本也包含在项目估算中，则可在活动层次或更高层次上计列间接成本。
        • 估算依据
          • 成本估算所需的支持信息的数量和种类，因应用领域而异，不论其详细程度如何，支持性文件都应该清晰、完整地说明成本估算是如何得出的。
          • 成本估算的支持信息可包括
            • 关于估算依据的文件（如估算是如何编制的）；
            • 关于全部假设条件的文件；
            • 关于各种已知制约因素的文件；有关已识别的、在估算成本时应考虑的风险的文件；
            • 对估算区间的说明（如“10，000美元±10%”就说明了预期成本的所在区间）；
            • 对最终估算的置信水平的说明。
        • 项目文件更新
          • 假设日志
          • 经验教训登记册
          • 风险登记册
  • 制定预算
    • 制定预算是汇总所有单个活动或工作包的估算成本，建立一个经批准的成本基准的过程。本过程的主要作用是，确定可据以监督和控制项目绩效的成本基准。
    • 项目预算包括经批准用于执行项目的全部资金，而成本基准是经过批准且按时间段分配的项目预算，包括应急储备，但不包括管理储备。
    • ITTO
      • 输入
        • 项目管理计划
          • 成本管理计划
          • 资源管理计划
          • 范围基准
        • 项目文件
          • 估算依据
            • 在估算依据中包括基本的假设条件，例如，项目预算中是否应该包含间接成本或其他成本。
          • 成本估算
            • 各工作包内每个活动的成本估算汇总后，即得到各工作包的成本估算。
          • 项目进度计划
            • 项目进度计划包括项目活动、里程碑、工作包和控制账户的计划开始和完成日期。可根据这些信息，把计划成本和实际成本汇总到相应的日历时段中。
          • 风险登记册
            • 应该审查风险登记册，以确定如何汇总风险应对成本。风险登记册的更新包含在项目文件更新中
        • 商业文件
          • 商业论证
            • 商业论证识别了项目成功的关键因素，包括财务成功因素。
          • 效益管理计划
            • 效益管理计划包括目标效益，例如净现值的计算、实现效益的时限，以及与效益有关的测量指标。
        • 协议
        • 事业环境因素
        • 组织过程资产
      • 工具与技术
        • 专家判断
        • 成本汇总
          • 先把成本估算汇总到WBS中的工作包，再由工作包汇总至WBS的更高层次（如控制账户），最终得出整个项目的总成本。
        • 数据分析
          • 储备分析
            • 可用于制定预算过程的数据分析技术包括（但不限于）可以建立项目管理储备的储备分析。管理储备是为了管理控制的目的而特别留出的项目预算，用来应对项目范围中不可预见的工作，目的是用来应对会影响项目的“未知-未知”风险。管理储备不包括在成本基准中，但属于项目总预算和资金需求的一部分。当动用管理储备资助不可预见的工作时，就要把动用的管理储备增加到成本基准中，从而导致成本基准变更。
        • 历史信息审核
          • 审核历史信息有助于进行参数估算或类比估算。历史信息可包括各种项目特征（参数），它们用于建立数学模型预测项目总成本。这些数学模型可以是简单的（例如，建造住房的总成本取决于单位面积建造成本），也可以是复杂的（例如，软件开发项目的成本模型中有多个变量，且每个变量又受许多因素的影响）。
        • 资金限制平衡
          • 应该根据对项目资金的任何限制，来平衡资金支出。如果发现资金限制与计划支出之间的差异，则可能需要调整工作的进度计划，以平衡资金支出水平。这可以通过在项目进度计划中添加强制日期来实现。
        • 融资
          • 融资是指为项目获取资金。长期的基础设施、工业和公共服务项目通常会寻求外部融资。如果项目使用外部资金，出资实体可能会提出一些必须满足的要求。
      • 输出
        • 成本基准
        • 项目资金需求
          • 根据成本基准，确定总资金需求和阶段性（如季度或年度）资金需求。成本基准中既包括预计支出及预计债务。项目资金通常以增量的方式投入，并且可能是非均衡的，呈现上图所示的阶梯状。如果有管理储备，则总资金需求等于成本基准加管理储备。在资金需求文件中，也可说明资金来源。
        • 项目文件更新
          • 成本估算
          • 项目进度计划
          • 风险登记册
  • 控制成本
    • 控制成本是监督项目状态，以更新项目成本和管理成本基准变更的过程。本过程的主要作用是，在整个项目期间保持对成本基准的维护。
    • 要更新预算，就需要了解截至目前的实际成本。只有经过实施整体变更控制过程的批准，才可以增加预算。只监督资金的支出，而不考虑由这些支出所完成的工作的价值，对项目没有什么意义，最多只能跟踪资金流。所以在成本控制中，应重点分析项目资金支出与相应完成的工作之间的关系。有效成本控制的关键在于管理经批准的成本基准。
    • 项目成本控制包括
      • 对造成成本基准变更的因素施加影响；
      • 确保所有变更请求都得到及时处理；
      • 当变更实际发生时，管理这些变更；
      • 确保成本支出不超过批准的资金限额， 既不超出按时段、按WBS
      • 组件、按活动分配的限额，
      • 也不超出项目总限额；
      • 监督成本绩效，找出并分析与成本基准间的偏差；
      • 对照资金支出，监督工作绩效；
      • 防止在成本或资源使用报告中出现未经批准的变更；
      • 向相关方报告所有经批准的变更及其相关成本；
      • 设法把预期的成本超支控制在可接受的范围内。
    • ITTO
      • 输入
        • 项目管理计划
          • 成本管理计划
          • 成本基准
          • 绩效测量基准
        • 项目文件
          • 经验教训登记册
        • 项目资金需求
        • 工作绩效数据
        • 组织过程资产
      • 工具与技术
        • 专家判断
        • 数据分析
          • 挣值分析
          • 偏差分析
          • 趋势分析
          • 储备分析
            • 在控制成本过程中，可以采用储备分析来监督项目中应急储备和管理储备的使用情况，从而判断是否还需要这些储备，或者是否需要增加额外的储备。随着项目工作的进展，这些储备可能已按计划用于支付风险或其他应急情况的成本；反之，如果抓住机会节约了成本，节约下来的资金可能会增加到应急储备中，或作为盈利/利润从项目中剥离。
            • 如果已识别的风险没有发生，就可能要从项目预算中扣除未使用的应急储备，为其他项目或运营腾出资源。同时，在项目中开展进一步风险分析，可能会发现需要为项目预算申请额外的储备。
        • 完工尚需绩效指数
        • 项目管理信息系统
      • 输出
        • 工作绩效信息
        • 成本预测
        • 变更请求
        • 项目管理计划更新
          • 成本管理计划
          • 成本基准
          • 绩效测量基准
        • 项目文件更新
          • 假设日志
          • 估算依据
          • 成本估算
          • 经验教训登记册
          • 风险登记册
• 项目质量管理
  • 概述说明
    • “质量”与“等级”不是相同的概念。质量作为实现的性能或成果，是“一系列内在特性满足要求的程度”（ISO9000）【18】。等级作为设计意图，是对用途相同但技术特性不同的可交付成果的级别分类。项目经理及项目管理团队负责权衡，以便同时达到所要求的质量与等级水平。质量水平未达到质量要求肯定是个问题，而低等级产品不一定是个问题。
      • 一个低等级（功能有限）产品具备高质量（无明显缺陷），也许不是问题。该产品适合一般使用。
      • 一个高等级（功能繁多）产品质量低（有许多缺陷），也许是个问题。该产品的功能会因质量低劣而无效和/或低效。
    • 预防胜于检查。最好将质量设计到可交付成果中，而不是在检查时发现质量问题。预防错误的成本通常远低于在检查或使用中发现并纠正错误的成本。
    • 根据不同的项目和行业领域，项目团队可能需要具备统计控制过程方面的实用知识，以便评估控制质量的输出中所包含的数据。
    • 项目管理团队应了解以下术语之间的差别
      • “预防”（保证过程中不出现错误）与“检查”（保证错误不落到客户手中）；
      • “属性抽样”（结果为合格或不合格）与“变量抽样”（在连续的量表上标明结果所处的位置，表明合格的程度）
      • “公差”（结果的可接受范围）与“控制界限”（在统计意义上稳定的过程或过程绩效的普通偏差的边界）。
    • 按有效性递增排列的五种质量管理水平
      • 通常，代价最大的方法是让客户发现缺陷。这种方法可能会导致担保问题、召回、商誉受损和返工成本。
      • 控制质量过程包括先检测和纠正缺陷，再将可交付成果发送给客户。该过程会带来相关成本，主要是评估成本和内部失败成本。
      • 通过质量保证检查并纠正过程本身，而不仅仅是特殊缺陷。将质量融入项目和产品的规划和设计中。
      • 在整个组织内创建一种关注并致力于实现过程和产品质量的文化。
    • 项目质量管理的趋势和新兴实践
      • 现代质量管理方法力求缩小差异，交付满足既定相关方要求的成果
      • 项目质量管理的趋势可能包括（但不限于）
        • 客户满意
          • 了解、评估、定义和管理要求，以便满足客户的期望。这就需要把“符合要求”（确保项目产出预定的成果）和“适合使用”（产品或服务必须满足实际需求）结合起来。在敏捷环境中，相关方与项目管理团队合作可确保在整个项目期间始终做到客户满意。
        • 持续改进
          • 由休哈特提出并经戴明完善的“计划-实施-检查-行动（PDCA）”循环是质量改进的基础。另外，诸如全面质量管理（TQM）、六西格玛和精益六西格玛等质量改进举措也可以提高项目管理的质量以及最终产品、服务或成果的质量。
        • 管理层的责任
          • 项目的成功需要项目团队全体成员的参与。管理层在其质量职责内，肩负着为项目提供具有足够能力的资源的相应责任。
        • 与供应商的互利合作关系
          • 组织与其供应商相互依赖。相对传统的供应商管理而言，与供应商建立合作伙伴关系对组织和供应商都更加有益。组织应着眼于长期关系而不是短期利益。互利合作关系增强了组织和供应商互相为对方创造价值的能力，推动他们共同实现客户的需求和期望，并优化成本和资源。
    • 项目质量管理的过程之间关系
  • 规划质量管理
    • 规划质量管理是识别项目及其可交付成果的质量要求和（或）标准，并书面描述项目将如何证明符合质量要求和（或）标准的过程。本过程的主要作用是，为在整个项目期间如何管理和核实质量提供指南和方向。
    • ITTO
      • 输入
        • 项目章程
        • 项目管理计划
          • 需求管理计划
          • 风险管理计划
          • 相关方参与计划
          • 范围基准
            • 在确定适用于项目的质量标准和目标时，以及在确定要求质量审查的项目可交付成果和过程时，需要考虑WBS和项目范围说明书中记录的可交付成果。范围说明书包含可交付成果的验收标准。该标准的界定可能导致质量成本并进而导致项目成本的显著升高或降低。满足所有的验收标准意味着满足相关方的需求。
        • 项目文件
          • 假设日志
          • 需求文件
            • 需求文件记录项目和产品为满足相关方的期望应达到的要求，它包括（但不限于）针对项目和产品的质量要求。这些需求有助于项目团队规划将如何实施项目质量控制。
          • 需求跟踪矩阵
            • 需求跟踪矩阵将产品需求连接到可交付成果，有助于确保需求文件中的各项需求都得到测试。矩阵提供了核实需求时所需测试的概述。
          • 风险登记册
          • 相关方登记册
        • 事业环境因素
        • 组织过程资产
      • 工具与技术
        • 专家判断
        • 数据收集
          • 标杆对照
          • 头脑风暴
          • 访谈
        • 数据分析
          • 成本效益分析
            • 成本效益分析是用来估算备选方案优势和劣势的财务分析工具，以确定可以创造最佳效益的备选方案。成本效益分析可帮助项目经理确定规划的质量活动是否有效利用了成本。达到质量要求的主要效益包括减少返工、提高生产率、降低成本、提升相关方满意度及提升赢利能力。对每个质量活动进行成本效益分析，就是要比较其可能成本与预期效益。
          • 质量成本
            • 与项目有关的质量成本（COQ）包含以下一种或多种成本
              • 预防成本
                • 预防特定项目的产品、可交付成果或服务质量低劣所带来的相关成本。
              • 评估成本
                • 评估、测量、审计和测试特定项目的产品、可交付成果或服务所带来的相关成本。
              • 失败成本（内部/外部）
                • 因产品、可交付成果或服务与相关方需求或期望不一致而导致的相关成本。
            • 最优COQ能够在预防成本和评估成本之间找到恰当的投资平衡点，以规避失败成本。有关模型表明，最优项目质量成本，指在投资额外的预防/评估成本时，既无益处又不具备成本效益。
        • 决策
          • 多标准决策分析
        • 数据表现
          • 流程图
            • 流程图，也称过程图，用来显示在一个或多个输入转化成一个或多个输出的过程中，所需要的步骤顺序和可能分支。它通过映射水平价值链的过程细节来显示活动、决策点、分支循环、并行路径及整体处理顺序。
              • 图中展示了其中一个版本的价值链，即SIPOC（供应商、输入、过程、输出和客户）模型。
            • 流程图可能有助于了解和估算一个过程的质量成本。通过工作流的逻辑分支及其相对频率来估算质量成本。这些逻辑分支细分为完成符合要求的输出而需要开展的一致性工作和非一致性工作。用于展示过程步骤时，流程图有时又被称为“过程流程图”或“过程流向图”，可帮助改进过程并识别可能出现质量缺陷或可以纳入质量检查的地方。
          • 逻辑数据模型
            • 逻辑数据模型把组织数据可视化，以商业语言加以描述，不依赖任何特定技术。逻辑数据模型可用于识别会出现数据完整性或其他质量问题的地方。
          • 矩阵图
            • 矩阵图在行列交叉的位置展示因素、原因和目标之间的关系强弱。根据可用来比较因素的数量，项目经理可使用不同形状的矩阵图，如L型、T型、Y型、X型、C型和屋顶型矩阵。在本过程中，它们有助于识别对项目成功至关重要的质量测量指标。
          • 思维导图
        • 测试与检查的规划
          • 在规划阶段，项目经理和项目团队决定如何测试或检查产品、可交付成果或服务，以满足相关方的需求和期望，以及如何满足产品的绩效和可靠性目标。不同行业有不同的测试与检查，可能包括软件项目的α测试和β测试、建筑项目的强度测试、制造和实地测试的检查，以及工程的无损伤测试。
        • 会议
      • 输出
        • 质量管理计划
          • 质量管理计划是项目管理计划的组成部分，描述如何实施适用的政策、程序和指南以实现质量目标。它描述了项目管理团队为实现一系列项目质量目标所需的活动和资源。质量管理计划可以是正式或非正式的，非常详细或高度概括的，其风格与详细程度取决于项目的具体需要。应该在项目早期就对质量管理计划进行评审，以确保决策是基于准确信息的。这样做的好处是，更加关注项目的价值定位，降低因返工而造成的成本超支金额和进度延误次数。
          • 质量管理计划包括（但不限于）的组成部分
            • 项目采用的质量标准
            • 项目的质量目标
            • 质量角色与职责
            • 需要质量审查的项目可交付成果和过程
            • 为项目规划的质量控制和质量管理活动
            • 项目使用的质量工具
            • 与项目有关的主要程序，例如处理不符合要求的情况、纠正措施画程序，以及持续改进程序。
        • 质量测量指标
          • 质量测量指标专用于描述项目或产品属性，以及控制质量过程将如何验证符合程度。质量测量指标的例子包括按时完成的任务的百分比、以CPI测量的成本绩效、故障率、识别的日缺陷数量、每月总停机时间、每个代码行的错误、客户满意度分数，以及测试计划所涵盖的需求的百分比（即测试覆盖度）
        • 项目管理计划更新
          • 风险管理计划
          • 范围基准
        • 项目文件更新
          • 经验教训登记册
          • 需求跟踪矩阵
          • 风险登记册
          • 相关方登记册
  • 管理质量
    • 管理质量是把组织的质量政策用于项目，并将质量管理计划转化为可执行的质量活动的过程。
    • 本过程的主要作用是，提高实现质量目标的可能性，以及识别无效过程和导致质量低劣的原因。管理质量使用控制质量过程的数据和结果向相关方展示项目的总体质量状态。
    • 管理质量有时被称为“质量保证”，但“管理质量”的定义比“质量保证”更广，因其可用于非项目工作。在项目管理中，质量保证着眼于项目使用的过程，旨在高效地执行项目过程，包括遵守和满足标准，向相关方保证最终产品可以满足他们的需求、期望和要求。管理质量包括所有质量保证活动，还与产品设计和过程改进有关。管理质量的工作属于质量成本框架中的一致性工作。
    • 项目经理和项目团队可以通过组织的质量保证部门或其他组织职能执行某些管理质量活动，例如故障分析、实验设计和质量改进。质量保证部门在质量工具和技术的使用方面通常拥有跨组织经验，是良好的项目资源。
    • 管理质量被认为是所有人的共同职责，包括项目经理、项目团队、项目发起人、执行组织的管理层，甚至是客户。所有人在管理项目质量方面都扮演一定的角色，尽管这些角色的人数和工作量不同。参与质量管理工作的程度取决于所在行业和项目管理风格。在敏捷项目中，整个项目期间的质量管理由所有团队成员执行；但在传统项目中，质量管理通常是特定团队成员的职责。
    • ITTO
      • 输入
        • 项目管理计划
          • 质量管理计划
        • 项目文件
          • 经验教训登记册
            • 项目早期与质量管理有关的经验教训，可以运用到项目后期阶段，以提高质量管理的效率与效果。
          • 质量控制测量结果
            • 质量控制测量结果用于分析和评估项目过程和可交付成果的质量是否符合执行组织的标准或特定要求。质量控制测量结果也有助于分析这些测量结果的产生过程，以确定实际测量结果的正确程度。
          • 质量测量指标
            • 核实质量测量指标是控制质量过程的一个环节。管理质量过程依据这些质量测量指标设定项目的测试场景和可交付成果，用作改进举措的依据。
          • 风险报告
            • 管理质量过程使用风险报告识别整体项目风险的来源以及整体风险敞口的最重要的驱动因素，这些因素能够影响项目的质量目标。
        • 组织过程资产
      • 工具与技术
        • 数据收集
          • 核对单
            • 适用于本过程的数据收集技术包括（但不限于）核对单。核对单是一种结构化工具，通常列出特定组成部分，用来核实所要求的一系列步骤是否已得到执行或检查需求列表是否已得到满足。基于项目需求和实践，核对单可简可繁。许多组织都有标准化的核对单，用来规范地执行经常性任务。在某些应用领域，核对单也可从专业协会或商业性服务机构获取。质量核对单应该涵盖在范围基准中定义的验收标准。
        • 数据分析
          • 备选方案分析
            • 该技术用于评估已识别的可选方案，以选择那些最合适的质量方案或方法。
          • 文件分析
            • 分析项目控制过程所输出的不同文件，如质量报告、测试报告、绩效报告和偏差分析，可以重点指出可能超出控制范围之外并阻碍项目团队满足特定要求或相关方期望的过程。
          • 过程分析
            • 过程分析可以识别过程改进机会，同时检查在过程期间遇到的问题、制约因素，以及非增值活动。
          • 根本原因分析
            • 根本原因分析（RCA）是确定引起偏差、缺陷或风险的根本原因的一种分析技术。一项根本原因可能引起多项偏差、缺陷或风险。根本原因分析还可以作为一项技术，用于识别问题的根本原因并解决问题。消除所有根本原因可以杜绝问题再次发生。
        • 决策
          • 多标准决策分析
        • 数据表现
          • 亲和图
            • 亲和图可以对潜在缺陷成因进行分类，展示最应关注的领域。
          • 因果图
            • 因果图，又称“鱼骨图”、“why-why分析图”和“石川图”将问题陈述的原因分解为离散的分支，有助于识别问题的主要原因或根本原因。
          • 流程图
            • 流程图展示了引发缺陷的一系列步骤。
          • 直方图
            • 直方图是一种展示数字数据的条形图，可以展示每个可交付成果的缺陷数量、缺陷成因的排列、各个过程的不合规次数，或项目或产品缺陷的其他表现形式。
          • 矩阵图
            • 矩阵图在行列交叉的位置展示因素、原因和目标之间的关系强弱。
          • 散点图
            • 散点图是种展示两个变量之间的关系的图形，它能够展示两支轴的关系，一支轴表示过程、环境或活动的任何要素，另一支轴表示质量缺陷。
          • 帕累托图
        • 审计
          • 审计是用于确定项目活动是否遵循了组织和项目的政策、过程与程序的一种结构化且独立的过程。质量审计通常由项目外部的团队开展，如组织内部审计部门、项目管理办公室（PMO）或组织外部的审计师。
          • 质量审计目标可能包括（但不限于）
            • 识别全部正在实施的良好及最佳实践
            • 识别所有违规做法、差距及不足
            • 分享所在组织和/或行业中类似项目的良好实践
            • 积极、主动地提供协助，以改进过程的执行，从而帮助团队提高生产效率；
            • 强调每次审计都应对组织经验教训知识库的积累做出贡献。
          • 采取后续措施纠正问题，可以降低质量成本，并提高发起人或客户对项目产品的接受度。质量审计可事先安排，也可随机进行；可由内部或外部审计师进行。
          • 质量审计还可确认已批准的变更请求（包括更新、纠正措施、缺陷补救和预防措施）的实施情况。
        • 面向X的设计
          • 面向X的设计（DfX）是产品设计期间可采用的一系列技术指南，旨在优化设计的特定方面，可以控制或提高产品最终特性。DfX中的“X”可以是产品开发的不同方面，例如可靠性、调配、装配、制造、成本、服务、可用性、安全性和质量。使用DfX可以降低成本、改进质量、提高绩效和客户满意度。
        • 问题解决
          • 问题解决发现解决问题或应对挑战的解决方案。它包括收集其他信息、具有批判性思维的、创造性的、量化的和/或逻辑性的解决方法。有效和系统化地解决问题是质量保证和质量改进的基本要素。问题可能在控制质量过程或质量审计中发现，也可能与过程或可交付成果有关。使用结构化的问题解决方法有助于消除问题和制定长久有效的解决方案。
          • 问题解决方法通常包括以下要素
            • 定义问题
            • 识别根本原因
            • 生成可能的解决方案
            • 选择最佳解决方案
            • 执行解决方案
            • 验证解决方案的有效性
        • 质量改进方法
          • 质量改进的开展，可基于质量控制过程的发现和建议、质量审计的发现，或管理质量过程的问题解决。计划一实施一检查一行动和六西格玛是最常用于分析和评估改进机会的两种质量改进工具。
      • 输出
        • 质量报告
          • 质量报告可能是图形、数据或定性文件，其中包含的信息可帮助其他过程和部门采取纠正措施，以实现项目质量期望。质量报告的信息可以包含团队上报的质量管理问题，针对过程、项目和产品的改善建议，纠正措施建议（包括返工、缺陷/漏洞补救、100%检查等），以及在控制质量过程中发现的情况的概述。
        • 测试与评估文件
          • 可基于行业需求和组织模板创建测试与评估文件。它们是控制质量过程的输入，用于评估质量目标的实现情况。这些文件可能包括专门的核对单和详反尽的需求跟踪矩阵。
        • 变更请求
        • 项目管理计划更新
          • 质量管理计划
          • 范围基准
          • 进度基准
          • 成本基准
        • 项目文件更新
          • 问题日志
          • 经验教训登记册
          • 风险登记册
  • 控制质量
    • 控制质量是为了评估绩效，确保项目输出完整、正确且满足客户期望，而监督和记录质量管理活动执行结果的过程。
    • 本过程的主要作用是，核实项目可交付成果和工作已经达到主要相关方的质量要求，可供最终验收。控制质量过程确定项目输出是否达到预期目的，这些输出需要满足所有适用标准、要求、法规和规范。
    • 控制质量过程的目的是在用户验收和最终交付之前测量产品或服务的完整性、合规性和适用性。本过程通过测量所有步骤、属性和变量，来核实与规划阶段所描述规范的一致性和合规性。
    • 在整个项目期间应执行质量控制，用可靠的数据来证明项目已经达到发起人和/或客户的验收标准。
    • 控制质量的努力程度和执行程度可能会因所在行业和项目管理风格而不同。例如，相比其他行业，制药、医疗、运输和核能产业可能拥有更加严格的质量控制程序，为满足标准付出的工作也会更广；在敏捷项目中，控制质量活动可能由所有团队成员在整个项目生命周期中执行，而在瀑布式项目中，控制质量活动由特定团队成员在特定时间点或者项目或阶段快结束时执行。
    • 补充：变更线
      • 变更请求
        • 预防措施
        • 纠正措施
        • 缺陷补救
        • 让现实符合计划
        • 更新
          • 让计划符合现实
      • 批准的变更请求
        • 实施整体变更控制过程
      • 实施变更请求
        • 指导与管理项目工作
        • 控制采购
      • 检查变更请求实施情况
        • 控制质量
        • 管理质量
        • 监控项目工作
    • ITTO
      • 输入
        • 项目管理计划
          • 质量管理计划
        • 质量管理计划
          • 经验教训登记册
          • 质量测量指标
            • 质量测量指标专用于描述项目或产品属性，以及控制质量过程将如何验证符合程度。
          • 测试与评估文件
            • 测试与评估文件用于评估质量目标的实现程度。
        • 批准的变更请求
          • 在实施整体变更控制过程中，通过更新变更日志，显示哪些变更已经得到批准，哪些变更没有得到批准。批准的变更请求可包括各种修正，如缺陷补救、修订的工作方法和修订的进度计划。完成局部变更时，如果步骤不完整或不正确，可能会导致不一致和延迟。批准的变更请求的实施需要核实，并需要确认完整性、正确性，以及是否重新测试。
        • 可交付成果
          • 可交付成果指的是在某一过程、阶段或项目完成时，必须产出的任何独特并可核实的产品、成果或服务能力。作为指导与管理项目工作过程的输出的可交付成果将得到检查，并与项目范围说明书定义的验收标准作比较。
        • 工作绩效数据
        • 事业环境因素
        • 组织过程资产
      • 工具与技术
        • 数据收集
          • 核对单
            • 核对单有助于以结构化方式管理控制质量活动。
          • 核查表
            • 核查表，又称计数表，用于合理排列各种事项，以便有效地收集关于潜在质量问题的有用数据。在开展检查以识别缺陷时，用核查表收集属性数据就特别方便，例如关于缺陷数量或后果的数据。
          • 统计抽样
            • 统计抽样是指从目标总体中选取部分样本用于检查（如从75张工程图纸中随机抽取10张）。样本用于测量控制和确认质量。抽样的频率和规模应在规划质量管理过程中确定。
          • 问卷调查
            • 问卷调查。问卷调查可用于在部署产品或服务之后收集关于客户满意度的数据。在问卷调查中识别的缺陷相关成本可被视为COQ模型中的外部失败成本，给组织带来的影响会超出成本本身。
        • 数据分析
          • 绩效审查
            • 绩效审查针对实际结果，测量、比较和分析规划质量管理过程中定义的质量测量指标。
          • 根本原因分析
            • 根本原因分析用于识别缺陷成因。
        • 检查
          • 检查是指检验工作产品，以确定是否符合书面标准。检查的结果通常包括相关的测量数据，可在任何层面上进行。可以检查单个活动的成果，也可以检查项目的最终产品。检查也可称为审查、同行审查、审计或巡检等，而在某些应用领域，这些术语的含义比较狭窄和具体。检查也可用于确认缺陷补救。
        • 测试/产品评估
          • 测试是一种有组织的、结构化的调查，旨在根据项目目需求提供有关被测产品或服务质量的客观信息。测试的目的是找出产品或服务中存在的错误、缺陷、漏洞或其他不合规问题。用于评估各项需求的测试的类型、数量和程度是项目质量计划的一部分，具体取决于项目的性质、时间、预算或其他制约因素。测试可以贯穿于整个项目，可以随着项目的不同组成部分变得可用时进行，也可以在项目结束（即交付最终可交付成果）时进行。早期测试有助于识别不合规问题，帮助减少修补不合规组件的成本。
        • 数据表现
          • 因果图
            • 因果图用于识别质量缺陷和错误可能造成的结果。
          • 控制图
            • 控制图用于确定一个过程是否稳定，或者是否具有可预页测的绩效。规格上限和下限是根据要求制定的，反映了可允许的最大值和最小值。上下控制界限不同于规格界限。控制界限根据标准的统计原则，通过标准的统计计算确定，代表一个稳定过程的自然波动范围。项目经理和相关方可基于计算出的控制界限，识别须采取纠正措施的检查点，以预防不在控制界限内的绩效。控制图可用于监测各种类型的输出变量。虽然控制图最常用来跟踪批量生产中的重复性活动，但也可用来监测成本与进度偏差、产量、范围变更频率或其他管理工作成果，以便帮助确定项目管理过程是否受控。
          • 直方图
            • 直方图可按来源或组成部分展示缺陷数量
          • 散点图
            • 散点图可在一支轴上展示计划的绩效，在另一支轴上展示实际绩效。
        • 会议
      • 输出
        • 质量控制测量结果
          • 控制质量的测量结果是对质量控制活动的结果的书面记录，应以质量管理计划所确定的格式加以记录。
        • 核实的可交付成果
          • 控制质量过程的一个目的就是确定可交付成果的正确性。开展控制质量过程的结果是核实的可交付成果，后者又是确认范围过程的一项输入，以便正式验收。如果存在任何与可交付成果有关的变更请求或改进事项，可能会执行变更、开展检查并重新核实。
        • 工作绩效信息
          • 工作绩效信息包含有关项目需求实现情况的信息、拒绝的原因、要求的返工、纠正措施建议、核实的可交付成果列表、质量测量指标的状态，以及过程调整需求。
        • 变更请求
        • 项目管理计划更新
          • 质量管理计划
        • 项目文件更新
          • 问题日志
          • 经验教训登记册
          • 风险登记册
          • 测试与评估文件
• 项目资源管理
  • 概述说明
  • 规划资源管理
    • 规划资源管理是定义如何估算、获取、管理和利用团队以及实物资源的过程。
    • 本过程的主要作用是，根据项目类型和复杂程度确定适用于项目资源的管理方法和管理程度。
    • 资源规划用于确定和识别一种方法，以确保项目的成功完成有足够的可用资源。项目资源可能包括团队成员、用品、材料、设备、服务和设施。有效的资源规划需要考虑稀缺资源的可用性和竞争，并编制相应的计划。
    • 这些资源可以从组织内部资产获得，或者通过采购过程从组织外部获取。其他项目可能在同一时间和地点竞争项目所需的相同资源，从而对项目成本、进度、风险、质量和其他项目领域造成显著影响。
    • ITTO
      • 输入
        • 项目章程
          • 项目章程提供项目的高层级描述和要求，此外还包括可能影响项目资源管理的关键相关方名单、里程碑概况，以及预先批准的财务资源。
        • 项目管理计划
          • 质量管理计划
          • 范围基准
        • 项目文件
          • 项目进度计划
            • 项目进度计划提供了所需资源的时间轴。
          • 需求文件
            • 需求文件指出了项目所需的资源的类型和数量，并可能影响管理资源的方式。
          • 风险登记册
            • 风险登记册包含可能影响资源规划的各种威胁和机会的信息。
          • 相关方登记册
            • 相关方登记册有助于识别对项目所需资源有特别兴趣或影响的那些相关方，以及会影响资源使用偏好的相关方。
        • 事业环境因素
        • 组织过程资产
      • 工具与技术
        • 专家判断
        • 数据表现
          • 层级型
            • 与WBS交叉，确认部门的全部项目职责。
          • 责任分配矩阵
            • 显示工作包或活动与项目团队成员之间的关系。
            • 责任分配矩阵展示项目资源在各个工作包中的任务分配。矩阵型图表的一个例子是职责分配矩阵（RAM），它显示了分配给每个工作包的项目资源，用于说明工作包或活动与项目团队成员之间的关系。在大型项目中，可以制定多个层次的RAM。例如，高层次的RAM可定义项目团队、小组或部门负责WBS中的哪部分工作，而低层次的RAM则可在各小组内为具体活动分配角色、职责和职权。矩阵图能反映与每个人相关的所有活动，以及与每项活动相关的所有人员，它也可确保任何一项任务都只有一个人负责，从而避免职权不清。RAM的一个例子是RACI（执行、负责、咨询和知情）矩阵，如图9-4所示。图中最左边的一列表示有待完成的工作（活动）。分配合每项工作的资源可以是个人或小组，项目经理也可根据项目需要，选择“领导”或“资源”等适用词汇，来分配项目责任。如果团队是由内部和外部人员组成，RACI矩阵对明确划分角色和职责特别有用。
          • 文本型
            • 提供诸如职责、职权、能力和资格等方面的信息。
        • 组织理论
        • 会议
      • 输出
        • 资源管理计划
          • 作为项目管理计划的一部分，资源管理计划提供了关于如何分类、分配、管理和释放项目资源的指南。资源管理计划可以根据项目的具体情况分为团队管理计划和实物资源管理计划。
          • 资源管理计划可能包括（但不限于）
            • 识别资源
              • 用于识别和量化项目所需的团队和实物资源的方法。
            • 获取资源
              • 关于如何获取项目所需的团队和实物资源的指南。
            • 角色与职责
              • 角色
                • 在项目中，某人承担的职务或分配给某人的职务，如土木工程师、商业分析师和测试协调员。
              • 职权
                • 使用项目资源、做出决策、签字批准、验收可交付成果并影响他人开展项目工作的权力。例如，下列事项都需要由具有明确职权的人来做决策：选择活动的实施方法，质量验收标准，以及如何应对项目偏差等。当个人的职权水平与j职责相匹配时，团队成员就能最好地开展工作。
              • 职责
                • 为完成项目活动，项目团队成员必须履行的职责和工作。
              • 能力
                • 为完成项目活动，项目团队成员需具备的技能和才干。如果项目团队成员不具备所需的能力，就不能有效地履行职责。一旦发现成员的能力与职责不匹配，就应主动采取措施，如安排培训、招募新成员、调整进度计划或工作范围。
            • 项目组织图
              • 项目组织图以图形方式展示项目团队成员及其报告关系。基于项目的需要，项目组织图可以是正式或非正式的，非常详细或高度概括的。例如，一个3000人的灾害应急团队的项目组织图，要比仅有20人的内部项目的组织图详尽得多。
            • 项目团队资源管理
              • 关于如何定义、配备、管理和最终遣散项目团队资源的指南。
            • 培训
              • 针对项目成员的培训策略。
            • 团队建设
              • 建设项目团队的方法。
            • 资源控制
              • 依据需要确保实物资源充足可用、并为项目需求优化实物资源采购，而采用的方法。包括有关整个项目生命周期期间的库存、设备和用品管理的信息。
            • 认可计划
              • 将给予团队成员哪些认可和奖励，以及何时给予。
        • 团队章程
          • 团队章程是为团队创建团队价值观、共识和工作指南的文件。
          • 团队章程可能包括（但不限于）：
            • 团队价值观
            • 沟通指南
            • 决策标准和过程
            • 冲突处理过程
            • 会议指南
            • 团队共识
          • 团队章程对项目团队成员的可接受行为确定了明确的期望。尽早认可并遵守明确的规则，有助于减少误解，提高生产力；讨论诸如行为规范、沟通、决策、会议礼仪等领域，团队成员可以了解彼此重要的价值观。由团队制定或参与制定的团队章程可发挥最佳效果。所有项目团队成员都分担责任，确保遵守团队章程中规定的规则。可定期审查和更新团队章程，确保团队始终了解团队基本规则，并指导新成员融入团队。
        • 项目文件更新
          • 假设日志
          • 风险登记册
  • 估算活动资源
    • 估算活动资源是估算执行项目所需的团队资源，以及材料、设备和用品的类型和数量的过程。
    • 本过程的主要作用是，明确完成项目所需的资源种类、数量和特性。
    • ITTO
      • 输入
        • 项目管理计划
          • 资源管理计划
          • 范围基准
        • 项目文件
          • 活动属性
            • 活动属性为估算活动清单中每项活动所需的团队和实物资源提供了主要数据来源，这些属性的例子包括资源需求、强制日期、活动地点、假设条件和制约因素。
          • 活动清单
            • 活动清单识别了需要资源的活动。
          • 假设日志
            • 假设日志可能包含有关生产力因素、可用性、成本估算以及工作方法的信息，这些因素会影响团队和实物资源的性质和数量。
          • 成本估算
            • 资源成本从数量和技能水平方面会影响资源选择。
          • 资源日历
            • 资源日历识别了每种具体资源可用时的工作日、班次、正常营业的上下班时间、周末和公共假期。在规划活动期间，潜在的可用资源信息（如团队资源、设备和材料）用于估算资源可用性。资源日历还规定了在项目期间确定的团队和实物资源何时可用、可用多久。这些信息可以在活动或项目层面建立，这考虑了诸如资源经验和/或技能水平以及不同地理位置等属性。
          • 风险登记册
            • 风险登记册描述了可能影响资源选择和可用性的各个风险。
        • 事业环境因素
        • 组织过程资产
      • 工具与技术
        • 专家判断
        • 自下而上估算
          • 团队和实物资源在活动级别上估算，然后汇总成工作包、控制账户和总体项目层级上的估算。
        • 类比估算
          • 类比估算将以往类似项目的资源相关信息作为估算未来项目的基础。这是一种快速估算方法，适用于项目经理只能识别WBS的几个高层级的情况下。
        • 参数估算
          • 参数估算基于历史数据和项目参数，使用某种算法或历史数据与其他变量之间的统计关系，来计算活动所需的资源数量。例如，如果一项活动需要4000个小时的编码时间，而且需要在1年之内完成，则需要两个人来编码（每人每年付出2000小时）参数估算的准确性取决于参数模型的成熟度和基础数据的可靠性。
        • 数据分析
          • 备选方案分析
            • 适用于本过程的数据分析技术包括（但不限于）备选方案分析。备选方案分析是一种对已识别的可选方案进行评估的技术，用来决定选择哪种方案或使用何种方法来执行项目工作。很多活动有多个备选的实施方案，例如使用能力或技能水平不同的资源、不同规模或类型的机器、不同的工具（手工或自动），以及关于资源自制、租赁或购买的决策。备选方案分析有助于提供在定义的制约因素范围内执行项目活动的最佳方案。
        • 项目管理信息系统
          • 项目管理信息系统可以包括资源管理软件，这些软件有助于规划、组织与管理资源库，以及编制资源估算。根据软件的复杂程度，可以确定资源分解结构、资源可用性、资源费率和各种资源日历，有助于优化资源使用。
        • 会议
          • 项目经理可以和职能经理一起举行规划会议，以估算每项活动所需的资源、支持型活动（LoE）、团队资源的技能水平，以及所需材料的数量。参会者可能包括项目经理、项目发起人、选定的项目团队成员、选定的相关方，以及其他必要人员。
      • 输出
        • 资源需求
          • 资源需求识别了各个工作包或工作包中每个活动所需的资源类型型和数量，可以汇总这些需求，以估算每个工作包、每个WBS分支以及整个项目所需的资源。资源需求描述的细节数量与具体程度因应用领域而异，而资源需求文件也可包含为确定所用资源的类型、可用性和所需数量所做的假设。
        • 估算依据
          • 资源估算所需的支持信息的数量和种类，因应用领域而异。但不论其详细程度如何，支持性文件都应该清晰完整地说明资源估算是如何得出的。
          • 资源估算的支持信息可包括
            • 估算方法
            • 用于估算的资源，如以往类似项目的信息
            • 与估算有关的假设条件
            • 已知的制约因素
            • 估算范围
            • 估算的置信水平
            • 有关影响估算的已识别风险的文件
        • 资源分解结构
          • 资源分解结构是资源依类别和类型的层级展现。资源类别包括（但不限于）人力、材料、设备和用品，资源类型则包括技能水平、要求证书、等级水平或适用于项目的其他类型。在规划资源管理过程中，资源分解结构用于指导项目的分类活动。在这一过程中，资源分解结构是一份完整的文件，用于获取和监督资源。
        • 项目文件更新
          • 活动属性
          • 假设日志
          • 经验教训登记册
  • 获取资源
    • 获取资源是获取项目所需的团队成员、设施、设备、材料、用品和其他资源的过程。本过程的主要作用是，概述和指导资源的选择，并将其分配给相应的活动。
    • 项目所需资源可能来自项目执行组织的内部或外部。内部资源由职能经理或资源经理负责获取（分配），外部资源则是通过采购过程获得。
    • 因为集体劳资协议、分包商人员使用、矩阵型项目环境、内外部报告关系或其他原因，项目管理团队可能或可能不对资源选择有直接控制权。
    • 重要的是，在获取项目资源过程中应注意下列事项：
      • 项目经理或项目团队应该进行有效谈判，并影响那些能为项目提供所需团队和实物资源的人员。
      • 不能获得项目所需的资源时，可能会影响项目进度、预算、客户满意度、质量和风险；资源或人员能力不足会降低项目成功的概率，最坏的情况可能导致项目取消。
      • 如因制约因素（如经济因素或其他项目对资源的占用）而无法获得所需团队资源，项目经理或项目团队可能不得不使用也许能力和成本不同的替代资源。在不违反法律、规章、强制性规定或其他具体标准的前提下可以使用替代资源。
    • ITTO
      • 输入
        • 项目管理计划
          • 资源管理计划
          • 采购管理计划
          • 成本基准
        • 项目文件
          • 项目进度计划
            • 项目进度计划展示了各项活动及其开始和结束日期，有助于确定需要提供和获取资源的时间。
          • 资源日历
            • 资源日历记录了每个项目资源在项目中的可用时间段。编制出可靠的进度计划，应依据对各个资源的可用性和时间限制（包括时区、工作时间、休假时间、当地节假日、维护计划和在其他项目的工作时间）的良好了解。资源日历需要在整个项目过程中渐进明细和更新。资源日历是本过程的输出，在重复本过程时随时可用。
          • 资源需求
            • 资源需求识别了需要获取的资源。
          • 相关方登记册
            • 相关方登记册可能会发现相关方对项目特定资源的需求或期望，在获取资源过程中应加以考虑。
        • 事业环境因素
        • 组织过程资产
      • 工具与技术
        • 决策
          • 多标准决策分析
            • 适用于获取资源过程的决策技术包括（但不限于）多标准决策分析选择标准常用于选择项目的实物资源或项目团队。使用多标准决策分析工具制定出标准，用于对潜在资源进行评级或打分（例如，在内部和外部团队资源之间进行选择）。根据标准的相对重要性对标准进行加权，加权值可能因资源类型的不同而发生变化。
            • 可使用的选择标准包括：
              • 可用性
                • 确认资源能否在项目所需时段内为项目所用。
              • 成本
                • 确认增加资源的成本是否在规定的预算内。
              • 能力
                • 确认团队成员是否提供了项目所需的能力。
            • 有些选择标准对团队资源来说是独特的，包括：
              • 经验
                • 确认团队成员具备项目成功所需的相关经验。
              • 知识
                • 团队成员是否掌握关于客户、执行过的类似项目和项目环境细节的相关知识。
              • 技能
                • 确认团队成员拥有使用项目工具的相关技能。
              • 态度
                • 团队成员能否与他人协同工作，以形成有凝聚力的团队。
              • 国际因素
                • 团队成员的位置、时区和沟通能力。
        • 人际关系与团队技能
          • 谈判
            • 很多项目需要针对所需资源进行谈判，项目管理团队需要与下列各方谈判：
            • 职能经理
              • 确保项目在要求的时限内获得最佳资源，直到完成职责。
            • 执行组织中的其他项目管理团队
              • 合理分配稀缺或特殊资源。
            • 外部组织和供应商
              • 提供合适的、稀缺的、特殊的、合格的、经认证的或其他特殊的团队或实物资源。特别需要注意与外部谈判有关的政策、惯例、流程、指南、法律及其他标准。
            • 在资源分配谈判中，项目管理团队影响他人的能力很重要，如同在组织中的政治能力一样重要。例如，说服职能经理，让他/她看到项目具有良好的前景，会影响他/她把最佳资源分配给这个项目而不是竞争项目。
        • 预分派
          • 预分派指事先确定项目的实物或团队资源，可在下列情况下发生：在竞标过程中承诺分派特定人员进行项目工作；项目取决于特定人员的专有技能；在完成资源管理计划的前期工作之前，制定项目章程过程或其他过程已经指定了某些团队成员的工作分派。
        • 虚拟团队
          • 虚拟团队的使用为招募项目团队成员提供了新的可能性。虚拟团队可定义为具有共同目标、在完成角色任务的过程中很少或没有时间面对面工作的一群人现代沟通技术（如电子邮件、电话会议、社交媒体、网络会议和视频会议等）使虚拟团队成为可行行。
          • 虚拟团队模式使人们有可能
            • 在组织内部地处不同地理位置的员工之间组建团队
            • 为项目团队增加特殊技能，即使相应的专家不在同一地理区域
            • 将在家办公的员工纳入团队
            • 在工作班次、工作小时或工作日不同的员工之间组建团队
            • 将行动不便者或残疾人纳入团队
            • 执行那些原本会因差旅费用过高而被搁置或取消的项目
            • 节省员工所需的办公室和所有实物设备的开支。
          • 在虚拟团队的环境中，沟通规划变得日益重要。可能需要花更多时间，来设定明确的期望、促进沟通、制定冲突解决方法、召集人员参与决策、理解文化差异，以及共享成功喜悦。
      • 输出
        • 物质资源分配单
          • 实物资源分配单记录了项目将使用的材料、设备、用品、地点点和其他实物资源。
        • 项目团队派工单
          • 项目团队派工单记录了团队成员及其在项目中的角色和职责可包括项目团队名录，还需要把人员姓名插入项目管理计划的其他部分，如项目组织图和进度计计划。
        • 资源日历
          • 资源日历识别了每种具体资源可用时的工作日、班次、正常营业的上下班时间、周末和公共假期。在规划活动期间，潜在的可用资源信息（如团队资源、设备和材料）用于估算资源可用性。资源日历规定了在项目期间确定的团队和实物资源何时可用、可用多久。这些信息可以在活动或项目层面建立，这考虑了诸如资源经验和/或技能水平以及不同地理位置等属性。
        • 变更请求
        • 项目管理计划更新
          • 资源管理计划
          • 成本基准
        • 项目文件更新
          • 经验教训登记册
          • 项目进度计划
          • 资源分解结构
          • 资源需求
          • 风险登记册
          • 相关方登记册
        • 事业环境因素更新
        • 组织过程资产更新
  • 建设团队
    • 建设团队是提高工作能力，促进团队成员互动，改善团队整体氛围，以提高项目绩效的过程。
    • 本过程的主要作用是，改进团队协作、增强人际关系技能、激励员工、减少摩擦以及提升整体项目绩效。
    • 项目经理在全球化环境和富有文化多样性的项目中工作：团队成员经常来自不同的行业，讲不同的语言，有时甚至会在工作中使用一种特别的“团队语言”或文化规范，而不是使用他们的母语；项目管理团队应该利用文化差异，在整个项目生命周期中致力于发展和维护项目团队，并促进在相互信任的氛围中充分协作；通过建设项目团队，可以改进人际技巧、技术能力、团队环境及项目绩效。在整个项目生命周期中，团队成员之间都要保持明确、及时、有效（包括效果和效率两个方面）的沟通。
    • 建设项目团队的目标包括（但不限于）：
      • 提高团队成员的知识和技能，以提高他们完成项目可交付成果的能力，并降低成本、缩短工期和提高质量；
      • 提高团队成员之间的信任和认同感，以提高士气、减少冲突和增进团队协作；
      • 创建富有生气、凝聚力和协作性的团队文化，从而：（1）提高个人和团队生产率，振奋团队精神，促进团队合作；（2）促进团队成员之间的交叉培训和辅导，以分享知识和经验；
      • 提高团队参与决策的能力，使他们承担起对解决方案的责任，从而提高团队的生产效率，获得
      • 更有效和高效的成果。
    • “塔克曼”团队发展5阶段
      • 有一种关于团队发展的模型叫塔克曼阶梯理论，其中包括团队建设通常要经过的五个阶段。尽管这些阶段通常按顺序进行，然而，团队停滞在某个阶段或退回到较早阶段的情况也并非罕见；而如果团队成员曾经共事过，项目团队建设也可跳过某个阶段。
        • 形成阶段
          • 在本阶段，团队成员相互认识，并了解项目情况及他们在项目中的正式角色与职责。在这一阶段，团队成员倾向于相互独立，不一定开诚布公。
        • 震荡阶段
          • 在本阶段，团队开始从事项目工作、制定技术决策和讨论项目管理方法。如果团队成员不能用合作和开放的态度对待不同观点和意见，团队环境可能变得事与愿违。
        • 规范阶段
          • 在规范阶段，团队成员开始协同工作，并调整各自的工作习惯和行为来支持团队，团队成员会学习相互信任。
        • 成熟阶段
          • 进入这一阶段后，团队就像一个组织有序的单位那样工作，团队成员之间相互依靠，平稳高效地解决问题。
        • 解散阶段
          • 在解散阶段，团队完成所有工作，团队成员离开项目。通常在项目可交付成果完成之后，或者，在结束项目或阶段过程中，释放人员，解散团队。
    • ITTO
      • 输入
        • 项目管理计划
          • 资源管理计划
            • 项目管理计划组件包括（但不限于）资源管理计划。资源管理计划为如何通过团队绩效评价和其他形式的团队管理活动，为项目团队成员提供奖励、提出反馈、增加培训或采取惩罚措施提供了指南。资源管理计划可能包括团队绩效评价标准。
        • 项目文件
          • 经验教训登记册
            • 项目早期与团队建设有关的经验教训可以运用到项目后期阶段，以提高团队绩效。
          • 项目进度计划
            • 项目进度计划定义了如何以及何时为项目团队提供培训，以培养不同阶段所需的能力，并根据项目执行期间的任何差异（如有）识别需要的团队建设策略。
          • 项目团队派工单
            • 项目团队派工单识别了团队成员的角色与职责。
          • 资源日历
            • 资源日历定义了项目团队成员何时能参与团队建设活动，有助于说明团队在整个项目期间的可用性。
          • 团队章程
            • 团队章程包含团队工作指南。团队价值观和工作指南为描述团队的合作方式提供了架构。
        • 事业环境因素
        • 组织过程资产
      • 工具与技术
        • 集中办公
          • 集中办公是指把许多或全部最活跃的项目团队成员安排在同一个物理地点工作，以增强团队工作能力。集中办公既可以是临时的（如仅在项目特别重要的时期），也可以贯穿整个项目。实施集中办公策略，可借助团队会议室、张贴进度计划的场所，以及其他能增进沟通和集体感的设施。
        • 虚拟团队
          • 虚拟团队的使用能带来很多好处，例如，使用更多技术熟练的资源、降低成本、减少出差及搬迁费用，以及拉近团队成员与供应商、客户或其他重要相关方的距离。虚拟团队可以利用技术来营造在线团队环境，以供团队存储文件、使用在线对话来讨论问题，以及保存团队日历。
        • 沟通技术
          • 在解决集中办公或虚拟团队的团队建设问题方面，沟通技术至关重要。它有助于为集中办公团队营造一个融洽的环境，促进虚拟团队（尤其是团队成员分散在不同时区的团队）更好地相互理解。
          • 可采用的沟通技术包括：
            • 共享门户
              • 共享信息库（例如网站、协作软件或内部网）对虚拟项目团队很有帮助。
            • 视频会议
              • 视频会议是一种可有效地与虚拟团队沟通重要技术。
            • 音频会议
              • 音频会议有助于与虚拟团队建立融洽的相互信任的关系。
            • 电子邮件/聊天软件
              • 使用电子邮件和聊天软件定期沟通也是一种有效的方式。
        • 人际关系与团队技能
          • 冲突管理
            • 项目经理应及时地以建设性方式解决冲突，从而创建高绩效团队。
          • 影响力
            • 本过程的影响力技能收集相关的关键信息，在维护相互信任的关系时，来解决重要问题并达成一致意见。
          • 激励
            • 激励为某人采取行动提供了理由。提高团队参与决策的能力并鼓励他们独立工作。
          • 谈判
            • 团队成员之间的谈判旨在就项目需求达成共识。谈判有助于在团队成员之间建立融洽的相互信任的关系。
          • 团队建设
            • 团队建设是通过举办各种活动，强化团队的社交关系，打造积极合作的工作环境。团队建设活动既可以是状态审查会上的五分钟议程，也可以是为改善人际关系而设计的、在非工作场所专门举办的专业提升活动。团队建设活动旨在帮助各团队成员更加有效地协同工作。如果团队成员的工作地点相隔甚远，无法进行面对面接触，就特别需要有效的团队建设策略。非正式的沟通和活动有助于建立信任和良好的工作关系。团队建设在项目前期必不可少，但它更是个持续的过程。项目环境的变化不可避免，要有效应对这些变化，就需要持续不断地开展团队建设。项目经理应该持续地监督团队机能和绩效，确定是否需要采取措施来预防或纠正各种团队问题。
        • 认可与奖励
          • 在建设项目团队过程中，需要对成员的优良行为给予认可与奖励。最初的奖励计划是在规划资源管理过程中编制的，只有能满足被奖励者的某个重要需求的奖励，才是有效的奖励。在管理项目团队过程中，可以正式或非正式的方式做出奖励决定，但在决定认可与奖励时，应考虑文化差异。
          • 当人们感受到自己在组织中的价值，并且可以通过获得奖励来体现这种价值，他们就会受到激励。通常，金钱是奖励制度中的有形奖励，然而也存在各种同样有效、甚至更加有效的无形奖励。大多数项目团队成员会因得到成长机会、获得成就感、得到赞赏以及用专业技能迎接新挑战，而受到激励。项目经理应该在整个项目生命周期中尽可能地给予表彰，而不是等到项目完成时。
        • 培训
          • 培训包括旨在提高项目团队成员能力的全部活动，可以是正式或非正式的，方式包括课堂培训、在线培训、计算机辅助培训、在岗培训（由其他项目团队成员提供）、辅导及训练。如果项目团队成员缺乏必要的管理或技术技能，可以把对这种技能的培养作为项目工作的一部分。项目经理应该按资源管理计划中的安排来实施预定的培训，也应该根据管理项目团队过程中的观察、交谈和项目绩效评估的结果，来开展必要的计划外培训，培训成本通常应该包括在项目预算中，或者如果增加的技能有利于未来的项目，则由执行组织承担。培训可以由内部或外部培训师来执行。
        • 个人和团队评估
          • 个人和团队评估工具能让项目经理和项目团队洞察成员的优势和劣势。这些工具可帮助项目经理评估团队成员的偏好和愿望、团队成员如何处理和整理信息、如何制定决策，以及团队成员如何与他人打交道。有各种可用的工具，如态度调查、专项评估、结构化访谈、能力测试及焦点小组。这些工具有利于增进团队成员间的理解、信任、承诺和沟通，在整个项目期间不断提高团队成效。
        • 会议
      • 输出
        • 团队绩效评价
          • 随着项目团队建设工作（如培训、团队建设和集中办公等）的开展，项目管理团队应该对项目团队的有效性进行正式或非正式的评价。有效的团队建设策略和活动可以提高团队绩效，从而提高实现项目目标的可能性。
          • 评价团队有效性的指标可包括
            • 个人技能的改进，从而使成员更有效地完成工作任务；
            • 团队能力的改进，从而使团队成员更好地开展工作；
            • 团队成员离职率的降低；
            • 团队凝聚力的加强，从而使团队成员公开分享信息和经验，并互相帮助来提高项目绩效。
          • 通过对团队整体绩效的评价，项目管理团队能够识别出所需的特殊培训、教练、辅导、协助或改变，以提高团队绩效。项目管理团队也应该识别出合适或所需的资源，以执行和实现在绩效评价过程中提出的改进建议。
        • 变更请求
        • 项目管理计划更新
          • 资源管理计划
        • 项目文件更新
          • 经验教训登记册
          • 项目进度计划
          • 项目团队派工单
          • 资源日历
          • 团队章程
        • 事业环境因素更新
          • 作为建设项目团队过程的结果，需要更新的事业环境因素包括（但不限于）
            • 员工发展计划的记录
            • 技能评估
        • 组织过程资产更新
          • 作为建设团队过程的结果，需要更新的组织过程资产包括（但不限于）
            • 培训需求
            • 人事评测
  • 管理团队
    • 管理团队是跟踪团队成员工作表现，提供反馈，解决问题并管理团队变更，以优化项目绩效的过程。本过程的主要作用是，影响团队行为、管理冲突以及解决问题。
    • ITTO
      • 输入
        • 项目管理计划
          • 资源管理计划
        • 项目文件
          • 问题日志
            • 在管理项目团队过程中，总会出现各种问题。此时，可用问题日志记录由谁负责在目标日期内解决特定问题，并监督解决情况。
          • 经验教训登记册
            • 项目早期的经验教训可以运用到项目后期阶段，以提高团队管理的效率与效果。
          • 项目团队派工单
            • 项目团队派工单识别了团队成员的角色与职责。
          • 团队章程
            • 团队章程为团队应如何决策、举行会议和解决冲突提供指南。
        • 工作绩效报告
          • 工作绩效报告是为制定决策、采取行动或引起关注所形成的实物或电子工作绩效信息，它包括从进度控制、成本控制、质量控制和范围确认中得到的结果，有助于项目团队管理。绩效报告和相关预测报告中的信息，有助于确定未来的团队资源需求，认可与奖励，以及更新资源管理计划。
        • 团队绩效评价
          • 项目管理团队应该持续地对项目团队绩效进行正式或非正式的评价。不断地评价项目团队绩效，有助于采取措施解决问题、调整沟通方式、解决冲突和改进团队互动。
        • 事业环境因素
        • 组织过程资产
      • 工具与技术
        • 人际关系与团队技能
          • 冲突管理
            • 在项目环境中，冲突不可避免。冲突的来源包括资源稀缺、进度优先级排序和个人工作风格差异等。采用团队基本规则、团队规范及成熟的项目管理实践（如沟通规划和角色定义），可以减少冲突的数量。
            • 成功的冲突管理可提高生产力，改进工作关系。同时，如果管理得当，意见分歧有利于提高创造力和改进决策。假如意见分歧成为负面因素，应该首先由项目团队成员负责解决；如果冲突升级，项目经理应提供协助，促成满意的解决方案，采用直接和合作的方式，尽早并且通常在私下处理冲突。如果破坏性冲突继续存在，则可使用正式程序，包括采取惩戒措施。
            • 项目经理解决冲突的能力往往决定其管理项目团队的成败。不同的项目经理可能采用不同的解决冲突方法。
            • 影响冲突解决方法的因素包括
              • 冲突的重要性与激烈程度
              • 解决冲突的紧迫性
              • 涉及冲突的人员的相对权力
              • 维持良好关系的重要性
              • 永久或暂时解决冲突的动机
            • 有五种常用的冲突解决方法，每种技巧都有各自的作用和用途
              • 撤退/回避
                • 从实际或潜在冲突中退出，将问题推迟到准备充分的时候，或者将问题推给其他人员解决。
              • 缓和/包容
                • 强调一致而非差异；为维持和谐与关系而退让一步，考虑其他方的需要。
              • 妥协/调解
                • 为了暂时或部分解决冲突，寻找能让各方都在一定程度上满意的方案，但这种方法有时会导致“双输”局面。
              • 强迫/命令
                • 以牺牲其他方为代价，推行某一方的观点；只提供赢输方案。通常是利用权力来强行解决紧急问题，这种方法通常会导致“赢输”局面。
              • 合作/解决问题
                • 综合考虑不同的观点和意见，采用合作的态度和开放式对话引导各方达成共识和承诺，这种方法可以带来双赢局面。
          • 制定决策
            • 这种情况下，决策包括谈判能力以及影响组织与项目管理团队的能力，而不是决策工具集所描述的一系列工具。
            • 进行有效决策需要
              • 着眼于所要达到的目标
              • 遵循决策流程
              • 研究环境因素
              • 分析可用信息
              • 激发团队创造力
              • 理解风险
          • 情商
            • 情商指识别、评估和管理个人情绪、他人情绪及团体情绪的能力。项目管理团队能用情商来了解、评估及控制项目团队成员的情绪，预测团队成员的行为，确认团队成员的关注点及跟踪团队成员的问题，来达到减轻压力、加强合作的目的。
          • 影响力
            • 在矩阵环境中，项目经理对团队成员通常没有或仅有很小的命令职权，所以他们适时影响相关方的能力，对保证项目成功非常关键。
            • 影响力主要体现在如下各方面
              • 说服他人
              • 清晰表达观点和立场
              • 积极且有效的倾听
              • 了解并综合考虑各种观点
              • 收集相关信息，在维护相互信任的关系下，解决问题并达成一致意见
          • 领导力
            • 成功的项目需要强有力的领导技能，领导力是领导团队、激励团队做好本质工作的能力。它包括各种不同的技巧、能力和行动。且领导力在项目生命周期中的所有阶段都很重要。有多种领导力理论，定义了适用于不同情形或团队的领导风格。领导力对沟通愿景及鼓舞项目团队高效工作十分重要。
        • 项目管理信息系统
      • 输出
        • 变更请求
          • 如果管理团队过程中出现变更请求，或者推荐措施、纠正措施或预防措施影响了项目管理计划的任何组成部分或项目文件，项目经理应提交变更请求。并通过实施整体变更控制过程对变更请求进行审查和处理。
          • 例如，人员配备变更，无论是自主选择还是由不可控事件造成，都会干扰项目团队，这种干扰可能导致进度落后或预算超支。人员配备变更包括转派人员、外包部分工作，或替换离职人员。
        • 项目管理计划更新
          • 资源管理计划
          • 进度基准
          • 成本基准
        • 项目文件更新
          • 问题日志
          • 经验教训登记册
          • 项目团队派工单
        • 事业环境因素更新
  • 控制资源
    • 控制资源是确保按计划为项目分配实物资源，以及根据资源使用计划监督资源实际使用情况并采取必要纠正措施的过程。
    • 本过程的主要作用是，确保所分配的资源适时适地可用于项目，且在不再需要时被释放。
    • ITTO
      • 输入
        • 项目管理计划
          • 资源管理计划
        • 项目文件
          • 问题日志
            • 问题日志用于识别有关缺乏资源、原材料供应延迟，或低等级原材料等问题。
          • 经验教训登记册
            • 在项目早期获得的经验教训可以运用到后期阶段，以改进实物资源控制。
          • 物质资源分配单
            • 实物资源分配描述了资源的预页期使用情况以及资源的详细信息，例如类型、数量、地点以及属于组织内部资源还是外购资源
          • 项目进度计划
          • 资源分解结构
          • 资源需求
          • 风险登记册
        • 工作绩效数据
          • 工作绩效数据包含有关项目状态的数据，例如已使使用的资源的数量和类型。
        • 协议
        • 组织过程资产
      • 工具与技术
        • 数据分析
          • 备选方案分析
            • 备选方案分析有助于选择最佳解决方案以纠正资源使用偏差，可以将加班和增加团队资源等备选方案与延期交付或阶段性交付相比较，以权衡利弊。
          • 成本效益分析
            • 成本效益分析有助于在项目成本出现差异时确定最佳的纠正措施。绩效审查。
          • 绩效审查
            • 绩效审查是测量、比较和分析计划的资源使用和实际资源使用的不同。分析成本和进度工作绩效信息有助于指出可能影响资源使用的问题。
          • 趋势分析
            • 在项目进展过程中，项目团队可能会使用趋势分析，基于当前绩效信息来确定未来项目阶段所需的资源。趋势分析检查项目绩效随时间的变化情况，可用于确定绩效是在改善还是在恶化。
        • 问题解决
        • 人际关系与团队技能
          • 谈判
            • 项目经理可能需要就增加实物资源、变更实物资源或资源相关成本进行谈判。
          • 影响力
            • 影响力有助于项目经理及时解决问题并千获得所需资源。
        • 项目管理信息系统
          • 项目管理信息系统（PMIS）可包括资源管理或进度计划软件件，可用于监督资源的使用情况，帮助确保合适的资源适时适地用于合适的活动。
      • 输出
        • 工作绩效信息
          • 工作绩效信息包括项目工作进展信息，这一信息将资源需求和资源分配与项目活动期间的资源使用相比较，从而发现需要处理的资源可用性方面的差异。
        • 变更请求
          • 如果控制资源过程出现变更请求，或者推荐的纠正措施或预防措施影响了项目管理计划的任何组成部分或项目文件，项目经理应提交变更请求。并通过实施整体变更控制过程对变更请求进行审查和处理。
        • 项目管理计划更新
          • 资源管理计划
          • 进度基准
          • 成本基准
        • 项目文件更新
          • 假设日志
          • 问题日志
          • 经验教训登记册
          • 物质资源分配单
          • 资源分解结构
          • 风险登记册
• 项目沟通管理
  • 概述说明
    • 沟通是指有意或无意的信息交换。交换的信息可以是想法、指示或情绪。
    • 信息交换的方法包括
      • 书面形式
        • 实物或电子形式。
      • 口头形式
        • 面对面或远程形式。
      • 正式或非正式形式（用正式纸质或社交媒体）
      • 手势动作
        • 语调和面部表情。
      • 媒体形式
        • 图片、行动，甚至只是遣词造句。
      • 遣词造句
        • 表达一种想法的词语往往不止一个，且各词语的含义会存在细微差异。
    • 沟通活动可按多种维度进行分类，包括（但不限于）
      • 内部
        • 针对项目内部或组织内部的相关方。
      • 外部
        • 针对外部相关方，如客户、供应商、其他项目、组织、政府，公众和环保倡导者。
      • 正式
        • 报告、正式会议（定期及临时）、会议议程和记录、相关方简报和演示。
      • 非正式
        • 采用电子邮件、社交媒体、网站，以及非正式临时讨论的一般沟通活动。
      • 层级沟通
        • 相关方或相关方群体相对于项目团队的位置将会以如下方式影响信息传递的形式和内容
          • 向上沟通
            • 针对高层相关方。
          • 向下沟通
            • 针对承担项目工作的团队和其他人员。
          • 横向沟通
            • 针对项目经理或团队的同级人员。
      • 官方沟通
        • 年报，呈交监管机构或政府部门的报告。
      • 非官方沟通
        • 采用灵活（往往为非正式）的手段，来建立和维护项目团队及其相关方对项目情况的了解和认可，并在他们之间建立强有力的关系。
      • 书面与口头沟通
        • 口头（用词和音调变化）及非口头（肢体语言和行为），社交媒体和网站、媒体发布。
    • 在编制传统（非社交媒体）的书面或口头信息的时候，应用书面沟通的5C原则，可以减轻但无法消除理解错误
      • 正确的语法和拼写
        • 语法不当或拼写错误会分散注意力，还有可能扭曲信息含义，降低可信度。
      • 简洁的表述和无多余字
        • 简洁且精心组织的信息能降低误解信息意图的可能性。
      • 清晰的目的和表述（适合读者的需要）
        • 确保在信息中包含能满足受众需求与激发其兴趣的内容。
      • 连贯的思维逻辑
        • 写作思路连贯，以及在整个书面文件中使用诸如“引言”和“小结”的小标题。
      • 受控的语句和想法承接
        • 可能需要使用图表或小结来控制语句和想法的承接。
    • 书面沟通的5C原则需要用下列沟通技巧来配合
      • 积极倾听。与说话人保持互动，并总结对话内容，以确保有效的信息交换。
      • 理解文化和个人差异。提升团队对文化及个人差异的认知，以减少误解井提升沟通能力。
      • 识别、设定并管理相关方期望。与相关方磋商，减少相关方社区中的自相矛盾的期望。
      • 强化技能。强化所有团队成员开展以下活动的技能：
        • 说服个人、园队或组织采取行动
        • 激励和鼓励人们，或帮功人们重型自信
        • 指导人们改进绩效和取得期望结果
        • 通过磋商达成共识以及减轻审批或决策延误
        • 解决冲突，防止破坏性影响
    • 有效的沟通活动和工件创建具有如下基本属性
      • 沟通目的明确
      • 尽量了解沟通接收方，满足其需求及偏好
      • 监督井衡量沟通的效果
  • 规划沟通管理
    • 规划沟通管理是基于每个相关方或相关方群体的信息需求、可用的组织资产，以及具体项目的需求，为项目沟通活动制定恰当的方法和计划的过程。
    • 本过程的主要作用是，为及时向相关方提供相关信息，引导相关方有效参与项目，而编制书面沟通计划。
    • ITTO
      • 输入
        • 项目章程
        • 项目管理计划
          • 资源管理计划
            • 指导如何对项目资源进行分类、分配、管理和释放。团队成员和小组可能有沟通要求，应该在沟通管理计划中列出。
          • 相关方参与计划
            • 相关方参与计划确定了有效吸引相关方参与所需的管理策略，而这些策略通常通过沟通来落实。
        • 项目文件
          • 需求文件
            • 需求文件可能包含项目相关方对沟通的需求。
          • 相关方登记册
            • 相关方登记册用于规划与相关方的沟通活动。
        • 事业环境因素
        • 组织过程资产
      • 工具与技术
        • 专家判断
        • 沟通需求分析
          • 分析沟通需求，确定项目相关方的信息需求，包括所需信息的类型和格式，以及信息对相关方的价值。
          • 常用于识别和确定项目沟通需求的信息包括（但不限于）
            • 相关方登记册及相关方参与计划中的相关信息和沟通需求
            • 潜在沟通渠道或途径数量，包括一对一、一对多和多对多沟通
            • 组织结构图
            • 项目组织与相关方的职责、关系及相互依赖
            • 开发方法
            • 项目所涉及的学科、部门和专业
            • 有多少人在什么地点参与项目
            • 内部信息需要（如何时在组织内部沟通）
            • 外部信息需要（如何时与媒体、公众或承包商沟通）
            • 法律要求
        • 沟通技术
          • 用于在项目相关方之间传递信息的方法很多。信息交换和协作的常见方法包括对话、会议、书面文件、数据库、社交媒体和网站。
          • 可能影响沟通技术选择的因素包括
            • 信息需求的紧迫性
              • 信息传递的紧迫性、频率和形式可能因项目而异，也可能因项目阶段而异。
            • 技术的可用性与可靠性
              • 用于发布项目沟通工件的技术，应该在整个项目期间都具备兼容性和可得性，且对所有相关方都可用。
            • 易用性
              • 沟通技术的选择应适合项目参与者，而且应在合适的时候安排适当的培训活动。
            • 项目环境
              • 团队会议与工作是面对面还是在虚拟环境中开展，成员处于一个还是多个时区，他们是否使用多语种沟通，是否还有能影响沟通效率的其他环境因素（如与文化有关的各个方面?）
            • 信息的敏感性和保密性
              • 需要考虑的一些方面有
                • 拟传递的信息是否属于敏感或机密信息?如果是，可能需要采取合理的安全措施。
                • 为员工制定社交媒体政策，以确保行为适当、信息安全和知识产权保护。
        • 沟通模型
          • 沟通模型可以是最基本的线性（发送方和接收方）沟通过程，也可以是增加了反馈元素（发送方、接收方和反馈）、更具互动性的沟通形式，甚至可以是融合了发送方或接收方的人性因素、试图考虑沟通复杂性的更加复杂的沟通模型。
          • 基本的发送方和接收方沟通模型示例
            • 此模型将沟通描述为一个过程，并由发送方和接收方两方参与；其关注的是确保信息送达，而非信息理解。
            • 基本沟通模型中的步骤顺序为：
              • 编码
                • 把信息编码为各种符号，如文本、声音或其他可供传递（发送）的形式。
              • 传递信息
                • 通过沟通渠道发送信息。信息传递可能受各种物理因素的不利影响，如不熟悉的技术，或不完备的基础设施。可能存在噪音和其他因素，导致信息传递和（或）接收过程中的信息损耗。
              • 解码
                • 接收方将收到的数据还原为对自己有用的形式。
          • 互动沟通模型示例
            • 此模型也将沟通描述为由发送方与接收方参与的沟通过程，但它还强调确保信息理解的必要性。此模型包括任何可能干扰或阻碍信息理解的噪音，如接收方注意力分散、接收方的认知差异，或缺少适当的知识或兴趣。
            • 互动沟通模型中的新增步骤有：
              • 确认已收到
                • 收到信息时，接收方需告知对方已收到信息（确认已收到）。这并不一定意味着同意或理解信息的内容，仅表示已收到信息。
              • 反馈/响应
                • 对收到的信息进行解码并理解之后，接收方把还原出来的思想或观点编码成信息，再传递给最初的发送方。如果发送方认为反馈与原来的信息相符，代表沟通已成功完成。在沟通中，可以通过积极倾听实现反馈。
          • 在跨文化沟通中，确保信息理解会面临挑战。沟通风格的差异可源于工作方法、年龄、国籍、专业学科、民族、种族或性别差异。不同文化的人们会以不同的语言（如技术设计文档、不同的风格）沟通，并喜欢采用不同的沟通过程和礼节。
            • 所示的沟通模型展示了发送方的当前情绪、知识、背景、个性、文化和偏见会如何影响信息本身及其传递方式。类似地，接收方的当前情绪、知识、背景、个性、文化和偏见也会影响信息的接收和解读方式，导致沟通中的障碍或噪音。
        • 沟通方法
          • 项目相关方之间用于分享信息的沟通方法有几种。这些方法可以大致分为
            • 互动沟通
              • 在两方或多方之间进行的实时多向信息交换。它使用诸如会议、电话、即时信息、社交媒体和视频会议等沟通工件。
            • 推式沟通
              • 向需要接收信息的特定接收方发送或发布信息。这种方法可以确保信息的发送，但不能确保信息送达目标受众或被目标受众理解。在推式沟通中，可以采用的沟通工件包括信件、备忘录、报告、电子邮件、传真、语音邮件、博客、新闻稿。
            • 拉式沟通
              • 适用于大量复杂信息或大量信息受众的情况。它要求接收方在遵守有关安全规定的前提之下自行访问相关内容。这种方法包括门户网站、企业内网、电子在线课程、经验教训数据库或知识库。
          • 应该采用不同方法来实现沟通管理计划所规定的主要沟通需求
            • 人际沟通
              • 个人之间交换信息，通常以面对面的方式进行。
            • 小组沟通
              • 在三到六名人员的小组内部开展。
            • 公众沟通
              • 单个演讲者面向一群人。
            • 大众传播
              • 信息发送人员或小组与大量目标受众（有时为匿名）之间只有最低程度的联系。
            • 网络和社交工具沟通
              • 借助社交工具和媒体，开展多对多的沟通。
        • 人际关系与团队技能
          • 沟通风格评估
            • 规划沟通活动时，用于评估沟通风格并识别偏好的沟通方法、形式和内容的一种技术。常用于不支持项目的相关方。可以先开展相关方参与度评估，再开展沟通风格评估。在相关方参与度评估中，找出相关方参与度的差距。为弥补这种差距，就需要特别裁剪沟通活动和工件。
          • 政治意识
            • 政治意识有助于项目经理根据项目环境和组织的政治环境来规划沟通。政治意识是指对正式和非正式权力关系的认知，以及在这些关系中工作的意愿。理解组织战略、了解谁能行使权力和施加影响，以及培养与这些相关方沟通的能力，都属于政治意识的范畴。
          • 文化意识
            • 文化意识指理解个人、群体和组织之间的差异，并据此调整项目的沟通策略。具有文化意识并采取后续行动，能够最小化因项目相关方社区内的文化差异而导致的理解错误和沟通错误。文化意识和文化敏感性有助于项目经理依据相关方和团队成员的文化差异和文化需求对沟通进行规划。
        • 数据表现
          • 相关方参与度评估矩阵
            • 适用于本过程的数据表现技术包括（但不限于）相关方参与度评估矩阵。相关方参与度评估矩阵显示了个体相关方当前和期望参与度之间的差距。在本过程中，可进一步分析该评估矩阵，以便为填补参与度差距而识别额外的沟通需求（除常规报告以外的）
        • 会议
      • 输出
        • 沟通管理计划
          • 沟通管理计划是项目管理计划的组成部分，描述将如何规划，结构化、执行与监督项目沟通，以提高沟通的有效性。
          • 沟通管理计划包括信息
            • 相关方的沟通需求
            • 需沟通的信息，包括语言、形式、内容和详细程度
            • 上报步骤
            • 发布信息的原因
            • 发布所需信息、确认已收到，或作出回应(若适用)的时限和频率
            • 负责沟通相关信息的人员
            • 负责授权保密信息发布的人员
            • 接收信息的人员或群体，包括他们的需要、需求和期望
            • 用于传递信息的方法或技术，如备忘录、电子邮件、新闻稿，或社交媒体
            • 为沟通活动分配的资源，包括时间和预算
            • 随着项目进展，如项目不同阶段相关方社区的变化，而更新与优化沟通管理计划的方法
            • 通用术语表
            • 项目信息流向图、工作流程(可能包含审批程序)、报告清单和会议计划等
            • 来自法律法规、技术、组织政策等的制约因素
          • 沟通管理计划中还包括关于项目状态会议、项目团队会议、网络会议和电子邮件等的指南和模板。如果项目要使用项目网站和项目管理软件，那就要把它们写进沟通管理计划。
        • 项目管理计划更新
          • 相关方参与计划
        • 项目文件更新
          • 项目进度计划
          • 相关方登记册
  • 管理沟通
    • 管理沟通是确保项目信息及时且恰当地收集、生成、发布、存储、检索、管理、监督和最终处置的过程。本过程的主要作用是，促成项目团队与相关方之间的有效信息流动。
    • ITTO
      • 输入
        • 项目管理计划
          • 资源管理计划
          • 沟通管理计划
          • 相关方参与计划
        • 项目文件
          • 变更日志
            • 变更日志用于向受影响的相关方传达变更，以及变更请求的批准、推迟和否决情况。
          • 问题日志
            • 将与问题有关的信息传达给受影响的相关方。
          • 经验教训登记册
            • 项目早期获取的与管理沟通有关的经验教训，可用于项目后期阶段改进沟通过程，提高沟通效率与效果。
          • 质量报告
            • 质量报告包括与质量问题、项目和产品改进，以及过程改进相关的信息。这些信息应交给能够采取纠正措施的人员，以便达成项目的质量期望。
          • 风险报告
            • 风险报告提供关于整体项目风险的来源的信息，以及关于已识别的单个项目风险的概述信息。这些信息应传达给风险责任人及其他受影响的相关方。
          • 相关方登记册
            • 相关方登记册确定了需要各类信息的人员、群体或组织。
        • 工作绩效报告
          • 根据沟通管理计划的定义，工作绩效报告会通过本过程传递给项目相关方。工作绩效报告的典型示例包括状态报告和进展报告。工作绩效报告可以包含挣值图表和信息、趋势线和预测、储备燃尽图、缺陷直方图、合同绩效信息以及风险概述信息。可以表现为有助于引起关注、制定决策和采取行动的仪表指示图、热点报告、信号灯图或其他形式。
        • 事业环境因素
        • 组织过程资产
      • 工具与技术
        • 沟通技术
          • 会影响技术选用的因素包括团队是否集中办公、需要分享的信息是否需要保密、团队成员的可用资源，以及组织文化会如何影响会议和讨论的正常开展。
        • 沟通方法
          • 沟通方法的选择应具有灵活性，以应对相关方社区的成员变化，或成员的需求和期望变化。
        • 沟通技能
          • 沟通胜任力
            • 经过裁剪的沟通技能的组合，有助于明确关键信息的目的、建立有效关系、实现信息共享和采取领导行为。
          • 反馈
            • 反馈是关于沟通、可交付成果或情况的反应信息。反馈支持项目经理和团队及所有其他项目相关方之间的互动沟通。例如，指导、辅导和磋商。
          • 非言语
            • 也称非口头技能。通过示意、语调和面部表情等适当的肢体语言来表达意思。镜像模仿和眼神交流也是重要的技能。团队成员应该知道如何通过说什么和不说什么来表达自己的想法。
          • 演示
            • 演示是信息和/或文档的正式交付。向项目相关方明确有效地演示项目信息
        • 项目管理信息系统
          • 项目管理信息系统（PMIS）能够确保相关方及时便利地获取所需信息。用来管理和分发项目信息的工具很多，包括：
            • 电子项目管理工具
              • 项目管理软件、会议和虚拟办公支持软件、网络界面、专门的项目门户网站和状态仪表盘，以及协同工作管理工具。
            • 电子沟通管理
              • 电子邮件、传真和语音邮件，音频、视频和网络会议，以及网站和网络发布。
            • 社交媒体管理
              • 网站和网络发布；以及为促进相关方参与和形成在线社区而建立博客和应用程序。
        • 项目报告
          • 项目报告发布是收集和发布项目信息的行为。项目信息应发布给众多相关方群体。应针对每种相关方来调整项目信息发布的适当层次、形式和细节。从简单的沟通到详尽的定制报告和演示，报告的形式各不相同。可以定期准备信息或基于例外情况准备。虽然工作绩效报告是监控项目工作过程的输出，但是本过程会编制临时报告、项目演示、博客，以及其他类型的信息。
        • 人际关系与团队技能
          • 积极倾听
            • 积极倾听技术包括告知已收到、澄清与确认信息、理解，以及消除妨碍理解的障碍。
          • 冲突管理
          • 文化意识
          • 会议管理
            • 会议管理是采取步骤确保会议有效并高效地达到预期目标。
          • 人际交往
            • 人际交往是通过与他人互动交流信息，建立联系。人际交往有利于项目经理及其团队通过非正式组织解决问题，影响相关方的行动，以及提高相关方对项目工作和成果的支持，从而改善绩效。
          • 政治意识
            • 政治意识有助于项目经理在项目期间引导相关方参与，以保持相关方的支持。
        • 会议
      • 输出
        • 项目沟通记录
          • 项目沟通工件可包括（但不限于）：绩效报告、可交付成果果的状态、进度进展、产生的成本、演示，以及相关方需要的其他信息。
        • 项目管理计划更新
          • 沟通管理计划
            • 如果本过程导致了项目沟通方法发生变更，就要把这种变更反映在项目沟通计划中。
          • 相关方参与计划
            • 本过程将导致相关方的沟通需求以及商定的沟通策略需要更新。
        • 项目文件更新
          • 问题日志
          • 经验教训登记册
          • 项目进度计划
          • 风险登记册
          • 相关方登记册
        • 组织过程资产更新
  • 监督沟通
    • 监督沟通是确保满足项目及其相关方的信息需求的过程。本过程的主要作用是，按沟通管理计划和相关方参与计划的要求优化信息传递流程。
    • 通过监督沟通过程，来确定规划的沟通工件和沟通活动是否如预期提高或保持了相关方对项目可交付成果与预计结果的支持力度。项目沟通的影响和结果应该接受认真的评估和监督，以确保在正确的时间，通过正确的渠道，将正确的内容（发送方和接收方对其理解一致）传递给正确的受众。监督沟通可能需要采取各种方法，例如，开展客户满意度调查、整理经验教训、开展团队观察、审查问题日志中的数据，或评估相关方参与度评估矩阵中的变更。
    • 监督沟通过程可能触发规划沟通管理和（或）管理沟通过程的迭代，以便修改沟通计划并开展额外的沟通活动，来提升沟通的效果。这种迭代体现了项目沟通管理各过程的持续性质。问题、关键绩效指标、风险或冲突，都可能立即触发重新开展这些过程。
    • ITTO
      • 输入
        • 项目管理计划
          • 资源管理计划
          • 沟通管理计划
            • 沟通管理计划是关于及时收集、生成和发布信息的现行计划，它确定了沟通过程中的团队成员、相关方和有关工作。
          • 相关方参与计划
            • 相关方参与计划确定了计划用以引导相关方参与的沟通策略。
        • 项目文件
          • 问题日志
            • 问题日志提供项目的历史信息、相关方参与问题的记录，以及它们如何得以解决。
          • 经验教训登记册
            • 在项目早期获取的经验教训可用于项目后期阶段，以改进沟通效果。
          • 项目沟通记录
            • 提供关于已开展的沟通的信息。
        • 工作绩效数据
          • 工作绩效数据包含关于实际已开展的沟通类型和数量的数据。
        • 事业环境因素
        • 组织过程资产
      • 工具与技术
        • 专家判断
        • 项目管理信息系统
          • 项目管理信息系统为（PMIS）项目经理提供一系列标准化工具，以根据沟通计划为内部和外部的相关方收集、储存与发布所需的信息。应监控该系统中的信息以评估其有效性和效果。
        • 数据分析
          • 相关方参与度评估矩阵
            • 它可以提供与沟通活动效果有关的信息。应该检查相关方的期望与当前参与度的变化情况，并对沟通进行必要调整。
        • 人际关系与团队技能
          • 观察/交谈
            • 适用于本过程的人际关系与团队技能包括（但不限于）观察和交谈。与项目团队展开讨论和对话，有助于确定最合适的方法，用于更新和沟通项目绩效，以及回应相关方的信息请求。通过观察和交谈，项目经理能够发现团队内的问题、人员间的冲突，或个人绩效问题。
        • 会议
      • 输出
        • 工作绩效信息
        • 变更请求
          • 监督沟通过程往往会导致需要对沟通管理计划所定义的沟通活动进行调整、采取行动和进行干预。变更请求需要通过实施整体变更控制过程进行处理。
          • 此类变更请求可能导致：修正相关方的沟通要求，包括相关方对信息发布、内容或形式，以及发布方式的要求；建立消除瓶颈的新程序。
        • 项目管理计划更新
          • 沟通管理计划
            • 需要更新沟通管理计划，记录能够让沟通更有效的新信息。
          • 相关方参与计划
            • 需要更新相关方参与计划，反映相关方的实际情况、沟通需求和重要性。
        • 项目文件更新
          • 问题日志
          • 经验教训登记册
          • 相关方登记册
• 项目风险管理
  • 概述说明
    • 单个项目风险是一旦发生，会对一个或多个项目目标产生正面或负面影响的不确定事件或条件。
    • 整体项目风险是（所有）不确定性对项目整体的影响，是相关方面临的项目结果正面和负面变异区间。它源于包括单个风险在内的所有不确定性。
      • 整体风险决定因素
        • 项目复杂性
          • 立项之前
          • 策划阶段
          • 遗传因素
        • 项目所处环境
          • 组织文件
          • 组织结构
          • 规章制度
          • 生活环境
        • 相关方复杂性
          • 矛盾较多
          • 人数较多
          • 周围人影响
        • 项目团队能力
          • 能力强
          • 能力弱
          • 自我关注程度
    • 风险敞口（Risk Exposure）.在某个项目、项目集或项目组合中，针对任一特定对象，而适时作出的对所有风险的潜在影响的综合评估。
      • 可能性和后果联合决定了风险敞口（Risk Exposure）。
      • 两者量化后的乘积就是风险敞口。
      • 风险敞口（risk exposure）反应了你应该预留多少时间或资金来容纳风险。要计算这个，首先应估计风险的数值概率，然后把它乘以风险的影响。在考虑影响的时候，不要忘记你在缓解行为中可能已经有所付出，但应变行为是风险影响的一部分。比如，你可能认为由于太受欢迎而造成的宕机概率大约为35%，而其影响是3天额外的开发时间，再加上带宽、场地租用和新设备的费用共2万美元。你的总体风险敞口就是7000美元加上一天。
    • 有些风险有100%的发生几率。这种就不再是风险一而是现实。修改你的发布计划来应付它们。
    • 风险四要素
      • 风险原因
        • 风险起因
        • 风险条件
      • 风险事件
      • 风险概率
      • 风险后果
      • 风险敞口
    • 风险分类
      • 已知-已知风险
        • 已经识别出并分析过的风险，人们不仅知道它们是什么风险，而且知道它们发生的可能性和后果。
      • 已知-未知风险
        • 已经识别出但其发生的可能性或后果还不清楚的风险，通常在项目预算和进度计划中列出一定的应急储备（包括应急资金和时间）来应对。
      • 未知-未知风险
        • 过去从未遇到过的完全未知的风险。也叫突发风险，需要通过提高项目韧性来应对。
      • 除了为已知风险列出具体风险预算，还不要为突发性风险预留合理的应急预算和时间
      • 采用灵活的项目过程，包括强有力的变变更管理，以便在保持朝项目目标推进的正确方向的
      • 授权目标明确且值得信赖的项目团队在商定限制范围内完成工作等等
    • 风险偏好（Risk Appetite）
      • 为了预期的回报，组织或个人愿意承担不确定性的程度。需要把风险偏好转变成可测量的风险临界值。
    • 风险临界值（Risk Threshold.）
      • 某种特定的风险敞口级别，高于该级别的风险需要处理，低于该级别的风险则可接受。
    • 风险承受力
      • 是指个人或组织能够承受的最高风险程度。
  • 规划风险管理
    • 规划风险管理是定义如何实施项目风险管理活动的过程。本过程的主要作用是，确保风险管理的水平、方法和可见度与项目风险程度，以及项目对组织和其他相关方的重要程度相匹配。
    • ITTO
      • 输入
        • 项目章程
        • 项目管理计划
          • 所有组件
          • 在规划项目风险管理时，应该考虑所有已批准的内子管理计划，使风险管理计划与之相协调；同时，其他项目管理计划组件中所列出的方法论可能也会会影响规划风险管理过程。
        • 项目文件
          • 相关方登记册
            • 相关方登记册包含项目相关方的详细信息，并概述其在项目中的角色和对项目风险的态度；可用于确定项目风险管理的角色和职责，以及为项目设定风险临界值。
        • 事业环境因素
          • 会影响规划风险管理过程的事业环境因素包括（但不限于）由组织或关键相关方设定的整体风险临界值。
        • 组织过程资产
      • 工具与技术
        • 专家判断
        • 数据分析
          • 相关方分析
            • 可通过相关方分析确定项目相关方的风险偏好。
        • 会议
          • 风险管理计划的编制可以是项目开工会议上的一项工作，或者可以举办专门的规划会议来编制风险管理计划。参会者可能包括项目经理、指定项目团队成员、关键相关方，或负责管理项目风险管理过程的团队成员；如果需要，也可邀请其他外部人员参加，包括客户、卖方和监管机构。熟练的会议引导者能够帮助参会者专注于会议事项，就风险管理方法的关键方面达成共识，识别和克服偏见，以及解决任何可能出现的分歧。
          • 在此类会议上确定开展风险管理活动的计划，并将其记录在风险管理计划中。
      • 输出
        • 风险管理计划
          • 风险管理计划是项目管理计划的组成部分，描述如何安排与实施风险管理活动。
          • 风险管理计划可包括以下部分或全部内容
            • 风险管理战略
              • 描述用于管理本项目的风险的一般方法。
            • 方法论
              • 确定用于开展本项目的风险管理的具体方法、工具及数据来源。
            • 角色与职责
              • 确定每项风险管理活动的领导者、支持者和团队成员，并明确他们的职责。
            • 资金
              • 确定开展项目风险管理活动所需的资金，并制定应急储备和管理储备的使用方案。
            • 时间安排
              • 确定在项目生命周期中实施项目风险管理过程的时间和频率，确定风险管理活动并将其纳入项目进度计划。
            • 风险类别
              • 确定对单个项目风险进行分类的方式。通常借助风险分解结构（RBS）来构建风险类别。风险分解结构是潜在风险来源的层级展现。风险分解结构有助于项目团队考虑单个项目风险的全部可能来源，对识别风险或归类已识别风险特别有用。
        • 相关方风险偏好
          • 应在风险管理计划中记录项目关键相关方的风险偏好。他们的风险偏好会影响规划风险管理过程的细节。特别是，应该针对每个项目目标，把相关方的风险偏好表述成可测量的风险临界值。这些临界值不仅将联合决定可接受的整体项目风险敞口水平，而且也用于制定概率和影响定义。以后将根据概率和影响定义，对单个项目风险进行评估和排序。
        • 风险概率和影响定义
          • 根据具体的项目环境，组织和关键相关方的风险偏好和临界值，来制定风险概率和影响定义。项目可能自行制定关于概率和影响级别的具体定义，或者用组织提供的通用定义作为出发点。应该根据拟开展项目风险管理过程的详细程度，来确定概率和影响级别的数量，即：更多级别（通常为五级）对应于更详细的风险管理方法，更少级别（通常为三级）对应于更简单的方法。
        • 概率和影响矩阵
          • 组织可在项目开始前确定优先级排序规则，并将其纳入组织过程资产，或者也可为具体项目量身定制优先级排序规则。在常见的概率和影响矩阵中，会同时列出机会和威胁；以正面影响定义机会，以负面影响定义威胁。概率和影响可以用描述性术语（如很高、高、中、低和很低）或数值来表达。如果使用数值，就可以把两个数值相乘，得出每个风险的概率-影响分值，以便据此在每个优先级组别之内排列单个风险相对优先级。
        • 报告格式
          • 确定将如何记录、分析和沟通项目风险管理过程的结果。在这一部分，描述风险登记册、风险报告以及项目风险管理过程的其他输出的内容和格式。
        • 跟踪
          • 跟踪是确定将如何记录风险活动，以及将如何审计风险的管理过程。
  • 识别风险
    • 识别风险是识别单个项目风险以及整体项目风险的来源并记录风险特征的过程。本过程的主要作用是，记录现有的单个项目风险，以及整体项目风险的来源；同时，汇集相关信息，以便项目团队能够恰当应对已识别的风险。
    • ITTO
      • 输入
        • 项目管理计划
          • 需求管理计划
            • 需求管理计划可能指出了特别有风险的项目目标。
          • 进度管理计划
          • 成本管理计划
          • 质量管理计划
          • 资源管理计划
          • 风险管理计划
          • 范围基准
          • 进度基准
          • 成本基准
        • 项目文件
          • 假设日志
            • 假设日志所记录的假设条件和制约因素可能引发单个项目风险，还可能影响整体项目风险的级别。
          • 成本估算
          • 持续时间估算
          • 问题日志
          • 经验教训登记册
          • 需求文件
          • 资源需求
          • 相关方登记册
        • 协议
          • 如果需要从外部采购项目资源，协议所规定的里程碑日期、合同类型、验收标准和奖罚条款等，都可能造成威胁或创造机会。
        • 采购文档
          • 如果需要从外部采购项目资源，就应该审查初始采购文档，因为从组织外部采购商品和服务可能提高或降低整体项目风险，并可能引发更多的单个项目风险。随着采购文档在项目期间的不断更新，还应该审查最新的文档，例如，卖方绩效报告、核准的变更请求和与检查相关的信息。
        • 事业环境因素
        • 组织过程资产
      • 工具与技术
        • 专家判断
        • 数据收集
          • 头脑风暴
          • 核对单
            • 基于从类似项目和其他信息来源积累的历史信息和知识来编制核对单。编制核对单，列出过去曾出现且可能与当前项目相关的具体单个项目风险，这是吸取已完成的类似项目的经验教训的有效方式。组织可能基于自己已完成的项目来编制核对单，或者可能采用特定行业的通用风险核对单。虽然核对单简单易用，但它不可能穷尽所有风险。所以，必须确保不要用核对单来取代所需的风险识别工作；同时，项目团队也应该注意考察未在核对单中列出的事项。此外，还应该不时地审查核对单，增加新信息，删除或存档过时信息。
          • 访谈
            • 可以通过对资深项目参与者、相关方和主题专家的访谈，来识别单个项目风险以及整体项目风险的来源。应该在信任和保密的环境下开展访谈，以获得真实可信、不带偏见的意见。
        • 数据分析
          • 根本原因分析
            • 根本原因分析常用于发现导致问题的深层原因并制定预防措施。可以用问题陈述（如项目可能延误或超支）作为出发点，来探讨哪些威胁可能导致该问题，从而识别出相应的威胁。也可以用收益陈述（如提前交付或低于预算）作为出发点，来探讨哪些机会可能有利于实现该效益，从而识别出相应的机会。
          • 假设条件和制约因素分析
            • 开展假设条件和制约因素分析，来探索假设条件和制约因素的有效性，确定其中哪些会引发项目风险。从假设条件的不准确、不稳定、不一致或不完整，可以识别出威胁，通过清除或放松会影响项目或过程执行的制约因素，可以创造出机会。
          • SWOT分析
            • 这是对项目的优势、劣势、机会和威胁（SWOT）进行逐个检查。在识别风险时，它会将内部产生的风险包含在内，从而拓宽识别风险的范围。首先，关注项目、组织或一般业务领域，识别出组织的优势和劣势；然后，找出组织优势可能为项目带来的机会，组织劣势可能造成的威胁。还可以分析组织优势能在多大程度上克服威胁，组织劣势是否会妨碍机会的产生。
          • 文件分析
            • 通过对项目文件的结构化审查，可以识别出一些风险。可供审查的文件包括（但不限于）计划、假设条件、制约因素、以往项目档案、合同、协议和技术文件。项目文件中的不确定性或模糊性，以及同一文件内部或不同文件之间的不一致，都可能是项目风险的指示信号。
        • 人际关系与团队技能
          • 引导
            • 引导能提高用于识别单个项目风险和整体项目风险来源的许多技术的有效性。熟练的引导者可以帮助参会者专注于风险识别任务、准确遵循与技术相关的方法，有助于确保风险描述清晰、找到并克服偏见，以及解决任何可能出现的分歧。
        • 提示清单
          • 提示清单是关于可能引发单个项目风险以及可作为整体项目风险来源的风险类别的预设清单。在采用风险识别技术时，提示清单可作为框架用于协助项目团队形成想法。可以用风险分解结构底层的风险类别作为提示清单，来识别单个项目风险。某些常见的战略框架更适用于识别整体项目风险的来源，如PESTLE（政治、经济、社会、技术、法律、环境）、TECCOP（技术、环境、商业、运营、政治），或VUCA（易变性、不确定性、复杂性、模糊性）
        • 会议
      • 输出
        • 风险登记册
          • 风险登记册记录已识别单个项目风险的详细信息。随着实施定性风险分析、规划风险应对、实施风险应对和监督风险等过程的开展，这些过程的结果也要记进风险登记册。取决于具体的项目变量（如规模和复杂性），风险登记册可能包含有限或广泛的风险信息。
          • 当完成识别风险过程时，风险登记册的内容可能包括（但不限于）
            • 已识别风险的清单
              • 在风险登记册中，每项单个项目风险都被赋予一个独特的标识号。要以所需的详细程度对已识别风险进行描述，确保明确理解。可以使用结构化的风险描述，来把风险本身与风险原因及风险影响区分开来。
            • 潜在风险责任人
              • 如果已在识别风险过程中识别出潜在的风险责任人，就要把该责任人记录到风险登记册中。随后将由实施定性风险分析过程进行确认。
            • 潜在风险应对措施清单
              • 如果已在识别风险过程中识别出某种潜在的风险应对措施，就要把它记录到风险登记册中。随后将由规划风险应对过程进行确认。
        • 风险报告
          • 风险报告提供关于整体项目风险的信息，以及关于已识别的单个项目风险的概述信息。在项目风险管理过程中，风险报告的编制是一项渐进式的工作。随着实施定性风险分析、实施定量风险分析、规划风险应对、实施风险应对和监督风险过程的完成，这些过程的结果也需要记录在风险登记册中。
          • 在完成识别风险过程时，风险报告的内容可能包括（但不限于）
            • 整体项目风险的来源
              • 说明哪些是整体项目风险敞口的最重要驱动因素。
            • 关于已识别单个项目风险的概述信息
              • 例如，已识别的威胁与机会的数量、风险在风险类别中的分布情况、测量指标和发展趋势。
          • 根据风险管理计划中规定的报告要求，风险报告中可能还包含其他信息。
        • 项目文件更新
          • 假设日志
          • 问题日志
          • 经验教训登记册
  • 实施定性风险分析
    • 实施定性风险分析是通过评估单个项目风险发生的概率和影响以及其他特征，对风险进行优先级排序，从而为后续分析或行动提供基础的过程。本过程的主要作用是重点关注高优先级的风险。
    • 实施定性风险分析，使用项目风险的发生概率、风险发生时对项目目标的相应影响以及其他因素，来评估已识别单个项目风险的优先级。这种评估基于项目团队和其他相关方对风险的感知程度，从而具有主观性。所以，为了实现有效评估，就需要认清和管理本过程关键参与者对风险所持的态度。风险感知会导致评估已识别风险时出现偏见，所以应该注意找出偏见并加以纠正。如果由引导者来引导本过程的开展，那么找出并纠正偏见就是该引导者的一项重要工作。同时，评估单个项目风险的现有信息的质量，也有助于澄清每个风险对项目的重要性的评估。
    • 实施定性风险分析能为规划风险应对过程确定单个项目风险的相对优先级。本过程会为每个风险识别出责任人，以便由他们负责规划风险应对措施，并确保应对措施的实施。如果需要开展实施定量风险分析过程，那么实施定性风险分析也能为其奠定基础。
    • 根据风险管理计划的规定，在整个项目生命周期中要定期开展实施定性风险分析过程。在敏捷开发环境中，实施定性风险分析过程通常要在每次迭代开始前进行。
    • ITTO
      • 输入
        • 项目管理计划
          • 风险管理计划
            • 本过程中需要特别注意的是风险管理的角色和职责、预算和进度活动安排，以及风险类别（通常在风险分解结构中定义）概率和影响定义、概率和影响矩阵和相关方的风险临界值。通常已经在规划风险管理过程中把这些内容裁剪成适合具体项目的需要。如果还没有这些内容，则可以在实施定性风险分析过程中编制，并经项目发起人批准之后用于本过程。
        • 项目文件
          • 假设日志
            • 假设日志用于识别、管理和监督可能影响项目的关键假设条件和制约因素，它们可能影响对单个项目风险的优先级的评估。
          • 风险登记册
            • 风险登记册包括将在本过程评估的、每个已识别的单个项目风险的详细信息。
          • 相关方登记册
            • 它包括可能被指定为风险责任人的项目相关方的详细信息。
        • 事业环境因素
        • 组织过程资产
      • 工具与技术
        • 专家判断
        • 数据收集
          • 访谈
            • 适用于本过程的数据收集技术包括（但不限于）访谈。结构化或半结构化的访谈可用于评估单个项目风险的概率和影响，以及其他因素。访谈者应该营造信任和保密的访谈环境，以鼓励被访者提出诚实和无偏见的意见。
        • 数据分析
          • 风险数据质量评估
            • 风险数据是开展定性风险分析的基础。风险数据质量评估旨在评价关于单个项目风险的数据的准确性和可靠性。使用低质量的风险数据，可能导致定性风险分析对项目来说基本没用。如果数据质量不可接受，就可能需要收集更好的数据。可以开展问卷调查，了解项目相关方对数据质量各方面的评价，包括数据的完整性、客观性、相关性和及时性，进而对风险数据的质量进行综合评估。可以计算这些方面的加权平均数，将其作为数据质量的总体分数。
          • 风险概率和影响评估
            • 风险概率评估考虑的是特定风险发生的可能性，而风险影响评估考虑的是风险对一项或多项项目目标的潜在影响，如进度、成本、质量或绩效。威胁将产生负面的影响，机会将产生正面的影响。要对每个已识别的单个项目风险进行概率和影响评估。此，还记录相应的说明性细节，例如，确定概率水平或影响级别所依据的假设条件。应该采用风险管理计划中的概率和影响定义，来评估风险的概率和影响。低概率和影响的风险将被列入风险登记册中的观察清单，以供未来监控。
          • 其他风险参数评估
            • 为了方便未来分析和行动，在对单个项目风险进行优先级排序时，项目团队可能考虑（除概率和影响以外的）其他风险特征。
            • 此类特征可能包括（但不限于）
              • 紧迫性
                • 为有效应对风险而必须采取应对措施的时间段。时间短就说明紧迫性高。
              • 邻近性
                • 风险在多长时间后会影响一项或多项项目目标。时间短就说明邻近性高。
              • 潜伏期
                • 从风险发生到影响显现之间可能的时间段。时间短就说明潜伏期短。
              • 可管理性
                • 风险责任人（或责任组织）管理风险发生或影响的容易程度。如果容易管理，可管理性就高。
              • 可控性
                • 风险责任人（或责任组织）能够控制风险后果的程度。如果后果很容易控制，可控性就高。
              • 可监测性
                • 对风险发生或即将发生进行监测的容易程度。如果风险发生很容易监测，可监测性就高。
              • 连通性
                • 风险与其他单个项目风险存在关联的程度大小。如果风险与多个其他风险存在关联，连通性就高。
              • 战略影响力
                • 风险对组织战略目标潜在的正面或负面影响。如果风险对战略目标有重大影响，战略影响力就大。
              • 密切度
                • 风险被一名或多名相关方认为要紧的程度。被认为很要紧的风险，密切度就高。
            • 相对于仅评估概率和影响，考虑上述某些特征有助于进行更稳健的风险优先级排序。
        • 人际关系与团队技能
          • 引导
        • 风险分类
          • 项目风险可依据风险来源（如采用风险分解结构【RBS】）、受影响的项目领域（如采用工作分解结构【WBS】），以及其他实用类别（如项目阶段、项目预算、角色和职责）来分类，确定哪些项目领域最容易被不确定性影响；风险还可以根据共同的根本原因进行分类。应该在风险管理计划中规定可用于项目的风险分类方法。
          • 对风险进行分类，有助于把注意力和精力集中到风险敞口最大的领域，或针对一组相关的风险制定通用的风险应对措施，从而有利于更有效地开展风险应对。
        • 数据表现
          • 概率和影响矩阵
            • 概率和影响矩阵是把每个风险发生的概率和一旦发生对项目目标的影响映射起来的表格。基于风险的概率和影响，对风险进行优先级排序，以便未来进一步分析并制定应对措施。组织可针对每个项目目标（如成本、时间和范围）制定单独的概率和影响矩阵，并用它们来评估风险针对每个目标的优先级别。组织还可以用不同的方法为每个风险确定一个总体优先级别。即可综合针对不同目标的评估结果，也可采用最高优先级别（无论针对哪个目标），作为风险的总体优先级别。
          • 层级型
            • 如果使用了两个以上的参数对风险进行分类，那就不能使用概率和影响矩阵，而需要使用其他图形。例如，气泡图能显示三维数据。在气泡图中，把每个风险都绘制成一个气泡，并用x轴值、y轴值和气泡大小来表示风险的三个参数。图例是气泡图的示例，其中，X轴代表可监测性，Y轴代表邻近性，影响值则以气泡大小表示。
        • 会议
      • 输出
        • 项目文件更新
          • 假设日志
            • 在实施定性风险分析过程中，可能做出新的假设、识别出新的制约因素，或者现有的假设条件或制约因素可能被重新审查和修改。应该更新假设日志，应记录这些新信息。
          • 问题日志
            • 应该更新问题日志，记录发现的新问题或当前问题的变化。
          • 风险登记册
            • 用实施定性风险分析过程生成的新信息，去更新风险登记册。风险登记册的更新内容可能包括：每项单个项目风险的概率和影响评估、优先级别或风险分值、指定风险责任人、风险紧迫性信息或风险类别，以及低优先级风险的观察清单或需要进一步分析的风险。
          • 风险报告
            • 更新风险报告，记录最重要的单个项目风险（通常为概率和影响最高的风险）、所有已识别风险的优先级列表以及简要的结论。
  • 实施定量风险分析
    • 实施定量风险分析是就已识别的单个项目风险和不确定性的其他来源对整体项目目标的影响进行定量分析的过程。本过程的主要作用是，量化整体项目风险敞口，并提供额外的定量风险信息，以支持风险应对规划。
    • 并非所有项目都需要实施定量风险分析。能否开展稳健的分析取决于是否有关于单个项目风险和其他不确定性来源的高质量数据，以及与范围、进度和成本相关的扎实项目基准。定量风险分析通常需要运用专门的风险分析软件，以及编制和解释风险模式的专业知识，还需要额外的时间和成本投入。项目风险管理计划会规定是否需要使用定量风险分析，定量分析最可能适用于大型或复杂的项目、具有战略重要性的项目、合同要求进行定量分析的项目，或主要相关方要求进行定量分析的项目。通过评估所有单个项目风险和其他不确定性来源对项目结果的综合影响，定量风险分析就成为评估整体项目风险的唯一可靠的方法。
    • 在实施定量风险分析过程中，要使用被定性风险分析过程评估为对项目目标存在重大潜在影响的单个项目风险的信息。
    • 实施定量风险分析过程的输出，则要用作规划风险应对过程的输入，特别是要据此为整体项目风险和关键单个项目风险推荐应对措施。定量风险分析也可以在规划风险应对过程之后开展，以分析已规划的应对措施对降低整体项目风险敞口的有效性。
    • ITTO
      • 输入
        • 项目管理计划
          • 风险管理计划
          • 范围基准
          • 进度基准
          • 成本基准
        • 项目文件
          • 假设日志
          • 估算依据
          • 成本估算
          • 成本预测
          • 持续时间估算
          • 里程碑清单
          • 资源需求
          • 风险登记册
          • 风险报告
          • 进度预测
        • 事业环境因素
        • 组织过程资产
      • 工具与技术
        • 专家判断
        • 数据收集
          • 访谈
            • 可用于针对单个项目风险和其他不确定性来源，生成定量风险分析的输入。当需要向专家征求信息时，访谈尤其适用。访谈者应该营造信任和保密的访谈环境，以鼓励被访者提出诚实和无偏见的意见。
        • 人际关系与团队技能
          • 引导
        • 不确定性表现方式
          • 要开展定量风险分析，就需要建立能反映单个项目风险和其他不确定性来源的定量风险分析模型，并为之提供输入。
        • 数据分析
          • 模拟
            • 在定量风险分析中，使用模型来模拟单个项目风险和其他不确定性来源的综合影响，以评估它们对项目目标的潜在影响。模拟通常采用蒙特卡洛分析。对成本风险进行蒙特卡洛分析时，使用项目成本估算作为模拟的输入；对进度风险进行蒙特卡洛分析时，使用进度网络图和持续时间估算作为模拟的输入。开展综合定量成本-进度风险分析时，同时使用这两种输入。其输出就是定量风险分析模型。
            • 用计算机软件数千次迭代运行定量风险分析模型。每次运行，都要随机选择输入值（如成本估算、持续时间估算或概率分支发生频率）。这些运行的输出构成了项目可能结果（如项目结束日期、项目完工成本）的区间。典型的输出包括：表示模拟得到特定结果的次数的直方图，或表示获得等于或小于特定数值的结果的累积概率分布曲线（S曲线）。
            • 在定量进度风险分析中，还可以执行关键性分析，以确定风险模型的哪些活动对项目关键路径的影响最大。对风险模型中的每一项活动计算关键性指标，即：在全部模拟中，该活动出现在关键路径上的频率，通常以百分比表示。通过关键性分析，项目团队就能够重点针对那些对项目整体进度绩效存在最大潜在影响的活动，来规划风险应对措施。
          • 敏感性分析
            • 敏感性分析有助于确定哪些单个项目风险或其他不确定性来源对项目结果具有最大的潜在影响。它在项目结果变异与定量风险分析模型中的要素变异之间建立联系。
            • 敏感性分析的结果通常用龙卷风图来表示。在该图中，标出定量风险分析模型中的每项要素与其能影响的项目结果之间的关联系数。这些要素可包括单个项目风险、易变的项目活动，或具体的不明确性来源。每个要素按关联强度降序排列，形成典型的龙卷风形状。
          • 决策树分析
            • 用决策树在若干备选行动方案中选择一个最佳方案。在决策树中，用不同的分支代表不同的决策或事件，即项目的备选路径。每个决策或事件都有相关的成本和单个项目风险（包括威胁和机会）。决策树分支的终点表示沿特定路径发展的最后结果，可以是负面或正面的结果。
            • 在决策树分析中，通过计算每条分支的预期货币价值，就可以选出最优的路径。
          • 影响图
      • 输出
        • 项目文件更新
          • 风险报告
            • 更新风险报告，反映定量风险分析的结果，通常包括：
              • 对整体项目风险敞口的评估结果
              • 项目详细概率分析的结果
                • 列出定量风险分析的重要输出，如S曲线、龙卷风图和关键性指标，以及对它们的叙述性解释。
                • 定量风险分析的详细结果可能包括
                  • 所需的应急储备，以达到实现目标的特定置信水平
                  • 对项目关键路径有最大影响的单个项目风险或其他不确定定性来源的清单
                  • 整体项目风险的主要驱动因素，即：对项目结果的不确定性有最大影响的因素
              • 单个项目风险优先级清单
              • 定量风险分析结果的趋势
              • 风险应对建议
  • 规划风险应对
    • 规划风险应对是为处理整体项目风险敞口，以及应对单个项目风险，而制定可选方案、选择应对策略并商定应对行动的过程。本过程的主要作用是，制定应对整体项目风险和单个项目风险的适当方法；本过程还将分配资源，并根据需要将相关活动添加进项目文件和项目管理计划。
    • 有效和适当的风险应对可以最小化单个威胁，最大化单个机会，并降低整体项目风险敞口；不恰当的风险应对则会适得其反。一旦完成对风险的识别、分析和排序，指定的风险责任人就应该编制计划，以应对项目团队认为足够重要的每项单个项目风险。这些风险会对项目目标的实现造成威胁或提供机会。项目经理也应该思考如何针对整体项目风险的当前级别做出适当的应对。
    • 风险应对方案应该与风险的重要性相匹配、能经济有效地应对挑战、在当前项目背景下现实可行、能获得全体相关方的同意，并由一名责任人具体负责。往往需要从几套可选方案中选出最优的风险应对方案。应该为每个风险选择最可能有效的策略或策略组合。可用结构化的决策技术来选择最适当的应对策略。对于大型或复杂项目，可能需要以数学优化模型或实际方案分析为基础，进行更加稳健的备选风险应对策略经济分析。
    • ITTO
      • 输入
        • 项目管理计划
          • 资源管理计划
          • 风险管理计划
          • 成本基准
        • 项目文件
          • 经验教训登记册
          • 项目进度计划
          • 项目团队派工单
          • 资源日历
          • 风险登记册
            • 风险登记册包含了已识别并排序的、需要应对的单个项目风险的详细信息。每项风险的优先级有助于选择适当的风险应对措施。例如，针对高优先级的威胁或机会，可能需要采取优先措施和积极主动的应对策略；而针对低优先级的威胁和机会，可能只需要把它们列入风险登记册的观察清单部分，或者只需要为之增加应急储备，而不必采取主动的管理措施。
            • 风险登记册列出了每项风险的指定风险责任人，还可能包含在早期的项目风险管理过程中识别的初步风险应对措施。风险登记册可能还会提供有助于规划风险应对的、关于已识别风险的其他信息，包括根本原因、风险触发因素和预警信号、需要在短期内应对的风险，以及需要进一步分析的风险。
          • 风险报告
            • 风险报告中的项目整体风险敞口的当前级别，会影响选择适当的风险应对策略。风险报告也可能按优先级顺序列出了单个项目风险，并对单个项目风险的分布情况进行了更多分析；这些信息都会影响风险应对策略的选择。
          • 相关方登记册
            • 相关方登记册列出了风险应对的潜在责任人。
        • 事业环境因素
        • 组织过程资产
      • 工具与技术
        • 专家判断
        • 数据收集
          • 访谈
        • 人际关系与团队技能
          • 引导
        • 威胁应对策略
          • 针对威胁，可以考虑下列五种备选策略
            • 上报
              • 如果项目团队或项目发起人认为某威胁不在项目范围内，或提议的应对措施超出了项目经理的权限，就应该采用上报策略。被上报的风险将在项目集层面、项目组合层面或组织的其他相关部门加以管理，而不在项目层面。项目经理确定应就威胁通知哪些人员，并向该人员或组织部门传达关于该威胁的详细信息。对于被上报的威胁，组织中的相关人员必须愿意承担应对责任，这一点非常重要。威胁通常要上报给其目标会受该威胁影响的那个层级。威胁一旦上报，就不再由项目团队做进一步监督，虽然仍可出现在风险登记册中供参考。
            • 规避
              • 风险规避是指项目团队采取行动来消除威胁，或保护项目免受威胁的影响。它可能适用于发生概率较高，且具有严重负面影响的高优先级威胁。规避策略可能涉及变更项目管理计划的某些方面，或改变会受负面影响的目标，以便于彻底消除威胁，将它的发生概率降低到零。风险责任人也可以采取措施，来分离项目目标与风险万一发生的影响。规避措施可能包括消除威胁的原因、延长进度计划、改变项目策略，或缩小范围。有些风险可以通过澄清需求、获取信息、改善沟通或取得专有技能来加以规避。
            • 转移
              • 转移涉及到将应对威胁的责任转移给第三方，让第三方管理风险并承担威胁发生的影响。采用转移策略，通常需要向承担威胁的一方支付风险转移费用。风险转移可能需要通过一系列行动才得以实现，包括（但不限于）购买保险、使用履约保函、使用担保书、使用保证书等。也可以通过签订协议把具体风险的归属和责任转移给第三方。
            • 减轻
              • 风险减轻是指采取措施来降低威胁发生的概率和（或）影响。提前采取减轻措施通常比威胁出现后尝试进行弥补更加有效。减轻措施包括采用较简单的流程，进行更多次测试，或者选用更可靠的卖方。还可能涉及原型开发，以降低从实验台模型放大到实际工艺或产品中的风险。如果无法降低概率，也许可以从决定风险严重性的因素入手，来减轻风险发生的影响。例如，在一个系统中加入冗余部件，可以减轻原始部件故障所造成的影响。
            • 接受
              • 风险接受是指承认威胁的存在，但不主动采取措施。此策略可用于低优先级威胁，也可用于无法以任何其他方式加以经济有效地应对的威胁。接受策略又分为主动或被动方式。最常见的主动接受策略是建立应急储备，包括预留时间、资金或资源以应对出现的威胁；被动接受策略则不会主动采取行动，而只是定期对威胁进行审查，确保其并未发生重大改变。
        • 机会应对策略
          • 针对机会，可以考虑下列五种备选策略
            • 上报
              • 如果项目团队或项目发起人认为某机会不在项目范围内，或提议的应对措施超出了项目经理的权限，就应该取用上报策略。被上报的机会将在项目集层面、项目组合层面或组织的其他相关部门加以管理，而不在项目层面。项目经理确定应就机会通知哪些人员，并向该人员或组织部门传达关于该机会的详细信息。对于被上报的机会，组织中的相关人员必须愿意承担应对责任，这一点非常重要。机会通常要上报给其目标会受该机会影响的那个层级。机会一旦上报，就不再由项目团队做进一步监督，虽然仍可出现在风险登记册中供参考。
            • 开拓
              • 如果组织想确保把握住高优先级的机会，就可以选择开拓策略。此策略将特定机会的出现概率提高到100%，确保其肯定出现，从而获得与其相关的收益。开拓措施可能包括：把组织中最有能力的资源分配给项目来缩短完工时间，或采用全新技术或技术升级来节约项目成本并缩短项目持续时间。
            • 分享
              • 分享涉及到将应对机会的责任转移给第三方，使其享有机会所带来的部分收益。必须仔细为已分享的机会安排新的风险责任人，让那些最有能力为项目抓住机会的人担任新的风险责任人。采用风险分享策略，通常需要向承担机会应对责任的一方支付风险费用。分享措施包括建立合伙关系、合作团队、特殊公司或合资企业来分享机会。
            • 提高
              • 提高策略用于提高机会出现的概率和（或）影响。提前采取提高措施通常比机会出现后尝试改善收益更加有效。通过关注其原因，可以提高机会出现的概率；如果无法提高概率，也许可以针对决定其潜在收益规模的因素来提高机会发生的影响。机会提高措施包括为早日完成活动而增加资源。
            • 接受
              • 接受机会是指承认机会的存在，但不主动采取措施。此策略可用于低优先级机会，也可用于无法以任何其他方式加以经济有效地应对的机会。接受策略又分为主动或被动方式。最常见的主动接受策略是建立应急储备，包括预留时间、资金或资源，以便在机会出现时加以利用；被动接受策略则不会主动采取行动，而只是定期对机会进行审查，确保其并未发生重大改变。
        • 应急应对策略
          • 可以设计一些仅在特定事件发生时才采用的应对措施。对于某些风险，如果项目团队相信其发生会有充分的预警信号，那么就应该制定仅在某些预定条件出现时才执行的应对计划。应该定义并跟踪应急应对策略的触发条件，例如，未实现中间的里程碑，或获得卖方更高程度的重视。采用此技术制定的风险应对计划，通常称为应急计划或弹回计划，其中包括已识别的、用于启动计划的触发事件。
        • 整体项目风险应对策略
          • 风险应对措施的规划和实施不应只针对单个项目风险，还应针对整体项目风险。用于应对单个项目风险的策略也适用于整体项目风险。
            • 规避
              • 如果整体项目风险有严重的负面影响，并已超出商定的项目风险临界值，就可以采用规避策略。此策略涉及采取集中行动，弱化不确定性对项目整体的负面影响，并将项目拉回到临界值以内。例如，取消项目范围中的高风险工作，就是一种整个项目层面的规避措施。如果无法将项目拉回到临界值以内，则可能取消项目。这是最极端的风险规避措施，仅适用于威胁的整体级别在当前和未来都不可接受。
            • 开拓
              • 如果整体项目风险有显著的正面影响，并已超出商定的项目风险临界值，就可以采用开拓策略。此策略涉及采取集中行动，去获得不确定性对整体项目的正面影响。例如，在项目范围中增加高收益的工作，以提高项目对相关方的价值或效益；或者，也可以与关键相关方协商修改项目的风险临界值，以便将机会包含在内。
            • 转移或分享
              • 如果整体项目风险的级别很高，组织无法有效加以应对，就可能需要让第三方代表组织对风险进行管理。若整体项目风险是负面的，就需要采取转移策略，这可能涉及支付风险费用；如果整体项目风险高度正面，则由多方分享，以获得相关收益。整体项目风险的转移和分享策略包括（但不限于）：建立买方和卖方分享整体项目风险的协作式业务结构、成立合资企业或特殊目的公司，或对项目的关键工作进行分包。
            • 减轻或提高
              • 本策略涉及变更整体项目风险的级别，以优化实现项目目标的可能性。减轻策略适用于负面的整体项目风险，而提高策略则适用于正面的整体项目风险。减轻或提高策略包括重新规划项目、改变项目范围和边界、调整项目优先级、改变资源配置、调整交付时间等。
            • 接受
              • 即使整体项目风险已超出商定的临界值，如果无法针对整体项目风险采取主动的应对策略，组织可能选择继续按当前的定义推动项目进展。接受策略又分为主动或被动方式。最常见的主动接受策略是为项目建立整体应急储备，包括预留时间、资金或资源，以便在项目风险超出临界值时使用；被动接受策略则不会主动采取行动，而只是定期对整体项目风险的级别进行审查，确保其未发生重大改变。
        • 数据分析
          • 备选方案分析
          • 成本效益分析
        • 决策
          • 多标准决策分析
      • 输出
        • 变更请求
        • 项目管理计划更新
          • 进度管理计划
          • 成本管理计划
          • 质量管理计划
          • 资源管理计划
          • 采购管理计划
          • 范围基准
          • 进度基准
          • 成本基准
        • 项目文件更新
          • 假设日志
          • 成本预测
          • 经验教训登记册
          • 项目进度计划
          • 项目团队派工单
          • 风险登记册
            • 需要更新风险登记册，录选择和商定的风险应对措施。
            • 风险登记册的更新可能包括（但不限于）
              • 商定的应对策略
              • 实施所选应对策略所需要的具体行动
              • 风险发生的触发条件、征兆和预警信号
              • 实施所选应对策略所需要的预算和进度活动
              • 应急计划，以及启动该计划所需的风险触发条件
              • 弹回计划，供风险发生且主要应对措施不足以应对时使用
              • 在采取预定应对措施之后仍然存在的残余风险，以及被有意接受的风险
              • 由实施风险应对措施而直接导致的次生风险。
          • 风险报告
            • 更新风险报告，记录针对当当前整体项目风险敞口和高优先级风险的经商定的应对措施，以及实施这些措施之后的预期变化。
  • 实施风险应对
    • 实施风险应对是执行商定的风险应对计划的过程。本过程的主要作用是，确保按计划执行商定的风险应对措施，来管理整体项目风险敞口、最小化单个项目威胁，以及最大化单个项目机会。
    • ITTO
      • 输入
        • 项目管理计划
          • 风险管理计划
        • 项目文件
          • 经验教训登记册
            • 项目早期获得的与实施风险应对有关的经验教训，可用于项目后期提高本过程的有效性。
          • 风险登记册
            • 风险登记册记录了每项单个风险的商定风险应对措施，以及负责应对的指定责任人。
          • 风险报告
            • 风险报告包括对当前整体项目风险敞口的评估，以及商定的风险应对策略，还会描述重要的单个项目风险及其应对计划。
        • 组织过程资产
      • 工具与技术
        • 专家判断
        • 人际关系与团队技能
          • 影响力
            • 有些风险应对措施可能由直属项目团队以外的人员去执行，或由存在其他竞争性需求的人员i去执行。这种情况下，负责引导风险管理过程的项目经理或人员就需要施展影响力，去鼓励指定的风险责任人采取所需的行动。
        • 项目管理信息系统
          • 项目管理信息系统（PMIS）可能包括进度、资源和成本车饮件，用于确保把商定的风险应对计划及其相关活动，连同其他项目活动，一并纳入整个项目。
      • 输出
        • 变更请求
        • 项目文件更新
          • 问题日志
            • 作为实施风险应对过程的一部分，已识别的问题会被记录到问题日志中。
          • 经验教训登记册
            • 更新经验教训登记册，记录在实施风险应对时遇到的挑战、本可采取的规避方法，以及实施风险应对的有效方式。
          • 项目团队派工单
            • 一旦确定风险应对策略，应为每项与风险应对计划相关的措施分配必要的资源，包括用于执行商定的措施的具有适当资质和经验的人员、合理的资金和时间，以及必要的技术手段。
          • 风险登记册
            • 可能需要更新风险登记册，反映开展本过程所导致的对单个项目风险的已商定应对措施的任何变更。
          • 风险报告
            • 可能需要风险报告，反映开展本过程所导致的对整体项目风险敞口的已商定应对措施的任何变更。
  • 监督风险
    • 监督风险是在整个项目期间，监督商定的风险应对计划的实施、跟踪已识别风险、识别和分析新风险，以及评估风险管理有效性的过程。本过程的主要作用是，使项目决策都基于关于整体项目风险敞口和单个项目风险的当前信息。
    • 为了确保项目团队和关键相关方了解当前的风险敞口级别，应该通过监督风险过程对项目工作进行持续监督，来发现新出现、正变化和已过时的单个项目风险。
    • 监督风险过程采用项目执行期间生成的绩效信息，以确定
      • 实施的风险应对是否有效
      • 整体项目风险级别是否已改变
      • 已识别单个项目风险的状态是否已改变
      • 是否出现新的单个项目风险
      • 风险管理方法是否依然适用
      • 项目假设条件是否仍然成立
      • 风险管理政策和程序是否已得到遵守
      • 成本或进度应急储备是否需要修改
      • 项目策略是否仍然有效
    • ITTO
      • 输入
        • 项目管理计划
          • 风险管理计划
            • 风险管理计划规定了应如何及何时审查风险，应遵守哪些政策和程序，与本监督过程有关的角色和职责安排，以及报告格式。
        • 项目文件
          • 问题日志
            • 问题日志用于检查未决问题是否已更新，并对风险登记册进行必要更新。
          • 经验教训登记册
            • 在项目早期获得的与风险相关的经验教训可用于项目后期阶段。风险登记册。
          • 风险登记册
            • 风险登记册的主要内容包括；已识别单个项目风险、风险责任人、商定的风险应对策略，以及具体的应对措施。它可能还会提供其他详细信息，包括用于评估应对计划有效性的控制措施、风险的症状和预警信号、残余及次生风险，以及低优先级风险观察清单。
          • 风险报告
            • 风险报告包括对当前整体项目风险敞口的评估，以及商定的风险应对策略，还会描述重要的单个项目风险及其应对计划和风险责任人。
        • 工作绩效数据
        • 工作绩效报告
      • 工具与技术
        • 数据分析
          • 技术绩效分析
            • 开展技术绩效分析，把项目执行期间所取得的技术成果与取得相关技术成果的计划进行比较。它要求定义关于技术绩效的客观的、量化的测量指标，以便据此比较实际结果与计划要求。技术绩效测量指标可能包括：重量、处理时间、缺陷数量、储存容量等。实际结果偏离计划的程度可以代表威胁或机会的潜在影响。
          • 储备分析
            • 在整个项目执行期间，可能发生某些单个项目风险，对预算和进度应急储备产生正面或负面的影响。储备分析是指在项目的任一时点比较剩余应急储备与剩余风险量，从而确定剩余储备是否仍然合理。可以用各种图形（如燃尽图）来显示应急储备的消耗情况。
        • 审计
          • 风险审计是一种审计类型，可用于评估风险管理过程的有效性。项目经理负责确保按项目风险管理计划所规定的频率开展风险审计。风险审计可以在日常项目审查会上开展，可以在风险审查会上开展，团队也可以召开专门的风险审计会。在实施审计前，应明确定义风险审计的程序和目标。
        • 会议
          • 适用于本过程的会议包括（但不限于）风险审查会应该定期安排风险审查，来检查和记录风险应对在处理整体项目风险和已识别单个项目风险方面的有效性。在风险审查中，还可以识别出新的单个项目风险（包括已商定应对措施所引发的次生风险）重新评估当前风险，关闭已过时风险，讨论风险发生所引发的问题，以及总结可用于当前项目后续阶段或未来类似项目的经验教训。根据风险管理计划的规定，风险审查可以是定期项目状态会中的一项议程，或者也可以召开专门的风险审查会。
      • 输出
        • 工作绩效信息
          • 工作绩效信息是经过比较单个风险的实际发生情况和预计发生情况，所得到的关于项目风险管理执行绩效的信息。它可以说明风险应对规划和应对实施过程的有效性。
        • 变更请求
          • 执行监督风险过程后，可能会就成本基准和进度基准，或项目管理计划的其他组件提出变更请求，应该通过实施整体变更控制过程对变更请求进行审查和处理。
          • 变更请求可能包括：建议的纠正与预防措施，以处理当前整体项目风险级别或单个项目风险。
        • 项目管理计划更新
          • 任何组件
        • 项目文件更新
          • 假设日志
            • 在监督风险过程中，可能做出新的假设、识别出新的制约因素，或者现有假设条件或制约因素可能被重新审查和修改。需要更新假设日志，记录这些新信息。
          • 问题日志
            • 作为监督风险过程的一部分，已识别的问题会记录到问题日志中。
          • 经验教训登记册
            • 更新经验教训登记册，记录风险审查期间得到的任何与风险相关的经验教训，以便用于项目的后期阶段或未来项目。
          • 风险登记册
            • 更新风险登记册，记录在监督风险过程中产生的关于单个项目风险的信息，可能包括添加新风险、更新已过时风险或已发生风险，以及更新风险应对措施，等等。
          • 风险报告
            • 应该随着监督风险过程生成新信息，而更新风险报告，反映重要单个项目风险的当前状态，以及整体项目风险的当前级别。风险报告还可能包括有关的详细信息，诸如最高优先级单个项目风险、已商定的应对措施和责任人，以及结论与建议。风险报告也可以收录风险审计给出的关于风险管理过程有效性的的结论。
        • 组织过程资产更新
• 项目采购管理
  • 概述说明
    • 虽然项目经理不必成为采购管理法律法规领域的专家，但应该对采购过程有足够了解，以便做出与合同及合同关系相关的明智决定。
    • 通常情况下，项目经理无权签署对组织有约束力的法律协议，这项工作仅由具备相关职权的人员执行。其书写形式也应符合当地、所在国或国际法中关于合同签署的规定。组织规定谁有权代表组织签署和管理协议。
    • 协议是买卖双方之间的法律文件，合同是对双方都有约束力的协议，规定卖方有义务提供有价值的东西，如规定的产品、服务或成果，买方有义务支付货币或其他有价值的补偿
    • 卖方通常应把相关工作当做一个项目来管理，合同条款和条件成为卖方许多管理过程的关键输入
    • 因应用领域不同，协议可以是合同、服务水平协议（SLA）、谅解备忘录、协议备忘录（MOA）或订购单
  • 规划采购管理
    • 规划采购管理是记录项目采购决策、明确采购方法，及识别潜在卖方的过程。本过程的主要作用是，确定是否从项目外部获取货物和服务，如果是，则还要确定将在什么时间、以什么方式获取什么货物和服务。货物和服务可从执行组织的其他部门采购，或者从外部渠道采购。
    • ITTO
      • 输入
        • 项目章程
        • 商业文件
          • 商业论证
          • 效益管理计划
        • 项目管理计划
          • 范围管理计划
            • 范围管理计划说明如何在项目的勺实施阶段管理承包商的工作范围。
          • 质量管理计划
            • 质量管理计划包含项目需要遵循的行业标准与准则。这些标准与准则应写入招标文件，如建议邀请书，并将最终在合同中引用。这些标准与准则也可用于供应商资格预审，或作为供应商甄选标准的一部分。
          • 资源管理计划
            • 资源管理计划包括关于哪些资源需要采购或租赁的信息，以及任何可能影响采购的假设条件或制约因素。
          • 范围基准
            • 范围基准包含范围说明书、WBS和WBS词典。在项目早期，项目范围可能仍要继续演进。应该针对项目范围中已知的工作，编制工作说明书（SOW）和工作大纲（TOR）.
        • 项目文件
          • 里程碑清单
            • 重要里程碑清单说明卖方需要在何时交付成果。
          • 项目团队派工单
            • 项目团队派工单包含关于项目团队技能和能力的信息，以及他们可用于支持采购活动的时间。如果项目团队不具备开展采购活动的能力，则需要外聘人员或对现有人员进行培训，或者二者同时进行。
          • 需求文件
            • 需求文件可能包括
              • 卖方需要满足的技术要求
              • 具有合同和法律意义的需求，如健康、安全、安保、绩效、环境、保险、知识产权、同等就业机会、执照、许可证，以及其他非技术要求
          • 需求跟踪矩阵
            • 需求跟踪矩阵将产品需求从其来源连接到能满足需求的可交付成果。
          • 资源需求
            • 源需求包含关于某些特定需求的信息，例如，可能需要采购的团队及实物资源。
          • 风险登记册
            • 风险登记册列明风险清单，以及风险分析和风险应对规划的结果。有些风险应通过采购协议转移给第三方。
          • 相关方登记册
            • 相关方登记册提供有关项目参与者及其项目利益的详细信息，包括监管机构、合同签署人员和法务人员。
        • 事业环境因素
        • 组织过程资产
          • 组织使用的各种合同协议类型也会影响规划采购管理理过程中的决策。
          • 能够影响规划采购管理过程的组织过程资产包括（但不限于）
          • 预先批准的卖方清单
            • 经过适当审查的卖方清单可以简化招标所需的步骤，并缩短卖方甄选过程的时间。
          • 正式的采购政策、程序和指南
            • 大多数组织都有正式的采购政策和采购机构。如果没有，项目团队就应该配备相关的资源和专业技能，来实施采购活动。
          • 合同类型
            • 所有法律合同关系通常可分为总价和成本补偿两大类。此外，还有第三种常用的混合类型，即工料合同。下文将分别讨论上述几类较常用的合同类型。但在实践中，单次采购合并使用两种或更多合同类型的情况也并不罕见。
              • 总价合同
                • 此类合同为既定产品、服务或成果的采购设定一个总价。这种合同应在已明确定义需求，且不会出现重大范围变更的情况下使用
                • 总价合同的类型包括
                  • 固定总价（FFP）
                    • FFP是最常用的合同类型。大多数买方都喜欢这种合同，因为货物采购的价格在一开始就已确定，并且不允许改变（除非工作范围发生变更）
                  • 总价加激励费用（FPIF）
                    • 这种总价合同为买方和卖方提供了一定的灵活性，允许一定的绩效偏离，并对实现既定目标给予相关的财务奖励（通常取决于卖方的成本、进度或技术绩效）。FPIF合同中会设置价格上限，高于此价格上限的全部成本将由卖方承担。
                  • 总价加经济价格调整（FPEPA）
                    • 这种合同适用于两种情况：卖方履约期将跨越几年时间或将以不同货币支付价款。它是总价合同的一种类型，但合同中包含了特殊条款，允许根据条件变化，如通货膨胀、某些特殊商品的成本增加（或降低），以事先确定的方式对合同价格进行最终调整。
              • 成本补偿合同
                • 此类合同向卖方支付为完成工作而发生的全部合法实际成本（可报销成本），外加一笔费用作为卖方的利润。这种合同适用于：工作范围预计会在合同执行期间发生重大变更。
                • 成本补偿合同又可分为：
                  • 成本加固定费用（CPFF）
                    • 为卖方报销履行合同工作所发生的一切可列支成本，并向卖方支付一笔固定费用。该费用以项目初始估算成本的某一百分比计列。除非项目范围发生变更，否则费用金额维持不变。
                  • 成本加激励费用（CPIF）
                    • 为卖方报销履行合同工作所发生的一切可列支成本，并在卖方达到合同规定的绩效目标时，向卖方支付预先确定的激励费用。在CPIF合同中，如果最终成本低于或高于原始估算成本，则买方和卖方需要根据事先商定的成本分摊比例来分享节约部分或分担超支部分。例如，基于卖方的实际成本，按照80/20的比例分担（分享）超过（低于）目标成本的部分。
                  • 成本加奖励费用（CPAF）
                    • 为卖方报销一切合法成本，但只有在卖方满足合同规定的、某些笼统主观的绩效批准的情况下，才向卖方支付大部分费用。奖励费用完全由买方根据自己对卖方绩效的主观判断来决定，并且通常不允许申诉。
              • 工料合同（T&M）
                • 工料合同（又称时间和手段合同），是兼具成本补偿合同和总价合同特点的混合型合同。这种合同往往适用于：在无法快速编制出准确的工作说明书的情况下扩充人员、聘用专家或寻求外部支持。
      • 工具与技术
        • 专家判断
        • 数据收集
          • 市场调研
            • 市场调研包括考察行业情况和具体卖方的能力。采购团队可运用从会议、在线评论和各种其他渠道得到的信息，来了解市场情况。采购团队也可以调整具体的采购目标，以便在平衡与有能力提供所需材料或服务的卖方的范围有关的风险的同时，利用成熟技术。
        • 数据分析
          • 自制或外购分析
            • 自制或外购分析用于确定某项工作或可交付成果最好由项目团队自行完成，还是应该从外部采购。制定自制或外购决策时应考虑的因素包括；组织当前的资源配置及其技能和能力，对专业技术的需求，不愿承担永久雇用的义务，以及对独特技术专长的需求；还要评估与每个自制或外购决策相关的风险。
            • 在自制或外购分析中，可以使用回收期、投资回报率（ROI）、内部报酬率（RR）、现金流贴现、净现值（NPV）、收益成本（BCA）或其他分析技术，来确定某种货物或服务是应该在项目内部自制，还是从外部购买。
        • 供方选择分析
          • 在确定选择方法前，有必要审查项目竞争性需求的优先级。由于竞争性选择方法可能要求卖方在事前投入大量时间和资源，因此，应该在采购文件中写明评估方法，让投标人了解将会被如何评估。
          • 常用的选择方法包括
            • 最低成本
              • 最低成本法适用于标准化或常规采购。此类采购有成熟的实践与标准，有具体明确的预期成果，可以用不同的成本来取得。
            • 仅凭资质
              • 仅凭资质的选择方法适用于采购价值相对较小，不值得花时间和成本开展完整选择过程的情况。买方会确定短名单，然后根据可信度、相关资质、经验、专业知识、专长领域和参考资料选择最佳的投标人。
            • 基于质量或技术方案得分
              • 邀请一些公司提交建议书，同时列明技术和成本详情；如果技术建议书可以接受，再邀请它们进行合同谈判。采用此方法，会先对技术建议书进行评估，考察技术方案的质量。如果经过谈判，证明它们的财务建议书是可接受的，那么就会选择技术建议书得分最高的卖方。
            • 基于质量和成本
              • 在基于质量和成本的方法中，成本也是用于选择卖方的一个考虑因素。一般而言，如果项目的风险和（或）不确定性较高，相对于成本而言，质量就应该是一个关键因素。
            • 独有来源
              • 买方要求特定卖方准备技术和财务建议书，然后针对建议书开展谈判。由于没有竞争，因此仅在有适当理由时才可采用此方法，而且应将其视为特殊情况。
            • 固定预算
              • 固定预算法要求在建议邀请书中向受邀的卖方披露可用预算，然后在此预算内选择技术建议书得分最高的卖方。因为有成本限制，所以卖方会在建议书中调整工作的范围和质量，以适应该预算。买方应该确保固定预算与工作说明书相符，且卖方能够在该预算内完成相关任务。此方法仅适用于工作说明书定义精确、预期不会发生变更，而且预算固定且不得超出的情况。
        • 会议
      • 输出
        • 采购管理计划
          • 采购管理计划包含要在采购过程中开展的各种活动。它应该记录是否要开展国际竞争性招标、国内竞争性招标、当地招标等。如果项目由外部资助，资金的来源和可用性应符合采购管理计划和项目进度计划的规定。
          • 采购管理计划可包括以下内容：
            • 如何协调采购与项目的其他工作，例如，项目进度计划制定和控制
            • 开展重要采购活动的时间表
            • 用于管理合同的采购测量指标
            • 与采购有关的相关方角色和职责如果执行组织有采购部，项目团队拥有的职权和受到的限制
            • 可能影响采购工作的制约因素和假设条件
            • 司法管辖权和付款货币
            • 是否需要编制独立估算，以及是否应将其作为评价标准
            • 风险管理事项，包括对履约保函或保险合同的要求，以减轻某些项目风险
            • 拟使用的预审合格的卖方（如果有）
          • 根据每个项目的需要，采购管理计划可以是正式或非正式的，非常详细或高度概括的。
        • 采购策略
          • 一旦完成自制或外购分析，并决定从项目外部渠道采购，就应制定一套采购策略。应该在采购策略中规定项目交付方法、具有法律约束力的协议类型，以及如何在采购阶段推动采购进展。
            • 交付方法
              • 对专业服务项目和建筑施工项目，应该采用不同的交付方法。
                • 专业服务项目的交付方法包括：买方或服务提供方不得分包、买方或服务提供方可以分包、买方和服务提供方设立合资企业、买方或服务提供方仅充当代表。
                • 而工业或商业施工项目的交付方法包括（但不限于）：交钥匙式、设计-建造（DB）、设计-招标-建造（DBB）、设计-建造-运营（DBO）、建造-拥有-运营-转让（BOOT），及其他。
            • 合同支付类型
              • 合同支付类型与项目交付方法无关，需要与采购组织的内部财务系统相协调。它们包括（但不限于）以下合同类型及其变种：总价、固定总价、成本加奖励费用、成本加激励费用、工料、目标成本及其他。
            • 采购阶段
              • 采购策略也可以包括与采购阶段有关的信息，这种信息可能包括：采购工作的顺序安排或阶段划分，每个阶段的描述，以及每个阶段的具体目标等。
        • 招标文件
          • 招标文件用于向潜在卖方征求建议书。如果主要依据价格来选择卖方（如购买商业或标准产品时），通常就使用标书、投标或报价等术语；如果其他考虑因素（如技术能力或技术方法）至关重要，则通常使用建议书之类的术语。具体使用的采购术语也可能因行业或采购地点而异。
          • 取决于所需的货物或服务，招标文件可以是信息邀请书、报价邀请书、建议邀请书，或其他适当的采购文件。
          • 使用不同文件的条件如下
            • 信息邀请书（RF）
              • 如果需要卖方提供关于拟采购货物和服务的更多信息，就使用信息邀请书。随后一般还会使用报价邀请书或建议邀请书。
            • 报价邀请书（RFQ）
              • 如果需要供应商提供关于将如何满足需求和（或）将需要多少成本的更多信息，就使用报价邀请书。
            • 建议邀请书（RFP）
              • 如果项目中出现问题且解决办法难以确定，就使用建议邀请书。这是最正式的“邀请书”文件，需要遵守与内容、时间表，以及卖方应答有关的严格的采购规则。
          • 买方拟定的采购文件不仅应便于潜在卖方做出准确、完整的应答，还要便于买方对卖方应答进行评价。采购文件会包括规定的应答格式、相关的采购工作说明书，以及所需的合同条款。
        • 采购工作说明书
          • 依据项目范围基准，为每次采购编制工作说明书（SOW），仅对将要包含在相关合同中的那一部分项目范围进行定义。工作说明书会充分详细地描述拟采购的产品、服务或成果，以便潜在卖方确定是否有能力提供此类产品、服务或成果。根据采购品的性质、买方的需求，或拟采用的合同形式，工作说明书的详细程度会有较大不同。工作说明书的内容包括：规格、所需数量、质量水平、绩效数据、履约期间、工作地点和其他要求。
          • 采购工作说明书应力求清晰、完整和简练。它需要说明所需的附加服务，例如，报告绩效，或对采购品的后续运营支持。在采购过程中，应根据需要对工作说明书进行修订，直到它成为所签协议的一部分。
          • 对于服务采购，可能会用“工作大纲（TOR）”这个术语。
          • 与采购工作说明书类似，工作大纲通常包括以下内容
            • 承包商需要执行的任务，以及所需的协调工作
            • 承包商必须达到的适用标准
            • 需要提交批准的数据
            • 由买方提供给承包商的，将用于合同履行的全部数据和服务的详细清单（若适用）
            • 关于初始成果提交和审查（或审批）的进度计划
        • 供方选择标准
          • 在确定评估标准时，买方要努力确保选出的建议书将提供最佳质量的所需服务。
          • 供方选择标准可包括（但不限于）
            • 能力和潜能
            • 产品成本和生命周期成本等
        • 自制或外购决策
          • 通过自制或外购分析，做出某项特定工作最好由项页目团队自己完成，还是需要从外部渠道采购的决策。
        • 独立成本估算
          • 对于大型的采购，采购组织可以自行准备独立估算，或聘用外部专业估算师做出成本估算，并将其作为评价卖方报价的对照基准。如果二者之间存在明用显差异，则可能表明采购工作说明书存在缺陷或模糊，或者潜在卖方误解了或未能完全响应采购工作说明书。
        • 变更请求
        • 项目文件更新
          • 经验教训登记册
          • 里程碑清单
          • 需求文件
          • 需求跟踪矩阵
          • 风险登记册
          • 相关方登记册
        • 组织过程资产更新
  • 实施采购
    • 实施采购是获取卖方应答、选择卖方并授予合同的过程。本过程的主要作用是，选定合格卖方并签署关于货物或服务交付的法律协议。本过程的最后成果是签订的协议，包括正式合同。
    • ITTO
      • 输入
        • 项目管理计划
          • 范围管理计划
          • 需求管理计划
          • 沟通管理计划
          • 风险管理计划
          • 采购管理计划
          • 配置管理计划
          • 成本基准
        • 项目文件
          • 经验教训登记册
          • 项目进度计划
          • 需求文件
          • 风险登记册
          • 相关方登记册
        • 采购文档
          • 采购文档是用于达成法律协议的各种书面文件，其中可能包括当前项目启动之前的较旧文件。
          • 采购文档可包括
            • 招标文件
              • 招标文件包括发给卖方的信息邀请书、建议邀请书、报价邀请书，或其他文件，以便卖方编制应答文件。
            • 采购工作说明书
              • 采购工作说明书（SOW）向卖方清晰地说明目标、需求及成果，以便卖方据此做出量化应答。
            • 独立成本估算
              • 独立成本估算可由内部或外部人员编制，用于评价投标人提交的建议书的合理性。
            • 供方选择标准
              • 此类标准描述如何评估投标人的建议书，包括评估标准和权重。为了减轻风险，买方可能决定与多个卖方签署协议，以便在单个卖方出问题并影响整体项目时，降低由此导致的损失。
        • 卖方建议书
          • 卖方为响应采购文件包而编制的建议书，其中包含的基本信息将被评估团队用于选定一个或多个投标人（卖方）。如果卖方将提交价格建议书，最好要求他们将价格建议书与技术建议书分开。评估团队会根据供方选择标准审查每一份建议书，然后选出最能满足采购组织需求的卖方。
        • 事业环境因素
        • 组织过程资产
      • 工具与技术
        • 专家判断
        • 广告
          • 广告是就产品、服务或成果与用户或潜在用户进行的沟通。在大众出版物（如指定的报纸）或专门行业出版物上刊登广告，往往可以扩充现有的潜在卖方名单单。大多数政府机构都要求公开发布采购广告，或在网上公布拟签署的政府合同的信息。
        • 投标人会议
          • 投标人会议（又称承包商会议、供应商会议或投标前会议）是在卖方提交建议书之前，在买方和潜在卖方之间召开的会议，其目的是确保所有潜在投标人对采购要求都有清楚且一致的理解，并确保没有任何投标人会得到特别优待。
        • 数据分析
          • 建议书评价
            • 对建议书进行评估，确定它们是否对包含在招标文件包中的招标文件、采购工作说明书、供方选择标准和其他文件，都做出了完整且充分的响应。
        • 人际关系与团队技能
          • 谈判
            • 谈判是为达成协议而进行的讨论。采购谈判是指在合同签署之前，对合同的结构、各方的权利和义务，以及其他条款加以澄清，以便双方达成共识。最终的文件措辞应该反映双方达成的全部一致意见。谈判以签署买方和卖方均可执行的合同文件或其他正式协议而结束。
            • 谈判应由采购团队中拥有合同签署职权的成员主导。项目经理和项目管理团队的其他成员可以参加谈判并提供必要的协助。
      • 输出
        • 选定的卖方
          • 选定的卖方是在建议书评估或投标评估中被判断为最有竞争力的投标人。对于较复杂、高价值和高风险的采购，在授予合同前，要把选定的卖方报给组织高高级管理人员审批。
        • 协议
          • 合同是对双方都有约束力的协议。它强制卖方提供规定的产品、服务或成果，强制买方向卖方支付相应的报酬。
          • 合同建立了受法律保护的买卖双方的关系协议文本的主要内容会有所不同，可包括（但不限于）
            • 采购工作说明书或主要的可交付成果
            • 进度计划、里程碑，或进度计划中规定的日期
            • 绩效报告
            • 定价和支付条款
            • 检查、质量和验收标准
            • 担保和后续产品支持
            • 激励和惩罚
            • 保险和履约保函
            • 下属分包商批准
            • 一般条款和条件
            • 变更请求处理
            • 终止条款和替代争议解决方法
        • 变更请求
        • 项目管理计划更新
          • 需求管理计划
          • 质量管理计划
          • 沟通管理计划
          • 风险管理计划
          • 采购管理计划
          • 范围基准
          • 进度基准
          • 成本基准
        • 项目文件更新
          • 经验教训登记册
          • 需求文件
          • 需求跟踪矩阵
          • 资源日历
          • 风险登记册
          • 相关方登记册
        • 组织过程资产更新
  • 控制采购
    • 控制采购是管理采购关系，监督合同绩效，实施必要的变更和纠偏，以及关闭合同的过程。本过程的主要作用是，确保买卖双方履行法律协议，满足项目需求。
    • 买方和卖方都出于相似的目的来管理采购合同，每方都必须确保双方履行合同义务，确保各自的合法权利得到保护。合同关系的法律性质，要求项目管理团队必须了解在控制采购期间所采取的任何行动的法律后果。对于有多个供应商的较大项目，合同管理的一个重要方面就是管理各个供应商之间的沟通。
    • 鉴于其法律意义，很多组织都将合同管理视为独立于项目的一种组织职能。虽然采购管理员可以是项目团队成员，但通常还向另一部门的经理报告。
    • 在控制采购过程中，需要开展财务管理工作，包括监督向卖方付款。这是要确保合同中的支付条款得到遵循，确保按合同规定，把付款与卖方的工作进展联系起来。需要重点关注的一点是，确保向卖方的付款与卖方实际已经完成的工作量之间有密切的关系。如果合同规定了基于项目输出及可交付成果来付款，而不是基于项目输入（如工时），那么就可以更有效地开展采购控制。
    • 在合同收尾前，若双方达成共识，可以根据协议中的变更控制条款，随时对协议进行修改。通常要书面记录对协议的修改。
    • ITTO
      • 输入
        • 项目管理计划
          • 需求管理计划
          • 风险管理计划
          • 采购管理计划
          • 变更管理计划
          • 进度基准
        • 项目文件
          • 假设日志
          • 经验教训登记册
          • 里程碑清单
          • 质量报告
          • 需求文件
          • 需求跟踪矩阵
          • 风险登记册
          • 相关方登记册
        • 协议
          • 协议是双方之间达成的谅解，包括对各方义务的一致理解。对照相关协议，确认其中的条款和条件的遵守情况。
        • 采购文档
          • 采购文档包含用于管理采购过程的完整支持性记录，包括工作说明书、支付信息、承包商工作绩效信息、计划、图纸和其他往来函件。
        • 批准的变更请求
          • 批准的变更请求可能包括对合同条款和条件的修改，例如，修改采购工作说明书、定价，以及对产品、服务或成果的描述。与采购相关的任何变更，在通过控制采购过程实施之前，都需要以书面形式正式记录，并取得正式批准。在复杂的项目和项目集中，变更请求可能由参与项目的卖方提出，并对参与项目的其他卖方造成影响。项目团队应该有能力去识别、沟通和解决会影响多个卖方的工作的变更。
        • 工作绩效数据
          • 工作绩效数据包含与项目状态有关的卖方数据，例如，技术绩效，已启动、进展中或已结束的活动，已产生或投入的成本。工作绩效数据还可能包括已向卖方付款的情况。
        • 事业环境因素
        • 组织过程资产
      • 工具与技术
        • 专家判断
        • 索赔管理
          • 如果买卖双方不能就变更补偿达成一致意见，或对变更是否发生存在分歧，那么被请求的变更就成为有争议的变更或潜在的推定变更。此类有争议的变更称为索赔。如果不能妥善解决，它们会成为争议并最终引发申诉。在整个合同生命周期中，通常会按照合同条款对索赔进行记录、处理、监督和管理。如果合同双方无法自行解决索赔问题，则可能不得不按合同中规定的程序，用替代争议解决方法（ADR）去处理。谈判是解决所有索赔和争议的首选方法。
        • 数据分析
          • 绩效审查
            • 对照协议，对质量、资源、进度和成本绩效进行测量、比较和分析，以审查合同工作的绩效。其中包括确定工作包提前或落后于进度计划、超出或低于预算，以及是否存在资源或质量问题。
          • 挣值分析
            • 挣值分析（EVA）计算进度和成本偏差，以及进度和成本绩效指数，以确定偏离目标的程度。
          • 趋势分析
            • 趋势分析可用于编制关于成本绩效的完工估算（EAC），以确定绩效是正在改善还是恶化。关于完工估算方法的详细信息
        • 检查
          • 检查是指对承包商正在执行的工作进行结构化审查，可能涉及对可交付成果的简单审查，或对工作本身的实地审查。在施工、工程和基础设施建设项目中，检查包括买方和承包商联合巡检现场，以确保双方对正在进行的工作有共同的认识。
        • 审计
          • 审计是对采购过程的结构化审查。应该在采购合同中明确规定与审计有关的权利和义务。买方的项目经理和卖方的项目经理都应该关注审计结果，以便对项目进行必要调整。
          • 采购审计是指对从规划采购管理过程到控制采购过程的所有采购过程进行结构化审查。其目的是找出合同准备或管理方面的成功经验与失败教训，供本项目其他采购合同或执行组织内其他项目的采购合同借鉴。
      • 输出
        • 结束的采购
          • 采购关闭，买方通常通过其授权的采购管理员，向卖方发出合同已经完成的正式书面通知。关于正式关闭采购的要求，通常已在合同条款和条件中规定，并包括在采购管理计划中。一般而言，这些要求包括：已按时按质按技术要求交付全部可交付成果，没有未决索赔或发票，全部最终款项已经付清。项目管理团队应该在关闭采购之前批准所有的可交付成果。
        • 工作绩效信息
          • 工作绩效信息是卖方正在履行的工作的绩效情况，包括与合同要求相比较的可交付成果完成情况和技术绩效达成情况，以及与SOW预算相比较的已完工作的成本产生和认可情况。
        • 采购文档更新
          • 采购文档更新可包括用于支持合同的全部进度计划、已提出但未批准的合同变更，以及已批准的变更请求。采购文档还包括由卖方编制的技术文件，以及其他工作绩效信息，例如，可交付成果的状况、卖方绩效报告和担保、财务文件（包括发票和支付记录），以及与合同相关的检查结果。
        • 变更请求
        • 项目管理计划更新
          • 风险管理计划
          • 采购管理计划
          • 进度基准
          • 成本基准
        • 项目文件更新
          • 经验教训登记册
          • 资源需求
          • 需求跟踪矩阵
          • 风险登记册
          • 相关方登记册
        • 组织过程资产更新
          • 作为控制采购过程的结果，需要更新的组织过程资产包括（但不限于）
            • 支付计划和请求
              • 所有支付都应按合同条款和条件进行。
            • 卖方绩效评估文件
              • 卖方绩效评估文件由买方准备，用于记录卖方继续执行当前合同工作的能力，说明是否允许卖方承接未来的项目，或对卖方现在的项目执行工作或过去的执行工作进行评级。
            • 预审合格卖方清单更新
              • 预审合格卖方清单是以前已经通过资格审查（获得批准）的潜在卖方的清单。因为卖方可能因绩效不佳而被取消资格并从清单中删除，所以应该根据控制采购过程的结果来更新这个清单。
            • 经验教训知识库
              • 经验教训应该归档到经验教训知识库中，以改善未来项目的采购工作。在合同执行终了时，应把采购的实际成果与原始采购管理计划中的预期成果进行比较。应该在经验教训中说明项目目标是否达成；若未达成，则说明原因。
            • 采购档案
              • 应该准备好带索引的全套合同文档，包括已关闭的合同，并将其纳入最终的项目档案。
• 项目相关方管理
  • 概述说明
    • 相关方满意度应作为项目目标加以识别和管理。有效引导相泪关方参与的关键是重视与所有相关方保持持续沟通（包括团队成员），以理解他们的需求和期望处理所发生的问题、管理利益冲突，并促进相关方参与项目决策和活动。
    • 在敏捷或适应型环境中需要考虑的因素
      • 高度变化的项目更需要项目相关方的有效互动和参与。为了开展及时且高效的讨论及决策，适应型团队会直接与相关方互动，而不是通过层层的管理级别。客户、用户和开发人员在动态的共创过程中交换信息，通常能实现更高的相关方参与和满意程度。在整个项目期间保持与相关方社区的互动，有利于降低风险、建立信任和尽早做出项目调整，从而节约成本，提高项目成功的可能性。
      • 为加快组织内部和组织之间的信息分享，敏捷型方法提倡高度透明。例如，邀请所有相关方参与项目会议和审查，或将项目工件发布到公共空间，其目的在于让各方之间的不一致和依赖关系，或者与不断变化的项目有关的其他问题，都尽快浮现。
  • 识别相关方
    • 识别相关方是定期识别项目相关方，分析和记录他们的利益、参与度、相互依赖性、影响力和对项目成功的潜在影响的过程。本过程的主要作用是，使项目团队能够建立对每个相关方或相关方群体的适度关注。
    • 本过程通常在编制和批准项目章程之前或同时首次开展。本过程需在必要时重复开展，至少应在每个阶段开始时，以及项目或组织出现重大变化时重复开展。每次重复开展本过程，都应通过查阅项目管理计划组件及项目文件，来识别有关的项目相关方。
    • ITTO
      • 输入
        • 项目章程
          • 项目章程会列出关键相关方清单，还可能包含与相关方职责有关的信息。
        • 商业文件
          • 商业论证
            • 商业论证确定项目目标，以及受项目影响的相关方的最初清单。
          • 效益管理计划
            • 收益管理计划描述了如何实现商业论证中所述收益。它可能指出将从项目成果交付中获益并因此被视为相关方的个人及群体。
        • 项目管理计划
          • 沟通管理计划
          • 相关方参与计划
        • 项目文件
          • 变更日志
          • 问题日志
          • 需求文件
        • 协议
          • 协议的各方都是项目相关方，还可涉及其他相关方。
        • 事业环境因素
        • 组织过程资产
      • 工具与技术
        • 专家判断
        • 数据收集
          • 问卷调查
            • 问卷和调查可以包括一对一调查、焦点小组讨论，或其他大规模信息收集技术。
          • 头脑风暴
            • 头脑风暴
              • 一种通用的数据收集和创意技术，用于向小组征求意见，如团队成员或主题专家。
            • 头脑写作
              • 头脑风暴的改良形式，让个人参与者有时间在小组创意讨论开始前单独思考问题。
              • 只需每个人把想法写下来，然后以匿名的方式进行传递，添加修改。
              • 适合团队中内向性格的成员多。
        • 数据分析
          • 相关方分析
            • 相关方分析会产生相关方清单和关于相关方的各种信息，例如，在组织内的位置、在项目中的角色、与项目的利害关系、期望、态度（对项目的支持程度），以及对项目信息的兴趣。
            • 相关方的利害关系可包括（但不限于）以下各条的组合
              • 兴趣
                • 个人或群体会受与项目有关的决策或成果的影响。
              • 权利（合法权利或道德权利）
                • 国家的法律框架可能已就相关方的合法权利做出规定，如职业健康和安全。道德权利可能涉及保护历史遗迹或环境的可持续性。
              • 所有权
                • 人员或群体对资产或财产拥有的法定所有权。
              • 知识
                • 专业知识有助于更有效地达成项目目标和组织成果，或有助于了解组织的权力结构，从而有益于项目。
              • 贡献
                • 提供资金或其他资源，包括人力资源，或者以无形方式为项目提供支持，例如，宣传项目目标，或在项目与组织权力结构及政治之间扮演缓冲角色。
            • 补充：相关方分析产出
              • 相关方清单
              • 相关方信息
                • 组织位置
                • 项目角色
                • 利害关系
                  • 兴趣
                    • 受到影响
                      • 项目决策
                      • 项目成果
                  • 权利
                    • 合法权利
                    • 道德权利
                  • 所有权
                  • 知识
                  • 贡献
                • 期望
                • 态度
                • 对信息兴趣
          • 文件分析
            • 评估现有项目文件及以往项目的经验教训，以识别相关方和其他支持性信息。
        • 数据表现
          • 相关方映射分析/表现
            • 相关方映射分析和表现是一种利用不同方法对相关方进行分类的方法。对相关方进行分类有助于团队与已识别的项目相关方建立关系。
            • 常见的分类方法包括
              • 权力利益方格、权力影响方格，或作用影响方格
                • 基于相关方的职权级别（权力）、对项目成果的关心程度（利益）、对项目成果的影响能力（影响），或改变项目计划或执行的能力，每一种方格都可用于对相关方进行分类。对于小型项目、相关方与项目的关系很简单的项目，或相关方之间的关系很简单的项目，这些分类模型非常实用。
              • 相关方立方体
                • 这是上述方格模型的改良形式。本立方体把上述方格中的要素组合成三维模型，项目经理和团队可据此分析相关方并引导相关方参与项目。作为一个多维模型，它将相关方视为一个多维实体，更好地加以分析，从而有助于沟通策略的制定。
          • 凸显模型
            • 通过评估相关方的权力（职权级别或对项目成果的影响能力）、紧迫性（因时间约束或相关方对项目成果有重大利益诉求而导致需立即加以关注）和合法性（参与的适当性）对相关方进行分类。在凸显模型中，也可以用邻近性取代合法性，以便考察相关方参与项目工作的程度。这种凸显模型适用于复杂的相关方大型社区，或在相关方社区内部存在复杂的关系网络。凸显模型可用于确定已识别相关方的相对重要性。
            • • 分类标准
                • 权力（职权级别或对项目成果的影响能力）
                • 紧迫性（因时间约束或相关方对项目成果有重大利益诉求而导致需立即加以关注）
                • 合法性（参与的适当性）
              • 适用条件
                • 复杂的相关方大型社区
                • 相关方社区内部存在复杂的关系网络
              • 主要作用
                • 确定已识别相关方的相对重要性
              • 应对措施
                • A）Core（确定型）：这些是关键的项目相关方。作为一个项目经理，你需要集中关注这些相关方。
                • B）Dominant（支配型）：这样的项目相关方有权力和合法性，但没有紧迫感。你应该关注他们的期望，但总是没有太多的紧迫性。
                • C）Dependent（依赖型）：根据显著性模型，这些项目相关方对项目没有真正的权力。然而，他们需要被管理，因为他们可以很容易地选择与其他项目相关方结盟，从而影响您的项目。
                • D）Dangerous（危险型）：适当命名的分类，这些利益相关者有权力和紧迫性，但没有合法性。想象一下，一个非常资深的人试图将她的观点强加给你的项目结果，而不是真正参与其中!项目经理需要使这些干系人适当地参与或满意。
                • E）Latent（潜伏型）：可能是项目干系人的最佳类别。这些干系人只有在项目出现严重问题时才会进入项目。与他们过度沟通微观层面的细节也不是一件好事。
                • F）Demanding（苛求型）：在突出模型中，这样的利益相关者似乎总是认为他们的工作需要你的立即关注。如果您在这些涉众身上花费了太多的时间和精力，那么您实际上不会获得太多的项目里程。还有其他更重要的人要合作。
                • G）Discretionary（自住型）：项目干系人的另一个很好的分类。定期更新他们的状态，他们会很高兴的。
                • H）Non-stakeholders（非相关方）：这些人不是项目的干系人。在这样的人身上投入时间和精力无论如何都不会帮助你塑造项目的结果。
          • 影响方向
            • 可以根据相关方对项目工作或项目团队本身的影响方向，对相关方进行分类。
            • 可以把相关方分类为
              • 向上（执行组织或客户组织、发起人和指导委员会的高级高级管理层）
              • 向下（临时贡献知识或技能的团队或专家）
              • 向外（项目团队外的相关方群体及其代表，如供应商、政府部门、公众、最终用户和监管部门）
              • 横向（项目经理的同级人员，如其他项目经理或中层管理人员，他们与项目经理竞争稀缺项目资源或者合作共享资源或信息）
          • 优先级排序
            • 如果项目有大量相关方、相关方社区的成员频繁变化，相关方和项目团队之间或相关方社区内部的关系复杂，可能有必要对相关方进行优先级排序。
        • 会议
      • 输出
        • 相关方登记册
        • 变更请求
        • 项目管理计划更新
          • 需求管理计划
          • 沟通管理计划
          • 风险管理计划
          • 相关方参与计划
        • 项目文件更新
          • 假设日志
          • 问题日志
          • 风险登记册
  • 规划相关方参与
    • 规划相关方参与是根据相关方的需求、期望、利益和对项目的潜在影响，制定项目相关方参与项目的方法的过程。本过程的主要作用是，提供与相关方进行有效互动的可行计划。
    • ITTO
      • 输入
        • 项目章程
        • 项目管理计划
          • 资源管理计划
          • 沟通管理计划
          • 风险管理计划
        • 项目文件
          • 假设日志
            • 假设日志中关于假设条件和制约因素的信息，可能与特定相关方相关联。
          • 变更日志
            • 变更日志记录了对原始项目范围的变更。变更通常与具体相关方相关联，因为相关方可能是：变更请求的提出者，变更请求的审批者，或受变更实施影响者。
          • 问题日志
            • 为了管理和解决问题日志中的问题，需要与受影响的相关方进行额外沟通。
          • 项目进度计划
            • 进度计划中的活动可能需要与具体相关方相关联，即把特定相关方指定为活动责任人或执行者。
          • 风险登记册
            • 风险登记册包含项目的已识别风险，它通常会把这些风险与具体相关方相关联，即把特定相关方指定为风险责任人或受风险影响者。
          • 相关方登记册
            • 相关方登记册提供项目相关方的清单，以及分类情况和其他信息。
        • 协议
        • 事业环境因素
        • 组织过程资产
      • 工具与技术
        • 专家判断
        • 数据收集
          • 标杆对照
        • 数据分析
          • 假设条件和制约因素分析
            • 可能需要分析当前的假设条件和制约因素，以合理剪裁相关方参与策略。
          • 根本原因分析
            • 开展根本原因分析，识别是什么根本s原因导致了相关方对项目的某种支持水平，以便选择适当策略来改进其参与水平。
        • 决策
          • 优先级排序/分级
            • 应该对相关方需求以及相关方本身进行优先级排序或分级。具有最大利益和最高影响的相关方，通常应该排在优先级清单的最前面。
        • 数据表现
          • 思维导图
            • 思维导图用于对相关方信息、相互关系以及他们与组织的关系进行可视化整理。
          • 相关方参与度评估矩阵
            • 相关方参与度评估矩阵。相关方参与度评估矩阵用于将相关方当前参与水平与期望参与水平进行比较。对相关方参与水平进行分类的方式之一。
            • 相关方参与水平可分为如下
              • 不了解型
                • 不知道项目及其潜在影响。
              • 抵制型
                • 知道项目及其潜在影响，但抵制项目工作或成果可能引发的任何变更。此类相关方不会支持项目工作或项目成果。
              • 中立型
                • 了解项目，但既不支持，也不反对。
              • 支持型
                • 了解项目及其潜在影响，并且会支持项目工作及其成果。
              • 领导型
                • 了解项目及其潜在影响，而且积极参与以确保项目取得成功。
              • • 在图中，C代表每个相关方的当前参与水平，而D是项目团队评估出来的、为确保项目成功所必不可少的参与水平（期望的）。应根据每个相关方的当前与期望参与水平的差距，开展必要的沟通，有效引导相关方参与项目。弥合当前与期望参与水平的差距是监督相关方参与中的一项基本工作。
        • 会议
      • 输出
        • 相关方参与计划
          • 相关方参与计划是项目管理计划的组成部分。它确定用于促进相关方有效参与决策和执行的策略和行动。基于项目的需要和相关方的期望，相关方参与计划可以是正式或非正式的，非常详细或高度概括的。
          • 相关方参与计划可包括(但不限于)调动个人或相关方参与的特定策略或方法。
        • 干系人管理计划
          • 干系人管理计划是项目管理计划的组成部分，为有效调动干系人参与而规定所需的管理策略。根据项目的需要，干系人管理计划可以是正式或非正式的，非常详细或高度概括的。
          • 除了干系人登记册中的资料，干系人管理计划通常还包括
            • 关键干系人的所需参与程度和当前参与程度
            • 干系人变更的范围和影响
            • 干系人之间的相互关系和潜在交叉
            • 项目现阶段的干系人沟通需求
            • 需要分发给干系人的信息，包括语言、格式、内容和详细程度
            • 分发相关信息的理由，以及可能对干系人参与所产生的影响
            • 向干系人分发所需信息的时限和频率
            • 随着项目的进展，更新和优化干系人管理计划的方法
          • 项目经理应该意识到干系人管理计划的敏感性，并采取恰当的预防措施。例如，有关那些抵制项目的干系人的信息，可能具有潜在的破坏作用，因此对于这类信息的发布必须特别谨慎。更新干系人管理计划时，应审查所依据的假设条件的有效性，以确保该计划的准确性和相关性。
  • 管理相关方参与
    • 管理相关方参与是与相关方进行沟通和协作以满足其需求与期望、处理问题，并促进相关方合理参与的过程。本过程的主要作用是，让项目经理能够提高相关方的支持，并尽可能降低相关方的抵制。
    • 在管理相关方参与过程中，需要开展多项活动
      • 在适当的项目阶段引导相关方参与，以便获取、确认或维持他们对项目成功的持续承诺
      • 通过谈判和沟通管理相关方期望
      • 处理与相关方管理有关的任何风险或潜在关注点，预测相关方可能在未来引发的问题
      • 澄清和解决已识别的问题
    • 管理相关方参与有助于确保相关方明确了解项目目的、目标、收益和风险，以及他们的贡献将如何促进项目成功。
    • ITTO
      • 输入
        • 项目管理计划
          • 沟通管理计划
            • 沟通管理计划描述与相关方沟通的方法、形式和技术。
          • 风险管理计划
            • 风险管理计划描述了风险类别、风险偏好和报告格式。这些内容都可用于管理相关方参与。
          • 相关方参与计划
            • 相关方参与计划为管理相关方期望提供指导和信息。
          • 变更管理计划
            • 变更管理计划描述了提交、评估和执行项目变更的过程。
        • 项目文件
          • 变更日志
            • 变更日志会记录变更请求及其状态，并将其传递给适当的相关方。
          • 问题日志
            • 问题日志会记录项目或相关方的关注点，以及关于处理问题的行动方案。
          • 经验教训登记册
            • 在项目早期获取的与管理相关方参与有关的经验教训，可用于项目后期阶段，以提高本过程的效率和效果。
          • 相关方登记册
            • 相关方登记册提供项目相关方清单，以及执行相关方参与计划所需的任何信息。
        • 事业环境因素
        • 组织过程资产
      • 工具与技术
        • 专家判断
        • 沟通技能
          • 反馈
            • 在开展管理相关方参与过程时，应该根据沟通管理计划，针对每个相关方采取相应的沟通方法。项目管理团队应该使用反馈机制，来了解相关方对各种项目管理活动和关键决策的反应。
        • 人际关系与团队技能
          • 冲突管理
            • 项目经理应确保及时解决冲突。
          • 文化意识
            • 文化意识有助于项目经理和团队通过考虑文化差异和相关方需求，来实现有效沟通。
          • 谈判
            • 谈判用于获得支持或达成关于支持项目工作或成果的协议，并解决团队内部或团队与其他相关方之间的冲突。
          • 观察/交谈
            • 通过观察和交谈，及时了解项目团队成员和其他相关方的工作和态度。
          • 政治意识
            • 通过了解项目内外的权力关系，建立政治意识。
        • 基本规则
          • 根据团队章程中定义的基本规则，来明确项目团队成员和其他相关方应该采取什么行为去引导相关方参与。
        • 会议
          • 会议用于讨论和处理任何与相关方参与有关的问题或关注点。
          • 在本过程中需要召开的会议类型包括（但不限于）
            • 决策
            • 问题解决
            • 经验教训和回顾总结
            • 项目开工
            • 迭代规划
            • 状态更新
      • 输出
        • 变更请求
        • 项目管理计划更新
          • 沟通管理计划
            • 需要更新沟通管理计划，以反映新的或已变更的相关方需求。
          • 相关方参与计划
            • 需要更新相关方参与计划，以反映为有效引导相关方参与所需的新的或更改的管理策略。
        • 项目文件更新
          • 变更日志
            • 根据变更请求更新变更日志。
          • 问题日志
            • 可能需要更新问题日志，以反映问题日志条目的更新或添加。
          • 经验教训登记册
            • 更新经验教训登记册记录管理相关方参与的有效或无效方法，以供当前或未来项目借鉴。
          • 相关方登记册
  • 监督相关方参与
    • 监督相关方参与是监督项目相关方关系，并通过修订参与策略和计划来引导相关方合理参与项目的过程。本过程的主要作用是，随着项目进展和环境变化，维持或提升相关方参与活动的效率和效果。
    • ITTO
      • 输入
        • 项目管理计划
          • 资源管理计划
          • 沟通管理计划
          • 相关方参与计划
        • 项目文件
          • 问题日志
            • 问题日志记录了所有与项目和相关方有关的已知问题。
          • 经验教训登记册
            • 在项目早期获取的经验教训，可用于项目后期阶段，以提高引导相关方参与的效率和效果。
          • 项目沟通记录
            • 根据沟通管理计划和相关方参与计划而与相关方开展的项目沟通，都已包括在项目沟通记录中。
          • 风险登记册
            • 风险登记册记录了与相关方参与及互动有关的风险，它们的分类，以及潜在的应对措施。
          • 相关方登记册
            • 相关方登记册记录了各种相关方信息，包括（但不限于）：相关方名单、评估结果和分类情况。
        • 工作绩效数据
        • 事业环境因素
        • 组织过程资产
      • 工具与技术
        • 数据分析
          • 备选方案分析
            • 在相关方参与效果没有达到期望要求时，应该开展备选方案分析，评估应对偏差的各种备选方案。
          • 根本原因分析
            • 开展根本原因分析，确定相关方参与未达预期效果的根本原因。
          • 相关方分析
            • 开展相关方分析，确定相关方群体和个人在项目任何特定时间的状态。
        • 决策
          • 多标准决策分析
            • 对考察相关方参与的成功程度的多种标准进行优先级排序和加权，识别出最适当的选项。
          • 投票
            • 通过投票，选出应对相关方参与水平偏差的最佳方案。
        • 数据表现
          • 相关方参与度评估矩阵
            • 使用相关方参与度评估矩阵，来跟踪每个相关方参与水平的变化，对相关方参与加以监督。
        • 沟通技能
          • 反馈
            • 反馈用于确保发送给相关方的信息被接收和理解。
          • 演示
            • 演示为相关方提供清晰的信息。
        • 人际关系与团队技能
          • 积极倾听
            • 通过积极倾听，减少理解错误和沟通错误。
          • 文化意识
            • 文化意识和文化敏感性有助于项目经理依据相关方和团队成员的文化差异和文化需求对沟通进行规划。
          • 领导力
            • 成功的相关方参与，需要强有力的领导技能，以传递愿景并激励相关方支持项目工作和成果。
          • 人际交往
            • 通过人际交往了解关于相关方参与水平的信息。
          • 政治意识
            • 政治意识有助于理解组织战略，理解谁能行使权力和施加影响，以及培养与这些相关方沟通的能力。
        • 会议
      • 输出
        • 工作绩效信息
        • 变更请求
          • 变更请求可能包括用于改善相关方当前参与水平的纠正及预防措施。应该通过实施整体变更控制过程对变更请求进行审查和处理。
        • 项目管理计划更新
          • 资源管理计划
            • 可能需要更新团队对引导相关方参与的职责。
          • 沟通管理计划
            • 可能需要更新项目的沟通策略。
          • 相关方参与计划
            • 可能需要更新关于项目相关方社区的信息。
        • 项目文件更新
          • 问题日志
          • 经验教训登记册
          • 风险登记册
          • 相关方登记册

敏捷部分

• 基础内容
  • 敏捷宣言
    • 2001年，软件业思想领袖共同发表《敏捷宣言》，正式宣告敏捷开发运动的开始。我们正在通过亲自开发和帮助他人开发，发现开发软件的更好方法。
    • 通过这项工作，我们开始更重视《敏捷宣言》四大价值观：
      • 个体以及互动而不是过程和工具
        • 要让每一个自组织团队都选择最适合他们的勺工具。
        • 各种敏捷工具、方法论和流程的选择非常多，你应该尽力做到都尝试一遍。
        • 工具和流程可是很棒很有用的东西，但必须要放对地方，要让使用者来掌控它们。流程和工具必须是为人服务的，而不是反过来。
      • 可用的软件而不是完整的文档
        • 大多数产品来说，用户文档都是很有价值的组成部分。但如果关注焦点不再是产品本身，而变成了流程文档，那就有问题了。
        • 如果在开发流程刚开始的时候，你对前期详尽文档太过投入，那就会错失检验和适应的良机，无法做到不断地从错误中学习并调整流程和需求。
        • 人们普遍误以为敏捷团队是不写文档不做计划刘的，但实际上，敏捷团队为规划和文档工作所花费的时间、精力]远多于传统团队，因为计划需要不断地进行细化和更新。
      • 客户合作而不是合同谈判
        • 承包商的出价通常就是份赌注：，赌他们能够在一定时间内完成工作，而利润则取决于他们能否多快好省地满足客户最低要求，招标合同只能承载温和的对立关系。
        • 敏捷宣言的作者们最终得出结论，基于合同的项目侧重方向不对。他们更喜欢采用时间材料模式，相关各方就像是一群合伙人，齐心协力在规定时间和预算范围内努力构建最有价值的系统。降低客户风险，不是靠前期担保方式转嫁风险给承包商，而是依靠流程中客户的持续参与，以及敏捷团队定期交付可工作软件增量的能力。
      • 应对变更而不是遵循计划
        • 计划驱动型组织通常都有“变化控制”流程，设计的初衷很美好，预防使命蔓延、特性蔓延以及其他各种形式的超支和延的寸影响目。
        • 软件开发的世界里，变化就像海上的天气一样不可可避免，因而理所当然的，认为变化是好事的流程就是最好的流程。
        • 软件项目的规划必须是流动而非固定的，这是为了团队好，但主要是为了产品的好，最终是为了客户的好。因而你需要为变化做计划，还要改变你的计划。
        • 敏捷实践者乐于指出，传统软件开发方法是计划驱动，敏捷项目是规划驱动的区别。
      • 源自这些价值观的十二大原则
        • 1、我们最重要的目标，是通过持续不断地及早交付有有价值的软件使客户满意。
          • 重点关注：客户满意
          • 实践要点：持续交付尽早交付
        • 2、欢迎需求变化，即使在开发后期也一样。善于掌控空变化，帮助客户获得竞争优势。
          • 重点关注：帮助客户获得竞争优势
          • 实践要点：拥抱变化实现软件灵活性良好设计及实践
        • 3、经常地交付可工作的软件，相隔几星期或几个月倾向于采取较短的周期。
          • 重点关注：经常交付
          • 实践要点：频繁交付快速交付时间越短越好
        • 4、项目过程中，业务人员和开发人员必须每天在一起工作。
          • 重点关注：客户协作
          • 实践要点：现场客户频繁沟通
        • 5、要善于激发项目人员，给他们所需的环境和支持，并相信他们能够达成目标。
          • 重点关注：激励团队
          • 实践要点：提供环境提供支持充分信任
        • 6、在团队内部，传递信息效果最高效的方式是面对面的交谈。
          • 重点关注：面对面沟通
          • 实践要点：尽可能面对面分布式团队可利用在线技术
        • 7、可工作的软件是进度的首要度量标准。
          • 重点关注：进度度量
          • 实践要点：可工作的软件而非已完成的代码量
        • 8、敏捷过程倡导可持续开发。责任人、开发人员和用户应该能够保持恒久稳定的进展速度。
          • 重点关注：可持续开发稳定的步调
          • 实践要点：不透支精力基于平均速率
        • 9、对技术精益求精，对设计不断完善，将提高敏捷能力。
          • 重点关注：技术精益求精设计不断完善
          • 实践要点：技术卓越良好设计保持代码简洁重构
        • 10、要做到简洁，即要尽最大可能减少不必要的工作，这是一门艺术。
          • 重点关注：简洁最小化工作
          • 实践要点：工作围绕客户需求开展不构建华而不实功能
        • 11、最好的架构、需求和设计出自于自组织的团队。
          • 重点关注：自组织
          • 实践要点：团队自主共同责任相互协作渐进方式
        • 12、团队定期地反省如何能提高成效，并由此调整团队的行为。
          • 重点关注：定期反省作出调整
          • 实践要点：定期回顾验证与适应持续改善
    • 也就是说，右栏中的项目固然有价值，但我们更重视左栏中的项目。
  • 项目生命周期
    • 预测型生命周期
      • 预测型生命周期预计会从高确定性的明确的需求、稳定的团队和低风险中获益。团队需要详细的计划，了解要交付什么以及怎样交付。当其他潜在变更受到限制时，这些项目就会成功。
      • 团队领导的目标是尽可能减少预测型项目的变更。团队在项目开始时创建详细的需求和计划时，他们可以阐明各种制约因素。然后，团队可以利用这些制约因素管理风险和成本。进而，团队在实施详细计划时，他们会监督并控制可能影响范围、进度计划或预算的变更。
      • 预测型项目强调根据部门划分的、有效的、顺序的工作，并且通常不会会在项目结束前交付商业价值。如果遇到变更或需求分歧，或者技术解决方案变得不再简单明了，预测型项目目就将产生意想不到的成本。
    • 迭代
      • 迭代型生命周期，迭代方法是通过一系列重复的循环活动来开发产品。
      • 迭代型生命周期通过连续的原型或概念验证来改进产品或成果。每一个新的原型都能带来新的相关方新的反馈和团队见解。然后，团队在下一周期重复一个或多个项目活动，在其中纳入新的信息。团队可能会在长达数周时间的一个特定迭代中使用时间盒，集中各种见解，然后根据这些见解对活动进行返工。这样，迭代有利于识别和减少项目的不确定性。
      • 当项目复杂性高、变更频繁或当项目范围受到相关方对所需最终产品的不同观点的支配时，采用迭代型生命周期会有优势。迭代型生命周期可能需要更长的时间，因为它是为学习而优化，而不是为交付速度而优化。
    • 增量
      • 增量型生命周期是通过在预定的时间区间内渐进增加产品功能的一系列迭代。来产出可交付成果。
      • 有些项目优化是为了加快交付速度。许多企业和项目无法等待所有的事情全部完成；这种情况下，客户愿意接受整个解决方案的一个部分。这种少量可交付成果的频繁交付称为增量型生命周期。
      • 与一次交付一个最终产品相比，增量型生命周期将经常优化为项目发起人或客户交付价值的工作。在开始工作之前，团队就计划了最初的可交付成果，他们还会尽快开始第一次交付的工作。
      • 例如，在继续修建大楼的其余部分之前，施工人员可能希望先展示一间已完工的房间或一层楼。这种情况下，在继续修建大楼的下一层前，他们可能会为已完工的楼层布置家具、刷漆等。客户可以查看和批准有关样式、颜色和其他细节，以便在进一步投入时间和金钱之前做出相应的调整。这样做将减少潜在的返工和/或客户的不满。
    • 适应型
      • 适应型生命周期（也称为变更驱动或敏捷方法），其目的在于应对大量变更，获取相关方的持续参与。适应型生命周期也包含迭代和增量的概念，但不同之处在于，迭代很快（通常2-4周迭代一次），并且所需时间和资源是固定的。
        • 需要应对快速变化的环境
        • 需求和范围难以确定
        • 能够以有利于相关方的方式定义较小的增量改进
      • 敏捷（适应）
        • 在敏捷环境中，团队预料需求会发生变更。迭代和增量方法能够提供反馈，以便改善项目下一部分的计划。不过，在敏捷项目中，增量交付会发现隐藏或误解的需求。
        • 在基于迭代的敏捷中，团队以迭代（相等持续时间的时间盒）形式交付完整的功能。团队集中于最重要的功能，作为一个团队合作完成其工作。然后，团队再集中于下一项最重要的功能，并合作完成其工作。团队可决定一次进行若干功能的开发工作，但团队不会同时完成所有的迭代工作（即团队不会在完成全部分析等工作后再解决所有需求）。
    • 四种生命周期的特点
      • 不确定性和复杂性模型
    • 混合生命周期
      • 对于整个项目，没有必要使用单一的方法。为达到特定的目标，项目经常要结合不同的生命周期要素。预测、迭代、增量和/或敏捷方法的组合就是一种混合方法。
      • 针对不同项目类型的基本的、单一的方法，它们结合起来就形成一种混合模型。早期过程采用了一个敏捷开发生命周期，之后往往是一个预测型的发布阶段。当项目可以从敏捷方法中受益并且项目的开发部分中存在不确定性、复杂性和风险时，可以使用这种方法，然后是一个明确的、可重复的发布阶段，该阶段适合采用预测方法进行，可能由不同的团队实施。这种方法的一个例子是，开发某种新的高科技产品，然后面向成千上万的用户推出，并对他们进行培训。
      • 以预测法为主、敏捷方法为辅的方法
        • 一个以预测法为主的项目中一个小的敏捷要素。在这种情况下，以敏捷方法处理具有不确定性、复杂性或范围蔓延机会项目的一部分，而使用预测法管理项目的其余部分。这种方法的一个例子是，某工程公司正在使用一个新的组件建造一个设施。
        • 虽然大部分项目可能是常规的、可预测的，就像组织实施的许多其它的设施项目一样，但这个项目包含了一种新的屋顶材料。承包商可能计划首先在地面上进行一些小规模的安装试验，以确定最佳的安装方法，并在有足够时间解决问题时尽早发现问题，随后通过试验和调整，增量地改进过程。
      • 以敏捷方法为主、预测法为辅的方法
        • 一个以敏捷方法为主、预测法为辅的方法。当某个特定要素不可协商，或者使用敏捷方法不可执行时，可能会使用这种方法。这种情况的例子包括，集成由不同供应商开发的外部组件，这些外部组件不能或不会以协作或增量方式合作。在组件交付之后，需要单独集成。
      • 符合目的的混合生命周期
        • 项目团队可能基于项目风险设计一个混合生命周期。例如，某校园建设项目可能会有多个建筑需要改善和建设。增量方法会将资源集中，使某些建筑比其他建筑更早完工，从而加快投资回报。众所周知，每个建筑的独自交付都能得益于该建筑独自采用预测型生命周期。
        • 项目管理的目标是在给定的当前环境下尽可能以最好的方式创造商业价值。项目采用敏捷方法亦或预测法，都无关紧要。要提出的问题是：“我们怎样做才能最成功?”
        • 当团队创造价值时，是否需要反馈?如果需要，增量方法将会有所帮助。在探讨各种想法时，是否需要管理风险?如果需要，迭代方法或敏捷方法将会有所帮助。
        • 当组织无法交付中间价值时，敏捷方法可能不是很有用。这样没有问题，但为了敏捷而敏捷并不是目标。关键在于，要选择一个对项目、风险和文化管理有用的生命周期或生命周期的组合。
        • 敏捷关乎频繁向客户交付。而这种交付要给团队带来反馈。团队利用上述反馈规划并重新规划下一部分的工作。
        • 举例
          • 某政府部门有一个信贷保险申请开发项目。这个多年期项目使用新的、响应能力更强的用户界面和系统集成来取代其过时的保险体系。项目的大部分使用敏捷方法实施，并伴有持续的业务输入。
          • 保险费率根据经济合作与发展组织（OECD）下发的一个200页的规范进行计算。计算步骤解释非常清楚，几乎不会有混淆机会（也几乎没有中间结果需要企业确认），并且计算步骤的编码是由一个独立团队完成。两个团队合作计算所需的输入变量，以及如何使用和显示输出值，但除此之外，计算团队在很大程度上以预测的方式工作。
      • 混合型生命周期作为过渡策略
        • 许多团队无法在一夜之间切换到敏捷工作方式。对于那些已经习惯于预测型环境、并在其中获得成功的人士，敏捷技术的观感截然不同。组织越大，活动部件越多，转换需要的时间就越长。因此，计划一个渐进的过渡是有意义的。
        • 渐进的过渡涉及到要增加更多的迭代技术，以便改进学习，加强团队和相关方的一致性。之后，还要考虑增加更多的增量技术，以加快对发起人的价值和投资回报。上述各种方法的组合被视为一种混合方法。
        • 可以先在一个风险不大、具有中低程度不确定性的项目中尝试这些新技术。在组织成功地使用混合方法后，再尝试更复杂的项目，这些项目需要增加更多的技术。这是一种根据组织的情况、特定的风险，以及团队适应并接受变革的就绪情况而调整的渐进混合过渡。
      • 混合敏捷方法
        • 敏捷团队很少将其实践局限于一种敏捷方法。每个项目背景都有其各自的独特性，比如团队成员技能和背景的不同组合；开发中的产品的各个组成部分；以及工作环境中的年龄、规模、关键性、复杂性和监管制约因素等。敏捷框架并不是针对团队定制的。为了定期交付价值，团队可能需要对实践进行裁剪。通常，团队都会实践各自特殊的敏捷组合，即便他们使用一个特定的框架作为起点也不例外。
        • 协调方法：裁剪敏捷框架的一个例子是，一个广泛使用的常见协调方法涉及到协调使用Scrum框架、看板方法和极限编程（XP）方法的要素。Scrum为产品待办事项列表、产品负责人、Scrum主管以及跨职能开发团队的使用提供指导，包括冲刺计划、每日例会、冲刺评审和冲刺回顾会议。看板面板帮助团队进一步提高效率，方法是将工作流可视化、使障碍更容易被察觉，以及通过调整在制品限制来实现流程管理。此外，受极限编程启发的工程实践，如使用故事卡、持续集成、重构、自动化测试和测试驱动开发，将进一步提高敏捷团队的效力。总之，与孤立采用各种实践相比，协调这些不同来源的实践将产生更好的协同成果。
  • 影响裁剪的项目因素
  • 典型敏捷流程
    • • 可行性阶段
        • 主要完成项目愿景和商业论证。
          • 项目愿景
            • 我们为什么要做这个项目?这是项目愿景。
          • 商业论证
            • 商业论证开发是敏捷项目管理中重要的起步点。商业论证是对项目的构想、目标、达到目的策略、重大事件、所需投资和预期回收所做的简明概要文件。商业论证向客户阐明了该项目为什么以及怎样带来价值。对于商业项目，价值通常使用如投资回报率（ROI）、内部收益率（IRR）、净现值（NPV）和回收期来评估。
      • 启动阶段
        • 主要完成项目章程，创建待办事项、高层级估算，产品路线图。
          • 项目章程
            • 轻量级。
          • 待办事项列表
            • 需求项是以用户故事的形式来表述的。
          • 高层级估算
            • 又亲和估算，使用T恤衫尺码（如S、M、L、XL、XXL等）或者咖啡杯尺寸（如小杯、中杯、大杯、超大杯等）来表示某个需求项的相对工作量大小。
          • 产品路线图
            • 利用故事地图来创建。用户故事地图展示产品路线图
        • 优先级评价
          • 要根据业务价值确定优先级，确定新能力的开发活动优先级时必须考虑的4个因素。
            • 获得这些功能带来的经济价值。
            • 开发（可能还包含支持）新功能所需的成本。
            • 开发新功能所产生的学习和知识的量及重要性。
            • 开发这些功能所减少的风险。
          • 由于大多数项目是为了节约开支或者赚钱，因此前两个因素常常在优先级讨论中占主导地位。然而，如果想最优地确定优先级，对学习和风险的适当考虑也是很重要的。
          • 确定经济优先级
            • 净现值
            • 内部收益率
            • 回收期
            • 贴现回收期
          • 确定合意性优先级（替代价值估计方法）
            • Kano分析
              • 惊喜属性
                • 有时候称为魅力属性。这些特性的交付是客户未预料到的、与众不同的或者可以带来高价值的好处，可能给客户带来竞争力和高满意度。
              • 满意属性
                • 作为满意的特性，越多越好。这些特性会给客户带来价值、创造竞争优势，大部分的竞争都聚焦在这个属性的领域。
              • 不满意属性
                • 这些特性必须具备，如果这些特性不具备，客户就不会喜欢这个产品，但是即使这些特性存在，也不会提升客户的满意度。
              • 无关紧要属性
                • 这些特性无论从哪方面来说对客户都没有影响。因为客户对其根本就不关心，我们应该尝试着消除、最小化或者延迟交付这些特性，比如一个外观很漂亮的电脑硬盘。
            • 相对权重
            • MoSCoW方法
              • MoSCoW技术把用户故事以降序方式进行优先顺序排列
                • M-must have，即必须有的；“必须有的”需求和特性是系统的必需组成部分，是对开发很重要的产品特征，没有这些系统将不能正常工作或者不能增加价值。
                • S-should have，即应该有的；“应该有的内”特性也非常重要，对开发不是很重要但有重要商业价值的产品特征。如果缺少这些特性，解决方法会变得烦琐或昂贵。
                • C-couldhave，即可能有的；“可能有的”特性能增加一些商业价值的产品特征。
                • W-won’t have this time，即希望有的，这次不会有；“希望有的，这次不会有”的特性指的是这个功能虽然不错，但不是必需的需求，带有一点商业价值的产品特征。
            • 风险
              • 应该首先开发髙价值、髙风险的功能。这些功能可以提供最髙的价值，而对它们的处理可以消除显著的风险。
              • 接下来是高价值、低风险的功能。这些功能提供了和第一个功能集相当的价值，但是风险较低。
              • 接下来是低价值、低风险的功能。它们被排在第三位，因为放弃它们对产品的总价值产生的影响较小，它们的风险也很低。
              • 最后，对那些提供低价值，但具有高风险的功能，最好是避免开发。
      • 发布阶段
        • 主要完成故事切片，故事估算，构建发布计划。
          • 故事切片
            • 史诗-特性-用户故事。
          • 故事估算
            • 估算技术有计划扑克或宽带德尔菲，计划扑克用到菲波那契数列（0、1、2、3、5、8等）
          • 发布计划
            • Release Plan，又称为版本计划
• 创建敏捷环境
  • 仆人式领导
    • 项目经理被定义为“由执行组织委派，领导团队实现项目目标的个人”。许多项目经理已经习惯于作为项目的协调中心，负责跟踪团队的状态，并向组织中的其他成员反映。当项目被分解为孤立的功能时，这种方法没有问题。
    • 然而，对于高不确定性项目，项目的复杂性是一个人所无法管理的。而跨职能团队既能协调自身的工作，还能与业务代表（产品负责人）开展合作。
    • 从事敏捷项目工作时，项目经理的角色就会从团队的中心转变成为团队和管理人员提供服务。在敏捷环境中，项目经理充当仆人式领导，其工作重点转变为引导需要帮助的人，促进团队的合作，保持与相关方的需要一致。作为仆人式领导，项目经理要鼓励将责任分配给团队成员，分配给那些掌握完成任务所需知识的人。
    • 项目经理成为仆人式领导时，工作重点就会从“管理协调”转向“促进合作”。
    • 仆人式领导为团队赋权
      • 敏捷方法强调，仆人式领导是一种为团队赋权的方法。仆人式领导是通过对团队服务来领导团队的实践，它注重理解和关注团队成员的需要和发展，旨在使团队尽可能达到最高绩效。
      • 仆人式领导的作用是促进团队发现和定义敏捷。仆人式领导实践并传播敏捷。
      • 仆人式领导按照以下顺序从事项目工作
        • 目的
          • 与团队一起定义“为什么”或目的，以便他们能围绕项目目标进行合作互动。整个团队在项目层面而不是在人员层面优化。
        • 人员
          • 目标确立后，鼓励团队创造人都能成功的环境。要求每个团队成员在项目工作中做出贡献。
        • 过程
          • 不要计划遵循“完美”的敏捷过程，而是要注重结果。如果跨职能团队能够常常交付完成的价值并反思产品和过程，团队就是敏捷的。团队将其过程称作什么并不重要。
      • 仆人式领导的职责
        • 仆人式领导通过管理关系，在团队内和组织中建立沟通与协作。这些关系可以帮助领导在组织中得心应手地为团队提供支持。这种支持有助于消除障碍，促进团队理顺过程。由于仆人式领导了解敏捷，在应用具体方法时践行敏捷，因而他们能帮助满足团队的需要。
        • 仆人式领导可能有很多头衔，但最重要的还是他们所做的工作。
          • 教育相关方，使其了解为什么要敏捷以及如何敏捷。根据优先级说明商业价值的好处，对被赋权团队加强问责，提高工作效率，并通过更频繁的评审改进质量。
          • 通过指导、鼓励和帮助为团队提供支持。倡导团队成员的培训和职业发展。“我们通过支持的方式领导团队”，这句话说的是领导在发展其团队成员时所扮演的角色。通过支持、鼓励和专业发展，团队成员将获得信心，承担更多的职责，并在组织中做出了更大的贡献。仆人式领导的一个关键作用是，培养和发展团队成员，帮助他们超越自身当前的角色，即使团队将失去他们也在所不惜。
          • 通过技术项目管理活动，如量化风险分析来帮助团队。有时团队成员可能并不具备在某些角色或功能方面的知识或经验。对相关技能有更多接触、或者接受过相关培训的仆人式领导可以通过提供培训或开展这些活动来为团队提供支持。
          • 庆祝团队的成功，为团队与外部团队合作提供支持，并起到桥梁作用。创造相互欣赏的积极氛围，建立加强合作的良好意愿。
      • 仆人式领导的促进作用
        • 项目经理成为仆人式领导时，工作重点就会从“管理协调”转向“促进合作”。促进者将帮助每个人各尽所能地思考和工作。促进者鼓励团队参与、理解，并对团队输出共同承担责任。促进者帮助团队创建可接受的解决方案。
        • 仆人式领导促进团队内部和团队之间的合作与对话。例如，仆人式领导在团队内部和团队之间帮助发现瓶颈问题，并进行相应沟通。然后，团队将解决这些瓶颈问题。
        • 此外，促进者还鼓励大家通过交互式会议、非正式对话和知识共享展开协作。仆人式领导要通过成为公正的搭桥者和教练来做到这一点，而不是代替他责任人做出决策。
      • 仆人式领导消除组织障碍
        • 《敏捷宣言》的第一个价值观关乎个人与过程和工具的交互。对仆人式领导而言，更好的职责是认真审视那些阻碍团队敏捷或组织敏捷的过程，并努力使其合理化。例如，如果一个部门需要大量文档，仆人式领导的角色就能发挥作用，他们可以与部门合作审查所需的文档，就敏捷交付如何满足这些需求达成共识提供协助，并对所需的文档数量进行评估，从而使团队能够将时间更多地用于提供有价值的产品，而不是创建详尽的文档。
        • 仆人式领导还应该关注其他冗长的过程，这些过程往往造成瓶颈问题，阻碍团队或组织的敏捷性。可能需要处理的过程或部门的例子包括，财务部门、变更控制委员会或审计部门。仆人式领导可以与他人携手合作，共同质疑和审核他们的过程，为敏捷团队和领导提供支持。例如，对团队而言，每两周交付一个工作产品仅仅是为了让产品进入队列或过程，而冗长的发布过程却可能需要6周或更长时间，这样做有什么好处呢?太多的组织都有这些“瓶颈”过程，正是它们阻碍了团队快速交付有价值的产品或服务。仆人式领导有能力改变或消除这些组织障碍，为交付团队提供支持。
• 团队构成
  • 《敏捷宣言》的价值观和原则的一个核心宗旨是强调个人和交互的重要性。敏捷优化了价值流，强调了向客户快速交付功能，而不是怎样“用”人。
  • 敏捷团队注重快速开发产品，以便能获得反馈。在实践中，最有效的敏捷团队往往由三到九个成员组成。理想情况下，敏捷团队应该集中在一个团队工作场所工作。团队成员100%为专职成员。敏捷鼓励自我管理团队，由团队成员决定谁执行下一阶段定义的范围内的工作。敏捷团队与仆人式领导一起茁壮成长。领导支持团队的工作方法。
  • 跨职能敏捷团队频繁创造功能性产品增量。这是因为团队集体对工作负责并共同拥有完成工作所需的所有必要技能。
  • 无论整体的敏捷方法是什么，团队越是限制其在制品，团队成员就越有可能通过合作来加快整个团队的工作。在成功的敏捷团队中，团队成员在工作中以各种方式开展合作（如结对、群集、群体开发），因而，他们会协同工作，而不会落入迷你瀑布的陷阱中。团队在给定时间解决所有的需求，然后试图完成所有的设计，继而又去完成所有的构建，就会发生迷你瀑布的情况。使用这个场景，在构建中或构建后测试中的某一时刻，团队可能会意识到，原先的假设已经不再有效。这种情况下，团队解决所有的需求根本是在浪费时间。相反，当团队成员合作打造全部功能中的少量功能时，随着工作的推进和交付少量已完成的功能，他们也在不断学习。
  • 成功敏捷团队的属性
• 自组织团队
  • 自组织
    • 团队成员自组织决定实现冲刺目标的最佳方式。没有项目经理或者其他经理告诉团队怎样开展工作（Scrum Master也不该冒昧这样做）。自组织是系统自下而上、自发的属性一没有外部的统治力量采用传统的自上而下、命令与控制的管理方式。
  • 自组织团队
    • 自组织团队也叫做自管理团队、或者被授权的团队。团队被授权自己管理他们的工作过程和进度、并且团队决定如何完成工作。
    • 自组织团队是敏捷软件开发最基本的要求。
      • 决定如何完成迭代/冲刺代办事项的方式并实现他们。团队被赋能成为自发组织和自我指导的团队。
      • 自发组织关注如何完成工作的方式。
      • 自我指导关注团队成员如何协调工作。
        • 原则11“最好的架构、需求和设计出于自组织团队”
• 敏捷的角色
  • 敏捷团队中有三种常见的角色
    • 跨职能团队成员
    • 产品负责人
    • 团队促进者

中心主题