PMP-第四章 项目整合管理(二）

管理项目知识

• Manage Project Knowledge
• 过程定义：使用现有知识并生成新知识，以实现项目目标，并且帮助组织学习的过程
• 过程作用：利用已有的组织知识来创造或改进项目成果，并且使当前项目创造的知识可用于支持组织运营和未来的项目或阶段
• 知识管理指管理显性和隐性知识，旨在重复使用现有知识并生成新知识
• 知识管理应该在项目整个周期内进行，而不只是在项目结束时总结经验教训。
• 从组织的角度，知识管理是指确保项目团队和干系人的技能、经验和专业知识在整个项目期间和组织中得到运用和传承
• 知识管理最重要的环节是营造一种相互信任的氛围激励人们分享知识或关注他人的知识

显性知识 vs 隐性知识

显性知识 Explicit knowledge	隐性知识 Tacit knowledge
能够用一定符码系统直接表 达的知识	个人知识以及难以明确表达 的知识
背后已有科学和实证基础	背后的科学原理不甚明确
稳定、明确	非正式、难捉摸
经过编码、格式化、结构化	尚未编码、非格式化、非结 构化
用文字、图片、数字、公式、 软件程序、规律、法规原则 和说明书等方式表述	用“know-how” 、洞察力、 习惯、信念、个人经验等形 式呈现
使用者对于所用显性知识有 明确认识	使用者对于隐性知识可能不慎了解
易于储存、理解、沟通、分 享、传递	不易保存、传递、掌握、分 享

管理项目知识:过程

小结:知识管理->隐性知识；信息管理->显性知识；

管理项目知识:T&T

知识管理

• 知识管理将员工联系起来使他们能够合作生成新知识，分享隐性知识，以及整合不同团队成员所拥有的知识
• 面对面互动最有利于建立知识管理所需的信任关系，一旦信任关 系建立，可以用虚拟互动来维护这种信任关系
• 知识管理工具和技术包括：
  • 人际交往，包括非正式的社交和在线社交
  • 实践社区和特别兴趣小组
  • 会议，包括虚拟互动会议
  • 工作跟随和跟随指导
  • 讨论论坛，如焦点小组
  • 知识分享活动，如专题讲座和会议
  • 研讨会，包括问题解决会议和经验教训总结会议
  • 讲故事
  • 创造力和创意管理技术
  • 知识展会和茶座
  • 交互式培训等

小结：人与人通过会议、交谈、培训和跟随；

信息管理

• 信息管理用于创建人们与知识之间的联系
• 可以有效促进简单、明确的显性知识的分享
• 通过增加互动要素，能强化信息管理工具与技术 的使用
• 信息管理包括：
  • 编撰显性知识的方法
  • 经验教训登记册
  • 图书馆服务
  • 信息收集
  • 项目管理信息系统（PMIS）

小结：人与信息

人际交往

• Networking
• 在组织、行业或职业环境中与他人的正式或非正 式互动
• 人员配置管理的有效性会有各种政治与人际因素的影响
• 人际交往是了解这些政治与人际因素的有益途径
• 目的：建立关系（Guanxi），增加获取资源的途径，改进人力资源管理，促进职业发展
• 方式：社交网络、邮件、午餐会、非正式对话、 座谈会等

经验教训登记册

• Lessons Learned Register
• 经验教训登记册可以记录遇到的挑战、问题、意识到的风险或机会，或其他适用的内容
• 经验教训登记册作为本过程输出可以在项目早期创建
• 在整个项目期间，可以作为很多过程的输入,也可以作为输出不断更新
• 参与项目的个人和团队也应参与记录经验教训，确保有效吸取经验教训
• 在项目或阶段结束时，把相关信息归入经验教训知识库，成为组织过程资产的一部分

项目管理计划更新
组织过程资产更新

• 所有项目都会生成新知识
• 通过本过程，有些知识被编撰，或被嵌入可交付成果，或嵌入过程与程序的改进中
• 在本过程，已有的知识也可以首次加以编撰或使用

经验教训 Lessons Learned

• 包括成功的经验和失败的教训，以及假如重新做的话（比如复盘时） 会有哪些不同或更好的做法
• 还包括问题的起因以及产生变更的原因 ：
  • 项目的技术方面
  • 项目的管理方面（如：我们是怎样做WBS分解以及风险 规划等？）
  • 软技能方面（如：作为项目经理，我们是怎样沟通和领导 团队的？）

监控项目工作

• Monitor and Control Project Work
• 过程定义：跟踪、审查和报告整体项目进展，以 实现项目管理计划中确定的绩效目标的过程
• 过程作用：让干系人了解项目的当前状态并认可，为处理绩效问题而采取的行动
• 监督贯穿整个项目，包括收集、测量和分析测量结果，以及预测趋势，以便推动过程改进
• 控制包括制定纠正或预防措施或重新规划，并跟踪行动计划的实施过程，以确保它们能有效解决问题

小结：监控 = 监督+ 控制；发现问题 和 解决问题。

监控项目工作:过程

小结：发现问题是通过数据分析；解决问题通过提交变更请求纠偏问题；

监控项目工作:输入

工作绩效信息

• 源自各个知识领域的控制过程
• 将执行过程中收集的工作绩效数据，交由控制过程进行分析后得到工作绩效信息，为项目决策提供可靠的基础
• 项目开始时，项目管理计划中规定了关于范围、 进度、预算和质量的具体工作绩效测量指标，该指标成为分析比较的基础，通过比较可以了解项 目的执行情况
• 挣值管理技术是一种常用的形成工作绩效信息的 分析工具

监控项目工作:T&T

数据分析

        

备选方案分析

• Alternatives Analysis 
• 备选方案分析是对尽可能多的潜在可选方案进行分析的技术，用于识别执行项目工作的不同方法

工作绩效报告

• 是为制定决策，采取行动或引起关注而汇编工作绩效信息所形成的实物或者电子项目文件
• 根据沟通管理计划，通过沟通过程向项目干系人发送工作绩效报告
• 工作绩效报告包括状态报告和进展报告，包含挣值图表和信息、趋势线和预测、储备燃尽图、缺陷直方图、合同绩效信息和风险情况概述等
• 工作绩效报告的表现形式可以为仪表板 （Dashboard）、热点报告（Heat Report）、信 号灯图（Stop Light Chart）等 

小结：工作绩效报告是体现项目做得情况如何。

详尽的绩效报告内容

• 对过去绩效的分析
  • 完成百分比的绩效信息
  • 每个领域(范围-进度-成本-质量)的状态信息
• 本期完成的工作
• 本报告期被批准的变更的汇总
• 当前的风险和问题状态
• 下个报告期需要完成的工作
• 项目预测分析，包括时间与成本
• 需要审查和讨论的其他相关信息

小结：过去和当前项目做得这么样及对未来的预测。

工作绩效报告-挣值报告

工作绩效报告-仪表板

监控项目工作：输出

变更请求

• 通过比较实际情况与计划要求，可能需要提出变更请求， 以调整质量要求或者范围、进度、成本基准
• 变更可能包括：  纠正措施  ，预防措施 ， 缺陷补救

项目管理计划更新

项目文件更新

可能包括 ：成本预测 ； 进度预测 ； 经验教训登记册等

实施整体变更控制

• Perform Integrated Change Control
• 过程定义：审查变更请求，批准变更，管理对可交付成果、项目文件和项目管理计划的变更，并对变更处理结果进行沟通的过程
• 过程作用：确保对项目中已记录在案的变更做综合评审
• 实施整体变更控制贯穿项目始终，项目经理对此承担最终责任
• 任何干系人都可以提出变更请求，尽管可以口头提出变更请求，但所有变更请求都必须以书面形式记录，并纳入变更管理和/或配置管理系统中
• 变更请求应该由变更控制系统和配置管理系统中规定的过程进行处理。

变更控制委员会

• Change Control Board ，CCB
• CCB是正式的团体，但不一定是固定的团体
• 设立原因：项目经理权力有限，对于涉及计划基准的变更不能自做主张
• 组成：项目发起人、客户、项目经理、相关专家、其他主要干系人
• 任务：审查、评价、批准、推迟或否决项目变更，记录和传达变更处理请求
• CCB的决策方式：通常采用一致同意的原则。

变更批准的权限

• 每项记录在案的变更请求都必须由一位责任人批准或否决
• 审批者：
  • 项目经理 
    • 批准不涉及基准的变更请求(紧急变更)
    • 紧急情况可批准特殊的变更请求 （比如应急计划或权变措施）
  • CCB ：批准或否决涉及基准的变更请求
  • 发起人 ：批准涉及章程的变更
  • 客户 ： 批准按合同实施项目的某些变更请求

小结：变更预算优先发起人，再是CCB；与钱相关的找发起人；

项目管理系统层次关系

配置管理系统

• Configuration Management System
• 包含在配置管理计划中
• 由一系列正式的书面程序组成，用于对以下工作提供技术和管理方面的指导与监督：
  • 识别并记录产品、成果、服务或部件的功能特征和物理特征
  • 控制对上述特征的任何变更
  • 记录并报告每一项变更及其实施情况
  • 支持对产品、成果或部件的审查，以确保其符合要求
• 配置管理系统包括文件和跟踪系统，记录和更新项目的特定信息，以及该记录和更新哪些信息，以保持产品、服务 或成果的一致性和（或）有效性。

变更控制系统

• Change Control System
• 包含在变更管理计划中
• 是指包括变更管理的一系列正式的书面程序，包括文档、跟踪系统和变更的批准层次等
• 该系统不仅说明什么样的变更需要哪个层次的批 准，而且也说明在什么情况下可以不经批准就实施变更
• 该系统说明CCB的组成、权力与责任
• 紧急情况下的变更可以不经CCB批准就实施，但事后需补办相关变更手续
• 变更控制系统是配置管理系统的子系统

小结：变更流程；

过程：实施整体变更控制

小结：先提交变更请求，再实施整体变更控制。

实施整体变更控制：输入

项目管理计划

• 变更管理计划：为管理变更控制提供指导，记录CCB的情况，记录变更并更新项目管理计划
• 配置管理计划：描述项目的配置项，识别应记录和更新的配置项，以便保持项目产品的一致性和有效性
• 范围、进度、成本基准

小结：变更流程和变更指南计记在变更新管理计划中；不可以更新或修改变更新管理计划。
考点：增加能功或需求查看变更管理计划。

项目文件

• 估算依据、需求跟踪矩阵、风险报告等

工作绩效报告

• 对本过程特别有用的绩效报告包括：资源可用情况、进度和成本数据、挣值报告、燃烧图或燃尽图

​​​​​​​​​​​​​​变更请求

• 所有监控和很多执行过程都会输出变更请求
• 变更有可能影响项目基准，也有可能只影响相对于基准的项目绩效
• 对于会影响基准的变更，在变更请求中通常应说明执行变更的成本、所需的计划日期修改，资源需求以及相关的风险。这种变更应该由CCB审批
• 只有经批准的变更才能纳入修改后的基准

事业环境因素

• 组织治理框架等

组织过程资产

• 变更控制程序
• 批准与签发变更的程序
• 配置管理知识库

实施整体变更控制：T&T

专家判断
变更控制工具

• 应支持配置管理活动
• 应支持变更管理活动

数据分析

• 备选方案分析
• 成本效益分析

决策

• 投票
• 独裁型决策
• 多标准决策分析

会议

• 指变更控制会议-CCB的会议
• CCB的角色与职责需要记录在变更管理计划中
• CCB的决定都应记录在案，并向干系人传达

配置管理活动

多标准决策分析

• Multi-criteria Decision Analysis
• 借助决策矩阵，用系统分析方法建立诸如风险水平、 不确定性和价值收益等多种标准，从而对众多方案进行评估和排序的一种技术
• 典型应用:不确定性下的决策准则

变更请求

• Change Requests
• 关于修改任何文件、可交付成果或基准的正式提议（Formal Proposal）
• 变更请求可以源自内部或外部，可选或强制提出
• 变更请求包括：
  • 纠正措施 Corrective action，纠正绩效偏差
  • 预防措施 Preventive action，防范绩效偏差
  • 缺陷补救 Defect repair，修正产品或组件的缺陷
  • 更新 Updates，针对受控文件或计划的变更

完整的变更管理流程

小结：0.影响->1.提交->2.评估->3.备选->4.审批->5.更新->6.通知->7.执行->8.实施->9.变更

实施整体变更控制：输出

批准的变更请求

• 由项目经理、 CCB等根据变更管理计划处理变更请求，做出批准、 推迟或否决的决定
• 批准的变更请求通过指导与管理项目工作过程加以实施
• 变更请求处理的结果，无论批准与否，都要在变更日志中更新

项目管理计划更新

• 项目管理计划的任意正式受控的组成部分都可通过本过程变更
• 对于基准的变更，只能针对今后的情况，而不能变更以往的绩效， 以保护基准和历史数据的严肃性
• 基准变更之后形成新的基准

项目文件更新

• 变更日志（Change Log）用来记录项目过程中出现的变更

结束项目或阶段

• Close Project or Phase
• 过程定义：终结项目、阶段或合同的所有活动的过程
• 过程作用：存档项目或阶段信息，完成计划的工作，释放组织团队资源以展开新的工作
• 该过程仅展开一次或仅在项目的预定点开展 
• 结束项目时，项目经理需要审查以往各阶段的收尾信息，确保所有项目工作都已完成，确保项目目标已经完成
• 结束项目时，项目经理需审查项目管理计划，确保所有项目工作都已完成，并且项目已经实现目标
• 如果项目在完工前就提前终止（异常结项），本过程在原本流程基础上还需制定程序，来调查和记录提前终止的原因

行政收尾活动

• Administrative Closure Activities
• 组织就正式有序结束项目或阶段所做的工作约定
• 行政收尾通常包括（但不限于）以下活动：

小结：行政收尾活动没有顺序。
补充活动：7.庆工会->8.释放资源，它们必须最后二步且有顺序。

过程：结束项目或阶段

结束项目或阶段：输入

项目章程

• 记录了项目成功标准、审批要求，以及由谁来签署项目结束

项目管理计划

 项目文件

• 假设日志
• 估算依据
• 变更日志
• 问题日志：用于确认没有未决问题
• 经验教训登记册
• 里程碑清单
• 项目沟通记录
• 质量控制测量结果
• 质量报告
• 需求文件
• 风险登记册
• 风险报告：用于确认项目结束时没有未关闭的风险

验收的可交付成果

• 正常收尾的验收的可交付成果包括批准的产品规范、交货收据和工作绩效文件
• 分阶段或被取消的项目中，包括部分完成或中间的可交付成果

商业文件

• 商业论证：用于确定项目是否达到了经济可行性研究的预期结果
• 收益管理计划：用于测量项目是否达到了计划的收益

 协议

• 合同条款中定义了对正式关闭采购的要求

采购文档

• 为关闭合同，需收集全部采购文档，并建立索引和加以归档

 组织过程资产 

• 项目或阶段收尾指南或要求（如经验教训、项目终期审计、项目评价、产品确认、验收 标准、合同收尾、资源重新分配、团队绩效评估，以及知识传递等）
• 配置管理知识库，包括组织标准、政策、程序和项目文件的各种版本及基准

结束项目或阶段：T&T

分析技术

• 文件分析：总结经验教训，分享知识，改进未来项目
• 回归分析：分析变量与结果之间相互关系，提高未来项目绩效
• 趋势分析：确认组织模式有效性，为未来做调整
• 偏差分析：分析偏差，改进组织的测量指标

会议

• 用于确认可交付成果已通过验收、确定已达到退出标准、正式关闭合同，评估干系人满意度，传递项目知识和信息，以及庆祝成功
• 参与者：团队成员、参加项目或受项目影响的干系人
• 会议类型：收尾报告会、客户总结会、经验教训总结会，以及庆祝会等

结束项目或阶段：输出

项目文件更新

• 更新所有项目文件，并标记为最终版本
• 经验教训登记册的最终版本，包括:收益管理、商业论证的准确性、项目和开发生命周期、干系人参与，以及其他项目管理过程

最终产品、服务或成果移交

• 把项目交付的产品、服务或成果移交给另一团队或组织，并由其在整个（产品）生命周期中进行运营、维护和支持
• 项目收尾，移交项目所产出的最终产品、服务或成果
• 阶段收尾，移交该阶段所产出的中间产品、服务或成果

最终报告

用最终报告总结项目绩效，可包括以下信息：

• 项目或阶段的概述
• 范围目标、范围的评估标准，以及证明达到完工标准的证据
• 质量目标、项目产品和质量的评估标准，核实信息以及偏差原因
• 成本目标，包括可接受的成本区间、实际成本，以及偏差原因
• 最终产品、服务或成果的确认信息的概述
• 进度目标，包括成果是否实现项目所预期的收益，以及未来实现情况
• 最终产品、服务或成果如何满足商业计划所述业务需求的概述
• 项目过程中发生的风险或问题及其解决情况的概述

组织过程资产更新

• 项目文件（项目管理计划、范围、进度、成本、变更管理文件等）
• 运营和支持文件（组织维护、运营和支持项目交付的产品或服务所需的文件）
• 项目或阶段收尾文件（表明项目或阶段正式结束的文件）
  • 如果项目提前终止，需说明原因，并把已/未完成的成果进行移交
• 经验教训知识库