第八章 整合管理 (2025年详细解析版）

目录

什么是整合管理？

  • 项目整合管理包括对隶属于项目管理过程组的各种过程和项目管理活动进行识别、定义、组合、统一和协调的各个过程(各个过程:指的是整合管理内包含的各个过程.每个知识领域都有好多过程.)

  • 整合管理包括对项目如下方面做出选择(关注哪几方面.)：

    • 资源分配(进行总的项目的资源分配包括人财物)
    • 平衡竞争性需求(项目里边要考虑很多干系人的需求,要平衡各种需求,而且各种需求很可能是竞争,甚至对抗的)
    • 研究各种备选方法(项目里边各个方面会遇到很多可选择的方法去做项目,要研究各种备选方法)
    • 为实现项目目标而裁剪过程(每个项目各不相同,所以要在整合的前期,对项目各方面进行裁剪)
    • 管理各个项目管理知识领域之间的依赖关系(凡是项目领域或者项目过程之间有依赖关系,都得去管理)

其他九个领域可以委托他人去做,唯独整合管理必须项目经理亲自去做.

重要性

  • 项目经理的关键决策不是技术,而是项目里的整合者,唯有整合管理这个知识领域是最重要,最核心的,它就是像总指挥部一样,把所有的其他的9个知识领域,把项目里边所有49个过程都黏在一起,把项目内外部的干系人都黏在一起,凡是有接口的地方都得需要进行整合,这是整合的重要性.

8.1 管理基础

  • 题目解析 : 实际上是介绍项目整合管理这个知识领域相关的一些背景,就叫管理基础,实际上完整应该叫项目整合管理的基础

8.1.1 执行整合由项目经理负责

  • 项目经理最关键的能力就是整合能力(项目经理最关键的能力,考试不考察IT能力,只有上午75道选选择题,有30道题在考IT,其他都不考IT知识,都是考项目管理,而项目管理最新核心的技能/关键能力,就是整合的能力.)

整合能力要考察两个方向的能力

组织层面(对上)

  • 项目经理想办法实现项目和战略层面的整合，与项目发起人携手合作，来理解战略目标，并确保项目目标和成果与项目组合、项目集以及业务领域保持一致.(项目经理在整个组织里地位不高,权力也不大,在组织层面它属于向上管理,向上管理就是项目经理要想办法让其所带项目,项目目标贴合于整个组织的战略,这样才不会被项目组合经理拿掉,因为项目组合负责对所有项目集排序,项目得靠前,越接近于组织的目标,项目越容易得到更好的资源,排序更靠前.


    向上组织层面管理离不开一个人,这个人就是发起人,发起人是层次级别比较高,由他为项目申请资源和钱,发起项目,任命项目经理,所以要和他去合作,在组织层面上进行整合,如果真实项目企业里,真实组织级项目管理,对上就是在PMO和发起人的帮助下,要和项目集经理,项目组合经理之间搞好关系.    )

项目层面(对内)

  • 项目层面上，项目经理负责指导团队关注真正重要的事务并协同工作。为此项目经理需要整合过程、知识和人员.(项目层面因为是项目经理,这是对内的整合,跟团队一块关注项目上的工作进行协调,在这里要整合很多东西,就是项目里的所有过程,所有知识,就是信息和所有的人员,包括项目团队成员,所有干系人.)

8.1.2 整合的三个层次

过程层面

  • 有些过程可能只发生一次，但很多过程在整个项目期间会相互重叠并重复发生多次。有些过程的执行会引发变更，又需要启动实施整体变更控制过程进行变更整合.( 在过程这个层面要进行整合,因为整个项目管理一共有49个过程,分成了五大过程组,十大知识领域,这些过程之间相互关系非常复杂,有的过程就是执行一次,有的过程执行很多次,但是每个过程过程之间,第一个过程的输出很可能是后几个过程的输入,某个过程的输入,很可能来自于前篇几个过程,所以过程之间很复杂,需要进行整合. )

认知层面

  • 管理项目的方法有很多，而方法的选择通常取决于项目的具体特点，包括规模、项目或组织的复杂性，以及执行组织的文化。也会受到项目经理的人际关系技能和能力的影响.( 每个人的文化背景,文化差异不一样,看待任何事情,每个人的出发点角度都不一样,人和人是很复杂的东西,就造成了每个人的认知不一样,每个人对技能,知识啊或者项目里的一些概念认知都不一样,所以需要项目经理进行整合,认知层面关注于项目管理方面的加上组织文化. )

背景层面

  • 与几十年前相比，当今企业和项目所处的环境有了很大的变化。新技术不断涌现。项目经理应考虑影响项目执行的各种背景，包括社会背景、组织背景、产品所在行业的背景、项目管理技术背景甚至项目团队的价值观.( 背景是一些新的技术,新的环境,价值观这方面背景不一样.认知层面和背景层面,统一理解也可以,背景层面就是范围更大一些,认知层面范围更小些. )

8.1.3 项目整合的复杂性

  • ① 包含多个部分

  • ② 不同部分之间存在一系列关联

  • ③ 不同部分之间的动态交互作用

  • ④ 这些交互作用所产生的行为远远大于各部分简单的相加（ 例如 : 突发性行为 ）

解析:
第一个:整个项目系统包括很多部分.

第二个:系统部件之间有联系,联系有静态联系.

第三个:组成部分之间会动态的交互,换句话就是会互相影响.

第四个:系统运行是交互的,组件之间产生的影响远远大于每个组成部分的影响,简单的加和就是太影响,会对项目更深远,所以项目经理要通过整合,使项目各种机制运行的更好,产生更好的结果,或者更符合项目目标,这就是项目整合的复杂性.

8.1.4 管理新实践(了解)

  • 与整合管理过程相关的新趋势和新兴实践包括：(管理新实践:完整说法应该是就是项目整合管理知识领域比较新的实践或者新的趋势.)

使用信息化工具

  • 用来收集、分析和使用信息，支持实现项目目标和项目效益

使用可视化管理工具

  • 可以通过可视化分析表等直观形式获取和监督关键的项目要素，直观看到项目的实时状态，促进知识转移

项目知识管理

  • 项目人员的流动性和不稳定性越来越高，应及时将项目生命周期中积累的知识传达给目标受众，防止知识流失

项目经理在项目以外的职责

  • 需要参与管理层和 PMO 负责的立项前、结项后的可行性研究与评估和效益管理，实现项目目标及价值，识别、引导职能部门、运营部门和高级管理人员参与

混合型方法

  • 经实践检验的新方法会不断地融入项目管理中，包括：敏捷或适应型方法、商业分析技术、相关分析工具，以及组织变革管理方法等

8.1.5 项目管理计划和项目文件

  • 整个项目里的文件,就是文字记载,文件分为两大类,一大类文件就叫项目管理计划,项目管理计划不是一个文件,而是一堆文件,另外的都叫项目文件

8.2 项目整合管理过程

  • 题目解析: 开始介绍就是整合管理知识领域,有多少个过程,每个过程介绍一下,每个过程大体的ITTO,项目整合应该是项目整合知识领域,就是项目整合管理知识领域的各个过程的总介绍.
  • 本节以后,每一个小节是介绍整合管理知识领域的每一个过程,从8.3到8.9一共有七个小节,就是整合管理知识领域有七个过程

8.2.1 过程概述

  • 项目整合管理过程包括：

    • ① 制定项目章程：编写一份正式批准项目并授权项目经理在项目动中使用组织资源的文件( 项目从无到有,总得有人制定项目章程,项目章程经过领导正式批准,这里会授权项目经理,可以动用什么资源做这个项目,这叫制定项目章程.
      制定项目章程不能项目经理主导,但是制定项目管理计划之后的48个过程,都得项目经理主导.       )

  • ② 制订项目管理计划：定义、准备和协调项目计划的所有组成部分，并把它们整合为一份综合项目管理计划( 把各个子计划,各个基准捏到一块,形成文件. )

    • ③ 指导与管理项目工作：为实现项目目标而领导和执行项目管理计划中所确定的工作，并实施已批准变更( 项目管理计划有了,项目经理要领着团队成员工作,开始干活了,这个叫指导与管理项目工作,有人说,这个过程不就是大家干活为什么不叫执行项目,这个不能叫执行项目,因为是项目经理,在管理项目,所以别的团队成员是在执行,但是项目经理不行,过程名是从项目经理的角度,项目经理在指导和管理大家工作,所以叫指导与管理项目工作. )

  • ④ 管理项目知识：使用现有知识并生成新知识，以实现项目目标，帮助组织学习.( 不管是显性的,隐性的,关于知识的存储,处理,共享,分享等等,跟后边有个知识领域叫沟通管理知识领域的一些关于沟通的一些过程有关系,他们两者之间是有关联的. )

    • ⑤ 监控项目工作：跟踪、审查和报告整体项目进展，以实现项目管理计划中确定的绩效目标.( 不断的/定期的或者不定期的,把项目的实际的状态跟计划或者基准期望的状态进行对比,
      如果出现问题,找到偏差,找到问题,或者对绩效进行预测等等,所有不光是做项目,干任何事都得做监控,没有监控怎么能叫管理,所以包括项目管理,传统管理,都是有计划,有监控,才能做管理,不然怎么去找差距,怎么控制别人.       )
    • ⑥ 实施整体变更控制：审查所有变更请求，批准变更，管理可交付成果、组织过程资产、项目文件和项目管理计划的变更，并对变更处理结果进行沟通.( 项目里边任何地方,任何人都可能提变更,但是所有变更都得经过实施整体变更控制这个过程进行处理,主要是要理解整个变更管理的流程,就是变更进来之后,由谁第一步处理,谁第二步处理,谁进行审批,批准之后的变更交给哪个过程等等. )

  • ⑦ 结束项目或阶段：结束项目、阶段或合同的所有活动.( 整个项目或者说项目的每一个阶段都得进行收尾,是由这个过程结束项目或者阶段,由这个过程去进行项目或者阶段的收尾,项目如果是分多个阶段,每一个阶段都得走这个流程. )

  • 深绿色的属于项目整合管理.

8.2.2 项目整合管理过程

8.2.3 裁剪考虑因素(了解)

  • 项目经理可能根据需要裁剪项目整合管理过程：
    • 项目生命周期（ 哪些阶段，阶段关系 ）
    • 开发生命周期（ 预测 / 适应 / 混合 ）
    • 管理方法（ 选择有效的管理过程 ）
    • 知识管理
    • 变更
    • 治理（ 监控机构/委员会参与如何报告状态 ）
    • 经验教训（ 收集哪些信息以适用于未来项目 ）
    • 效益（ 何时以何种方式报告效益 ）

解析:
在做整合的时候,要不要完全执行七个过程,每个过程执行这个步骤,或者每个过程采取的ITTO要不要跟这个表格里的一致?
那肯定是不一定,因为作为项目经理,要领着团队对项目管理过程或者方法进行裁剪,再进行就是在进行项目整合管理,对过程进行裁剪的时候,要考虑下边一些方面了解即可,比如项目生命周期,到底分哪个阶段,阶段之间是交叠关系,并行关系还是顺序关系,到底是采用传统的,预测型的,还是根据项目特点是敏捷或者适应,或者这个两者结合,
这都是要和团队进行考量的,还有管理方法就是选择哪些项目管理过程,如何进行项目的知识管理或者变更管理,每个项目变更管理流程都不一样,项目的治理结构是什么,受哪个委员会监管,周报月报应该以什么形式进行汇报,属于项目治理那包括做项目的过程中项目的经验教训,收集哪些信息放到经验教训,才能有利于未来项目,因为这个经验教训,就是为未来的项目做准备,没用的信息就别收集了,要进行裁剪,每个项目现在都是关注于为组织或者该企人创造价值或者带来收益,那项目里要写清楚如何给创造价值,国内一直不强调,但是国外项目管理体系强调有一个文件,叫收益管理计划,这个收益管理计划就是要写清楚这个项目什么时候,以什么方式为企业或者组织或者社会带来效益,把这些东西事先都考虑清楚,这个就是整合的时候,进行裁剪要考虑的内容.

8.2.4 敏捷与适应方法

  • 在敏捷或适应型环境中需要考虑的因素
    • 团队被授权自己管理工作过程和进度、并且团队决定如何完成工作(如果采取的是敏捷开发方法或者叫适应性开发方法,还要注意一点东西,也不光是在整合管理,只要是使用敏捷方法进行项目开发,第一件事就非常重要,就是项目经理要授权,授权之后,把权利授权给项目团队,团队可以自组织的或者叫自管理的进行规划,进行执行,进行监控,去总结,这种叫自组织团队,这是所谓敏捷特别关注的)
    • 项目经理的关注点发生改变.( 项目经理跟传统的这个项目经理,发生一点改变,比如更关注的是营造合作的氛围,让团队去做决策,让团队有能力应对变更,或者让团队具有对应性,让团队参与项目管理,甚至参与整合.这是敏捷项目.敏捷项目人员缩减,所以要求每个团队都是身兼数职,说的好听一点叫T型人才,那就是不要专注于某一个领域,就得是通才,这叫团队成员具有广泛技能,这是敏捷团队. )
      • 注营造合作型的决策氛围
      • 确保团队有能力应对变更
      • 促进团队成员以相关领域专家的身份参与整合管理
      • 团队成员具有广泛技能

8.3 制定项目章程

  • 制定项目章程必须是第一个过程,因为本来组织里边没有这个项目,发起人希望有这个项目,他就游说更高层的领导,当然他是最大领导就更好了,他去领导最高层领导启动这个项目,这个项目能给整个企业带来好处,发起人请自己或者请外部的专家,呈交给最大的领导,领导一看这个项目能对组织长远发展造成巨大的好处行,由发起人投资或者找到的钱,包括关键资源,发起人或者企业的领导,还有PMO就是这些人才有资格,去写项目章程.

制定项目章程流程

  • 制定项目章程,项目经理可以参与写,但是实际上是替别人写,因为最后发布项目章程,肯定不能是项目经理发布,项目经理没有资格,所以应该是领导发布项目章程,任命项目经理,在项目章程里任命项目经理,使他有动用组织的资源做各种活动的权利.

8.3.1 课程目标

  • 掌握制定项目章程过程的含义与作用

  • 掌握立项管理文件的意义与编制基础( 立项管理文件是任命项目经理之前就有的. )

  • 了解协议、事业环境因素和组织过程资产对项目启动的影响

  • 知道获取专家判断的渠道有哪些( 哪些渠道获得专家帮助制定渠道章程. )

  • 掌握头脑风暴、焦点小组、访谈等数据收集技术

  • 掌握项目章程的含义和包含的主要内容( 需要了解项目章程的大体内容. )

  • 了解假设日志 ( 在项目启动的时候,就开始把一些识别出来的假设条件,资源因素等等记到一个文件里,这个文件叫假设日志. )

8.3.2 过程定义 ：制定项目章程

定义

  • 编写一份正式批准项目并授权项目经理在项目活动中使用组织资源的文件.( 制定项目章程就是编写项目章程.项目章程要经过批准授予项目经理权利,它最重要的过程,最重要的输出,是项目章程. )

作用

  • 明确项目与组织战略目标之间的直接联系，确立项目的正式地位，并展示组织对项目的承诺.(项目章程里领导确定你是项目经理,你可以动用哪些资源,这就是承诺.)

时机

  • 仅开展一次或仅在项目的预定义点开展(实际上如果是多阶段项目不是一次,整个项目启动的时候,肯定要做一个项目章程,如果项目是多阶段的,每个阶段都是决策点,每个阶段启动的时候,其实都要去审查一下项目章程,看一下项目执行到这个阶段,项目章程是可以有一些修改的必要的,所以每个阶段开展的时候,每个阶段之前,都可以去审查甚至修改项目章程.这就叫预定一点开展,整个49个过程.几乎没有任何一个过程是只执行一次.)

  • 图解: 图展现的是项目章程的重大作用,体现了项目需求组织,如果是内部项目就是你的领导,如果是外部项目就是客户,右边就是项目执行组织,就是项目经理带领团队所在的组织,他们之间建立起一个连接.

8.3.3 数据流向图

  • 解析:
    中间蓝色的方块,表示制定项目章程,如果想制定项目章程往左看,要有一些输入,输入来自于来自于立项管理,软考特别强调逆向管理,逆向管理这个阶段或者流程产生作为制定项目章程过程的输入,这个过程还有两个输入,就是要参考企业的组织过程,资产这些环境因素,这整体上作为这个过程的输入,这个过程输出会产生两个,一个是最重要的是制定一个项目章程,项目章程给定义范围的时候,执行这个过程要参项目章程等等.项目章程作为输入回到蓝色的制定项目章程过程,又产生了第二个输出叫假设日志,假设日志直接存到一个文件里,但这个文件就叫假设日志,假设这属于项目文件,它不属于项目管理计划,所以是这个输出交给项目文件.

8.3.4 ITTO

  • 基本要掌握十之八九.

关于项目章程

项目章程的起草人与签发人是谁？

  • 起草人：项目启动者或发起人，或授权项目经理代为起草签发人：项目发起人、PMO、或高层管理人员(比如领导跟你说了你未来就是项目经理,领导说现在项目启动,你说不行,每个项目必须得有项目章程,领导说没有时间写,项目经理可以帮领导起草项目章程,经过授权之后可以起草,但是签发人不能项目经理,必须是是发起人或者PMO或者高层管理人员.)

项目章程的主要作用？

  • 为项目"正名”，对项目经理授权。项目章程授权项目经理进行项目管理过程中的规划、执行和控制，同时还授权项目经理在项目活动中使用组织资源

项目章程是否可有可无？

  • 所有项目必须有项目章程，不论是内部项目还是外部项目

何时任命项目经理？

  • 越早越好！应尽早确认并任命项目经理，最好在制定项目章程时就任命，最晚也必须在规划开始之前(越早任命项目经理越好,最晚也得在项目章程里去确定,即使项目经理没参加制定起草项目章程,也在项目章程里写清楚谁是项目经理,因为马上就启动了,马上就规划了,规划的时候很重要,项目经理要领着大家制定企划,最晚在规划之前确定相应.)

为什么要坚持有项目章程的两个至关重要

  • 只有项目章程这个文件,才是对项目经理的一个证明,这个证明就是查项目章程,对项目经理授权,项目章程一般是组织层面的认可或者发布,你是项目经理,你有权做什么规划,执行监控,最重要的是有资格动用组织的哪些资源,关键资源包括多少设备,包括哪几个职能部门,多少个人归你调动,都是在项目章程里要写清楚所以对项目经理至关重要.
  • 所有项目不管大小,必须有项目章程,没有项目章程的项目,组织没正确授权,凡是出现组织资源不够用了,砍掉一些项目,肯定是把没有项目章程的项目优先砍掉.

8.3.4.1 输入

立项管理文件

  • 立项管理从业务视角描述必要的信息，并且据此决定项目的期望结果是否值得所需投资。组织高层管理者通常使用立项管理文件作为决策依据(PMBOK指南是美国出标准,指南里它叫商业论证,国内基本上没有叫商业论证的,国内一般都是项目启动之前都有一个文件,一般叫可研报告,软考这把这个输入给改了,改成叫立项管理文件了.)(立项管理文件本质是一分可行性研究报告,这里的名字就叫立项管理文件.决策依据:就是这个项目立项还是不立项.)

  • 立项管理包含商业需求和成本效益分析，论证项目的合理性并确定项目边界

在多阶段项目中，可通过对立项管理文件的定期审核，来确保项目能实现其商业利益

  • 解析:
    其实第六章提到过,对于大型项目,都是分阶段的项目,可以通过对立项管理文件定期审查,定期审查就是每一个阶段结束和下一个阶段开始的时间点,都要对立项文件做审查,项目能不能继续为企业创造价值,没价值的赶紧终止.审核什么?审核立项管理文件.

立项管理文件不是项目文件项目经理不可以对它们进行更新或修改，只可以提出相关建议.(项目经理不能控制,不能修改,只能提建议,从项目经理的角度讲,立项管理文件里哪些地方不妥,需要修改,具体修改还是领导去请专家进行修改.)

协议

  • 协议定义了启动项目的初衷。有多种形式，包括合同、谅解备忘录(MOUS)、服务水平协议(SLA)、协议书、意向书等；(服务管理有一个SLA,就是服务级别管理,就是它,内部的两个部门之间可以通过SLA作为启动IT部门的一个依据,这也属于协议的一种)

  • 协议可以是口头协议，也可以是电子邮件或其他书面协议

为外部客户做项目时，协议应该以正式书面合同的形式出现

事业环境因素

  • 能够影响制定项目章程过程的事业环境因素包括：

    • 政府或行业标准（ 如 : 产品标准、质量标准、安全标准和工艺标准 ）
    • 法律法规要求和( 或 )制约因素
    • 市场条件
    • 组织文化和政治氛围
    • 组织治理框架（ 通过安排人员、制定政策和确定过程，以结构化的方式实施控制、指导和协调，以实现组织的战略和运营目标 ）
    • 干系人的期望和风险临界值

组织过程资产

  • 组织过程资产:就是项目经理要利用企业里已有的,早期项目积累下来的知识,或者数据,或者方案,或者模板,拿过来用
  • 能够影响制定项目章程过程的组织过程资产包括：
    • 组织的标准政策、流程和程序
    • 项目组合、项目集和项目的治理框架（ 用于提供指导和制定决策的治理职能和过程 )
    • 监督和报告方法
    • 模板 ( 如 : 项目章程模板 ）
    • 历史信息与经验教训知识库（ 如 : 项目记录与文件、关于以往项目选择决策的结果及以往项目绩效的信息 ）

聪明的人不重复发明轮子，项目经理应善于使用组织过程资产帮助自己项目获得成功

8.3.4.2 工具与技术

专家判断

  • 专家判断是指基于某应用领域、知识领域、学科和行业等的专业知识而做出的，关于当前活动的合理判断。这些专业知识可来自具有专业学历、知识、技能、经验或培训经历的任何小组或个人.(谁可以是专家?这些专业知识可来自具有专业学历也行,具有相关的知识也行,具有相关制这个技能或者经验,要求多低,专家有相关培训经历的人或者小组,都可以作为知识来源,或者都可以作为专家,其实这个专家判断这个技术真的很low,只要不是竞争对手,谁都是专家.
    笔者认为: 做过同类型系统的,使用过同类型系统的,学习培训过,学历认证过,多种途径知道这款系统产品和同类产品的,在项目中都可以作为专家小组的成员,成为该项目的专家.    )

专家的获取渠道

  • ① 组织内的其他部门
  • ② 顾问
  • ③ 干系人，包括客户或发起人
  • ④ 专业与技术协会
  • ⑤ 行业团体
  • ⑥ 主题专家（ SME ）(主题专家就是这个问题方面的专家.类似于这个专业这个方向的专家)
  • ⑦ 项目管理办公室（ PMO ）

征求意见的主题

  • ① 组织战略
  • ② 效益管理
  • ③ 关于项目所在的行业以及项目关注的领域的技术知识
  • ④ 持续时间和成本估算
  • ⑤ 风险识别

数据收集

头脑风暴

  • 头脑风暴(有些地方简称脑暴)用于在短时间内获得大量创意，适用于团队环境。目的是产生尽量多的新想法，只记录不允许批评(重点目的是产生尽量多的新想法,如果组织头脑风暴,项目经理要鼓励大家用各种方法鼓励大家产生各种想法,新奇的想法,怪异的想法都可以,千万不允许任何人包括项目经理去批评任何一个想法,就是鼓励,看似很荒诞的想法,也要鼓励,及时是违法乱纪的想法,也要记录下来,至于评审是下个阶段的考虑.考察的是特点)

  • 头脑风暴由两个部分构成：

    • 创意产生（ 过程中 ）
    • 创意分析（ 结束后 ）
焦点小组
  • 焦点小组召集干系人和主题专家讨论项目风险、成功标准和其他议题，比比一对一访谈更有利于互动交流.( 焦点小组相当于平时说的座谈会,一般平时工作中也用不到,关注某一个方面的主题专家,专家在一个方面领域研究的很深,而且观点可能是各不一致,这样的讨论就是特别热烈,会比正常的讨论更激烈一些. )
访谈
  • 访谈是指通过与干系人直接交谈来了解高层级需求假设条件、制制约因素、审批标准以及其他信息.( 在收集需求的时候,特别是收集关键干系人,重要干系人需求,肯定是要领着团队成员亲自上门,问领导对这个新的系统有什么要求,技术就是访谈,就是面对面的进行交流,一般最重要的干系人才进行访谈,访谈就是问他一些关于启动项目的一些想法,记录下来,访谈是收集需求过程的核心方法. )

这两个也是收集需求的技术

人际关系与团队技能

引导
  • 引导是通过创造他人积极参与、形成活跃氛围，从而达到预期成果的技术。从项目管理角度讲，引导是指有效引导团队活动以达成成功的决定、解决方案或结论的能力.( 引导它不是一个独立的技术,可以认为它用一堆技术来达成某一个效果,这个技术就是引导,就是想办法让干系人积极参与这件事,就是引导他参与.其实不光是团队活动,应该是引导所有干系人这参与,以达成成功.或者说以确定统一的解决方案. )

    • 引导者应确保参与者有效参与互相理解，考虑所有意见，按既定决策流程全力支持得到的结论或结果

    • 引导者还应确保所达成的行动计划和协议在之后得到合理执行

冲突管理
  • 冲突管理有助于干系人就目标、成功标准、高层级需求、项目描述、点总体里程碑和其他内容达成一致意见.( 干系人目标,成功标准,高层级需求,这些都是项目章程里要写的.在制定项目章程的时候,会涉及到很多的关键概念,都针对项目章程,要确定哪些内容,可能会有些争执,所以有冲突,要用冲突管理去解决,使整个项目章程通过组织批准. )
会议管理
  • 会议管理包括准备议程、确保邀请每个关键干系人群体的代表，以及准备和发送后续的会议纪要和行动计划.( 沟通知识领域会详细讲会议管理,会前进行计划,会中进行控制,会后写纪要进行行动的追踪,都属于会议管理. )

会议

  • 在制定项目章程过程中，与关键干系人举行会议的目的是识别项目目标、成功标准、主要可交付成果、高层级需求、总体里程碑和其他概述信息
  • 辨析:
    会议管理是任何会开会的过程中,如何控制会议.会议是个工具的技术,是指要领着大家开会,具体怎么开,可能会用到会议管理技巧.

8.3.4.3 输出

项目章程

  • 项目章程是由项目启动者或发起人发布的，正式批准项目成立，并授权项目经理使用组织资源开展项目活动的文件

  • 项目章程确保干系人在总体上就主要可交付成果、里程碑以及每个项目参与者的角色和职责达成共识

  • 项目章程包括：

    • ① 项目目的
    • ② 可测量的项目目标和相关的成功标准
    • ③ 高层级需求
    • ④ 高层级项目描述、边界定义以及主要可交付成果
    • ⑤ 整体项目风险
    • ⑥ 总体里程碑进度计划
    • ⑦ 预先批准的财务资源
    • ⑧ 关键干系人名单
    • ⑨ 项目审批要求（ 例如，用什么标准评价项目成功，由谁对项目成功下结论，由谁来签署项目结束 ）
    • ⑩ 项目退出标准（ 例如，在何种条件下，才能关闭或取消项目或阶段 ）
    • ⑪ 委派的项目经理及其职责和职权
    • ⑫ 发起人或其他批准项目章程的人员的姓名和职权

项目章程示例

  • 每一个企业,每一个组织的项目章程,模板完全不一样,整体上每个项目每个组织,项目章程应该都得很精简的,顶多一两页,或者顶多三五页,项目章程就是给公司里所有人都发,告诉大家启动这个项目.
项目名称：CRM 软件开发。

总体里程碑进度表：2009年5月1日开工，2009年11月5日结束。

项目经理：李某某；联系电话：xXxxxxxXXXX。

项目立项依据：公司业务经过多年的发展，公司已经拥有了大量优质客户和一大批潜在客户，为了稳定与发展公司的客户群，公司管理层决定开发一个CRM系统。

项目目标：以标准的客户关系管理理论为指导，结合公司的营销经验，在6个月时间里开发完成具备客户管理、市场管理、销售管理、服务管理、统计分析和CallCenter六大功能的CRM客户管理软件。预算为6个月投入为50万人民币。

项目干系人：

i.赵某某：项目发起人和赞助人，负责监督项目；
ii.李某某：项目经理，负责计划、监控项目，对项目质量负责；
iii.钱某某：IT部门经理，负责为项目提供适当资源和培训；
iv.王某某：业务接口人，负责为项目提供业务需求。

签名：（以上所有干系人签名）

假设日志

  • 假设日志属于项目文件的一类，用于记录整个项目生命周期中的所有 假设条件和 制约因素(制定项目章程这个过程,除了产生项目章程,还有一个输入输出叫假设日志.)

  • 项目启动之前进行可行性研究和论证时，识别高层级的战略和运营假设条件与制约因素，纳入项目章程(辨析:项目启动之前,进行可行性研究和论证时,很早的时候,识别出的高层级的假设条件或者支援因素,就可以纳入项目章程,这里的纳入项目章程,其实在PMBok指南里,写的是应该纳入假设日志,说纳入项目章程也也可以,应该是启动项目的时候发现比较重要的假设条件或者质疑因素,认为有必要可以记录到项目章程里,认为不太重要的都记录到假设日志.就是所有质疑愿因素或假设条件都记录到假设日志,启动的时候,非常重要的才记录到项目章程.)

  • 规划阶段，较低层级的活动和任务假设条件不断被识别，要不断记录进假设日志中.(项目后边就是规划之后,或者执行的时候,或者监控的时候,再碰到那种假设条件或者质疑因素,都统统的记录到假设日志中.)

核心知识整理

  • 项目章程由 项目发起人或其他管理层发布， 项目经理经授权可参与起草

  • 项目章程对 项目经理进行授权，从而确保项目经理可以把组织资源用于项目活动

  • 在项目中，项目经理应该 尽早委派，最晚在规划之前

  • 专家判断是常用的工具与技术，人人都可以是专家

  • 通过头脑风暴产生大量新想法，不允许批评

  • 善用引导技术扩大参与度，达到预期成果

  • 假设日志用于记录整个项目生命周期中的所有假设条件和制约因素.(国产化的项目是属于信创的范围,所有数据库系统朝着系统必须用国产的,这就是制约因素.)

8.4 制订项目管理计划

8.4.1 课程目标

  • 掌握制定项目管理计划过程定义与作用
  • 了解制定项目管理计划涉及到的事业环境因素和组织过程资产
  • 理解制定项目管理计划与其他规划过程的输出的关系
  • 熟记项目管理计划包含的内容(12个子计划4个基准等内容)
  • 掌握项目管理计划与其他项目文件的区别

8.4.2 过程定义：制定项目管理计划

定义

  • 定义、准备和协调项目计划的所有组成部分，并把它们整合为一份综合项目管理计划.( 组成部分就是很多子计划和基准,就是把这些组成部分整合成一份综合的项目管理计划. )

作用

  • 生成一份综合文件，用于确定所有项目工作的基础及其执行方式(传统的预测型的项目管理过程,就是一切行动听指挥,指挥是计划还是一切行动,在项目管理计划里都写清楚了,执行就行了.)

时机

  • 仅开展一次或仅在项目的预定义点开展

  • 项目管理计划的目的：

    • 指导项目的执行、监控和收尾
    • 有助于干系人之间的沟通
    • 为绩效测量和项目控制提供基准

  • 解析:
    其实制定项目管理计划与其叫制定项目管理计划,不如叫整合项目管理计划,项目管理计划里边大的计划,包括范围管理计划,需求管理计划,成本管理计划,进度管理计划,资源管理计划,很多小的子计划等等.
    应该先做子计划和基准,就是先亲自或者派团队成员做不同的子计划,最后形成基准,最后把所有子计划和基准整合到一块,形成最大的项目管理计划,这个过程就叫制定项目管理计划.

8.4.3 数据流向图

  • 制定项目管理计划是整合,把这个其他组件,就是规划过程,子的规划过程会产生很多子的计划,把很多子计划叫其他组件,和四个基准整合到一块,形成项目管理计划.

关于项目管理计划

  • 项目管理计划确定项目的执行、监控和收尾方式，其内容会根据项目所在的应用领域和复杂程度的不同而不同，可以是概括或详细的

  • 项目管理计划应 基准化，即至少应规定项目的范围、日时间和成本方面的基准，以便据此考核项目执行情况和管理项目绩效.( 基准化就是项目管理计划通过批准之后,要作为基准,未来监控的时候要跟基准去比较,看执行情况,快了慢了,多了少了,基准化包括范围,进度,成本,都是基准化之后,才能进行未来的绩效考核. )

  • 确定基准之前，可多次更新无需遵循正式的流程

  • 一旦确定了基准，只能通过 实施整体变更控制过程进行更新.(一旦关键干系人批准了,再去改这个项目管理计划,必须走变更流程了,基准化的东西如果变更都得走严格的流程.)

8.4.4 ITTO

1. 输入

项目章程

  • 项目章程是项目启动时候制定的，是项目的纲领性文件，项目团队必须把项目章程作为初始项目规划的起始点，供项目管理计划的各个组成部分进一步细化.( 制定项目管理计划要参考项目章程,不能超越项目章程,可以细化,项目章程是规划的起点. )

其他过程的输出

  • 创建项目管理计划需要整合诸多过程的输出。其他规划过程的输出（ 子计划和基准 ）和项目管理计划之间的关系是循环往复和迭代的.( 项目管理计划是大型的综合性的计划,是整合了很多东西,很多东西是由其他规划过程产生的输出. )

事业环境因素

  • 能够影响制定项目管理计划过程的 事业环境因素包括：

    • 政府或行业标准（ 如 : 产品标准、质量标准、安全标准和工艺标准 ）
    • 法律法规要求和相关制约因素
    • 垂直市场（ 如 : 建筑）和专门领域（ 如 : 环境、安全、风险或敏捷软件开发 ）的项目管理知识体系
    • 组织的结构、文化、管理实践和可持续性
    • 组织治理框架（ 通过安排人员、制定政策和确定过程，以结构化的方式实施控制、指导和协调，以实现组织的战略和运营目标 ）
    • 基础设施 ( 如 : 现有的设施和固定资产 )

组织过程资产

  • 能够影响制定项目管理计划过程的 组织过程资产包括：

    • 组织的标准政策、流程和程序项目管理计划模板，包括：
      • 根据项目的特定要求而裁剪组织的标准流程的指南和标准
      • 项目收尾指南或要求，如产品确认及验收标准
    • 变更控制程序，包括修改正式的组织标准、政策、计划、程序或项目文件，以及批准和确认变更所须遵循的步骤
    • 监督和报告方法、风险控制程序，以及沟通要求
    • 以往类似项目的相关信息（ 如 : 范围、成本、进度与绩效测量基准、项目日历、项目进度网络图和风险登记册 ）
    • 历史信息和经验教训知识库

2. 工具与技术

专家判断

  • 征求专家意见的 主题

    • 根据项目需要裁剪项目管理过程，包括这些过程间的依赖关系和相互影响，以及这些过程的主要输入和输出
    • 根据需要制定项目管理计划的附加组成部分
    • 确定这些过程所需的工具与技术
    • 编制应包括在项目管理计划中的技术与管理细节
    • 确定项目所需的资源与技能水平
    • 定义项目的配置管理级别
    • 确定哪些项目文件受制于正式的变更控制过程
    • 确定项目工作的优先级，确保把项目资源在合适的时间分配到合适的工作

  • 直言解析 : 专家判断就是在制定项目管理计划的时候,请专家这啊帮你干什么.

数据收集

  • 头脑风暴特点 : 广泛参与,鼓励发言,不允许批评.
  • 焦点小组特点 : 主题专家座谈会,激烈的讨论,深入的讨论.
  • 访谈的特点 : 向重要干系人面对面的获得信息,关注如何制定项目管理计划
  • 核对单 : 核对单是一种比较简单的结构化很容易操作的一个工具和技术,通过核对单事先确定好的纸质的条目文件,去请求别人或者记录别人的一些信息,叫核对单.

人际关系与团队技能

会议

  • 在制定项目管理计划过程中，可以通过会议讨论项目方法，确定为达成项目目标而采用的工作执行方式，以及制定项目监控方式

  • 项目开工会议 ( kick-off meeting ) 一般是在 项目计划编制基本结束、执行工作开始前由主要干系人联合召开的会议，标志着项目开始实施，相当于开工典礼.(
    生活例子解析: 
    大部分传统的项目什么时候开开工会,开工会不是启动会,开工会像是最开始是踢球,场上双方球员对阵,谁来发球,教练踢到中间,不犯规的情况下,谁抢到谁算,这就是开工会.
    术语解析:
    规划做完之后,确定了,然后下一步开始执行,执行之前,要鼓励大家士气,所以规划之后执行之前那个时间点开的会叫开工会.    )

  • 项目开工会议的内容主要包括：

    • 明确项目目标以及团队目标
    • 介绍干系人及团队成员，建立联系
    • 阐明每个干系人的角色和职责
    • 获得团队对项目的承诺

对于小型项目：项目在启动之后就会开工
对于多阶段项目：通常在每个阶段开始时都要召开一次开工会议

3. 输出

项目管理计划内容(第二次复习要被记)

10+2 子计划( 9个知识领域,有十个子计划 )

  • 范围管理计划：确定如何定义、制定、监督、控制和确认项目范围
  • 需求管理计划：确定如何分析、记录和管理需求
  • 进度管理计划：为编制、监督和控制项目进度建立准则并确定活动
  • 成本管理计划：确定如何规划、安排和控制成本
  • 质量管理计划：确定在项目中如何实施组织的质量政策、方法和标准
  • 资源管理计划：指导如何对项目资源进行分类、分配、管理和释放
  • 沟通管理计划：确定项目信息将如何、何时、由谁来进行管理和传播
  • 风险管理计划：确定如何安排与实施风险管理活动
  • 采购管理计划：确定项目团队将如何从执行组织外部获取货物和服务
  • 干系人参与计划：确定如何根据干系人的需求、利益和影响让他们参与项目决策和执行
**两个特殊管理计划**
  • 变更管理计划：描述在整个项目期间如何正式审批和采纳变更请求
  • 配置管理计划：描述如何记录和更新项目的特定信息，以及该记录和更新哪些信息，以保持产品、服务或成果的一致性和（或）有效性

范围管理计划有两个子计划,范围管理计划和需求管理计划.

3+1基准

  • 范围基准：经过批准的范围说明书、工作分解结构 ( WBS ) 和相应的WBS词典，用作比较依据
  • 进度基准：经过批准的进度模型，用作与实际结果进行比较的依据
  • 成本基准：经过批准的、按时间段分配的项目预算，用作与实际结果进行比较的依据
  • 绩效测量基准；经过整合的项目范围、进度和成本计划，用作项目执行比较依据，以测量和管理项目绩效

其他内容

  • 项目生命周期：描述项目从开始到结束所经历的一系列阶段
  • 开发方法：描述产品、服务或成果的开发方法，例如 : 预测、迭代、敏捷或混合型模式
  • 管理审查：确定项目经理和有关干系人审查项目进展的时间点，以考核绩效是否符合预期，或者确定是否有必要采取预防或纠正措施
写论文有帮助举例 :
  • 因为项目里边技术特别复杂,涉及到很多软硬件配置,需要控制他们的变更,所以在做项目管理计划的时候,对其中的变更管理计划和配置管理计划,做了特别细致的阐述.

项目管理计划示例

     1.项目名称
         京华网上花店系统。
     2.项目背景
     随着互联网技术的飞速发展，互联网已经走进千家万户，“ 京华 ” 鲜花店为了突破时空限制，降低交易成本，节约客户订购、支付和配送的时间，方便客户购买，决定进入电子商务网上鲜花销售市场，建立一个京华网上销售系统，利用互联网在线支付平台进行交易，实现网络营销与传统营销双通道同时运行的新型鲜花营销模式。
     建设网上花店将取得以下几方面的收益：
       ① 网上销售带来量的增加。预计网站运营起半年内花店收入增长10%，一年半内销售收入增长50%。
       ② 网上销售带来的成本节约。预计鲜花销售成本可减少20%～30%。
       ③ 品牌增值带来的收益。网上商店的运作将扩大“京华”的知名度，提升“京华”品牌，最终使“京华”成为北京地区有影响力的鲜花网上销售企业。
     3.项目范围管理计划（范围基准）
     京华网上花店系统的总体目标是成为北京地区有影响力的鲜花网上销售企业，这一目标将分三个阶段实现。
     项目的范围定为采用现有的各种网络技术，构建一个鲜花、礼品等商品多级查询、选择、订购的网上销售系统，为客户提供方便、快捷、安全的网上购物环境。
     项目可交付成果包括一个网上购物商城，提供各类管理文档、开发技术文件、系统使用和用户手册，并对人员提供必要的培训。详细的可交付物说明参见WBS文档。
     项目范围管理的方法为：
     （1）范围说明书只有项目经理有权更新和发布。
     （2）范围说明书是制定项目WBS的基础和依据。
     （3）对项目范围说明书的更改或调整可能会引起合同变更，对此要慎重。
     4.项目进度管理计划（进度基准）
     项目建设周期约需要6个月。
     5.项目成本管理计划（成本基准）
     项目建设预计投入20万元，用于平台搭建、软硬件资源购买、技术支持及管理和人员的费用。成本预算方案见表8-3。



      6.项目质量管理计划
      项目开发过程中按照公司制定的CMMI三级标准过程来进行。在里程碑会议和周例会上按照公司的软件开发质量检查表、质量评审过程进行质量审查，提出改进措施并及时进行改进。详细的质量检查表、质量检查过程标准参见公司标准。
      7.项目人力资源计划
      金某某（项目经理）      主要负责经营策略与项目规划
      蒋某某                主要负责网站开发
      邓某                  主要负责网站的制作和维护
      程某某                主要负责市场调查和业务流程设计
      8.项目沟通计划
      利用BBS建立一个项目共享区，所有项目干系人都通过这个共享区进行交流与沟通。项目的进展情况通过项目例会和里程碑会议进行检查与收集。项目沟通计划可根据项目实际情况进行及时调整。
      9.项目风险管理计划（风险登记册）
      项目实施过程中可能遇到的风险及防范措施如下。
      1）技术风险
     （1）黑客攻击或者病毒入侵会导致网站死机或者不能访问，影响网上花店的运作。防范措施是加强病毒和入侵检测，设置好防火墙。
     （2）设备硬件损坏导致网站不能访问或者数据丢失，使花店客户遭受损失。防范措施是做好数据备份以及硬件备份。
     （3）开发方出现问题使开发进度缓慢导致实施进度无法跟上计划。防范措施：一是多方比较慎重选择合作方；二是签订规范合理合同，在出现纠纷时能通过法律途径保护本网站的正当权益。
      2）经营风险
     （1）网站宣传推广效果不好，网站访问量少。防范措施是推广网站时应根据企业的自身情况选定合适的搜索引擎注册，并且隔一段时间观察排名情况，总结出哪些搜索引擎能带来实际效果。注意跟进，积累数据，为了以后的业务开展积累经验，不断改进网站推广方式。还要注意引进结合网下的多种推广方式。
     （2）由于目前企业计算机人才缺乏，对外包单位依赖较大，网站一旦出现问题只能由其解决。防范措施是加强员工两个方面的技术培训，一是要求电子商务员熟悉网站各模块的操作；二是要求网络管理员熟悉网站系统的管理以及网站应用系统的程序。
     （3）若项目运营得比较成功，客户量增大，客户订单增长迅速，花店接纳客户能力（快速供货能力）会受到考验。防范措施是加强与供应商的合作与联系，提高双方的反应能力，避免出现订单积压、供货链断裂的现象。
      3）管理风险
     （1）由于业务流的改变，网上花店人员对新的销售流程不熟悉导致花店动作出现混乱。防范措施是加强对花店人员的业务培训，主要是网上业务流程的培训。
     （2）由于有网上与网下两种销售方式，其中的协调可能会出现问题。防范措施是统一协调制定网上网下的营销方案，加强各部门对网上销售业务的培训，以及准备应急的方案。
      4）市场风险可能出现多家竞争对手，使竞争激烈，导致预期销售量减少。防范措施是加强对竞争对手的分析，及时调整经营策略。
      10.项目采购计划
      项目所需要的硬件和软件的采购计划如下。
     （1）硬件选型方案所需设备如表8-4所示。

核心知识整理

  • 对于项目执行来说，“ 一切活动看计划 "
  • 项目管理计划由 项目管理团队与项目团队成员一同编制.( 由项目管理团队与项目团队成员一同编制,项目经理是属于管理团队计划,要让大家一块编制,一个是使用更多的智慧,一个是就是让大家更有未来团队执行的时候,更有动力,更有主人翁精神. )
  • 项目管理计划记录了规划过程组的各个子规划过程的全部成果
  • 项目管理计划包括 12 个子计划、4 个基准以及其他内容
  • 项目管理计划需要 关键干系人审批( 项目管理计划不能说项目经理审批绝对不行,因为这个计划涉及到很多部门,很多职能人员,所以项目管理计划包括任何一个子计划,都得是关键相关方批准,关键相关方可能包括职能部门经理(除了项目经理和团队成员之外),发起人领导(要用别人的资源或者设备),PMO等,每个组织里面关键干系人不一样,但是必须关键干系人批准. )
  • 通常采用 滚动式规划来逐渐细化项目管理计划，但形成基准后的变更需 CCB 批准(滚动式规划:通过子计划和基准给项目管理计划输入,反过来又要进行细节调整,调来调去,这是一个逐渐细化的过程,一旦决定,调整的差不多了,关键相关方已经批准了,形成基准了,再去变的话,就得走变更流程.)
  • 项目开工会一般是在 规划结束、执行之前召开的

8.5 指导与管理项目工作

8.5.1 课程目标

  • 掌握指导与管理项目工作过程的定义、作用
  • 熟悉指导与管理项目工作过程的输入、工具与技术及输出的内容
  • 掌握项目管理信息系统这一工具的应用以及各种会议的区分
  • 了解本过程输出的可交付成果、工作绩效数据的含义和内容
  • 掌握变更请求的类别，并能对它们进行区分( 变更有4类变更 )
  • 掌握问题日志的内容及应用

8.5.2 过程定义：指导与管理项目工作

定义

  • 为实现项目目标而领导和执行项目管理计划中所确定的工作，并实施已批准变更.( 简单来记指导与管理项目工作,既要执行项目管理计划的工作,也要执行经过批准或者修改之后带来那些工作,这叫批准的变更. )

作用

  • 对项目工作和可交付成果开展综合管理，以提高项目成功的可能性.( 综合管理就是团队成员在执行,项目经理在领导和指导大家执行,叫综合管理 )

时机

  • 需要在整个项目期间开展.( 需要在整个项目期间一直在做 )

  • 谁来执行这个过程 ：

    • 项目经理与项目管理团队(过程名是从项目经理或者管理团队的角度,把这个过程命名成指导与管理项目工作.)
    • 管理项目内的各种技术接口和组成部分
    • 对所有的活动进行动态管理
    • 对项目成员的工作进行检查、监督和控制

8.5.3 数据流向图

本过程重点关注如下内容

解析

  • 分配资源,执行活动 : 任何项目资源都是有限的,在执行的过程中,到底如何分配资源,要分配资源也包括人,用这些资源去执行活动,只有有资源执行活动,才能交付可交付成果,实现项目目标.
  • 实施已批准变更 : 项目里肯定有变更,已经批准的变更要放到过程里边去,实施批准的变更不光实施计划,还要实施这种变更.
  • 收集工作绩效数据 : 在执行的过程中,不要只关注交付可交付成果,要把执行过程中进度范围成本各个信息记下来,要交给监控过程去用,所以要及时的,实事求是的搜集工作绩效误区.

8.5.4 ITTO

1. 输入

项目文件

  • 可作为本过程输入的项目文件包括：

    • 需求跟踪矩阵：把产品需求连接到相应的可交付成果，有助于把关注点放在最终结果上
    • 风险登记册：提供可能影响项目执行的各种威胁和机会的信息
    • 风险报告：提供关于整体项目风险来源的信息，以及关于已识别单个项目风险的概括信息
    • 里程碑清单：列出特定里程碑的计划实现日期
    • 项目进度计划：至少包含工作活动清单、持续时间、资源，以及计划的开始与完成日期
    • 项目沟通记录：包含绩效报告、可交付成果的状态，以及项目生成的其他信息
    • 经验教训登记册：用于改进项目绩效，以免重犯错误。登记册有助于确定针对哪些方面设定规则或指南，以使团队行动保持一致
    • 变更日志：记录所有变更请求的状态

批准的变更请求

事业环境因素

  • 能够影响指导与管理项目工作过程的事业环境因素包括：

    • 组织的结构、文化、管理实践和可持续性
    • 基础设施（ 如 : 现有的设施和固定资产 ）
    • 干系人的风险临界值（ 如 : 允许的成本超支百分比 ）

组织过程资产

  • 能够影响指导与管理项目工作过程的组织过程资产包括：

    • 组织的标准政策、流程和程序
    • 问题与缺陷管理程序，用于定义问题与缺陷控制、
    • 问题与缺陷识别及其解决，以及行动事项跟踪问题与缺陷管理数据库，包括历史问题与缺陷状态、问题和缺陷解决情况，以及行动事项的结果
    • 绩效测量数据库，用来收集与提供过程和产品的测量数据
    • 变更控制和风险控制程序
    • 以往项目的项目信息（ 如 : 范围、成本、进度与绩效测量基准，项目日历，项目进度网络图，风险登记册，风险报告以及经验教训知识库 ）

2. 工具与技术

专家判断

  • 征求专家意见的主题

    • 关于项目所在的行业以及项目关注的领域的技术知识
    • 成本和预算管理
    • 法规与采购
    • 法律法规
    • 组织治理

项目管理信息系统（ PMIS ）

  • 项目管理信息系统充（ Project Management Information System ）由收集、整合和传播项目管理过程成果的工具和技术所组成的信息系统

  • 进度计划工具 : Excel也可以画干特图.
  • 工作授权系统 : 各项工作或者任务由谁在什么时间以什么顺序完成,比如:在工作授权系统里,先记录就是a工作,这个工作是由张三来做a工作,他的后续工作a做完才能做b工作,b工作由李四做,项目启动了,工作授权系统给第一个活动的张三发一个邮件或者什么提示,通知他可以做这件事了,张三把他的工作完成了,他在系统里提交已经完成了,经过测试,领导同意了,这一瞬间系统才给后边的负责b工作的李四发一个邮件或者一个系统提醒,告诉他可以开始做了,这就是经过授权之后,每个活动的人才开始工作,这个叫工作授权系统. 没有系统过去都是靠项目经理去监监控活动之间关系,前一个活动做完,再授权下一个活动开始,也可以叫工作授权.

会议

  • 可以通过会议来讨论和解决项目的相关事项。参会者不仅包括项目经理、项目团队成员，还要邀请与所讨论事项相关或会受该事项影响的干系人参会。应该明确每个参会者的角色，确保有效参会
会议类型
  • 开工会议
  • 技术会议
  • 敏捷或选代规划会议
  • 每日站会( 每一天早晨大家站着开一个15分钟的会,叫每日站会,一般是敏捷项目才有. )
  • 指导小组会议
  • 问题解决会议
  • 进展跟进会议
  • 回顾会议
会议技巧

  • 会前准备，应该做好准备工作，包括确定会议议程、目的、目标和期限

  • 会中控制把握会议进程和主题，处理意外情况

  • 会后总结要形成书面的会议纪要和行动方案。应该按照项目管理计划中的规定保存会议纪要

解析

  • 会前准备 : 开会之前要做好准备,准备包括要制定好会议的议程,确定会议的目标目的,还有就是谁来参加会议,叫会前准备.
  • 会中控制 : 如果你是会议主持人的话,要根据事先制定好的议程和主题,别让会议太拖沓,别让会议跑题了.
    会议控制有很多技巧,个开会的过程当中有很多人不来参加,或者很多人来参加了却低头不语,适当的去激发大家活跃气氛,如果开会的过程当中,总是有一个人反复的挑战你,规划怎么做,执行怎么执行,他会破坏会议环境,怎么去面对.
  • 会后总结,开会的过程当中形成了会议纪要,会议纪要和方案要发布给所有人,会议里大家承诺的行动,要跟踪,看看是不是大家执行了.

3.输出

可交付成果(最重要的输出)

  • 可交付成果（Deliverable）是在某一过程、阶段或项目完成时，必须产出的任何独特并可核实的产品、成果或服务能力.(可交付成果不一定是整个项目产生的,每个阶段都要有可交付成果,甚至每个过程都要有可交付成果.)

  • 注意以下几点：

    • 必须独特并可核实
    • 在某一个过程或阶段结束时都会产生可交付成果
    • 包括项目管理计划及其组成部分.(做一个软件开发产品,软件是可交付成果,但是中间的这些文件也是可交付成果.)

一旦完成了可交付成果的第一个版本，就应该执行变更控制

工作绩效数据

  • 工作绩效数据是在执行项目工作的过程中，从每个正在执行的活动中收集到的原始观察结果和测量值.(指导和管理项目工作或者是执行的时候,把执行过程中积累的第一手资料,叫工作绩效数据,原始观察结果和原始测量值把这些值叫工作绩效数据)

  • 工作绩效数据包括(了解)

    • 已完成的工作
    • 关键绩效指标 ( KPI )
    • 技术绩效测量结果
    • 进度活动的实际开始日期和完成日期
    • 已完成的故事点
    • 可交付成果状态
    • 进度进展情况
    • 变更请求的数量
    • 缺陷的数量
    • 实际成本及实际持续时间等

提示工作绩效数据是实事求是的数据。纯天然，没经过美颜处理

数据的变化

  • 数据位是最低的,就是从生产系统或者业务系统自动积累的,没经过处理的第一手的资料叫数据.
  • 一旦把数据经过处理之后,格式化结构化了,就变成信息.
  • 把信息层次再提高一下,经过分析处理,经过数据挖掘,经过AI技术,把这个信息处理成有意义的东西,给领导看,这个叫报告.报告要求图文并茂.
  • 数据/信息/报告是分层次的.

补充：项目管理数据和信息

  • 在整个项目生命周期需要收集、分析和转化大量的数据。经过汇总转化后以各种形式存储并分发给项目团队成员和其他干系人

解析

  • 工作绩效数据 : 执行的时候产生的,原始的数据,叫工作绩效数据
  • 工作绩效信息 : 工作绩效信息是把绩效数据跟各领域的基准相比,它是比较的数据,工作绩效信息也是很乱的一个东西,9大知识领域会产生9个工作绩效信息.

举例

  • 比如今天完成了两个活动,第一个活动花费了5万块钱,第二个活动花费了3万块钱,这个叫工作绩效数据,是关于成本的,花了一个3万,一个5万,到底多花了还是少花了,就是记下来了,项目经理或者项目管理团队或者团队成员把工作绩效数据跟跟基准成本基准比,或者说跟成本管理计划相比,本来今天应该花6万基准,结果花了8万,跟基准一比发现多花了2,比较结果或者多花2万,这个信息就不是数据,就叫工作绩效信息.

  • 工作绩效报告 : 项目经理或者团队把工作绩效信息再进行综合汇总、摘要，以图文并茂的形式,形成简要的一个文件,文件叫工作绩效报告.(一个总结好的清晰明了的文件.)

    • 报告不仅要信息，而且对发现的问题提出，最好还要提出解决方案，请领导关注或者请领导定夺
    • 工作绩效报告是为制定决策，提出问题采取行动或引起关注.
    • 由监控项目工作这个过程汇总所有工作绩效信息，形成工作绩效报告。

补充：项目数据、信息和报告流向

解析

  • 三个概念之间是如何形成的，就是执行过程，换句话说是指导和管理项目工作这个过程形成工作绩效数据，控制过程，是九大知识领域的监控过程，把自己知识领域的数据跟基准比，形成很多绩效信息，再由监控项目工作过程，把所有工作绩效信息，形成唯一的一个工作绩效报告，这个工作绩效报告通过沟通管理知识领域发给关系人。

问题日志

  • 在整个项目生命周期中，项目经理通常会遇到问题、差距、不一致或意外冲突。问题日志是一种记录和跟进所有问题的项目文件.(问题日志很多过程都会发现问题，都要进入到问题日志，只不过指导与管理项目工作会集中发现很多问题，所以写了一个输出叫问题日志。)

考过

  • 由谁负责解决问题 : 项目经理对于问题日志里每个问题，要分配，这个问题最后要由谁负责，或者谁解决，要为每个问题分配一个责任人，小型项目，项目经理可以是责任人，大型项目应该为每个问题分配一个责任人，由这个问题责任人去跟踪解决问题，如果这个问题再扩大，赶紧向项目经理汇报，请求项目经理的协助也解决不了，赶紧向发起人汇报，不然问题很可能造成项目更大的风险或者漏洞，甚至导致问题不及时解决，项目失败。

问题状态

  • 问题状态，问题日志可能并不陌生，工作中不一定是项目，比如：客户服务，其实每一个报错向你汇报bug，它就是一个问题，这个问题没解决的，状态叫open，open是没解决，如果解决了，客户已经满意了，把这个问题状态改成close，未来如果是很长时间，还是没解决open的问题，那可能会引起更多的投诉或者不满，这是如何用问题日志进行问题的记录和管理.

提示问题日志可以帮助项目经理有效跟进和管理问题，确保它们得到调查和解决。应该随着监控活动随时更新问题日志.( 问题日志可以帮助项目经理有效跟进和管理问题，确保得到调查和解决，换句话说，项目经理即使不是每个问题的责任人、负责人，也要在项目里，一直要监控问题日志的情况，实际上最关心的就是可以筛选看哪些问题，特别是级别比较高的问题还处于未解决状态。 )

变更请求

  • 变更请求是关于修改任何文件、可交付成果或基准的正式提议.(变更请求是关于修改任何受控文件(比如:基准),或者变更管理计划里写清楚的受控文件的修改,一般来讲,可交成果和基准修改都要提变更请求,但是很多琐碎的文件,就不应该走变更流程,提变更请求.)
变更请求的特点

任何方面

  • 开展项目工作时发现的问题都可提出变更请求，可针对项目政策或程序、项目或产品范围、成本、进度、成果、质量等

人人可提

  • 任何项目干系人都可以提出变更请求，内部或外部、强制的或自自由选择

统一审批

所有变更请求都将交给实施整体变更控制过程进行审查，可能被批准，也可能被拒绝

影响广泛

  • 被批准之后会引起对相关文档、可交付成果或基准的修改，也可能导致对项目管理计划其他相关部分的更新

总结:

变更请求人人可以提,就是所有干系人,包括客户,未来的用户,发起人,团队成员,职能经理都行,人人都可提任何方面的变更,但是,只要是提出正式的变更,所有变更都得走变更流程,统一审批,在审批之后,可以拒绝或者同意,但是必须走变更流程.
为什么所有变更必须走流程?

比如说客户提出的范围变更,他很可能去影响进度,成本,资源等等,这个就叫影响广泛,所以这个变更要走流程,经过评估之后,再决定是否进行变更,牵一发而动全身.

变更请求包括：
  • 纠正措施
  • 预防措施
  • 缺陷补救
  • 更新
纠正措施
  • 纠正措施（ Corrective Action ）就是为使项目工作绩效重新与项目管理计划一致，而进行的有目的的活动.( 纠正就是已经发现了工作绩效 ( 绩效: 一般是指进度或者成本 ) 进度延误了或者成本跟计划或者基准相比成本超支了,已经实际情况跟计划基准已经不一致了,想让他重新一致,比如说已经超支了,想让他节约回来,已经延误了,想把时间追回来,让他重新一致,采取的措施叫纠正措施. )

提示 : 在根据需要采取纠正措施之后要对纠正措施的有效性进行评价，看是否达到了预期的效果

预防措施
  • 预防措施（ Preventive Action ）是为确保项目工作的 未来绩效符合项目管理计划，而进行的有目的的活动.( 距离解析 : 今天下午讲课,5点已经讲完了,就是该把整个管理讲完,5点已经讲完了,但是如果通知说明天上午会议室占用,明天上午本来要讲范围管理,明天上午没法讲了,就决定还是今天5点讲到6点,这个措施是为了防止明天会产生进度延误,预防未来可能的偏差
    今天提前多讲了,这个措施就叫预防措施.     )

提示 : 预防措施就是通过实施某项活动来降低项目风险消极后果

缺陷补救
  • 缺陷补救（ Defect Repair ）是为了修正不一致产品或产品组件的有目的的活动，主要针对成果.( 预防还是纠正两类都是针对于绩效进度成本之类的,缺陷补救针对于可交付成果,就是项目该交付的可交付成果,包括最终的产品,中间的可交付成果,做错了不符合用户要求,就得返工,这种就是缺陷,缺陷不仅仅会影响进度或者成本,很可能会造成更严重的信誉的损失. )

提示 : 应通过优秀的过程控制尽量防止出现缺陷补救的情况发生(一般来讲进度成本绩效可以有一些偏差,但是没有成果的就是不一致严重.)

更新
  • 更新（ Updates ）是对正式受控的项目文件或计划等进行的变更，以反映修改或增加的意见或内容.( 更新就是针对于受控的文件(文件包括项目管理项(重要的项目,不是所有的,是在项目管理计划里写清楚哪个项目文件重要，更新它的时候才会提变更请求)、有计划(一般来说,项目管理计划更新,要提变更请求))，就是对于文档类的东西进行变更，这种变更请求叫更新 )

提示 : 对项目文件或项目管理计划的更新也是变更请求的一部分.(一般来说前三类变更，就是预防、缺陷补救，纠正措施，很可能会引起更新，因为要改计划或者改基础)

预防措施、纠正措施、缺陷补救之间的区别

项目文件更新

  • 可在本过程更新的项目文件包括：

    • 活动清单：为完成项目工作，可以通过增加或修改活动来更新活动清单
    • 假设日志：可以增加新的假设条件和制约因素，也可以更新或关闭已有的假设条件和制约因素
    • 经验教训登记册：任何有助于提高当前或未来项目绩效的经验教训都应得到及时记录
    • 需求文件：在本过程中可以识别新的需求，也可以适时更新需求的实现情况
    • 风险登记册：在本过程中可以识别新的风险，也可以更新现有风险。风险登记册用于在风险管理过程中记录风险
    • 干系人登记册：如果在本过程中收集到了现有或新干系人的更多信息，则记录到干系人登记册中

项目管理计划更新

  • 项目管理计划的任何变更都以变更请求的形式提出，且通过组织的变更控制过程进行处理。项目管理计划的任一组成部分都可在本过程中通过变更请求加以更新

组织过程资产更新

  • 可在本过程更新任何组织过程资产

核心知识整理

  • 指导与管理项目工作过程执行的是项目管理计划和已批准的变更请求，并在过程中收集工作绩效数据

  • 项目的大多数预算和资源都花费在这个过程

  • 项目管理信息系统PMIS是事业环境因素的组成部分，它的两个重要子系统是配置管理系统和变更控制系统

  • 可交付成果必须独特并可核实，既包括最终产品，也包括项目管理计划及其组成部分

  • 问题日志是一种记录和跟进所有问题的项目文件，应该为每个问题分派责任人

  • 变更请求是在项目计划执行过程中以正式书面文件提出的，由整体变更控制过程处理。包括纠正措施、预防措施、缺陷补救及更新

8.6 管理项目知识

8.6.1 过程定义：管理项目知识

定义

  • 使用现有知识并生成新知识，以实现项目目标，并且帮助组织学习

作用

  • 利用已有的组织知识来创造或改进项目成果，并且使当前项目创造的知识可用于支持组织运营和未来的项目或阶段

时机

  • 在整个项目期间开展

误解：知识管理只是在项目结束时总结经验训，以供未来项目使用

解析：知识管理是利用现有知识来创造和改进项目成果，越早执行越好；项目创造出新的知识应该随时记录到经验教训登记册，项目未来的活动或未来阶段均可使用( 首先这个管理项目知识不是说等项目结束了,把知识统一的整理一下,不是看这个过程,它是两件事,要用已有知识改进当前的项目成果,所以管理项目知识越早执行越好,只不过在项目结束之后要统一的,把项目积累的知识记录回经验教训.
登记册过程很简单,但是主要会教训登记册,实际上建设教训登记册随时记录,就是项目经理和团队成员发现的新知识,随时记录到登记册里,等项目结束之后,登记册要归到组织过程资产里去,整体来讲这个过程会持续随之展开. )

8.6.2 数据流向图

显性知识与隐性知识

解析

显性知识

  • 实际上平时所说的数据管理,信息管理,主要指的是显性知识或者可编码,就是能用文字或者数字表达出来的这些知识,这些知识是容易交流,容易共享.

隐性知识

  • 实际上项目里边最可贵的也是最难分享的,任何情况都是隐性知识,也叫不可编码的知识,很难分享和交流,因为难以格式化,难以表达,比如:信念,洞察力,经验,诀窍等等.

工具与技术

  • 一般来讲，进行显性知识的传播用传统的一种工具或者技术就行了，叫信息管理。所以信息管理对项目中的显性知识进行处理，包括记录，生成新知识，信息管理只关注显性知识。
  • 知识管理工具和技术是管理隐性知识，它包括知识分享，知识集成等。

关键环节

  • 营造相互信任的氛围激励人们分享、关注他人的知识( 促进分享,创造相互信任的氛围. )

8.6.3 ITTO

  • 组织过程资产更新:一般是项目收尾的时候,要把经验总结为组织过程资产,给组织未来的项目看.

1.输入

项目管理计划

  • 项目管理计划的所有组成部分均为本过程的输入

项目文件

  • 输入的项目文件包括：项目团队派工单资源分解结构供方选择标准千系人登记册

可交付成果

  • 可交付成果是在某一过程阶段或项目完成时，必须产出的任何独特并可核实的产品、成果或服务能力

事业环境因素

  • 能够影响管理项目知识过程的事业环境因素包括：

    • 组织文化、干系人文化和客户文化。相互信任的工作关系和互不指责的文化对知识管理尤其重要。其他因素则包括赋学习的价值和社会行为规范

    • 设施和资源的地理分布。团队成员所在的位置有助于确定收集和分享知识的方法

    • 组织中的知识专家。有些组织拥有专门从事知识管理的团队或员工

    • 法律法规要求和（或）制约因素。包括对项目信息的保密性要求

组织过程资产

  • 能够影响管理项目知识过程的组织过程资产包括：

    • 组织的标准政策、流程和程序。可能包括：信息的保密性和获取渠道、安全与数据保护、记录保留政策、版权信息的使用、机密信息的销毁、文件格式和最大篇幅、注册数据和元数据、授权使用的技术和社交媒体等

    • 人事管理制度。包括员工发展与培训记录以及关于知识分享行为的能力框架

    • 组织对沟通的要求。正式且严格的沟通要求有利于信息分享。对于生成新知识和整合不同干系人群体的知识，非正式沟通更加有效

    • 正式的知识分享和信息分享程序。包括项目和项目阶段开始之前、开展期间和结束之后的学习回顾，例如识别、吸取和分享从当前项目和其他项目获得的经验教训

    • 经验教训登记册。提供个有效的知识管理实践

2.工具与技术

专家判断

  • 征求专家意见的主题

    • 知识管理
    • 信息管理
    • 组织学习知识和信息管理工具
    • 来自其他项目的相关信息

知识管理

  • 知识管理工具和技术将员工联系起来，使他们能够合作生成新知识、分享隐性知识，以及集成不同团队成员所拥有的知识

  • 使用的具体技能包括：

    • ① 人际交往，包括非正式的社交和在线社交。可以进行开放式提问的在线论坛有助于与专家进行知识分享对话；

    • ② 实践社区和特别兴趣小组；

    • ③ 会议，包括使用通信技术进行互动的虚拟会议；

    • ④ 工作跟随和跟随指导；

    • ⑤ 讨论论坛，如焦点小组；

    • ⑥ 知识分享活动，如 : 专题讲座和会议；

    • ⑦ 研讨会，包括问题解决会议和经验教训总结会议；

    • ⑧ 讲故事；

    • ⑨ 创造力和创意管理技术；

    • ⑩ 知识展会和茶座；

    • ⑪ 交互式培训等

  • 提示 : 面对面互动最有利于建立知识管理所需的信任关系。首次沟通应通过面对面沟通建立关系

解析

  • 讲故事: 把收集来的用户的需求,不叫需求,就是叫用户故事,这样的话,就是更容易进行人和人之间的交流,更容易让这个互相之间懂相互在说什么.

信息管理

  • 信息管理工具和技术用于创造信息并建立人们与信息之间的联系。它们可用于有效分享简单、明确并经编撰的显性知识

  • 具体手段和工具( 工具有信息库 )：

    • 编撰显性知识的方法，例如，如何确定经验教训登记册的条目

    • 经验教训登记册

    • 图书馆服务(应该是文库目录服务,翻译有误)

    • 信息收集，例如搜索网络和阅读已发表的文章

    • 项目管理信息系统（ PMIS )，项目管理信息系统通常包括文档管理系统

  • 提示 : 加入互动功能，更有利于信息获取和分享，如 " 与我联系 " 的功能

