PMP解析.docx
《PMP解析.docx》由会员分享，可在线阅读，更多相关《PMP解析.docx（64页珍藏版）》请在冰豆网上搜索。
PMP解析
项目管理概论
第1章引论
1.1PMBOK®指南的目的
引文1：
PMBOK®指南旨在识别项目管理知识体系中被普遍公认为良好做法的那一部分。
解析：
注意“普遍公认”，并不是绝对好的。
引文2：
良好做法并不意味着这些知识必须一成不变地运用于所有项目；组织和／或项目管理团队负责为具体项目选择适用的知识。
1.2什么是项目
引文1：
项目是为创造独特的产品、服务或成果而进行的临时性工作。
解析：
PMBOK中项目的定义。
引文2：
临时性并不一定意味着持续时间短。
解析：
古代长城、金字塔、三峡工程历时几十甚至上百年，仍然具有临时性，可作为项目看待。
引文3：
项目所创造的产品、服务或成果一般不具有临时性。
大多数项目都是为了创造持久性的结果。
例如，国家纪念碑建设项目就是要创造一个流传百世的成果。
项目所产生的社会、经济和环境影响，也往往比项目本身长久得多。
解析：
项目是临时性，但项目成果一般是持久的。
引文4：
每个项目都会创造独特的产品、服务或成果。
解析：
项目的独特性主要指项目成果的独特性。
引文4：
项目可以创造：
一种产品、一种能力或一种成果
解析：
比如PMP导图就是一个具体的成果，再比如培训项目产生的结果就是学员能力的提升。
1.3什么是项目管理
引文1：
项目管理就是将知识、技能、工具与技术应用于项目活动，以满足项目的要求。
解析：
PMBOK中项目管理的定义。
引文2：
平衡相互竞争的项目制约因素，包括（但不限于）：
○范围
○质量
○进度
○预算
○资源
○风险
具体的项目会有具体的制约因素，项目经理需要加以关注。
这些因素间的关系是，任何一个因素发生变化，都会影响至少一个其他因素。
解析：
项目的制约要素还有，但哪个更重要呢？
没有绝对的答案都很重要。
记住：
制约要素的重要性是由管理层决定的，而非项目经理或团队。
1.4项目管理、项目集管理和项目组合管理间的关系
引文：
在成熟的项目管理组织中，项目管理会处于一个由项目集管理和项目组合管理所治理的更广阔的环境中。
1.4.1项目组合管理
引文：
项目组合是指为便于有效管理、实现战略业务目标而组合在一起的项目、项目集和其他工作。
项目组合中的项目或项目集不一定彼此依赖或有直接关系。
解析：
注意项目组合是为实现“特定”的战略目标，并且其中的项目或项目集不一定彼此依赖。
引文：
项目组合管理包括识别、排序、授权、管理和控制项目、项目集和其他有关工作。
引文：
项目组合管理重点关注：
通过审核项目和项目集来确定资源分配的优先顺序，并确保对项目组合的管理与组织战略协调一致。
1.4.2项目集管理
引文：
项目集是一组相互关联且被协调管理的项目。
协调管理是为了获得对单个项目分别管理所无法实现的利益和控制。
引文：
项目集管理重点关注项目间的依赖关系，并有助于找到管理这些依赖关系的最佳方法。
解析：
项目集中的项目必须是彼此依赖或相关联的。
1.4.3项目与战略计划
引文：
项目经常被作为实现组织战略计划的一种手段。
启动原因包括：
市场需求、战略机会/业务需求、客户要求、技术进步、法律要求。
解析：
要了解为什么启动一个项目。
1.4.4项目管理办公室
引文：
项目管理办公室（PMO）是负责对所辖各项目进行集中协调管理的一个组织部门。
解析：
PMO是一个常规的组织部门，不是临时的机构。
PMO的重要职能是支持项目经理，包括管理共享资源；整理项目管理的方法、标准；指导监督项目；培训人员；审计；开发项目流程及模板；协调项目间沟通等；
引文：
项目经理与PMO的目标不同，所需遵守的要求也就不同，但他们的所有努力都必须符合组织的战略需求。
解析：
项目经理关注特定的项目目标、控制分配给本项目的资源、理管理单个项目的制约因素。
1.5项目管理与运营管理
解析：
参见2.2项目与运营
1.6项目经理的角色
引文：
项目经理是执行组织委派其实现项目目标的个人。
1.7项目管理知识体系
引文：
本标准仅适用于单个项目，且仅包含被普遍公认为良好做法的项目管理过程。
解析：
PMP只适用于单个项目。
1.8事业环境因素
引文：
事业环境因素是指围绕项目或能影响项目成败的任何内外部环境因素。
这些因素来自任何或所有项目参与单位。
解析：
所有影响项目的外部因素都是事业环境因素，影响项目的内部因素有些是组织过程资产，有些是事业环境因素。
例如：
政府或行业标准、商业数据库能影响项目，它们又是来自企业外部，所以一定是事业环境因素；
再如：
公司的文化组织结构、基础设施、工作授权系统、项目管理信息系统、组织已有沟通渠道、人事制度等，这些是组织内部不容易修改因素的但能影响项目，他们也是事业环境因素；
注意，尽管项目管理信息系统属于事业环境因素，但信息系统里面积累的数据属于组织过程资产。
第2章项目生命周期与组织
2.1项目生命周期——概述
引文：
项目生命周期是通常按顺序排列而有时又相互交叉的各项目阶段的集合。
阶段的名称和数量取决于参与项目的一个或多个组织的管理与控制需要、项目本身的特征及其所在的应用领域
解析：
项目生命周期包括几个阶段是由项目特点决定的。
2.1.1项目生命周期的特征
引文：
成本与人力投入在开始时较低，在工作执行期间达到最高，并在项目快要结束时迅速回落
引文：
干系人的影响力、项目的风险与不确定性在项目开始时最大，并在项目的整个生命周期中随时间推移而递减
2.1.2产品生命周期与项目生命周期的关系
引文：
产品生命周期包含通常顺序排列且不相互交叉的一系列产品阶段
解析：
注意，只是“通常”，不一定。
后面提到过阶段间的其他关系，比如交叠和迭代。
2.1.3项目阶段
引文：
项目阶段大多是按顺序完成的，但在某些情况下也可重叠。
引文：
阶段结束点是对项目进行重新评估，并在必要时变更或终止项目的一个当然时点。
这些时点可称为阶段出口、里程碑、阶段关卡、决策关卡、时段关卡或关键决策点。
解析：
阶段结束点很重要，每个阶段结束必须评估，对它的几个称呼要有印象。
2.2项目与运营
引文：
项目与运营的主要区别在于，运营是持续性的，生产重复的产品、服务或成果。
项目（连同团队，也经常连同机会）是临时性的，有明确的终点。
解析：
运营是为了持续，项目是为了结束。
2.3项目干系人
引文：
项目干系人是积极参与项目或其利益可能受项目实施或完成的积极或消极影响的个人或组织（如客户、发起人、执行组织或公众）
解析：
干系人很广泛
2.4组织对项目管理的影响
2.4.2组织结构
引文：
组织结构是一种事业环境因素，它可能影响资源的可用性，并影响项目的管理模式。
组织结构的类型包括职能型、项目型以及位于这两者之间的各种矩阵型结构。
2.4.3组织过程资产
第3章单个项目的项目管理过程
引文：
过程是为完成预定的产品、成果或服务而执行的一系列相互关联的行动和活动。
每个过程都有各自的输入、工具和技术以及相应输出
引文：
对于任一具体项目，项目经理都要与项目团队共同负责，确定应采用哪些过程以及应多么严格地运用每个过程。
3.1项目管理过程间的作用
引文：
各项目管理过程组以它们所产生的输出相互联系。
3.2项目管理过程组
引文：
过程组不同于项目阶段。
大型或复杂项目可以分解为不同的阶段或子项，每个阶段或子项目通常都要重复所有过程组。
3.3启动过程组
引文：
启动过程组包含获得授权，定义一个新项目或现有项目的一个新阶段，正式开始该项目或阶段的一组过程。
解析：
如果一个项目被分为多个阶段，则每个阶段都要进行启动。
引文：
让客户和其他干系人参与启动过程，通常能提高他们的主人翁意识，使他们更容易接受可交付成果，更容易对项目表示满意。
解析：
让客户尽早参与的好处。
引文：
表3-1项目管理过程组与知识领域表
解析：
这张表要记住。
3.4规划程组
引文：
这种项目管理计划的渐进明细通常叫做“滚动式规划”，表明项目规划和文档编制是反复进行的持续性过程。
引文：
项目团队应当鼓励所有相关干系人参与。
3.5执行过程组
引文：
执行过程组不但要协调人员和资源，还要按照项目管理计划整合并实施项目活动
引文：
项目的一大部分预算将花费在执行过程组中。
3.6监控过程组
引文：
监控过程组的关键作用是持续并有规律地观察和测量项目绩效，从而识别与项目管理计划的偏差。
3.7收尾过程组
引文：
收尾过程组包含为完结所有项目管理过程组的所有活动，以正式结束项目或阶段或合同责任而实施的一组过程。
解析：
每个阶段都要收尾。
第4章项目整合管理
引文：
在项目管理中，“整合”兼具统一、合并、连接和一体化的性质，对完成项目、成功管理干系人期望和满足项目要求，都至关重要。
解析：
整合管理就是管理项目接口，包括内、外、人、财、物等所有接口。
4.1制定项目章程
引文：
在项目中，应尽早确认并任命项目经理，最好在制定项目章程时就任命，最晚也必须在规划开始之前。
项目经理应该参与制定项目章程，因为该章程将授权项目经理在项目活动中使用组织资源。
解析：
项目章程是一份非常重要的法律文件，相当于项目的“宪法”，后续的一切项目计划都要围绕项目章程来编制，不能违反项目章程。
项目章程宣告一个项目的正式启动，项目经理的任命，并对项目的目标，范围，主要可交付成果，主要制约因素与主要假设条件等进行总体性描述。
解析：
做项目不可没有项目章程,否则项目没有基本的保障。
引文：
项目由项目以外的人员批准，如发起人、PMO或项目组合指导委员会。
他们亲自编制项目章程，或授权项目经理代为编制。
解析：
项目章程至少包括以下几方面的内容，起到以下几方面的作用：
确定项目经理，规定项目经理的权力。
正式确定项目的存在，给项目一个合法的地位。
规定项目的总体目标，包括范围，时间，成本和质量等。
通过叙述启动项目的理由，把项目与公司的日常经营运作及战略计划等联系起来。
4.1.1制定项目章程：
输入
引文：
工作说明书（SOW）是对项目所需交付的产品或服务的叙述性说明。
解析：
SOW来自项目外部，如果是组织内部的项目，是由发起人或启动者提供，如果是外部项目，通常来自合同。
4.1.3制定项目章程：
输出
解析：
项目章程中一定要写清楚委派的项目经理及其职责和职权；
4.2制定项目管理计划
4.2.1制定项目管理计划：
输入
引文：
编制项目管理计划需要整合诸多规划过程（如第5章至第12章所述）的输出。
其他规划过程所输出的任何基准和子管理计划，都是本过程的输入。
4.2.3制定项目管理计划：
输出
解析：
项目管理计划包括三个基准：
进度基准、成本绩效基准、范围基准；10个子计划包括（但不限于）：
范围管理计划、需求管理计划、进度管理计划、成本管理计划、质量管理计划、过程改进计划、人力资源计划、沟通管理计划、风险管理计划、采购管理计划。
4.3.3指导与管理项目执行：
输出
引文：
批准的可交付成果是在某一过程、阶段或项目完成时，必须产出的任何独特并可验证的产品、成果或服务能力。
解析：
过程、阶段或项目结束时都课程产生可交付成果。
4.4监控项目工作
引文：
监督是贯穿于整个项目周期的项目管理活动之一，它包括收集、测量和发布绩效信息，分析测量结果和预测趋势，以便推动过程改进。
4.5实施整体变更控制
引文：
项目的任何干系人都可以提出变更请求。
尽管也可以口头提出，但所有变更请求都必须以书面形式记录，并纳入变更管理和/或配置管理系统中。
解析：
任何干系人都可提变更。
任何变更都要记录并管理。
引文：
项目经理有权批准某些种类的变更请求。
必要时，需由变更控制委员会（ChangeControlBoard，CCB）负责批准或否决变更请求。
解析：
项目经理可批准小的、紧急的变更；大的、设计基线的变更要有CCB处理，注意：
上述两种渠道都是在走“实施整体变更控制”流程。
引文：
配置控制重点关注可交付成果及各个过程的技术规范，而变更控制则着眼于识别、记录和控制对项目及产品基准的变更。
解析：
配置控制关注成果；变更控制关注过程（变更的过程）。
4.6结束项目或阶段
引文：
结束项目时移交项目所产出的最终产品、服务或成果；在阶段收尾中，则是移交该阶段所产出的中间产品、服务或成果。
第5章项目范围管理
引文：
“范围”这一术语有两种含义：
产品范围——某项产品、服务或成果所具有的特性和功能。
项目范围——为交付具有规定特性与功能的产品、服务或成果而必须完成的工作。
引文：
根据项目管理计划（见4.2.3.1节）来衡量项目范围是否完成，根据产品需求（见5.1节）来衡量产品范围是否完成。
5.1收集需求
引文：
需求是指发起人、客户和其他干系人的已量化且记录下来的需要与期望
解析：
谁都可以提需求。
5.1.2收集需求：
工具与技术
引文：
焦点小组会议是把预先选定的干系人和主题专家集中在一起
解析：
焦点小组会议要点是“专注于主题”
引文：
引导式研讨会是快速定义跨职能需求和协调干系人差异的重要技术
解析：
引导式研讨会要点是“跨职能”
引文：
头脑风暴法。
用来产生和收集对项目需求与产品需求的多种创意的一种技术。
解析：
拒绝评论和批评，尽量多地产生新想法。
引文：
德尔菲技术。
由一组选定的专家回答问卷，并对每一轮需求收集的结果再给出反馈。
解析：
德尔菲技术的使用范围很广，可以用于需求分析、编制工作分解结构、鉴别和评价风险、预测成本、预测工期等。
使用德尔菲技术必须遵守以下几个原则：
专家之间必须完全背靠背，更不能进行讨论。
专家以匿名的书面形式提出意见。
往往需要经过几轮的“提意见、反馈、提意见”（专家匿名提意见，主持人收集和汇总意见并向专家反馈情况，专家再次提意见）。
旨在取得一致意见。
解析：
匿名，参与者不知道谁还参与了该次评审，可以避免老师、权威、领导等特殊身份的影响。
引文：
问卷调查是指通过设计书面问题，向为数众多的受访者快速收集信息。
解析：
人数众多时使用，收集到问卷后要进行统计分析。
引文：
观察是指直接观察个人在各自的环境中如何开展工作和实施流程。
当产品使用者难以或不愿说明他们的需求时，就特别需要通过观察来了解细节。
引文：
原型法是指在实际制造产品之前，先造出该产品的实用模型，并据此征求对需求的反馈意见
解析：
原型法体现了项目渐进明细的特点。
5.2定义范围
5.2.2定义范围：
工具与技术
引文：
对于那些以产品为可交付成果的项目（区别于提供服务或成果的项目），产品分析是一种有效的工具。
引文：
产品分析技术包括产品分解、系统分析、需求分析、系统工程、价值工程和价值分析等。
5.2.3定义范围：
输出
引文：
项目范围说明书详细描述项目的可交付成果，以及为提交这些可交付成果而必须开展的工作。
解析：
项目范围说明书不仅包括产品描述及可交付成果，还包括产品验收标准。
解析：
项目干系人对项目的需要、想要与期望可能并不十分明确。
这就要求项目管理团队运用自己的专业知识与技能，通过与干系人密切沟通，把干系人比较笼统和抽象的需求转变为具体的、可测量的需求。
引文：
项目制约因素。
列出并说明与项目范围有关、且限制项目团队选择的具体项目制约因素，例如，客户或执行组织事先确定的预算、强制性日期或强制性进度里程碑。
如果项目是根据合同实施的，那么合同条款通常也是制约因素。
解析：
制约因素是外部的、强制的，确定存在的，并且是限制项目的。
引文：
项目假设条件。
列出并说明与项目范围有关的具体项目假设条件，以及万一不成立而可能造成的后果
解析：
假设条件是不确定的，可能给项目带来风险。
5.3创建工作分解结构
引文：
创建工作分解结构（WBS）是把项目可交付成果和项目工作分解成较小的、更易于管理的组成部分的过程。
解析：
WBS以成果为导向，这里的“工作”是名词
解析：
WBS分解的最底层是工作包。
解析：
工作分解结构中的“工作”并不是指工作本身，而是工作所导致的成果。
这也是PMI主义。
考生必须牢记这一点。
解析：
工作分解结构是用来确定项目的范围的，项目的全部工作都必须包含在工作分解结构之中，而且不包含在工作分解结构中的任何工作都不是项目的组成部分，都不能做，否则就是“镀金”。
这是工作分解结构100%规则的要求——工作分解结构必须且只能包括100%的工作。
解析：
工作分解结构的编制需要所有（主要）项目干系人的参与，需要项目团队成员的参与。
解析：
工作分解结构中的各要素应该是相对独立的，要尽量减少相互之间的交叉。
5.3.2创建工作分解结构：
工具与技术
引文：
工作包是工作分解结构的底层，是能够可靠地估算和管理工作成本和活动持续时间的位置
解析：
先分解近期的工作，未来远期才完成的可交付成果或子项目，留到后来分解。
这种技术有时称做滚动式规划。
引文：
工作分解结构包含了全部的产品和项目工作，包括项目管理工作。
通过把工作分解结构底层的所有工作逐层向上汇总，来确保没有遗漏工作，也没有增加多余的工作。
这有时被称为100%规则。
解析：
别忘了WBS中包括项目管理的工作。
5.3.3创建工作分解结构：
输出
引文：
控制账户是一种管理控制点。
在该控制点上，把范围、成本和进度加以整合，并把它们与挣值相比较，以测量绩效。
解析：
工作包粒度太小，对每个包计算绩效太繁琐，所以提出控制账户的概念。
引文：
工作分解结构词典对工作分解结构组成部分（包括工作包和控制账户）进行更详细的描述。
解析：
应该说WBS词典作用比WBS更大，写WBS词典的工作量也较大。
引文：
范围基准是项目管理计划的组成部分。
范围基准包括：
项目范围说明书、工作分解结构、工作分解结构词典
解析：
PMP考试常考。
5.4核实范围
引文：
核实范围包括与客户或发起人一起审查可交付成果，确保可交付成果已圆满完成，并获得客户或发起人的正式验收。
解析：
核实范围由项目之外的客户或发起人做，强调的是正式验收。
解析：
核实范围是在项目监控阶段进行的，强调在可交付成果完成时及时进行验收，不要拖到项目结束时才进行验收。
这样做的目的是，为了在还有时间解决问题时就及时发现问题。
解析：
核实范围涉及检查工作结果，确认是否符合范围要求，正式签署对工作结果（可交付成果）的验收。
解析：
范围核实和质量控制是不同的，前者注重的可交付成果的可接受性，而后者注重的是可交付成果的正确性（符合质量要求）。
通常是质量控制在前，范围核实在后；前后的输出之一是“确认的可交付成果”，它又是后者的输入。
引文：
范围核实与质量控制的不同之处在于，范围核实主要关注对可交付成果的验收，而质量控制则主要关注可交付成果是否正确以及是否满足质量要求。
引文：
质量控制通常先于范围核实进行，但二者也可同时进行。
5.45.5控制范围
引文：
未得到控制的变更通常被称为项目范围蔓延。
解析：
所有变更必须严格进行控制。
PMI强烈反对范围蔓延。
解析：
控制账户用来进行项目范围、时间和成本等控制的，工作分解结构某个层次上的要素，可以是工作包，也可以是比工作包更高层次上的一个要求。
第6章项目时间管理
项目时间管理旨在保证在规定的时间内完成项目。
PMPBOK指南中所规定的项目时间管理可以概述为：
在工作分解结构的基础上，针对提交工作包的需要，列出为完成项目而必须进行的全部活动，然后再分析这些活动间的逻辑关系。
估计各活动所需要的资源，估算各活动所需要的工期，制定项目进度计划，并在执行过程中加以控制。
6.1定义活动
6.1.2定义活动：
工具与技术
引文：
活动是为完成工作包而必须开展的工作。
定义活动过程最终输出的是活动，而非可交付成果。
引文：
WBS和WBS词典是制定最终活动清单的依据。
WBS中的每个工作包都需分解成活动，以便通过这些活动来完成相应的可交付成果。
解析：
工作包是名词，活动是为完成工作包而做的动作，是对工作包的再次分解。
引文：
让团队成员参与分解，有助于得到更好、更准确的结果。
解析：
定义活动需要项目团队内部的成员参加
引文：
滚动式规划是一种渐进明细的规划方式，即对近期要完成的工作进行详细规划，而对远期工作则暂时只在WBS的较高层次上进行粗略规划。
6.1.3定义活动：
输出
引文：
在项目初始阶段，活动属性包括活动标志、WBS标志和活动名称；当活动完成时，活动属性则可能还包括活动编码、活动描述、紧前活动、紧后活动、逻辑关系、时间提前与滞后量（见6.2.2.3节）、
资源需求、强制日期、制约因素和假设条件。
解析：
活动属性的完善也体现了项目渐进明细的特点。
6.2排列活动顺序
6.2.2排列活动顺序：
工具与技术
引文：
PDM用于关键路径法（CPM），是一种用方框或矩形（称为节点）表示活动的项目进度网络图绘制法。
这种技术又称为节点法（Activity-On-Node，AON），是大多数项目管理软件所使
用的方法。
解析：
PDM就是AON的一种，题目选项同时出现时都不选。
引文：
PDM包括4种依赖关系或逻辑关系。
解析：
箭线法ADM活动间只有一种逻辑关系
引文：
强制性依赖关系往往与客观限制条件有关，又称硬逻辑关系。
解析：
强制性依赖关系每个人都要遵守
引文：
选择性依赖关系有时又称首选逻辑关系、优先逻辑关系或软逻辑关系。
应该基于具体应用领域的最佳实践，来确定选择性依赖关系
解析：
量选择性依赖关系因人而异，没有对错之分。
最佳实践属于选择性依赖关系。
引文：
时间提前量与滞后量的使用，不能取代进度逻辑关系。
提前量是指以紧前活动的完成或开始时间为基点，紧后活动的开始或完成可以提前的时间。
解析：
先确定逻辑关系，在逻辑关系基础上确定时间提前量与滞后量。
题目里把提前量与滞后量看成是等待时间。
解析：
节点法和箭线法都不允许在网络图中出现“回路”和“有条件的路径”，而条件图法则允许。
6.3估算活动资源
引文：
估算活动资源是估算每项活动所需材料、人员、设备或用品的种类和数量的过程
解析：
注意这个过程没估算钱，估算钱是在估算成本那个过程。
引文：
资源日历说明了在拟开展活动的时期中，哪些资源（如人员、设备和材料）可用，也说明了这些资源何时可用以及可用多长时间。
引文：
资源日历可针对某个活动或整个项目。
资源日历中应该列出资源的属性（如资源的经验和／或技能水平）、来源地和可用时间等。
解析：
人也是资源。
资源日历不同于工作日历，它的横坐标不是一天一天的工作时间，通常是月、周
6.3.2估算活动资源：
工具与技术
引文：
自下而上估算，应将活动进一步细分，然后估算资源需求。
接着再把这些资源需求汇总起来，得到每一个活动的资源需求。
解析：
特点：
准、慢。
适合规划后期信息比较充足时使用。
解析：
如果需要向管理层或客户汇报项目进度计划安排或实际进度进展情况，请用里程碑图和汇总横道图。
6.3.3估算活动资源：
输出
引文：
资源分解结构是按资源类别和类型而划分的资源层级结构。
6.4估算活动持续时间
引文：
应该由项目团队中最熟悉具体活动的个人或小组，来提供活动持续时间估算所需的各种输入。
解析：
渐进明细
6.4.2估算活动持续时间：
工具与技术
引文：
类比估算是指以过去类似项目的参数值（如持续时间、预算、规模、重量和复杂性等）为基础，来估算未来项目的同类参数或指标。
解析：
自上而下。
特点：
快、不准。
项目早期使用。
引文：
如果以往活动是本质上而不只是表面上类似，并且从事估算的项目团
升级会员 