管理项目知识
1、过程定义
使用现有知识并生成新知识，以实现项目目标，并且帮助组织学习的过程。
管理显性和隐性知识，重复使用现有知识并生成新知识。重点关注把现有知识条理化和系统化，以便更好的加以利用。
2、管理项目知识过程
3、管理项目知识的工具
知识管理（无法脱离人而存在）促进员工合作创造新知识，分享隐性知识。比如人际交往、工作跟随和跟随指导。
1）人际交往
在组织、行业或职业环境中与他人的正式或非正式互动。
人际交往在项目初始时特别有用，目的是为了建立关系，增加获取资源的途径，改进人力资源管理。人际交往的方式有很多种：写信、午餐会、座谈会等等。
2）工作跟随
徒弟跟着师傅实习，徒弟无需承担任何责任，全部责任由师傅承担。
3）跟随指导
师傅跟随和观察新手的工作情况，并给予指导。
4、管理项目知识的工具
信息管理（可以脱离人而存在）用于促进显性知识分享的各种具体方法。比如：图书馆服务、文献检索、经验教训登记册编制
5、管理项目知识的输出
经验教训登记册会得到更新，最终存入组织过程资产中。
监控项目工作
1、过程定义
跟踪、审查启动、规划、执行、收尾各个过程，来实现项目管理计划中确定的绩效目标。就是把实际绩效和项目管理计划进行对比，发现偏差、分析原因，提出变更。
2、监控项目工作的输入
工作绩效信息work performance information
从各控制过程中收集并结合相关背景和跨领域关系，进行整合分析而得到的绩效数据。
比如：第一天计划预习PMBOK 到50 页，实际只预习到30 页。对比发现，比计划少预习20页，20 是工作绩效信息。
3、监控项目工作的工具：数据分析
4、监控项目工作的输出
工作绩效报告 work performance reports
为制定决策、提出问题、采取行动或引起关注，而汇编工作绩效信息，所形成的实物或电子项目文件。比如：第一天计划预习PMBOK 到50 页，实际只预习到30 页。对比发现，比计划少预习20页。第二天少预习10 页、第三天又少预习15 页……最终写成一份报告，为什么总是不遵守计划，怎么总是少预习。是工作效率太低、还是懒惰引起的，分析找到原因等等。汇总写成一份状态报告。
5、监控项目工作的输出
变更请求，是指监控项目工作时会引发变更请求。
通过比较实际情况与计划要求，可能需要提出变更请求，来扩大、调整或縮小项目范围与产品范围，或者提高、调整或降低质量要求和进度或成本基准。
实施整体变更控制
1、过程定义
审查所有变更请求，批准或否决变更，并管理对可交付成果、项目文件和项目管理计划的变更，并对变更处理结果进行沟通的过程。
这个过程的作用，就是对这四种提出来的变更请求，批准或否决，然后更新相应的计划或文件。
提出的变更到底是同意，还是拒绝？需要在这个过程做判断。
实施整体变更控制过程贯穿项目始终，项目经理对此负最终责任。
这句话说明PM对变更负最终责任，万一哪个变更变得不好，责任都在PM没有把控好。PM要对变更请求跟踪负责到底。
2、配置管理系统
包含在配置管理计划中，由一系列正式的书面程序组成，用于对以下工作提供技术和管理方面的指导与监督：
1）识别并记录产品、成果、服务或部件的功能特征和物理特征
2）控制对上述特征的任何变更
3）记录并报告每一项变更及其实施情况
4）支持对产品、成果或部件的审查，以确保其符合要求
配置管理系统明确了为核准和控制变更所需的批准层次。
配置管理活动包括：
1）识别配置项：选择与识别配置项，从而为定义与核实产品配置、 标记产品和文件、管理变更和明确责任提供基础。——相当于编号，version 1.0,version 2.0
2）记录并报告配置项状态：关于各个配置项的信息记录和报告。
——相当于记录版本的说明，1.0 版本拓展了场景文字……；2.0 版本优化了bug，解决了闪退问题…
3）配置核实与审计：保证项目的配置项组成的正确性，以及相应的变更都被登记、评估、批准、跟踪和正确实施，从而确保配置文件所规定的功能要求都已实现。
——确保配置项组成的正确性，确保变更都被记录、评估、批准、跟踪和正确实施。现在2.0 的版本要变更到2.1 了，要确保这个变更符合流程。
也可以用五大过程组的关系来理解这三个活动：
识别配置项属于规划过程组的活动；
记录并报告配置项状态属于执行过程组的活动；
配置项核实与审计属于监控过程组的活动；
3、变更控制委员会 （CCB：Change Control Board）
1）CCB 是正式的团体，但不一定是固定的团体；
2）组成：项目发起人、客户、项目经理、相关专家、其他主要干系人；
3）任务：审查、评价、批准、推迟或否决项目变更，记录和传达变更处理请求；
4）设立原因：项目经理权力有限，对于涉及计划基准的变更不能自做主张；
一句话概括CCB 设立的原因：PM 一个人决定不了的大事需要通过CCB 来群体决策。
4、变更控制系统：Change Control System
包含在变更管理计划中，是配置管理系统的子系统。
1）是指包括变更管理的一系列正式的书面程序，包括文档、跟踪系统和变更的批准层次等；
2）该系统不仅说明什么样的变更需要哪个层次的批准，而且也说明在什么情况下可以不经批准就实施变更；
3）该系统说明CCB 的组成、权力与责任；
4）紧急情况下的变更可以不经CCB 批准就实施，但事后需补办相关变更手续；
5、变更的批准权限：
每项记录在案的变更请求都必须由一位责任人批准或否决。这个责任人通常是PM 或者发起人，在项目管理计划或组织流程中会指定批准责任人。必要时由CCB 开展实施整体变更控制过程。
1）PM：一般批准不涉及基准的变更请求，紧急情况可批准特殊的变更请求。
比如有客户老板的连环夺命call，要求马上、立即、立刻进行一个变更，不变就解约，非常紧急。那就PM 自己决定要不要变吧。因为如果走流程的话，时间来不及。
注意：一些很简单的变更，不涉及基准的，比如说干系人登记册里一位干系人的名字写错了，这种小问题，PM 也可以自行决定，不用走流程.
2）发起人：一般批准章程的变更；章程写的不清楚，要进行变更，由发起人来决定要不要变；
3）变更控制委员会CCB：批准或否决基准的变更请求；
4）客户：批准按合同实施的项目的某些变更请求；
虽然影响基准的变更必须要通过CCB 的批准,但并不意味着CCB 只能批准影响基准的变更,有一些在变更控制系统中指定需要CCB 批准的变更但并没有影响基准。
6、完整的变更管理流程
0）PM 对可能引起变更的因素施加影响；
——注意！是“施加”影响，而不是第2 步的“评估”影响。看看是否是不必要的变更，避免因个人的主观臆断随意进行变更。
1）干系人正式向PM 提交变更请求，并记录变更请求；
——书面记录变更、创建变更请求。
2）PM 评估变更对项目的影响；
——记录后，评估如果实施变更会对项目产生什么影响。
3）PM 与干系人沟通并寻求处理变更的备选方案；
——寻找处理变更的解决方案
4.1）PM 自主决策；
——如果变更不影响基准，PM 自主决策，之后更新到变更日志中。
4）PM 提交含解决方案的变更请求给CCB 审批；
——如果变更影响基准，PM 将变更请求提交给CCB。
——如果CCB 否决了变更请求，将结果更新到变更日志中。
5）更新项目管理计划与项目文件；
——如果CCB 批准了变更请求，就需要更新项目管理计划／文件。
6）通知受变更影响的干系人；
——通知会受到变更影响的干系人。
7）项目团队执行批准的变更；
——项目团队执行、实施批准的变更请求。
8）跟踪确认变更的实施情况；
——被批准执行的变更，跟踪、记录实施情况如何。
Q&A
Q：无论谁批准的变更，最后都是Pm负责吗？
A： 是的，最终负责人都是PM
练习题
1、项目经理接管了一个目前处于设计的项目，而且还从许多来源收到变更请求。在这种情况下，下列哪一项最有帮助？
A. 参与项目的项目发起人
B. 定义明确的范围管理计划
C. 变更控制委员会
D. 变更控制系统
2、项目管理计划制定完毕并由利害关系者批准。项目经理接下来应该怎么做？
A. 开始执行项目管理计划中规定的工作
B. 审查风险评估并更新风险登记簿
C. 为承包商制定工作说明书
D. 针对项目设立变更控制委员会
若有收获，就点个赞吧
0 人点赞