人际关系与团队技能

  • 积极倾听 : 积极倾听在所有的沟通技巧里,最好的沟通方式是面对面沟通,但是还有一个跟它并列的,面对面沟通过程中你也要积极倾听,积极倾听是一个非常好的沟通方式.
  • 领导力 : 领导力主要是影响力,就是如何这个建立愿景,激励别人.
  • 大局观 : 大局观应该翻译就是政治意识,但是官方的教程把这翻译成大局观了.项目经理不光要关注项目本身,在那个小的范围还要关注整个组织内外部的大环境,根据大的环境(比如 : 组织之间之内的各种领导关系,层级关系),进行有效的沟通或者知识管理.

3.输出

经验教训登记册

  • 如何记录项目中获得的经验教训呢？

  • 经验教训登记册用于记录遇到的挑战、问题、意识到的风险和机会，或其他内容经验教训登记册可以包含情况的类别和描述、与情况相关的影响、建议和行动方案可以采用纯文字的形式，也可加入视频、图片、音频内容(登记册可以认为就是一个word文件或者一个Excel表格,把收集到团队的随时积累的每个知识都记录到经验教训登记册的条目里,载体无所谓,记录方式无所谓,用纸笔也行.)

项目管理计划更新

  • 项目管理计划的任何变更都以变更请求的形式提出，且通过组织的变更控制过程进行处理。项目管理计划的任一组成部分都可在本过程中更新

