【信息系统项目管理师】第八章项目整合管理考试重点

最新推荐文章于 2024-04-02 22:30:00 发布

ITPro进化论

最新推荐文章于 2024-04-02 22:30:00 发布

阅读量791

点赞数

分类专栏：信息系统项目管理师文章标签： windows

本文链接：https://blog.csdn.net/weixin_51575203/article/details/130610700

版权

信息系统项目管理师专栏收录该内容

24 篇文章 45 订阅

订阅专栏

8.1管理基础

项目整合管理由项目经理负责，项目经理负责整合所有其他知识领域的成果，并掌握项目总体情况。项目整合管理的责任不能被授权或转移，项目经理必须对整个项目承担最终责任。整合是项目经理的一项关键技能。执行项目整合时项目经理承担双重角色：

组织层面上，项目经理扮演重要角色，与项目发起人携手合作，了解战略目标并确保项目目标和成果与项目组合、项目集以及业务领域保持一致。
项目层面上，项目经理负责指导团队关注真正重要的事务并协同工作。为此，项目经理需要整合过程、知识和人员。

发生整合的三个层面：

1.过程层面执行整合

2.认知层面执行整合

3.背景层面执行整合

与整合管理过程相关的发展新实践包括：

使用自动化工具(如项目管理信息系统）
使用可视化管理工具（便于看到实时状态，促进知识转移，促进干系人参与到问题解决中）
项目知识管理（应对项目人员的流动性和不稳定性）
增加项目经理的职责（项目经理被要求介入启动和结束项目，例如开展商业论证和效益管理)混合型方法（敏捷或其他迭代做法、商业分析技术–BA、组织变革管理方法等混合使用）

项目管理计划和项目文件的区别：

项目管理计划

在全部49个项目管理过程中，只有“制定项目章程”和“制订项目管理计划”这两个过程没有“项目管理计划”这个项目管理计划输入。

项目文件

在全部49个项目管理过程中，只有6个过程没有“项目文件”这个输入，即制定项目章程、制订项目管理计划、规划范围管理、规划进度管理、定义活动、规划成本管理。

8.2项目整合管理过程

裁剪考虑：项目生命周期、开发生命周期、管理方法、知识管理、变更、治理、经验教训、效益

敏捷与适应方法：

1.迭代和敏捷方法中：帮助项目经理将决策权下放，团队成员以领域专家的身份参与整合管理：

团队成员可以自行决定并控制具体产品的规划知H火以
团队成员自行决定各个组件的整合方式

2.与传统方法的比较：

对项目经理的期望不变，但把对具体产品的规划和交付授权给团队
项目经理的关注点在于营造一个合作型的决策氛围，确保团队有能力应对变更。团队成员有广泛技能（而不是狭窄领域），则更利于合作型决策氛围

文件和计划的更新内容

8.3制定项目章程

项目章程范例：

项目章程

项目章程在项目执行和项目需求之间建立了联系。
通过编制项目章程，来确认项目是否符合组织战略和日常运营的需要。
项目章程不能当作合同，在执行外部项目时，通常需要用正式的合同来达成合作协议。
项目章程授权项目经理进行项目管理过程中的规划、执行和控制，同时还授权项目经理在项目活动中使用组织资源。
因此，应在规划开始之前任命项目经理，项目经理越早确认并任命越好，最好在制定项目章程时就任命。
项目章程可由发起人编制，也可由项目经理与发起机构合作编制。
项目章程一旦被批准，就标志着项目的正式启动。
项目由项目以外的机构来启动，例如发起人、项目集或项目管理办公室（PMO）、项目组合治理委员会主席或其授权代表。项目启动者或发起人应该具有一定的职权，能为项目获取资金并提供资源。

立项管理文件

一般情况下立项管理包含商业需求和成本效益分析，论证项目的合理性并确定项目边界。
由于立项管理文件不是项目文件，项目经理不可以对它们进行更新或修改，只可以提出相关建议。虽然立项管理文件是在项目之前制定的，但需要定期审核。

协议

协议有多种形式，包括合同、谅解备忘录、服务水平协议（SLA)、协议书、意向书、口头协议或其他书面协议。为外部客户做项目时，通常需要签订合同。

数据收集

人际关系与团队技能

项目章程
项目章程记录了关于项目和项目预期交付的产品、服务或成果的高层级信息：

（1）项目目的；

（2）可测量的项目目标和相关的成功标准；

（3）高层级需求、高层级项目描述、边界定义以及主要可交付成果；

（4）整体项目风险；

（5）总体里程碑进度计划；

（6）预先批准的财务资源；

（7）关键干系人名单；

