PMP第五版考点汇总冲刺版.docx
《PMP第五版考点汇总冲刺版.docx》由会员分享，可在线阅读，更多相关《PMP第五版考点汇总冲刺版.docx（52页珍藏版）》请在冰豆网上搜索。
PMP第五版考点汇总冲刺版
PMP第五版考点汇总冲刺版
第一章引论
P2：
《PMI道德与专业行为规范》详细描述从业者在责任、尊重、公正、诚实方面的基本义务，全球适用。
P3：
项目时为创造独特的产品、服务、或成果而进行的临时性工作。
（还有：
渐进明细性）
项目的“临时性”是指项目有明确的起点和终点，是指项目的参与程序及其长度：
1.当项目目标达成时
2.或当项目因不会或不能达到目标而中止时
3.或当项目需求不复存在时，项目就结束了。
项目可以创造：
●一个产品，可能是其他产品的组成部分、某个产品的升级，也可能本身就是最终产品；
●一种服务或提供某种服务的能力（如支持生产或配送的业务职能）；
●对现有产品线或服务线的改进（如实施六西格玛项目以降低缺陷率）；
●一种成果，例如某个结果或文件（如某研究项目所创造的知识，可据此判断某种趋势是否存在，或判断某个新过程是否有益于社会）。
P4：
项目的例子包括（但不限于）：
●开发一种新的产品、服务或成果；
●改变一个组织的结构、流程、人员配备或风格；
●开发或购买一套新的或改良后的信息系统（硬件或软件）；
●执行一项研究，其结果将被恰当地记录；
●建造一座大楼、工厂或基础设施；
●实施、改进或提升现有的业务流程和程序。
P9：
项目集管理就是在项目集中应用知识、技能、工具与技术来满足项目集的要求，获得分别管理各项目所无法实现的利益和控制。
P10：
项目组合管理是指为了实现战略目标而对一个或多个项目组合进行的集中管理。
项目组合管理重点关注：
通过审查项目和项目集，来确定资源分配的优先顺序，并确保对项目组合的管理与组织战略协调一致。
组织经常直接或间接利用项目，去实现战略规划中的目标。
项目的批准通常出于以下一项或多项战略考虑：
●市场需求（如为应对汽油紧缺，某汽车公司批准一个低油耗车型研发项目）；
●战略机会／业务需求（如为提高收入，某培训公司批准一个新课开发项目）；
●社会需要（如某发展中国家的某非政府组织批准一个项目，向传染病高发社区提供饮用水系统、厕所设施和卫生教育）；
●环境考虑（如为降低污染，某上市公司批准一个项目，建立一项共享电动小轿车的新服务）；
●客户要求（如为了给新工业园区供电，某电力公司批准一个新变电站建设项目）；
●技术进步（如基于计算机存储技术和电子技术的发展，某电子公司批准一个更快速、更便宜、更小巧的笔记本电脑开发项目）；
●法律要求（如某化学制品厂批准一个项目，研发新型有毒物品处理指南）。
有几种不同类型的PMO，它们对项目的控制和影响程度各不相同，例如：
●支持型。
支持型PMO担当顾问的角色，向项目提供模板、最佳实践、培训，以及来自其他项目的信息和经验教训。
这种类型的PMO其实就是一个项目资源库，对项目的控制程度很低。
●控制型。
控制型PMO不仅给项目提供支持，而且通过各种手段要求项目服从，例如要求采用项目管理框架或方法论，使用特定的模板、格式和工具，或者服从治理。
这种类型的PMO对项目的控制程度属于中等。
●指令型。
指令型PMO直接管理和控制项目。
这种类型的PMO对项目的控制程度很高。
P12：
项目经理与PMO之间的角色差异可能包括：
●项目经理关注特定的项目目标，而PMO管理主要的项目集范围变更，这些变更可被视为能促进业务目标实现的潜在机会；
●项目经理控制分配给本项目的资源，以更好地实现项目目标，而PMO负责优化利用所有项目共享的组织资源；
●项目经理管理单个项目的制约因素（范围、进度、成本和质量等），而PMO站在企业的高度对方法论、标准、整体风险／机会、测量指标和项目间的依赖关系进行管理。
P14：
基于项目的组织（Project-basedOrganizations，PBO）是指建立临时机构来开展工作的各种组织形式。
在各种不同的组织结构中［如职能型、矩阵型或项目型（见2.1.3节）］，都可以建立PBO。
采用PBO可以减轻组织中的层级主义和官僚主义，因为在PBO中，考核工作成败的依据是最终结果，与职位或政治因素无关。
P16：
组织驱动因素包括：
组织结构、组织文化、组织技术和人力资源实践。
P17：
要有效管理项目，除了应具备特定应用领域的技能和通用管理方面的能力以外，项目经理还需具备以下能力：
●知识能力——项目经理对项目管理了解多少。
●实践能力——项目经理能够应用所掌握的项目管理知识做什么、完成什么。
●个人能力——项目经理在执行项目或相关活动时的行为方式。
个人态度、主要性格特征和领导力，决定着项目经理指导项目团队平衡项目制约因素、实现项目目标的能力，决定着项目经理的行为的有效性。
第二章组织影响和项目生命周期
P23：
弱矩阵型组织保留了职能型组织的大部分特征，其项目经理的角色更像协调员或联络员。
项目联络员作为工作人员的助理和沟通协调员，不能亲自制定或推行决策。
项目协调员有权力做一些决策，有一定的职权，向较高级别的经理汇报。
P26：
在很多组织结构中，都有战略层、中级管理层和操作层。
项目经理与这三个层级的协作互动取决于下列因素：
●项目的战略重要性；
●干系人对项目施加影响的能力；
●项目管理成熟度；
●项目管理体系；
●组织沟通。
项目经理与上述三个层级的协作互动决定了项目的特征，例如：
●项目经理的职权水平；
●资源的可用性和管理；
●项目预算的控制者；
●项目经理的角色；
●项目团队的组成。
P27：
组织过程资产可分成以下两大类：
（1）流程与程序；
●指南和标准，用于裁剪组织标准流程和程序以满足项目的特定要求；
●特定的组织标准，例如人力资源政策。
●模板
●变更控制程序
●财务控制程序
●问题与缺陷管理程序，包括对问题与缺陷的控制、识别与处理，以及对行动方案的跟踪；
●组织对沟通的要求
●确定工作优先顺序、批准工作与签发工作授权的程序；
●风险控制程序
●标准化的指南、工作指示、建议书评价准则和绩效测量准则。
●项目收尾指南或要求
（2）共享知识库。
●配置管理知识库，包括执行组织的所有标准、政策、程序和任何项目文件的各种版本与基准；
●财务数据库，包括人工时、实际成本、预算和成本超支等方面的信息；
●历史信息与经验教训知识库
●问题与缺陷管理数据库
●过程测量数据库，用来收集与提供过程和产品的测量数据；
●以往项目的项目档案
P29：
事业环境因素是指项目团队不能控制的，将对项目产生影响、限制或指令作用的各种条件。
事业环境因素包括（但不限于）：
●组织文化、结构和治理；
●设施和资源的地理分布；
●政府或行业标准（如监管机构条例、行为准则、产品标准、质量标准和工艺标准）；
●基础设施（如现有的设施和固定资产）；
●现有人力资源状况（如人员在设计、开发、法律、合同和采购等方面的技能、素养与知识）；
●人事管理制度（如人员招聘和留用指南、员工绩效评价与培训记录、奖励与加班政策，以及考勤制度）；
●公司的工作授权系统；
●市场条件；
●干系人风险承受力；
●政治氛围；
●组织已有的沟通渠道；
●商业数据库（如标准化的成本估算数据、行业风险研究资料和风险数据库）；
●项目管理信息系统（如自动化工具，包括进度计划软件、配置管理系统、信息收集与发布系统或进入其他在线自动系统的网络界面）。
P32：
项目经理的重要职责之一就是管理干系人的期望。
由于干系人的期望往往差别很大，甚至相互冲突，所以这项工作困难重重。
项目经理的另一项职责就是平衡干系人的不同利益，并确保项目团队以专业和合作的方式与干系人打交道。
项目经理可以邀请项目发起人或来自不同地区的团队成员，共同识别和管理可能分布在全球各地的干系人。
P33：
职能经理是在行政或职能领域（如人力资源、财务、会计或采购）承担管理角色的重要人物。
他们配有固定员工，以开展持续性工作；他们对所辖职能领域中的所有任务有明确的指挥权。
职能经理可为项目提供相关领域的专业技术，或者，职能部门可为项目提供相关服务。
P37：
项目团队的两种基本组成方式：
●专职团队。
在专职团队中，所有或大部分项目团队成员都全职参与项目工作。
项目团队可能集中办公，也可能是虚拟团队，团队成员通常直接向项目经理汇报工作。
对项目经理来说，这是最简单的结构，因为职权关系非常清楚，团队成员专注于项目目标。
●兼职团队。
有些项目是临时的附加工作，项目经理和团队成员一边在本来的部门从事本职工作，一边在项目团队从事项目工作。
职能经理控制着团队成员和项目资源，项目经理可能同时肩负其他管理职责。
兼职的团队成员也可能同时参与多个项目。
P40：
最高的风险影响（损失量）：
发生在实施和收尾阶段；
最高风险发生在：
概念阶段。
P42：
阶段与阶段的关系有两种基本类型：
●顺序关系。
在顺序关系中，一个阶段只能在前一阶段完成后开始。
其按部就班的特点减少了项目的不确定性，但也排除了缩短项目总工期的可能性。
●交叠关系。
在交叠关系中，一个阶段在前一阶段完成前就开始。
这有时可作为进度压缩的一种技术，被称为“快速跟进”。
阶段交叠可能需要增加额外的资源来并行开展工作，可能增加风险，也可能因尚未获得前一阶段的准确信息就开始后续工作而造成返工。
P44：
预测型生命周期（也称为完全计划驱动型生命周期）是项目生命周期的一种。
P45：
以下情况优先选择预测型生命周期：
充分了解拟交付的产品，有厚实的行业实践基础，或者整批一次性交付产品有利于干系人。
P46：
适应型生命周期（也称为变更驱动方法或敏捷方法），其目的在于应对大量变更，获取干系人的持续参与。
:
适应型生命周期也包含迭代和增量的概念，但不同之处在于，迭代很快（通常2～4周迭代１次），而且所需时间和资源是固定的。
以下情况优先选择适应型方法：
需要应对快速变化的环境，需求和范围难以事先确定，或者，能够以有利于干系人的方式定义较小的增量改进。
第三章项目管理过程
P48：
从项目开始到结束，项目管理过程和产品导向过程始终彼此重叠、相互作用。
P58：
项目或阶段收尾时，可能需要进行以下工作：
●获得客户或发起人的验收，以正式结束项目或阶段；
●进行项目后评价或阶段结束评价；
●记录裁剪任何过程的影响；
●记录经验教训；
●对组织过程资产进行适当更新；
●将所有相关项目文件在项目管理信息系统中归档，以便作为历史数据使用；
●结束所有采购活动，确保所有相关协议的完结；
●对团队成员进行评估，释放项目资源。
P59、P85、P90、P93、P97、P139、P413：
●工作绩效数据。
在执行项目工作的过程中，从每个正在执行的活动中收集到的原始观察结果和测量值。
例如，已完成的工作、工作完成百分比、关键绩效指标（CPI*SPI）、质量和技术绩效测量结果、进度活动的开始和结束日期、变更请求的数量、缺陷数量、实际成本和实际持续时间等。
●工作绩效信息。
从各控制过程中收集并结合相关背景和跨领域关系，进行整合分析而得到的绩效数据。
通过沟通过程进行传递。
绩效信息的例子有可交付成果的状况、变更请求的落实状况、预测的完工估算和完工尚需估算。
控制范围过程产生的工作绩效信息包括收到的变更的分类、识别的范围偏差和原因、偏差对进度和成本的影响，以及对将来范围绩效的预测。
●工作绩效报告。
为制定决策、提出问题、采取行动或引起关注，而汇编工作绩效信息，所形成的实物或电子项目文件。
项目信息可以通过口头形式进行传达，但为了便于项目绩效信息的记录、存储和分发，有必要使用实物形式或电子形式的项目文件。
例如，状况报告、备忘录、论证报告、信息札记、电子报表、推荐意见或情况更新。
对实施整体变更控制过程特别有用的工作绩效报告包括：
资源可用情况、进度和成本数据、挣值管理（EVM）报告、燃烧图或燃尽图。
第四章项目整合管理
P66：
制定项目章程是编写一份正式批准项目并授权项目经理在项目活动中使用组织资源的文件的过程。
本过程的主要作用是，明确定义项目开始和项目边界，确立项目的正式地位，以及高级管理层直述他们对项目的支持。
P67：
在项目中，应尽早确认并任命项目经理，最好在制定项目章程时就任命，最晚也必须在规划开始之前。
P68：
项目工作说明书（StatementofWork，SOW）是对项目需交付的产品、服务或成果的叙述性说明。
对于内部项目，项目启动者或发起人根据业务需要及对产品或服务的需求，来提供工作说明书。
对于外部项目，工作说明书则由客户提供，可以是招标文件（如建议邀请书、信息邀请书、投标邀请书）的一部分，或合同的一部分。
SOW应包括以下内容：
●业务需要。
组织的业务需要可基于市场需求、技术进步、法律要求、政府法规或环境考虑。
通常，会在商业论证中，进行业务需要和成本效益分析，对项目进行论证。
●产品范围描述。
记录项目所需产出的产品、服务或成果的特征，以及这些产品、服务或成果与项目所对应的业务需要之间的关系。
●战略计划。
战略计划文件记录了组织的愿景、目的和目标，也可包括高层级的使命阐述。
所有项目都应该支持组织的战略计划。
确认项目符合战略计划，才能确保每个项目都能为组织的整体目标做贡献。
P69：
商业论证或类似文件能从商业角度提供必要的信息，决定项目是否值得投资。
高于项目级别的经理和高管们往往使用该文件作为决策的依据。
在商业论证中，开展业务需要和成本效益分析，论证项目的合理性，并确定项目边界。
在多阶段项目中，可通过对商业论证的定期审核，来确保项目能实现其商业利益。
（备注：
先有项目工作说明书，后有商业论证）
P70：
协议定义了启动项目的初衷。
协议有多种形式，包括合同、谅解备忘录（MOUs）、服务品质协议（SLA）、协议书、意向书、口头协议、电子邮件或其他书面协议。
通常，为外部客户做项目时，就用合同。
P71：
项目章程是由项目启动者或发起人发布的，正式批准项目成立，并授权项目经理动用组织资源开展项目活动的文件。
在项目章程中记录业务需要、假设条件、制约因素、对客户需要和高层级需求的理解，以及需要交付的新产品、服务或成果，例如：
●项目目的或批准项目的原因；
●可测量的项目目标和相关的成功标准；
●高层级需求；
●假设条件和制约因素；
●高层级项目描述和边界定义；
●高层级风险；
●总体里程碑进度计划；
●总体预算；
●干系人清单；
●项目审批要求（如用什么标准评价项目成功，由谁对项目成功下结论，由谁来签署项目结束）；
●委派的项目经理及其权责；
●发起人或其他批准项目章程的人员的姓名和职权。
P76：
引导技术：
头脑风暴、冲突处理、问题解决和会议管理等，都是引导者可以用来帮助团队和个人完成项目活动的关键技术。
项目管理计划包括（3个基准+13个计划）：
范围基准、进度基准、成本基准、范围管理计划、需求管理计划、进度管理计划、成本管理计划、质量管理计划、过程改进计划、人力资源管理计划、沟通管理计划、风险管理计划、采购管理计划、干系人管理计划、变更管理计划、配置管理计划。
P78：
项目管理计划是用于管理项目的主要文件之一，同时，还会使用其他项目文件。
这些其他文件不属于项目管理计划。
P81：
已批准的变更，包括：
●纠正措施。
为使项目工作绩效重新与项目管理计划一致而进行的有目的的活动。
●预防措施。
为确保项目工作的未来绩效符合项目管理计划而进行的有目的的活动。
●缺陷补救。
为了修正不一致的产品或产品组件而进行的有目的的活动。
P82：
批准的变更请求是实施整体变更控制过程的输出，包括那些经变更控制委员会审查和批准的变更请求。
批准的变更请求可能是纠正措施、预防措施或缺陷补救。
项目团队把批准的变更请求列入进度计划并付诸实施。
批准的变更请求可能对项目或项目管理计划的某些领域产生影响。
批准的变更请求可能导致修改政策、项目管理计划、程序、成本、预算或进度计划。
批准的变更请求可能要求实施预防或纠正措施。
P84：
会议通常可分为下列三类：
●交换信息；（交流会）
●头脑风暴、方案评估或方案设计；（评审会）
●制定决策。
（决策会）
最好不要把各种会议类型混合在一起。
会前，应该做好准备工作，包括确定会议议程、目的、目标和期限；会后，要形成书面的会议纪要和行动方案。
应该按照项目管理计划中的规定保存会议纪要。
P88：
如果项目是项目集的一部分，还应向项目集管理层报告项目进展和状态。
P90：
批准的变更是实施整体变更控制过程的结果。
需要对它们的执行情况进行确认，以保证它们都得到正确的落实。
确认的变更用数据说明变更已得到正确落实。
P91：
在项目管理中，根据可能的项目或环境变量的变化，以及它们与其他变量之间的关系，采用分析技术来预测潜在的后果。
例如，可用于项目的分析技术包括：
●回归分析；
●分组方法；
●因果分析；
●根本原因分析；
●预测方法（如时间序列、情景构建、模拟等）；
●失效模式与影响分析（FMEA）；
●故障树分析（FTA）；
●储备分析；
●趋势分析；
●挣值管理；
●差异分析。
P96：
配置控制重点关注可交付成果及各个过程的技术规范，而变更控制则着眼于识别、记录、批准或否决对项目文件、可交付成果或基准的变更。
配置管理活动如下：
●配置识别。
识别与选择配置项，从而为定义与核实产品配置、标记产品和文件、管理变更和明确责任提供基础。
●配置状态记录。
为了能及时提供关于配置项的适当数据，应记录和报告相关信息。
此类信息包括已批准的配置识别清单、配置变更请求的状态和已批准的变更的实施状态。
●配置核实与审计。
通过配置核实与配置审计，可以保证项目的配置项组成的正确性，以及相应的变更都被登记、评估、批准、跟踪和正确实施，从而确保配置文件所规定的功能要求都已实现。
P99：
实施整体变更控制过程的会议通常是指变更控制会议。
根据项目需要，可以由变更控制委员会（CCB）开会审查变更请求，并做出批准、否决或其他决定。
CCB也可以审查配置管理活动。
应该明确规定变更控制委员会的角色和职责，并经相关干系人一致同意后，记录在变更管理计划中。
CCB的决定都应记录在案，并向干系人传达，以便其知晓并采取后续措施。
P100：
变更日志用来记录项目过程中出现的变更。
应该与相关的干系人沟通这些变更及其对项目时间、成本和风险的影响。
被否决的变更请求也应该记录在变更日志中。
P102：
验收的可交付成果可能包括批准的产品规范、交货收据和工作绩效文件。
在分阶段实施的项目或被取消的项目中，可能会包括未全部完成的可交付成果或中间可交付成果。
第五章项目范围管理
P108：
范围管理计划有助于降低项目范围蔓延的风险。
依据项目章程中的项目背景信息来规划各个范围管理过程。
项目章程提供了高层级的项目描述和产品特征。
产品特征出自项目工作说明书。
P109：
范围管理计划要对将用于下列工作的管理过程做出规定：
●制定详细项目范围说明书；
●根据详细项目范围说明书创建WBS；
●维护和批准WBS；
●正式验收已完成的项目可交付成果；
●处理对详细项目范围说明书的变更。
该工作与实施整体变更控制过程直接相联。
P110：
需求管理计划的主要内容包括（但不限于）：
●如何规划、跟踪和报告各种需求活动；
●配置管理活动，例如，如何启动产品变更，如何分析其影响，如何进行追溯、跟踪和报告，以及变更审批权限；
●需求优先级排序过程；
●产品测量指标及使用这些指标的理由；
●用来反映哪些需求属性将被列入跟踪矩阵的跟踪结构。
P114：
收集需求的工具与技术
1.访谈：
经常是一个访谈者和一个被访者之间的“一对一”谈话，但也可以包括多个访谈者和/或多个被访者。
2.焦点小组：
召集预定的干系人和主题专家，了解他们对所讨论的产品、服务或成果的期望和态度。
由一位受过训练的主持人引导大家进行互动式讨论。
3.引导式研讨会：
把主要干系人召集在一起，通过集中讨论来定义产品需求。
研讨会是快速定义跨职能需求和协调干系人差异的重要技术。
由于群体互动的特点，被有效引导的研讨会有助于参与者之间建立信任、改进关系、改善沟通，从而有利于干系人达成一致意见。
此外，研讨会能够比单项会议更早发现问题，更快解决问题。
●在软件开发行业，使用“联合应用设计/开发（JAD）”的引导式研讨会。
注重把业务主题专家和开发团队集中在一起，来改进软件开发过程。
●在制造行业，则使用“质量功能展开（QFD）”（又称“客户声音”）这种引导式讨论会，来帮助确定新产品的关键特征。
从收集客户需要开始，然后客观地对这些需要进行分类和排序，并为实现这些需要而设定目标。
●用户故事是对所需功能的简短文字描述，经常产生于需求研讨会。
用户故事描述哪个干系人将从功能中受益（角色），他需要实现什么（目标），以及他将获得的收益（动机）。
用户故事在敏捷方法中广泛使用。
4.常用的群体创新技术：
●头脑风暴法。
一种用来产生和收集对项目需求与产品需求的多种创意的技术。
头脑风暴法本身不包含投票或排序，但常与包含该环节的其他群体创新技术一起使用。
●名义小组技术。
用于促进头脑风暴的一种技术，通过投票排列最有用的创意，以便进一步开展头脑风暴或优先排序。
●概念/思维导图。
把从头脑风暴中获得的创意整合成一张图的技术，以反映创意之间的共性与差异，激发新创意。
●亲和图。
用来对大量创意进行分组的技术，以便进一步审查和分析。
●多标准决策分析。
借助决策矩阵，用系统分析方法建立诸如风险水平、不确定性和价值收益等多种标准，从而对众多方案进行评估和排序的一种技术。
5.群体决策的方法有很多，例如：
●一致同意。
每个人都同意某个行动方案。
达成一致同意的一种方法就是德尔菲技术，由一组选定的专家回答问卷，并对每轮需求收集的结果给出反馈。
只有主持人可以看到专家的答复，以保持匿名状态。
●大多数原则。
获得群体中超过50%人员的支持，就能做出决策。
把参与决策的小组人数定为奇数，防止因平局而无法达成决策。
●相对多数原则。
根据群体中相对多数者的意见做出决策，即便未能获得大多数人的支持。
通常在候选项超过两个时使用。
●独裁。
在这种方法中，由某一个人为群体做出决策。
（备注：
并非真正意义上的独裁）
6.问卷调查：
指设计一系列书面问题，向众多受访者快速收集信息。
问卷调查方法非常适用于以下情况：
受众多样化，需要快速完成调查，受访者地理位置分散，并且适合开展统计分析。
7.观察是：
当产品使用者难以或不愿清晰说明他们的需求时，就特别需要通过观察来了解他们的工作细节。
观察，也称为“工作跟踪”，通常由观察者从外部来观看业务专家如何执行工作。
也可以由“参与观察者”来观察，他通过实际执行一个流程或程序，来体验该流程或程序是如何实施的，以便挖掘隐藏的需求。
8.原型法：
指在实际制造预期产品之前，先造出该产品的实用模型，并据此征求对需求的早期反馈。
原型法支持渐进明细的理念，需要经历从模型创建、用户体验、反馈收集到原型修改的反复循环过程。
故事板是一种原型技术，通过一系列的图像或图示来展示顺序或导航路径。
9.标杆对照：
将实际或计划的做法（如流程和操作过程）与其他可比组织的做法进行比较，以便识别最佳实践，形成改进意见，并为绩效考核提供依据。
标杆对照所采用的可比组织可以是内部的，也可以是外部的。
10.系统交互图：
范围模型的一个例子，它是对产品范围的可视化描绘，显示业务系统（过程、设备、计算机系统等）及其与人和其他系统（行动者）之间的交互方式。
系统交互图显示了业务系统的输入、输入提供者、业务系统的输出和输出接收者。
11.文件分析：
通过分析现有文档，识别与需求相关的信息，来挖掘需求。
P122：
对于那些以产
升级会员 