组织过程资产更新

  • 所有项目都会生成新知识。通过管理项目知识过程，某些新知识被编撰，被嵌入可交付成果，或者被用于改进过程和程序。在本过程中，也可以首次编撰或使用现有知识可在本过程更新任一组织过程资产

核心知识整理

  • 管理项目知识是利用已有的组织知识来改进项目成果，并且使当前项目创造的知识可用于支持组织运营和未来的项目或阶段

  • 项目创造出新的知识应该随时记录到经验教训登记册

  • 知识可分为显性知识与隐性知识

  • 知识管理这个工具和技术主要是利用人际互动来管理隐性知识

  • 信息管理这个工具和技术用于管理显性知识

  • 加入互动功能，更有利于信息获取和分享

  • 在项目或阶段结束时，把相关信息归入经验教训知识库，成为组织过程资产的一部分

8.7 监控项目工作

8.7.1 过程定义：监控项目工作

  • 监督和监控比较解析:
    监控分为两部分,监控实际上有一个工作叫监督,监督是比较弱了,监督执行,只能没有权利关系的角度,监督这件事做的好或者不好,真正有效的干预要通过控制手段,控制才可以,要求对方采取纠正措施,改进自己的缺陷解决问题,把监督和控制合到一块才叫监控.

定义

  • 跟踪、审查和报告整体项目进展，以实现项目管理计划中确定的绩效目标