（8）项目审批要求（例如，评价项目
成功的标准，由谁对项目成功下结论，由谁签署项目结束)；

（9）项目退出标准(例如，在何种条件下才能关闭或取消项目或阶段)；

（10）委派的项目经理及其职责和职权；

（11）发起人或其他批准项目章程的人员的姓名和职权等。

假设日志

假设日志用于记录整个项目生命周期中的所有假设条件和制约因素。

专家判断：项目经理的周边到处都是专家。项目经理自己本身是项目管理专家，但并不表示他什么都该知道。专业技术方面的问题可以咨询主题专家，财务问题可以咨询财务专家。通俗点来说专家判断就是拍脑袋想问题。专家判断可用于第四章整合管理的全部过程组。

8.4制定项目管理计划

项目管理计划

项目管理计划确定项目的执行、监控和收尾方式，其内容会根据项目所在的应用领域和复杂程度的不同而不同。
项目管理计划可以是概括或详细的，每个组成部分的详细程度取决于具体项目的要求。
项目管理计划应基准化，即至少应规定项目的范围、时间和成本方面的基准，以便据此考核项目执行情况和管理项目绩效。
- 在确定基准之前，可能要对项目管理计划进行多次更新，且这些更新无需遵循正式的流程。
- 但是一旦确定了基准，就只能通过提出变更请求、实施整体变更控制过程进行更新。
- 在项目收尾之前，项目管理计划需要通过不断更新来渐进明细，并且这些更新需要得到控制和批准。

基准：某网银每天限制转账额度5000，超过5000就要使用大额转账技术，比如u盾、密保卡等等。
这个5000就是一个基准。如果这个基准需要变化，需要经过正式的变更控制程序才能变更。

数据收集

人际关系与团队技能

项目管理计划

项目管理计划是说明项目执行、监控和收尾方式的一份文件，它整合并综合了所有知识领域子管理计划和基准，以及管理项目所需的其他组件信息，项目管理计划的组件取决于项目的具体需求。
项目管理计划组件主要包括：
- 子管理计划：范围管理计划、需求管理计划、进度管理计划、成本管理计划、质量管理计划、资源管理计划、沟通管理计划、风险管理计划、采购管理计划、干系人参与计划。
- 基准：范围基准、进度基准和成本基准。
- 其他组件：变更管理计划、配置管理计划、绩效测量基准、项目生命周期、开发方法、管理审查。

“其他过程的输出”，是指子计划和基准，比如：范围管理计划、进度管理计划、成本管理计划等等，制定项目管理计划要参考这些子计划，把他们整合为综合的“项目管理计划”。项目管理计划并不是一步到位，而是需要不断更新来渐进明细。

PM要求在项目中所做的所有事情都必须是在计划中所体现的，做计划之外试图“讨好”干系人被称为“镀金”，这是项目中明令禁止的。

比如客户要PM去买包烟，PM买了烟后又私自决定给客户配了个打火机。这就是镀金了，客户并不需要打火机，也许客户自己有更高级的“ZIPPO”，并不需要PM给他买的打火机。镀金，是画蛇添足、因为浪费了资源。

8.5指导与管理项目工作

批准的变更请求

批准的变更请求是实施整体变更控制过程的输出，包括经项目经理审查和批准的变更请求，必要时需要经变更控制委员会（CCB）审查和批准。
CCB是项目的所有者权益代表，负责对变更进行决策。CCB由项目所涉及的主要干系人共同组成，通常包括用户和项目所在组织管理层的决策人员。CCB是决策机构，不是作业机构；通常CCB的工作是通过评审手段来决定项目基准是否需要变更，但不提出变更方案。
经CCB批准的变更请求可能是纠正措施、预防措施和缺陷补救措施，并由项目团队纳入项目进度计划付诸实施，批准的变更请求可能对项目或项目管理计划的相关领域产生影响，还可能导致修改正式受控的项目管理计划组件或项目文件。

项目管理信息系统

项目管理信息系统给项目提供了IT软件工具，例如进度计划软件工具、工作授权系统、配置管理系统信息收集与发布系统，以及讲入其他在线信息系统（如知识库）的登录界面，支持自动收集和报告关键绩效指标（KPI）。

会议

参会者可包括项目经理、项目团队成员，以及与所讨论事项相关或会受该事项影响的干系人。
会议类型一般包括：开工会议、技术会议、敏捷或迭代规划会议、每日站会、指导小组会议、问题解决会议、进展跟进会议以及回顾会议。

可交付成果

可交付成果是在某一过程、阶段或项目完成时，必须产出的任何独特并可核实的产品、成果或服务能力。它通常是项目的结果，包括项目管理计划的组成部分。