作用

  • 让干系人了解项目的当前状态并认可为处理绩效问题而采取的行动，以及通过成本和进度预测，让干系人了解未来项目状态

时机

  • 在整个项目期间开展

监督

  • 收集、测量和分析测量结果，以及预测趋势，以便推动过程改进洞察项目的健康状况

控制

  • 制定纠正或预防措施或重新规划并跟踪行动计划的实施过程，以确定它们能否有效解决问题

  • 监控项目工作:任何一个管理的一个职能,包括通用管理监控都很重要,当初要制定计划,制定基准,都是在给监控用,监控就是在项目的执行过程中,从第三方的角度随时来看项目,包括项目的进展,项目的成本花费,人员的状态是不是符合预定标准,如果不监控比如一年的项目,等到一年再看结果,那肯定就死定了.

提示 : 监督发现问题，控制纠正问题.(实际上如果拆分的话,就是监督是发现问题,控制是纠正问题,监控项目工作的目的或者干什么.)

8.7.2 数据流向图

监控项目工作关注点(可以写到论文或案例中)

  • 把项目的实际绩效与项目管理计划进行比较

  • 定期评估项目绩效，决定是否需要采取纠正或预防措施，并推荐必要的措施

  • 检查单个项目风险的状态

  • 在整个项目期间，维护一个准确且及时更新的信息库，以反映项目产品及相关文件的情况

  • 为状态报告、进展测量和预测提供信息

  • 做出预测，以更新当前的成本与进度信息

  • 监督已批准变更的实施情况

  • 如果项目是项目集的一部分，还应向项目集管理层报告项目进展和状态

  • 确保项目与商业需求保持一致

8.7.3 ITTO

1.输入

项目管理计划

  • 项目管理计划中的子计划和基准是监控的依据监控就是审查实际执行的工作和项目管理计划中所确定的工作有何出入

项目文件

  • 输入的项目文件包括：假设日志、风险登记册风险报告，里程碑清单估算依据、问题日志经验教训登记册、成本预测、进度预测、质量报告

工作绩效信息

  • 工作绩效信息来自于各个子控制过程，呈，已经把工作绩效数据与项目管理计划组成部分、项目文件进行了比较

协议

  • 协议中包括买方就卖方应实施的工作或应交付的产品所做的规定，项目经理需要监督承包商的工作，确保所有协议要求

事业环境因素

  • 能够影响监控项目工作过程的事业环境因素包括：

    • 项目管理信息系统，例如进度、成本、资源工具、绩效指标、数据库、项目记录和财务数据
    • 基础设施（ 如 : 现有设施、设备、组织通讯渠道 ）
    • 干系人的期望和风险临界值
    • 政府或行业标准（ 如 : 监管机构条例、产品标准、质量标准和工艺标准 ）

组织过程资产

  • 能够影响监控项目工作过程的组织过程资产包括：

    • 组织的标准政策、流程和程序
    • 财务控制程序（ 如 : 必需的费用与支付审查、会计编码及标准合同条款等 ）
    • 监督和报告方法
    • 问题管理程序，用于定义问题控制、问题识别及其解决，以及行动事项跟踪
    • 缺陷管理程序，用于定义缺陷控制、缺陷识别及其解决，以及行动事项跟踪
    • 组织知识库，尤其是过程测量和经验教训知识库