工作绩效数据

工作绩效数据是在执行项目工作的过程中，从每个正在执行的活动中收集到的原始观察结果和测量值。

绩效报告比如：第一天计划预习第四版教材到50页，实际只预习到30页。【绩效信息】对比发现，比计划少预习20页。第二天少预习10页、第三天又少预习15页最终写成一份报告，为什么总是不遵守计划，怎么总是少预习。是工作效率太低、还是懒惰引起的，分析找到原因等等。汇总写成一份状态报告。【绩效报告】

问题日志

问题日志是一种记录和跟进所有问题的项目文件；在整个项目生命周期应该随时监控活动更新问题日志。

变更请求

变更请求是关于修改任何文件、可交付成果或基准的正式提议。
任何项目干系人都可以提出变更请求，应该通过实施整体变更控制过程对变更请求进行审查和处理。
变更请求一般包括：
- 纠正措施：为使项目工作绩效重新与项目管理计划一致，而进行的有目的的活动。
- 预防措施：为确保项目工作未来绩效符合项目管理计划，而进行的有目的的活动。
- 缺陷补救：为了修正不一致产品或产品组件，而进行的有目的的活动。
- 更新：对正式受控的项目文件或计划进行变更，以反映修改、增加的意见或内容。

8.6管理项目知识

管理项目知识

组织角度看：在项目开始之前、开展期间和结束之后都能使用旧知识、生成新知识。
最重要的环节：营造信任氛围，激励人们分享自己的知识和关注他人的知识。
实践中双管齐下：知识管理工具和技术（用于人际互动）、信息管理工具和技术（用于编撰显性知识）

知识管理

知识管理工具和技术将员工联系起来，使他们能够合作生成新知识、分享隐性知识，以及集成不同团队成员所拥有的知识。
面对面互动最有利于建立知识管理所需的信任关系。建立之后，可以用虚拟互动来维护这种信任关系。

信息管理

信息管理用于创建人们与知识之间的联系，可以有效促进简单、明确的显性知识的分享。

人际关系与团队技能

经验教训登记册

经验教训登记册可以包含执行情况的类别和详细的描述，还可包括与执行情况相关的影响、建议和行动方案。
经验教训登记册可以记录遇到的挑战、问题、意识到的风险和机会以及其他适用的内容。
经验教训登记册在项目早期创建，作为管理项目知识过程的输出。因此，在整个项目期间，它可以作为很多过程的输入，也可以作为输出而不断更新。参与工作的个人和团队也参与记录经验教训。可通过视频、图片、音频或其他合适的方式记录知识，确保有效吸取经验教训。在项目或阶段结束时，把相关信息归入经验教训知识库，作为组织过程资产一部分。

8.7监控项目工作

监控项目工作

监督是贯穿于整个项目的项目管理活动之一，包括收集、测量和分析测量结果，以及预测趋势，以便推动过程改进。
监控项目工作过程主要关注：

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

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

③检查单个项目风险的状态；

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

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

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

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

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

⑨确保项目与商业需求保持一致等。

数据分析

决策：投票可以包括用下列方法进行决策：一致同意、大多数同意或相对多数原则。

工作绩效报告：基于工作绩效信息，以实体或电子形式编制形成工作绩效报告，以制定决策、采取行动或引起关注。根据项目沟通管理计划，通过沟通过程向项目干系人发送工作绩效报告。

8.8实施整体变更控制

实施整体变更控制

实施整体变更控制过程贯穿项目始终，项目经理对此承担最终责任。变更请求可能影响项目范围、产品范围以及任一项目管理计划组件或任一项目文件。在整个项目生命周期的任何时间，参与项目的任何干系人都可以提出变更请求。【PM对变更负最终责任，万一哪个变更变得不好，责任都在PM没有把控好。PM要对变更请求跟踪负责到底】
在基准确定之前，变更无须正式受控、实施整体变更控制过程。一旦确定了项目基准，就必须通过实施整体变更控制过程来处理变更请求。尽管变更可以口头提出，但所有变更请求都必须以书面形式记录，并纳入变更管理和（或）配置管理系统中。
在批准变更之前，可能需要了解变更对进度的影响和对成本的影响。在变更请求可能影响任一项目基准的情况下，都需要开展正式的整体变更控制过程。每项记录在案的变更请求都必须由一位责任人批准、推迟或否决，这个责任人通常是项目发起人或项目经理。应该在项目管理计划或组织程序中指定这位责任人，必要时应该由CCB来开展实施整体变更控制过程。变更请求得到批准后，可能需要新编(或修订)成本估算、活动排序、进度日期、资源需求和（或）风险应对方案分析，这些变更可能会对项目管理计划和其他项目文件进行调整。