2.工具与技术

专家判断

  • 征求专家意见的主题

    • 挣值分析
    • 数据的解释和情境化
    • 持续时间和成本的估算技术
    • 趋势分析
    • 关于项目所在的行业以及项目关注的领域的技术知识
    • 风险管理
    • 合同管理

数据分析

备选方案分析
  • 用于在出现偏差时选择要执行的纠正措施或纠正措施和预防措施的组合
成本效益分析
  • 有助于在项目出现偏差时确定最节约成本的纠正措施
挣值分析
  • 对范围、进度和成本绩效进行了综合分析
根本原因分析
  • 关注识别问题的主要原因，它可用于识别出现偏差的原因以及项目经理为达成项目目标应重点关注的领域.(根本原因分析,有些企业简称根因分析,在很多过程都会用到,比如质量,控制质量过程,发现质量问题首先进行根本原因分析,第二步是找解决方案,根本原因分析永远是解决问题的第一步.)
偏差分析
  • 偏差分析审查目标绩效与实际绩效之间的差异（或偏差），可涉及持续时间估算、成本估算、资源使用、资源费率、技术绩效和其他测量指标

重要性 : 在监控项目工作过程中通过偏差分析对成本、时间、技术和资源偏差进行综合分析，以了解项目的总体偏差情况
如偏差不可接受，可推荐合适的预防或纠正措施

  • 偏差分析不只是做找差距/找偏差,找到差距之后,还要负责找到为什么有差距(就是找原因),还要做找到解决原因的推荐的措施,才是完整的偏差分析.

案例

  • 比如成本超支了5万块钱,超支5万块钱怎么办,是放任不管,还是下周要采取纠正措施,那超支5万那就采取纠正措施吗?
  • 解析:
    不一定.如果偏差不可接受,才采取纠正措施,到底5万块钱可接受还不可接受,每个项目不一样而且也不是项目经理现场决定的,项目经理认为本周5万块钱偏差太大了,要采取金融措施,或者说进度上,认为现在进度落后了两天,要采取措施,不是项目经理临时决定的.
  • 解决 : 
    现在成本超了5万,项目经理要参考什么,项目里边有一个子计划,项目管理计划其中一个子计划,叫项目成本管理计划,成本管理计划里边会清清楚楚的记清楚,因为当时就是项目经理领大家写的成本管理计划,另一边会写成本偏差的容忍值,比如成本偏差容忍值每周正负10万块钱无所谓,不用采取集中措施,这周结束了,只差了5万不要采取任何措施,所以不是说有偏差就要采取措施,不然项目经理死定了,随时随地都有偏差,项目经理不是一直在执行预防或者纠正措施,就是得有一个预值或者界限值.
趋势分析
  • 趋势分析根据以往结果预测未来绩效，它可以预测项目的进度或成本，可以根据趋势分析的结果，提出必要的预防措施建议.(趋势分析比偏差分析高级一点,它用的技术至少比偏差分析稍微高级一点点,它是根据过去的结果来预测未来的绩效,除了进度和成本可以是其他的,但是主要是进度或者成本,如果是发现未来绩效会变差,可以提预防措施提前执行.)

  • 到目前为止的进度情况可以公布一下,根据现在的情况整个项目下个月可能会延期15天,整个项目可能会延期一个月,这是对未来的预测,如果说领导或者关键干系人不满意,可以提前采取措施,提前增加资源啊赶工等,把让未来的绩效变好.
  • 建议应该在项目的早期进行趋势分析,这样的话,有时还有时间进行各种权衡,提前采取干预

提示 : 偏差分析关注现在，趋势分析关注未来。趋势分析通常基于偏差分析( 趋势分析是基于偏差分析的,没有偏差分析结果,不可能对未来进行预测 )

决策(就是选择的意思)

  • 可用于本过程的决策技术包括（ 但不限于 ）投票。投票可以包括用下列方法进行决策：一致同意、大多数同意或相对多数原则.(人为什么高贵,因为人有做选择的权利,人什么时候最痛苦,就是在做选择或者做决策的时候,如果在面临决策的时候,掌握一些科学的手段或者方法,就可以提高决策效率,减少困扰,所以决策工具的技术,也是项目经理应该了解的.)

会议

  • 会议可以是面对面或虚拟会议，正式或非正式会议。参会者可以包括项目团队成员和其他合适的项目干系人；会议的类型包括（但不限于）用户小组会议和用户审查会议.(指在监控项目工作的过程当中,可能要组织大家召开各种会议.)

3.输出

工作绩效报告

  • 工作绩效报告是为制定决策、采取行动或引|起关注而汇编工作绩效信息所形成的实物或电子项目文件.(工作绩效报告文件唯一是监控项目工作过程产生的)

解析:

把子的监工过程各个方面形成的工作绩效信息,整合或者汇编形成工作绩效报告,通过沟通管理计划不是工作绩效报告发给所有人,而是在沟通管理计划里写清楚工作绩效报告每一周的报告,要通过什么形式,发给哪些该系人,然后才能对应的去发送发布.(在大中型的项目管理里边,写工作绩效报告这件事,很浪费人力物力还有时间,所以项目经理应该号召所有的人员,或者相关能力比较强的团体成员去写报告.)

提示 : 绩效报告由项目团队编制，而非项目经理独自完成

工作绩效报告

  • 工作绩效报告的形式多样，可以包括状态报告和进展报告

变更请求

  • 结论 : 通过比较实际情况与计划要求可能需要提出变更请求

**图片解析 : **

主要是可能需要提出变更请求,变更请求可以是关于项目范围的,主要是由用户或者客户提的,团队或者其他干系人也可以提,监控过程当中,要扩大调整缩小范围,或者监控过程当中,发现质量有问题,可以去调整产品质量,也可以另外一个渠道,去改质量标准或者基准,都可以调整,这些最后都要形成变更请求.

提示 : 所有变更必须通过实施整体变更控制过程进行审查和处理

项目管理计划更新

  • 项目管理计划的任何变更都以变更请求的形式提出，且通过组织的变更控制过程进行处理。在监控项目工作过程中提出的变更可能会影响整体项目管理计划

项目文件更新

  • 成本预测：本过程引起的成本预测的变更应通过成本管理过程进行记录
  • 进度预测：本过程引起的进度预测的变更应通过进度管理过程进行记录
  • 问题日志：在本过程中产生的新问题应该记录到问题日志中
  • 经验教训登记册：更新经验教训登记册，记录应对偏差的有效方式以及纠正措施和预防措施
  • 风险登记册：在本过程中识别的新风险应记录在风险登记册中，并通过风险管理过程进行管理

核心知识整理

  • 不仅要对项目执行情况进行监控，而且要对项目启动、规划、收尾等进行监控
  • 偏差分析就是审查目标绩效与实际绩效之间的差异或偏差，所有领域的指标都可以进行偏差分析
  • 趋势分析根据以往结果预测未来绩效，可以预测项目的进度或成本
  • 偏差分析关注现在，趋势分析关注未来，趋势分析通常基于偏差分析
  • 各个子监控过程的工作绩效信息汇编成工作绩效报告
  • 监控项目工作过程的一项重要输出是变更请求。此外，变更请求也可以在执行过程中提出

8.8 实施整体变更控制

整体变更控制是项目管理49个过程里,非常非常重要的一个过程,因为项目里边变更,不是难以避免,是不可避免,所有变更都应该交给这个过程处理.后面有一章专门讲变更和配置管理,而且有的时候,下午的考题,比如:案例题,会单独出变更管理流程怎么做?

8.8.1 课程目标

  • 熟记实施整体变更控制的概念

  • 了解实施整体变更控制过程包括的变更管理活动

  • 熟练掌握整体变更控制流程( 有个变更申请提出来之后,以什么流程进行处理 )

  • 掌握配置管理活动(重点难点,后面章节分散了此处的学习难度.)

  • 熟记变更控制委员会 CCB 的定义、组成及作用

8.8.2 过程定义：实施整体变更控制

定义

  • 审查所有变更请求、批准变更，管理对可交付成果、项目文件和项目管理计划的变更，并对变更处理结果进行沟通( 基准变更其实也包括拒绝变更. )

作用

  • 确保对项目中已记录在案的变更做综合评审。如果不考虑变更对整体项目目标或计划的影响就开展变更，往往会加剧整体项目风险.(一定要把整体变更控制这个过程放到整合管理,不管是哪方面提出的任何一个变更,都要考虑这个变更对项目整体的影响.)

时机

  • 在整个项目期间开展

关于实施整体变更控制

  • 该过程贯穿项目始终：任何时间、任何干系人都可以提出变更请求，因此实施整体变更控制过程贯穿项目始终

  • 基准变更必须走正式变更流程 ：除基准之外，应该在项目的配置管理计划中规定哪些项目组件的变更需要走正式流程

  • 变更请求必须书面记录 ：每项记录在案的变更请求都必须由一位责任人批准、推迟或否决，这个责任人可以是、项目发起人、项目经理或变更控制委员会 CCB.

解析:整个大的项目管理计划包括12个子计划,12个子计划最后两个子计划,一个是励志管理计划,一个是变更管理计划,那实际上配置管理计划里讲的很清楚,哪些配置项如果产生变更,要走整体变更控制流程.
变更请求可以是口头提出来的,比如 : 领导要提个变更,可能只是口头说说,但是项目团队必须把它变成多面的一个记录,因为最终要进行评估处理,最终要提交给CCB,也别特别教条,有的变更记录是输入系统记录的,系统里也是书面记录.

8.8.3 数据流向图

8.8.4 ITTO

**重要工具 : **

  • 变更控制工具
  • 批准变更请求

重要概念：变更控制委员会

  • 变更控制委员会（ Change Control Board，CCB ）是一个由干系人正式组成的团体，负责审查、评价、批准、推迟或否决项目变更，以及记录和传达变更处理决定.(变更管理计划里会写的很清楚,怎么样的变更是项目经理审批就行了,比如:金额在3万块钱以下或者某些紧急情况,这些要走变更流程,但是审变更的审批环节,项目经理就行了,更小的更专业的变更,变更管理计划理写只需要团队成员某个技术工程师或者技术总监批准就行了,涉及到5万块钱以上或涉及到四个基准的变更等等,这些变更才通过CCB审批,不是所有变更都走CCB,最重要的或者基准的变更才走CCB.)

  • CCB : 基本都是高于项目经理的人.

提示 : 变更控制委员会CCB所作出的决定和建议都应该记录在案

1.输入

项目管理计划、项目文件、工作绩效报告

变更请求

再次提醒
  • 只要项目没正式结束，所有干系人在项目的任何时间都可以提变更请求，并且项目经理或团队成员必须书面记录并进行评估

示例

  • 每个企业不一样,叫的名字可能不一样.