变更请求

变更请求可能包含纠正措施、预防措施、缺陷补救，以及针对正式受控的项目文件或可交付成果的更新。变更可能影响项目基准，也可能不影响项目基准，变更决定通常由项目经理做决策。
对于会影响项目基准的变更，通常应该在变更请求中说明执行变更的成本、所需的计划日期修改、资源需求以及相关的风险。这种变更应由CCB（如有)和客户或发起人审批，除非他们本身就是CCB的成员。只有经批准的变更才能纳入修改后的基准。

变更控制工具

配置控制重点关注可交付成果及各个过程的技术规范；变更控制则重点关注识别、记录、批准或否决对项目文件、可交付成果或基准的变更。

配置管理活动包括：

识别配置项：识别与选择配置项，为定义与核实产品配置、标记产品和文件、管理变更和明确责任提供基础。
记录并报告配置项状态：对各个配置项的信息进行记录和报告。
进行配置项核实与审计：通过配置核实与审计，确保项目的配置项组成的正确性，以及相应的变更都被登记、评估、批准、跟踪和正确实施，确保配置文件所规定的功能要求都已实现。

变更管理活动包括：

识别变更：识别并选择过程或项目文件的变更项。
记录变更：将变更记录为合适的变更请求。
做出变更决定：审查变更，批准、否决、推迟对项目文件、可交付成果或基准的变更或做出其他决定。
跟踪变更：确认变更被登记、评估、批准和跟踪，并向干系人传达最终结果。
也可以使用变更控制工具管理变更请求和后续的决策，同时还需要及时沟通，帮助CCB的成员履行职责，并向干系人传达变更相关的决定。

数据分析

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

变更程序：

①变更申请→②对变更的初审→③变更方案论证→④变更审查→⑤发出通知并实施→⑥实施监控→⑦效果评估→⑧变更收尾

每项记录在案的变更请求都必须由一位责任人批准或否决。这个责任人通常是PM或者发起人，在项目管理计划或组织流程中会指定批准责任人。必要时由CCB开展实施整体变更控制过程。

（1）PM：一般批准不涉及基准的变更请求，紧急情况可批准特殊的变更请求。

比如有客户老板的连环夺命call，要求马上、立即、立刻进行一个变更，不变就解约，非常紧急。那就PM自己决定要不要变吧。因为如果走流程的话，时间来不及。
注意：一些很简单的变更，不涉及基准的，比如说干系人登记册里一位干系人的名字写错了，这种小问题，PM也可以自行决定，不用走流程
（2）发起人：一般批准章程的变更；
章程写的不清楚，要进行变更，由发起人来决定要不要变；
（3）变更控制委员会CCB：批准或否决基准的变更请求；
（4）客户：批准按合同实施的项目的某些变更请求
虽然影响基准的变更必须要通过CCB的批准，但并不意味着CCB只能批准影响基准的变更,有一些在变更控制系统中指定需要CCB 批准的变更但并没有影响基准。

决策

投票：可以采取一致同意、大多数同意或相对多数原则的方式
独裁型决策制定：将由一个人负责为整个集体制定决策。
多标准决策分析：该技术借助决策矩阵，根据一系列预定义的准则，用系统分析方法评估变更请求。

批准的变更请求：由项目经理、CCB或指定的团队成员，根据变更管理计划处理变更请求，做出批准、推迟或否决的决定。

项目管理计划（更新）：基准的变更，只能基于最新版本的基准并应对未来的情况，而不能变更以往的绩效，保证保护基准和历史绩效数据的严肃性和完整性。

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

8.9结束项目或阶段

结束项目或阶段过程所需执行的活动包括：

检查：为达到阶段或项目的完工或退出标准所必须的行动和活动；
关闭：为关闭项目合同协议或项目阶段合同协议所必须开展的活动；
总结：为完成收集项目或阶段记录、审计项目成败、管理知识分享和传递、总结经验教训、存档项目信息以供组织未来使用等工作所必须开展的活动；
移交：为向下一个阶段，或者向生产和（或）运营部门移交项目的产品、服务或成果所必须开展的行动和活动；
改进：收集关于改进或更新组织政策和程序的建议，并将它们发送给相应的组织部门；
测量：测量干系人的满意程度等。
如果项目在完工前提前终止，结束项目或阶段过程还需要制定程序，调查和记录提前终止的原因。为了实现上述目的，项目经理应该引导所有合适的干系人参与结束项目或阶段的工作。