事业环境因素

  • 能够影响实施整体变更控制过程的事业环境因素包括：

    • 法律限制,例如国家或地区法规

    • 政府或行业标准 ( 如 : 产品标准、质量标准、安全标准和工艺标准 ）

    • 法律法规要求和(或)制约因素

    • 组织治理框架 (通过安排人员、制定政策和确定过程，以结构化的方式实施控制、指导和协调，以实现组织的战略和运营目标 ）

    • 合同和采购制约因素

组织过程资产

  • 能够影响实施整体变更控制过程的组织过程资产包括：

    • 变更控制程序，包括修改组织标准、政策、计划和程序或任一项目文件所须遵循的步骤，以及如何

    • 批准和确认变更批准与签发变更的程序

    • 配置管理知识库，包括组织标准、政策、程序和项目文件的各种版本及基准

2.工具与技术

专家判断

  • 征求专家意见的主题

    • 关于项目所在的行业以及项目关注的领域的技术知识
    • 法律法规
    • 法规与采购
    • 配置管理
    • 风险管理

变更控制工具

  • 变更控制工具是用于进行配置管理和变更管理的手工或自动化的工具

  • 配置管理关注技术规范,他不关注流程,所谓的技术规范比如:现在要开发一个软件,只关注这个软件产品有几个功能,这个软件产品达到哪些能力或者性能,这个软件产品的模块有服务器的模块,关注这些东西,关注技术规范
应支持的配置管理活动
识别配置项
  • 确定哪些可交付成果最终产品或重要文件)作为配置项纳入配置管理系统
记录并报告配置项状态
  • 每个配置项状态发生变化时都要进行记录，以便随时提供配置项的正确信息
进行配置项核实与审计
  • 核实每个配置项正确完成并可用、确保对每个变更都被按流程处理

配置管理主要做要识别配置项,因为配置管理第一个最重要的一件事,识别哪些软硬件纳入配置项,一旦纳入配置项,就开始进行变更管理了.每一周每一时刻每一个配置项都有变化,服务器端的模块,把它纳入配置项了,开发团队开发完,测试完了,要把这个模块放到配置库,并且在配置管理上写清楚,
服务器模块1.0版本成功开发了,就是配置箱的状态要随时记录,然后每一周或者每一个月,要把目前各个配置项,项目里边有100个配置项,要把所有配置项的状态进行审核,就是看一下每个配置项记录的信息跟配置项真实的信息是否一致,是不是某个配置项服务器端模块已经开发到3.0版本了,但是配置库里,配置项只记录到2.0版本,那这不行了.

  • 变更管理着眼流程,着眼于识别记录批准或否决,对各种东西进行变更的流程,叫变更管理.
应支持的变更管理活动
识别变更
  • 识别并选择过程或项目文件的变更项
记录变更
  • 将变更记录为合适的变更请求
做出变更决定
  • 审查变更，批准、否决、推迟变更
跟踪变更
  • 确认变更被登记、评估、批准、距跟踪并向干系人传达最终结果

数据分析

备选方案分析
  • 该技术用于评估变更请求，并并决定哪些请求可接受、压应否决或需修改
成本效益分析
  • 该分析有助于确定变更请求是否值得投入相关成本

为什么在做变更的时候要做成本效益分析?

  • 对一个项目提出变更之后,要做这个变更或者不做这个变更,或者用什么手段做变更,都要考虑一下方案,
    变更方案的投入和变更方案所产生的收益是否值得,所以要做成本效益分析.项目里面质量是不是做的越高越好,需要做成本效益分析知晓.

决策

投票

  • 决策方法最简单的就是投票,比如有1万个投票人,只有两个候选人,那1万个人很难达成一致,如果是就是口碑人特别多的情况下,可以采取这个大多数同意,如果是候选人特别多,退而求其次,可以采取相对多数的原则,这是投票.

独裁型决策制定

  • 做决策的人就是一个是品行比较高,大公无私没有私心,为全局或者为整体着想.另一个他的经验或者决策能力足够强,评定谁做决策者,最好的方式就是独裁型决策,这种方式进行决策最快最节约成本,而且很可能就是这种个人英雄主义也不是什么坏事,他可能比大多数人的格局都要高一些,就是一种决策方式而已.

多标准决策分析

  • 在生产环境下经常用到多标准决策分析,只要是做决策的过程当中都会用到多标准决策分析,特别典型的是评标的时候,比如自己是甲方,有三家供应商投标,建议书方案都交上来了,然后分别从三个维度或者更多的维度,评价供应商是否符合要求的维度,第一个维度就是以技术分,看哪个技术方案最出色,技术分占比如说50%的比重,这是一个维度,第二个维度就是客户服务,第三个维度就是看有没有证书,投标企业如果有一个PNP证书加5分,有一个软考高项加20分,中项加10分等,通过很多维度对供应商进行评判,这个维度就叫多个维度,就叫多标准,很多情况下都可以做标准决策.

会议

  • 变更控制会是由变更控制委员会CCB召开的会议，负责审查变更请求，并做出批准、否决或推迟的决定。针对基准或重大变更。(实施整体变更控制的过程当中,经常开的一个会,由变更控制委员会CCB坐到一块召开的会议,其实就是针对重大的基准变更,这就是一个CCB会议.( CCB本身是一个委员会 ))

  • 三项重要任务：

    • 评估变更的影响(不是直接交给CCB一个变更单,而是由项目经理领的团队成员,事先把项目的变更范围,变更对各方面的影响,项目经理带来领团队成员事先就调查好,写清楚然后交给CCB,所以这个CCB会议,评估变更影响.评估影响做的是,在有了项目经理和团队给的数据支撑之后,大家看一下整体上变更对项目的影响,影响可不可以接受而已.)
    • 讨论并提议所请求变更的备选方案.(具体讨论一下项目经理或者团队成员所准备的变更请求的备选方案,
      备选方案可以认为就是为了满足客户而追加范围,每种方案要写清楚怎么做,花费多少人财物,但是做决策需要CCP做决策.      )
    • 将会议决定传达给变更请求责任.(会议结束之后,要把基准的变更请求,分发给所有受影响的改写人,
      特别是未来谁要执行变更要写清楚.      )

提示 : CCB的决定不论批准还是拒绝，并向干系人传达都应记录到变更日志.(应该把结果通知受影响的干系人,还要把结果记录到变更日志.)

3.输出

批准的变更请求

  • 由PM、CCB或指定的团队成员根据变更管理计划处理变更请求，并做出决定。批准的变更请求应通过指导与管理项目工作过程加以实施.( 比较重要的输出,就是批准的变更请求,就是开会最后批准了,因为批准的辩证请求,要交给行过程进行执行.)

项目管理计划更新

  • 项目管理计划的任一正式受控的组成部分，者都可通过本过程进行变更

项目文件更新

  • 正式受控的任一项目文件都可在实施整体变更控制过程变更，同同时将项目期间发生的变更全部记录在变更日志中

变更流程总结

  • 进行变更流程之前，项目经理要识别变更，并把变更进行书面记录(书面记录就是形成变更申请单)，形成变更申请单，之后开始走如下变更流程：

解析

评估变更对项目的整体影响

  • 应该是分别评估变更对项目各方面的影响,然后汇总形成变更对项目的整体影响,注意不是CCB组的工作,项目经理领着团队做这个步骤.

识别并讨论实现变更的备选方案

  • 项目去做变更,可以用几种方式去实现变更.

审批变更(批准\否决或推迟)

  • 变更由CCB批准否决或者推迟,那些重大基准的变更,审批权才在CCB,小的变更要走这个流程,要书面记录,变更申请也要进行,审批只需要CCB项目经理审批就行,所以不一定是所有变更都由CCB审批,可能是项目经理或者有权限的团队成员都可以做这个审批.

把变更审批结果记录到变更日志

  • 不管是拒绝或者批准的变更,都要把审批结果记录到变更日志.

调整项目管理计划项目文件和项目基准

  • 经过审批的变更,在基准的变更请求基础之上,直接可以修改项目,管理计划里的基准就行,不要因为再去修改基准,再提一个变更,就没有必要了.( 比如:CCB都同意范围变更,范围变更必然会影响进度基准,成本基准,资源的调配等等,会改一些项目管理计划,或者说受控的文件顺手就是 )

结果通知干系人，管理他们的期望

  • 不管是大型项目,还是生产环境下的项目还是日常生活中一些项目小的地方,如果出现变更的话,要提前把变更结果,通知给干系人.  ( 比如 : 物业或者这社区,决定今天下午2点到三点,供水设备或者供电设备进行升级,那升级这件事要干什么,要提前的通知给不能受影响的人,不然那些干系人做饭或者在下午在用呼吸机,结果突然把电断了,影响太大了,所以提前进行通知让大家知道,不然的话,可能突然变更会引起很多人的不方便,甚至不满,甚至是项目失败.( 变更结果通知相关方为什么?要管理大家的期望,只有把干系人的期望管理好.  )   )  

核心知识整理

  • 实施整体变更控制过程贯穿项目始终
  • 所有变更请求必须书面记录
  • 变更控制委员会CCB所作出的决定和建议都应该记录在案
  • 变更审批权限以及CCB角色和职责要事先记录在变更管理计划中
  • 任何干系人在项目的任何时间都可以提变更请求
  • 配置控制重点关注可交付成果及各个过程的技术规范
  • 变更控制则着眼于识别、记录、批准或否决对项目文件、可交付成果或基准的变更
  • 变更控制会是由变更控制委员会CCB召开的会议，负责审查变更请求

8.9 结束项目或阶段

  • 结束项目或者阶段,就是整个项目要进行收尾,这个过程就是收尾,不光是整个项目这个项目里边如果是分阶段的项目,每个阶段都得进行收尾,在阶段要像项目一样进行管理.
  • 结束项目或阶段关于这个过程,项目要有始有终,就是项目从启动,规划最后进入收尾阶段之后,就是提前终止的项目也要进行收尾,不允许出现不明不白的项目,就是最后就无疾而终,即使提前终止也要执行收尾.( 比如:要把项目分阶段,那很可能一个项目做完规划之后,因为市场前景问题,再审查一下可研报告后,发现这个项目不适合再进行下去了,就是规划之后就结束了.那也要启动一次这个过程,进行收尾. )

8.9.1 课程目标

  • 掌握结束项目或阶段过程的定义和重要性
  • 了解结束项目或阶段过程所必须实施的活动
  • 熟悉结束项目或阶段过程的输入、工具与技术及输出的内容
  • 掌握行政收尾(行政收尾就是流程性的收尾)包含的活动(
    在过去的项目管理体系里边,是比较强调行政收尾这个概念的,但是新的体系里,特别是软考高项,现在对行政收尾的概念不是太关心了.
    行政收尾也叫管理收尾,它不是实质性的收尾,行政收尾之前,事先已经把项目的主体的产品该验收的验收了,行政收尾就是流程性的收尾,不是验收,验收已经结束了,这时候去确认项目各个方面各个流程走完了,该支付给分包商的款项已经结清了,行政收尾来确定这些东西,最后行政收尾把项目进行一个总结归纳,释放资源,走这么一个流程,这叫行政收尾.( 如果是项目里涉及到交钥匙工程的一个主承包商,涉及到子承包商,事先确定子承包商,那些子任务已经完成了,已经验收了,然后才进入行政收尾. ))

8.9.2 过程定义：结束项目或阶段

定义

  • 终结项目、阶段或合同的所有活动

作用

  • 存档项目或阶段信息，完成计划的工作，释放组织团队资源以展开新的工作

为什么要释放资源呢

  • 因为做项目要提高资源利用率,所以及时尽快的结束项目或者阶段,把资源交给别的工作,那一般来讲,这个过程还是在每一个项目或者每一个阶段结束的时候才进行,当然有一种特殊情况就是提前终止,提前终止的时候,也要执行一次这个过程.

时机

  • 仅开展一次或仅在项目的预定义点开展
  1. 提前终止的项目也要执行本过程
  2. 本过程中最重要的工作是行政收尾
  3. 如果项目在完工前就提前终止，需要制定程序，来调查和记录提前终止的原因(做实质性的验收,不是在收尾的时候验收已经做完了,实际上对产品的验收是在监控的时候来做,又提到就是关于提前终止,如果这个项目是提前终止的不是正常结束的,在结束项目或阶段的时候,要调查提前终止的原因.)

8.9.3 数据流向图

解析:

  • 要把整个项目收尾了所以要参考很多内容,从最开始的项目章程(这里面有项目目标,最后要确定是不是符合项目目标,或者符合项目的退出条件),参考项目章程,参考所有的项目管理计划理子计划和基准,看是不是都满足了,如果有合同还要参考合同或者协议,还要参考每一个知识领域里边比较细节的这些内容,要参考最初的项目的立项管理文件(结束项目或者阶段这个过程,如果顺利执行的话,会形成或者最后会打包),还交付整个项目的最终产品服务或者成果移交给客户,实际上是关于可交付成果的,实体的验收是在监控做,但是移交给客户是在结束项目或者阶段这个过程,最后要把项目里边涉及的经验教训登记册归纳进组织过程资产.

结束项目或阶段过程的关注点(下午案例或者论文题考试的时候,可能会用到,不需要背记以了解或者理解为主.)

  • 在结束项目时，项目经理需要回顾(为什么要回顾?要保证项目管理计划里,规定的所有功能都实现了,所有基准都达成了.)项目管理计划，确保所有项目工作都己完成、项目目标均己实现。结束项目或阶段过程所需执行的活动包括：

    • 为达到阶段或项目的完工或退出标准所必须的行动和活动；(退出项目之前所做的工作,都是在收尾这个过程来做)
    • 为关闭项目合同协议或项目阶段合同协议所必须开展的活动；(本书没有专门一个过程是进行合同收尾,所以合同的收尾也是在这个过程去做)
    • 为完成收集项目或阶段记录、审计项目成败、管理知识分享和传递、总结经验教训、存档项目信息以供组织未来使用等工作所必须开展的活动；(关注各种信息或者最终文件的收集.)
    • 为向下一个阶段，或者向生产和（或）运营部门移交项目的产品、服务或成果所必须开展的行动和活动；(如果是一个多阶段的项目,要为下一个阶段进行成果转移做一些工作,如果是一个已经是最后一个阶段或者项目结束了,要为把这个项目产品转移给运营部门或者客户去运营做一些准备,这些活动也是放到这个收尾过程.)
    • 收集关于改进或更新组织政策和程序的建议，并将它们发送给相应的组织部门；(关于累积组织过程资产,收集关于改进或更新组织政策和程序的建议,给别的过程或者给整个企业来使用.)
    • 测量干系人的满意程度等。(项目收尾要调查客户的满意度,所有干系人对这个项目的满意度,都应该调查,包括领导(PMO或者上层对项目的一个反馈),调查团队成员对项目的满意度(那团队成员通过做这个项目,他的能力是不是提升了,技术能力,软技能,社交能力,沟通能力是不是提升了,团队成员对参与项目是不是满意,是不是留下了美好的回忆,都需要进行满意度调查))

8.9.4 ITTO

1.输入

项目章程

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

项目管理计划

  • 项目管理计划的所有组成部分均为本过程的输入

项目文件

  • 假设日志
  • 需求文件
  • 里程碑清单
  • 风险登记册
  • 风险报告
  • 估算依据
  • 变更日志
  • 问题日志
  • 经验教训登记册
  • 项目沟通记录
  • 质量控制测量结果
  • 质量报告

解析

  • 项目章程里边会有一些收尾的标准,还有谁最终有资格审批项目收尾,还有项目管理计划,还有很多项目的文件.
  • 还有一些输出 ( 比如 : 项目收尾的时候,已经有验收的可交付成果了,在进行收尾之前可交付成果已经被验收了,才能称为验收的可交付成果,可交付成果的验收是在监控的过程做,具体在监控过程组有一个过程叫确认范围,由确认范围把可交付成果经过验收,形成验收的可交付成果,直接交给收尾过程就可以.),
  • 验收的时候还要参考立项管理文件(本着有始有终原则,当初可研报告说的天花乱坠,项目会产生什么结果,结果没交付,就不好了).
  • 合同(协议)还有涉及到买卖双方
  • 还有采购文档 ( 包括 : 如果项目是乙方,需要采购文件,如果是甲方,也需要跟乙方的采购文件,必须先把跟乙方的合同先关闭,才能结束咱们这个项目或者阶段).
  • 还要参考组织过程资产.

验收的可交付成果等

2. 工具与技术

专家判断

  • 征求专家意见的主题

    • 管理控制
    • 审计
    • 法规与采购
    • 法律法规

数据分析

解析

文件分析 : 通过评估各种文档文件,来为收尾做一些工作.( 比如:通过各种文件来整理一些经验教训)

回归分析 : 在数据分析数据挖掘领域里,回归分析是一种预测类型的分析,(比如 : 目前项目的执行情况,交付的结果等,通过各种数据来预测,预测未来项目的某个走向,预测未来项目第几天交付,预测未来项目会花多少钱)
技术角度整体来讲,只要是用已有的数据建立模型之后,对未来的那种连续性的值(包括但不限于金额),只要是预测(通过体重预测年龄等方式),预测的值是连续值,这种技术就叫回归分析.
用于项目结果和不同项目变量之间的相互关系,以提高未来项目的绩效.(它是用于进行预测的,也可以说就是通过分析各种变量之间关系,来预测项目里的某个项目经理关心的结果,回归一定是用于预测,还包括现在或者未来会经常听到回归模型,回归模型就是形成模型之后,用模型来预测未来.)

趋势分析: 它是预测未来,实际上,趋势分析最重要的手段是回归分析,回归分析是大部分情况下用于进行趋势分析.

偏差分析 : 是看目前的状态.

会议

  • 会议用于确认可交付成果已通过验收，矿确定已达到退出标准，正式关闭合同，评估干系人满意度，收集经验教训，传递项目知识和信息，以及庆祝成功

解析

  • 要适当的时间召开会议,是比较重要的,毕竟是收尾了,要确定是不是项目达到验收标准,确认是不是各个合同已经正式收尾或者关闭了,最后评估各类相关方的满意度等等.
  • 项目结束的时候,各方面收尾都正常进行了,还要开一个会议(庆功会),也是属于这个会议的范畴.

以下不重要

  • 参会者可包括项目团队成员，以及参与项目或受项目影响的其他干系人
  • 会议形式可以是面对面或虚拟会议，正式或非正式会议
  • 会议的类型包括( 但不限于）:
    • 收尾报告会
    • 客户总结会
    • 经验教训总结会
    • 庆祝会

3. 输出

项目文件更新

项目文件
  • 在结束项目或阶段这个过程，有可能更新所有项目文件，并将所有文件标记为最终版本(最后归到组织过程资产)
经验教训登记册

  • 最终版本的经验教训登记册必须要包含阶段或项目收尾的最终信息，可包含：

    • 效益管理、项目评估的准确性、项目和开发生命周期、风险和问题管理、干系人参与，以及其他项目管理过程

解析

关于经验教训登记册,最后的经验教训登记册会包括项目里方方面面的内容,最后会归到组织过程资产.

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

  • 项目交付的产品、服务或成果可转交给另一团队或组织，并由其在整个生命周期中进行运营、维护和支持

解析

  • 是比较重要的输出,它会形成最终的项目里的产品\服务或者成果可移交给运维部门,或者移交给客户
  • 现在项目结束了,产品是后续存在的.(项目有三个特点:临时,独特,鉴定明细,项目的临时性不适用于产品,项目结束了,产品才开始,才开始运营,由另外一个运营团队或者客户组织,在产品的生命周期中进行运营维护或者支持,产品的运营才开始.)

最终报告

概述

回顾

  • 前篇只学习一个比较重要的报告工作绩效报告,是在监控项目工作的过程中,要把所有各方面的工作绩效信息,汇总形成工作绩效报告.

报告特点

  • 只要是看到报告两个字,层次都非常高.报告一般是图文并茂,格式比较规整,有很多整体性的东西给别人看,领导一般只看报告.

最终报告

  • 项目或者阶段收尾的时候,项目经理要提交关于这项目或者关于这个阶段的整体的报告.
报告内容包括(不需要背记)
  • 项目或阶段的概述
  • 范围目标、范围的评估标准，以及证明达到完工标准的证据(范围比较重要,范围的目标,评估标准,为什么说这个项目达成范围目标了,依据是什么)
  • 质量目标、项目和产品质量的评估标准、相关核实信息和实际里程碑交付日期以及偏差原因(质量方面总的总结)
  • 成本目标，包括可接受的成本区间、实际成本，以及产生任何偏差的原因
  • 最终产品、服务或成果的确认信息的总结.(关于最后交付物的总体的总结)
  • 进度计划目标包括成果是否实现项目所预期的效益。如果在项目结束时未能实现效益，则指出效益实现程度并预计未来实现情况(预期效益)
  • 关于最终产品、服务或成果如何满足商业计划所述业务需求的概述。如果在项目结束时未能满足业务需求，则指出需求满足程度并预计业务需求何时能够得到满足.(项目要跟企业的业务目标或者战略达成一致,总结一下交付的产品是不是满足业务需求了.)

总结

  • 项目结束或者阶段结束,要提交一个最终报告,形成关于可交付的,宏观的,整体的,一个总结

组织过程资产更新(了解)

项目文件
  • 在项目活动中产生的各种文件，例如项目管理计划范围文件成本文件、进度文件和项目日历，以及变更管理文件
运营和支持文件
  • 组织维护、运营和支持项目交付的产品或服务时所需的文件可以是新生成的文件或对已有文件的更新.(最后项目产品要交给运营或者职能部门去运营,所以这个组织过程资产里要涵盖运营和支持的文件,除了交给运营部门之外,还要归纳进组织过程资产.)
项目或阶段收尾文件
  • 项目或阶段收尾文件包括表明项目或阶段完工的正式文件，，以及用来将完成的项目或阶段可交付成果移交给他人的正式文件
经验教训快识库
  • 将在整个项目期间获得的经验教训和知识归入经验教训知识库供未来项目使用

核心知识整理

  • 无论什么原因导致项目终止，也无论什么时候项目终止（ 因未完成而终止或者因各种原因而提前终止 ），都必须进行行政收尾工作

  • 如果项目在完工前就提前终止，需要制定程序，来调查和记录提前终止的原因

  • 如果项目中包含合同，则需要在项目收尾前完成合同收尾

  • 回归分析技术分析作用于项目结果的不同项目变量之间的相互关系，以提高未来项目的绩效

  • 结束项目或阶段时，将所有文件标记为最终版本

  • 经验教训登记册最终汇编为经验教训知识库，存储于组织过程资产

解析

  • 前两个意思是不允许出现无疾而终,或者叫烂尾楼
  • 第三个如果项目中包含合同,作为总包商,先要结束跟分包商的合同,才进行阶段或者项目的收尾.
  • 回归分析本质上是进行预测.细节是用各种变量预测那种连续性的项目结果,预测成本,预测进度等.

整合管理总结

过程组 描述
启动过程组 起草项目章程,它是由领导发布的.
规划过程 领着团队成员制定项目管理计划或者整合项目管理计划(有了项目章程之后,项目经理有使用资源的权限了)
执行过程组 一个是要指导管理项目工作
另外要管理项目的知识
监控过程组 一个是整体上要监控项目的工作
另外一个是变更(实施整体变更控制).
收尾过程组 结束项目或者阶段

单词

序号 单词 简写 翻译 描述
1 MOUS 谅解备忘录
2 SLA 服务水平协议
3 SME 主题专家
4 PMO 项目管理办公室
5 kick-off meeting 项目开工会议
6 Project Management Information System PMIS 项目管理信息系统
7 Deliverable 可交付成果
8 KPI 关键绩效指标
9 Corrective Action 纠正措施
10 Preventive Action 预防措施
11 Defect Repair 缺陷补救
12 Updates 更新
13 Change Control Board CCB 变更控制委员会
posted @ 2025-01-08 17:27  北极的大企鹅  阅读(860)  评论(0)    收藏  举报
阅读 - 79万