pmp项目价值分级管理

pmp等级划分

PMP认证不分等级，只要通过考试，即可拿到PMP证书，即表示考生的项目管理水平达到了国际的标准，有能力从事项目管理方面的工作。国内自1999年开始推行PMP认证，由国际监考机构普尔文进行监考及考试组织。

PMP指的是项目管理专业人士资格认证。它是由美国项目管理协会发起的，严格评估项目管理人员知识技能是否具有高品质的资格认证考试。

要想获得PMP专业认证，考生须达到美国项目管理协会（PMI）规定，对项目管理专业知识的掌握程度及其相应的工作经验和要求；另一方面，获得PMP证书的专业人员应继续从事项目工作，以不断适应项目管理发展的要求！

pmp等级是什么
pmp等级是什么？一起来了解一下吧。
PMP认证不分等级，只要通过考试，即可拿到PMP证书，表示考生的项目管理水平达到了国际的标准，有能力从事项目管理方面的工作。
PMP的全称是ProjectManagementProfessional，项目管理专业人士资格认证。它是由美国项目管理协会(PMI)发起的，严格评估项目管理人员知识技能是否具有高品质的资格认证考试。目前已在全球200多个国家和地区推出，其目的是给项目管理人员提供统一的行业标准。
拓展：PMP与软考的区别和侧重方向
PMP指项目管理专业人士资格认证，由美国项目管理协会PMI发起，是国际资格认证，不分等级。PMP认证的内容是项目管理专业知识，可以在许多行业和领域使用。
软考是我国计算机软件考试，是职称考试，也是职业资格水平考试，有等级划分。与PMP不同的是，它是专业的计算机软件领域的考试，项目管理考试部分参考了PMP内容，但在PMP知识的基础上具有更多的计算机软件领域专业知识。
PMP在外资企业和大型民营企业更加受认可，更注重实际工作需要。获取PMP证书，不仅提升项目经理的项目管理水平，也直接体现项目经理的个人竞争力，是项目管理专业人士身份的象征。而软考最受到大家关注的是职称的评定体系。




pmp项目管理是什么
PMP是美国PMI的项目管理专业人士资格认证,主要学习项目管理的5大过程组和10大知识领域，学习了之后对项目管理工作很有帮助。如果现在或以后会从事项目管理工作，建议可以去欣旋考一个这样的证书，含金量很高，而且他们通过率很高。
PMP分等级吗？
PMP证书是不分等级的，无论以什么分数通过了考试，证书都是一样的。
成绩划分一般以A\T\B\N来展示，PMP考试一共分为五个过程组，考生最终得到的成绩就是每个过程组所获得的等级，比如4A1T等。
A\T\B\N含义：
Above Target（高于目标）
Target（达到目标）
Below Target（低于目标）
Needs Improvement（有待提高）
需要注意的一点：
A、T、B、N四个级别是有区间的，同时每个领域的题目数量也是不一样的，所以有时候会出现某学员3T2B没通过，而另一个学员3T2B却通过的情况。
因此，查看成绩报告时不能简单根据A、T、B、N的数量，仍需以PMI给出的PASS或FAIL为准。

PMP-项目资源管理
规划资源管理

定义：定义被医赵否收如何估算、获取、管理和利用团队以及实物资源。

规划资源管理的工具：

数据表现（层级型、责任分配矩阵、文本型）
确保每个工作包都有明确的责任人，确保全体团队成员都清楚的理解其角色和职责。一般有三种格式：层级型、矩阵型、文来自本型。

层级型组织图：是自上而下的显示各种职位和教育相互关系，有助于明确高层级的角色。 （OBS：公司组织分解结构）

文本型：适用于记录详细职责。

矩阵型：责任分配矩阵（Responsibility Assignment Matrix,简称RAM），是用来显示分配给每个工作包或者活动与项目团队成员之间的联系。

旨在所有工作落实到人，确保任何一项任务都只有一个人负责，伟林声设袁命步统运永欢避免职责混乱。确保人人有事做、事事有人做。责任分配矩阵的一个例子是RACI矩阵，每一项工作都只有一个A在负责。（R=执行（Responsible） A=负责（Accountable） C=咨询（Consult） I=知情（I证进施善妈般nform）每项活动，可以有很多个R，很多个I，很多个C，但是只能有一个A）

组织理论

阐述个人、团队、组织单位的行为方式。
每一个团队、组织都有一套自己的潜规则，描述了人员在里面应该采取什么样的行动方式。根地良我年据组织理论灵活运用领导风格，以适应项目生命周期中团队成熟度的变化。

规划资源管理的输出：

资源管理计划
是项目管理子计费给培屋鲜把在划之一。是关于如何分类、分配、管理和释放项目资源的指南。包括：

识别资源
获取资源
角色和职责
项目组织图
项目团队资源管理：关于如何定义、配备、管理和最终遣散项目团队肥你但以笔建述资源的指南
培训
团队建灯规牛设
资源控制
认可计划：将给予团队成员哪些认可和奖励，以及何时给予
团队章程（班规随为变名；团队之间指责；有人乱来）
团队章程：为团队创建团队价值观、共识和工作指南的文件。

规定团队的核心价值观、行为规范和工作规则。使团队成员对什么行为可接受或不可接受的，建立和保持基本一致的认识。
团队章程应该由团队成员通过共同讨论来制定，而不能由少数人制定出来再强加给大家。团队章程对项目团队成员的可接免美构受行为确定了明确的期望。尽早制定并遵守明确的规则，可减少误解，提高生产力。
讨论诸如行为规范、沟通、决策、会议礼仪等领域，有利于团队成员相互了解彼此重要价值观。规则一旦建立，全体项目团队成员都必须遵守。

估算活动资源

定义：估算执行各项活动所需的团队资源，以及材料、设备和用品的类型和数量。
估算活通充动资源的工具：
自下镇密零而上估算
先估算每差更练种示架钢附占个活动所需的团队资源和实物资源，然后汇总，得出整个项目的资源需求。
估算活动资石又福硫百源的输出：
资源分解结构
是把整个项目所需要的资源按照类别、类型进行展现
获取资源

定义：获取项目所需的团队成员、设施、设备、材料、用品和其他资源。

获取资源的工具：

谈判Negotiation
许多项目中，通过谈判完成人度边千曲参员分派，是组建项目团队最主要的一个方法。

项目管理团队需要与下列各方谈判：
1）职能经理：获得普通、一般资源。
2）执行组织中的其他项目管理团队：竞争特殊、稀缺资源。
3）外部组织、卖方、供应商、承包商等：获得特殊资源。
谈判：它的目标很克带田明确，需要什么资源就和混杨强农打密南谁谈判

预分派Pre-assignment
事先选定已经分配到位的人，不由项目经理决定。

三种情况：
1）气倒标书中规定了；
2）顺觉起历石里项目章程中说明，高层指定；
3）特定人员的专有技能，项目离开他就做不了；

虚拟团队Virtual Teams
有共同的目标，很少或没有时间面对面工作的一群人，比如有些人在国外、有些人工作班次和时间不同。
缺点：虚拟团队可能产生孤立感，团队成员之间难以分享知识经验，所以当采取虚拟团队的时候，沟通规划就非常重要。

获取资源的输出：

实物资源分配单
记录了项目将使用的材料、设备、用品、地点和其他实物资源。

项目团队派工单Project Team Assignments
记录了团队成员及其在项目中的角色职责 需要包含项目人员名称，相关的文件包括：

项目团队名录（directory）
项目组织图
进度计划

建设团队Develop Team

定义：提高工作能力，促进团队成员互动，改善团队整体氛围，以提高项目绩效。
目标：个人能力的提高，提高团队凝聚力。建设团队是为了让团队成员更加有活力、更加有氛围凝聚力。

塔克曼团队发展阶段理论（阶段一般按顺序进行，但有时也会发生逆转或跳跃）：
A、形成forming–相互认识，了解项目情况与职责；相互独立，不开诚布公；（重新加新人，会回到该阶段）
B、震荡storming—相对独立，开始从事项目工作，对不同的观点和意见不能采取合作和开放的态度；
C、规范norming—协同工作，按团队需要调整各自的工作习惯和行为，相互信任。（一起协同工作了，并调整各自不好的）
D、成熟performing—有序工作；相互依靠，平衡高效地解决问题；
E、解散adjourning—完成所有工作，团队成员离开项目。

建设团队的工具：

集中办公Colocation
把项目团队成员安排在同一个物理地点工作，也称为紧密矩阵、作战室War Room。张贴进度计划，增强团队工作能力、加强沟通、培养集体感。
团队建设 （Team Building）
旨在帮助各团队成员更加有效地协同工作。
培训
培训包括旨在提高项目团队成员能力的全部活动，可以是正式的或非正式的，可以是计划内也可以是计划外。
1）计划内培训：项目团队缺乏必要的管理和技术技能，应该按资源管理计划中的安排来实施预定的培训；
2）计划外培训：根据管理项目团队过程中的观察、交谈和项目绩效评估的结果，来开展必要的计划外培训。
建设项目团队的输出：

团队绩效评价
随着项目团队建设的开展，项目管理团队应对项目团队的有效性进行评价。评价指标可包括：
 个人技能的改进
 团队能力的改进
 团队成员离职率的降低
 团队凝聚力的加强
事业环境因素更新 ？？？
管理团队（关注团队成员）

定义：跟踪团队成员表现，提供反馈、解决问题，并协调各种变动，以便优化项目绩效。

管理团队的工具：

冲突管理
在项目环境中，冲突不可避免。冲突的来源很多，不一致的需求、对资源的竞争、技术意见、个性等等。

成员之间对需求的不一致意见引发冲突；
对资源的竞争引发冲突；
个性不同引发冲突
冲突处理顺序：
i. 首先依靠冲突者自己解决问题
ii. 自己解决不了，依靠PM去解决（5种冲突解决方法）
iii. 如果PM解决不了，只能再找他的直接领导协调解决

5种冲突解决优劣顺序排列：

合作/解决问题（面对）Collaborate/Problem Solve/Confronting：直面问题、引导各方达成共识，双方都满意；
妥协/调解Compromise/Reconcile：各退一步、双方一定程度上满意，比如去买东西时讨价还价，你说100，我说80，最后各退一步90成交；
缓和/包容Smooth/Accommodate：强调一致而非差异即求同存异、寻找共同点（有共同点）；
撤退/回避Withdraw/Avoid：从实际问题和冲突中退出，问题先不谈；
强迫/命令Force/Direct：利用权力来强行解决问题。（一般紧急情况使用）。
控制资源（只针对实物资源）

定义：确保按计划为项目分配实物资源，以及根据资源使用计划监督资源实际使用情况，并采取必要纠正措施的过程。
确保所分配的资源适时适地可用于项目。
与管理团队过程关注团队成员不同，控制资源过程关注实物资源。

PMP:5.项目范围管理
项目范围管理

项目范围管理包括确保项目做且只做所需的全部工作来自，以成功完成项目的各个过程。

管理项目范围主要在于定义和控制降夫易节图合量急哪些工作应该包括在项目散钢制预日六省屋然迅内，哪些不应该包括在项目内。

核心概念：

规划范围管理：为记录营洲如何定义、确认和控制项目范围及产品范围， 而创建范围管理计划的过程

在项目环境中，“掉决才范围”这一术语有两种含绝次太须卷集况冲误久烈义：

{

}

从预测型方法到适应型项府万害陈医或敏捷型方法， 项目生命周期可以处于这个连续区间内的任何位置。

在预测型生命周期中，在项目开始时就对项目可交付成果进行定义，对任何范围变化都要进行渐进管理。

在适应型或敏捷型生命周期中，通过多次迭代来开发可交付成果，并在每次迭代开始时定义和批准详细的范围。

采用适应型生似质儿掌是命周期， 旨在应对大量变更， 需要相关方持续参与项目；因此，应将适应型项目教育的整体范围分解为一系列拟实现的需求和拟执行的工笔算少歌鲁功响缺准还百作（有时称为产品未完项）。在一个迭代开始 时，团队将努力确定产品未完项中，哪些最优先项应在下一次迭代中交付。在每次迭代中，都会重 复开展三个过程：收集需求、定义范围和创建 WBS。

在预测型项目中，这些过程在项目开始时开展，并在必要时通过实施整体变更控制过程进行更新。

在适应型或敏捷型生命周期中，发起人和客户代表应该复广持续参与项目，随同可交付成果的创建提供反馈意见，并确保产品未完项反映他们的当前需求。在每次迭代中，都限测乎检然渐功多应放会重复开展两个过程：确认范围和控制范围。

在预测型项目中，确认范温矛找光只围在每个可交付成果生成时或者在阶段审查点开展，而控制范围则是一个持续性的过程。

在预测型项目中，经过批准的项目范围说国吃统虽理问明书、工作分解结构（WBS）和相应的 WBS 词典构占专切成项目范围基准。只有通过正式变更控制程序，才能进行基准变更。在开展确认范围、控制范围及其哪染矛市孙必发盟担他控制过程时，基准被用作比较的基础。

而采用适应型生命周期的项目，则使用未完项（包括产品需 求和用户故事）反映当前需求。

项目范围的完成情况是根据项目管理计划来衡量的， 而

产品范围的完成情况是根据产品程煤侵态需求来衡量的。在这里台国操迫，“需求”是指根据特定协沉矛步终衡垂议或其他强制性规范，产使则差室杨他令技品、服务或成果必须具备的条件或能力。

确认范围是正式验收已完成的项目可交付成果的过程。

从控制质量过程输出的核实的可交付成果是确认范围过程的输入，而验收的可交付成果是确认范围过程的输出之一，由获得授权的相关方正式签字批准。因此，相关方需要在规划阶段早期介入（有时需要在启动阶段就介入），对可交付成果的质量提出意见，以便控制质量过程能够据此评估绩效并提出必要的变更建议。

项目范围管理的发展趋势和新兴实践：

如何运用商业分析，通过定义、管理和控制需求活动来提高竞争优势。

商业分析活动可在项目启动和项目经理任命之前就开始。

{

}

裁剪时需要考虑的因素：

{

}

在敏捷或适应型环境中需要考虑的因素：

不断涌现的需求往往导致真实的业务需求 与最初所述的业务需求之间存在差异。

因此， 敏捷方法有目的地构建和审查原型， 并通过多次发布版本来明确需求。

这样一来，范围会在在整个项目期间被定义和再定义。

在敏捷方法中，把需求 列入未完项。

========================规划范围管理========================

规划范围管理是为记录如何定义、确认和控制项目范围及产品范围， 而创建范围管理计划的过程。

本过程的主要作用是， 在整个项目期间对如何管理范围提供指南和方向。

本过程仅开展一次或仅在项目的预定义点开展。

输入：

项目章程：

项目管理计划：

{

项目生命周期描述：项目生命周期定义了项目从开始到完成所经历的一系列阶段。

开发方法：开发方法定义了项目是采用瀑布式、迭代型、适应型、敏捷型还是混合型开发方法。

}

事业环境因素

{

uu组织文化；

uu基础设施；

uu人事管理制度；

uu市场条件。

}

组织过程资产

{

}

工具与技术：

家判断：

{

}

数据分析：

会议：

输出：

范围管理计划：范围管理计划是项目管理计划的组成部分， 描述将如何定义、制定、监督、控制和确认项目范围。根据项目需要，范围管理计划可以是正式或非正式的，非常详细或高度概括的。范围管理计划要对将用于下列工作的管理过程做出规定：

{

}

需求管理计划（“商业分析计划”）：需求管理计划是项目管理计划的组成部分， 描述将如何分析、记录和管理项目和产品需求：

{

}

========================收集需求========================

收集需求：为实现项目目标而确定、记录并管理相关方的需要和需求的过程。

本过程的主要作用是， 为定义产品范围和项目范围奠定基础，

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

需求是指根据特定协议或其他强制性规范，产品、服务或成果必须具备的条件或能力。

它包括发起人、客户和其他相关方的已量化且书面记录的需要和期望。

应该足够详细地探明、分析和记录这些需求，将其包含在范围基准中，并在项目执行开始后对其进行测量

需求将成为工作分解结 构（WBS）的基础，也将成为成本、进度、质量和采购规划的基础。

输入：

项目章程：

项目管理计划：

{

}

项目文件：

{

}

商业文件

{

}

协议：

事业环境因素：uu组织文化； uu基础设施； uu人事管理制度； uu市场条件。

组织过程资产：uu政策和程序； uu包含以往项目信息的历史信息和经验教训知识库。

工具与技术：

专家判断

{

}

数据收集

{

}

数据分析

{

}

决策：

{

}

数据表现：

{

}

人际关系与团队技能

{

}

系统交互图：系统交互图是范围模型的一个例子， 它是对产品范围的可视化描绘， 显示业务系统（过程、设 备、计算机系统等）及其与人和其他系统（行动者）之间的交互方式。系统交互图显示 了业务系统的输入、输入提供者、业务系统的输出和输出接收者。

原型法：原型是有形的实物，它使得相关方可以体验最终产品的模型，而不是仅限于讨论抽象的需求描述。原型法支持渐进明细的理念，需要经历从模型创建、用户体验、反馈收集到原型修改的反复循环过程。在经过足够的反馈 循环之后，就可以通过原型获得足够的需求信息，从而进入设计或制造阶段。

故事板是一种原型技术，通过一系列的图像或图示来展示顺序或导航路径。故事板用于各种行业 的各种项目中，如电影、广告、教学设计，以及敏捷和其他软件开发项目。在软件开发中，故事板使用实体模型来展示网页、屏幕或其他用户界面的导航路径。

输出

需求文件：描述各种单一需求将如何满足与项目相关的业务需求。

一开始可能只有高层级的需求， 然后随着有关需求信息的增加而逐步细化。

只有明确的（可测量和可测试的）、可跟踪的、完整的、相互协调的，且主要相关方愿意认可的需求，才能作为基准。

需求文件的格式多种多样，既可以是一份按相关方和优先级分类列出全部需求的简单文件，也可以是一份包括内容提要、细节描述和附件等的详细文件。

许多组织把需求分为不同的种类（相关方的需要）， 如业务解决方案和技术解决方案（指导需求实现）。

把需求分成不同的类别，有利于对需求进行进一步完善和细化。需求 的类别包括：

{

}

需求跟踪矩阵：把产品需求从其来源连接到能满足需求的可交付成果的一种表格。

使用需求跟踪 矩阵，把每个需求与业务目标或项目目标联系起来，有助于确保每个需求都具有商业价值。

需求跟踪矩阵提供了在整个项目生命周期中跟踪需求的一种方法，有助于确保需求文件中被批准的每项需求在项目结束的时候都能交付。

最后，需求跟踪矩阵还为管理产品范围变更提供了框架。

应在需求跟踪矩阵中记录每个需求的相关属性，这些属性有助于明确每个需求的关键信息。

需求跟踪矩阵中记录的典型属性包括唯一标识、需求的文字描述、收录该需求的理由、所有者、来源、 优先级别、版本、当前状态（如进行中、已取消、已推迟、新增加、已批准、被分配和已完成）和 状态日期。

为确保相关方满意，可能需要增加一些补充属性，如稳定性、复杂性和验收标准。

========================定义范围========================

定义范围：制定项目和产品详细描述的过程。

本过程的主要作用是，描述产品、服务或成果的边界和验收标准。

由于在收集需求过程中识别出的所有需求未必都包含在项目中，所以定义范围过程就要从需求文件（收集需求过程的输出）中选取最终的项目需求，然后制定出关于项目及其产品、服务或成果的详细描述。

应根据项目启动过程中记载的主要可交付成果、假设条件和制约因素来编制详细的项目范围说明书。

在项目规划过程中，随着对项目信息的更多了解，应该更加详细具体地定义和描述项目范围。

此外，还需要分析现有风险、假设条件和制约因素的完整性，并做必要的增补或更新。

需要多次反复开展定义范围过程：在迭代型生命周期的项目中，先为整个项目确定一个高层级的愿景，再一次针对一个迭代期明确详细范围。

通常，随着当前迭代期的项目范围和可交付成果的进展，而详细规划下一个迭代期的工作。

输入：

项目章程

项目管理计划:

{

}

项目文件:

{

}

事业环境因素：uu组织文化； uu基础设施； uu人事管理制度； uu市场条件。

组织过程资产:

{

}

工具与技术：

专家判断：

数据分析：

{

}

决策：

{

}

人际关系与团队技能：

{

}

产品分析：可用于定义产品和服务， 包括针对产品或服务提问并回答， 以描述要交付的产品的用途、特征及其他方面。每个应用领域都有一种或几种普遍公认的方法，用以把高层级的产品或服务描述转变为有意义的可交付成果。首先获取高层级的需求，然后将其细化到最终产品设计所需的详细程度。产品分析技术包括（但不限于）：

{

}

输出：

项目范围说明书：是对项目范围、主要可交付成果、假设条件和制约因素的描述。

它记录了整个范围，包括项目和产品范围；详细描述了项目的可交付成果；

还代表项目相关方之间就项目范围所达成的共识。

为便于管理相关方的期望，项目范围说明书可明确指出哪些工作不属于本项目范围。

项目范围说明书使项目团队能进行更详细的规划，在执行过程中指导项目团队的工作，并为评价变 更请求或额外工作是否超过项目边界提供基准。

项目范围说明书描述要做和不要做的工作的详细程度，决定着项目管理团队控制整个项目范围的有效程度。

详细的项目范围说明书包括以下内容（可能直接列出或参引其他文件）：

{

}

虽然项目章程和项目范围说明书的内容存在一定程度的重叠，但它们的详细程度完全不同。

项目章程包含高层级的信息，而项目范围说明书则是对范围组成部分的详细描述，这些组成部分需要在项目过程中渐进明细。

项目文件更新：

{

}

========================创建WBS========================

创建WBS：将项目可交付成果和项目工作分解为较小的、更易于管理的组件的过程。

本过程的主要作用是， 为所要交付的内容提供架构， 它仅开展一次或仅在项目的预定义点开展。

WBS是对项目团队为实现项目目标、创建所需可交付成果而需要实施的全部工作范围的层级分解。

WBS 组织并定义了项目的总范围，代表着经批准的当前项目范围说明书中所规定的工作。

WBS 最低层的组成部分称为工作包，其中包括计划的工作。

工作包对相关活动进行归类，以便对工作安排进度、进行估算、开展监督与控制。

在“工作分解结构”这个词语中，“工作”是指作为活动结果的工作产品或可交付成果，而不是活动本身。

输入：

项目管理计划：项目范围管理计划（范围管理计划定义了如何根据项目范围说明书创建 WBS。）

项目文件：

{

}

事业环境因素：包括（但不限于）项目所在行业的 WBS 标准，这些标准可以作为创建 WBS 的外部参考资料。

组织过程资产：uu用于创建 WBS 的政策、程序和模板； uu以往项目的项目档案； uu以往项目的经验教训。

工具与技术：

专家判断：

分解：

分解是一种把项目范围和项目可交付成果逐步划分为更小、更便于管理的组成部分的技术；

工作包是 WBS 最低层的工作，可对其成本和持续时间进行估算和管理。

分解的程度取决于所需的控制程 度，以实现对项目的高效管理；

工作包的详细程度则因项目规模和复杂程度而异。

要把整个项目工作分解为工作包，通常需要开展以下活动：

{

}

图 图 5-12 显示了某工作分解结构的一部分，其中若干分支已经向下分解到工作包层次。

对 WBS 较高层组件进行分解，就是要把每个可交付成果或组件分解为最基本的组成部分，即可核实的产品、服务或成果。

如果采用敏捷方法，可以将长篇故事分解成用户故事。

WBS 可以采用提纲式、组织结构图或能说明层级结构的其他形式。

通过确认 WBS 较低层组件是完成上层相应可交付成果的必要且充分的工作，来核实分解的正确性。

不同的可交付成果可以分解到不同的层次。

某些可 交付成果只需分解到下一层，即可到达工作包的层次，而另一些则须分解更多层。

工作分解得越细 致，对工作的规划、管理和控制就越有力。

但是，过细的分解会造成管理努力的无效耗费、资源使 用效率低下、工作实施效率降低，同时造成 WBS 各层级的数据汇总困难。

要在未来远期才完成的可交付成果或组件， 当前可能无法分解。

项目管理团队因而通常需要等待对该可交付成果或组成部分达成一致意见，才能够制定出 WBS 中的相应细节。这种技术有时称做滚动式规划。

WBS 包含了全部的产品和项目工作，包括项目管理工作。

通过把 WBS 底层的所有工作逐层向上汇总，来确保既没有遗漏的工作，也没有多余的工作。

这有时被称为 100% 规则。

输出：

范围基准：是经过批准的范围说明书、WBS 和相应的 WBS 词典，只有通过正式的变更控制程序才能 进行变更，它被用作比较的基础。范围基准是项目管理计划的组成部分，包括：

{

}

项目文件更新：

{

}

========================确认范围========================

确认范围：正式验收已完成的项目可交付成果的过程。

本过程的主要作用是，使验收过程具有客观性；

同时通过确认每个可交付成果，来提高最终产品、服务或成果获得验收的可能性。

本过程应 根据需要在整个项目期间定期开展。

由客户或发起人审查从控制质量过程输出的核实的可交付成果，确认这些可交付成果已经圆满完成并通过正式验收。

本过程对可交付成果的确认和最终验收，需要依据：从项目范围管理知识领域的各规划过程获得的输出（如需求文件或范围基准），以及从其他知识领域的各执行过程获得的工作绩效数据。

确认范围过程与控制质量过程的不同之处在于，前者关注可交付成果的验收，而后者关注可交付成果的正确性及是否满足质量要求。控制质量过程通常先于确认范围过程，但二者也可同时进行。

输入：

项目管理计划：

{

}

项目文件：

{

}

核实的可交付成果：核实的可交付成果是指已经完成，并被控制质量过程检查为正确的可交付成果。

工作绩效数据：工作绩效数据可能包括符合需求的程度、不一致的数量、不一致的严重性或在某时间段内开展确认的次数。

工具与技术：

检查：

指开展测量、审查与确认等活动，来判断工作和可交付成果是否符合需求和 产品验收标准。

检查有时也被称为审查、产品审查和巡检等。

在某些应用领域，这些术语具有独特 和具体的含义。

决策：投票（当由项目团队和其他相关方进行验收时，使用投票来形成结论。）

输出：

验收的可交付成果：

符合验收标准的可交付成果应该由客户或发起人正式签字批准。

应该从客户或发起人那里获得正式文件， 证明相关方对项目可交付成果的正式验收。

这些文件将提交给结束项目或阶段程序

工作绩效信息：工作绩效信息包括项目进展信息

需求变更：对已经完成但未通过正式验收的可交付成果及其未通过验收的原因，应该记录在案。可能需要针对这些可交付成果提出变更请求，开展缺陷补救。

项目文件更新：

{

}

========================控制范围========================

控制范围：监督项目和产品的范围状态，管理范围基准变更的过程。

本过程的主要作用是，在整 个项目期间保持对范围基准的维护，且需要在整个项目期间开展。

控制项目范围确保所有变更请求、推荐的纠正措施或预防措施都通过实施整体变更控制过程进行处理。

在变更实际发生时，也要采用控制范围过程来管理这些变更。

控制范围过程应该与其他控制过程协调开展。

未经控制的产品或项目范围的扩大（未对时间、成本和资源做相应调整）被称为范围蔓延。

变更不可避免，因此在每个项目上，都必须强制实施某种形式的变更控制。

输入：

项目管理计划：

{

}

项目文件：

{

}

工作绩效数据：

组织过程资产：

{

}

工具与技术：

数据分析：确定偏离范围基准的原因和程度，并决定是否需要采取纠正或预防措施，是项目范围控制的重要工作。

{

}

输出：

工作绩效信息：

本过程产生的工作绩效信息是有关项目和产品范围实施情况（对照范围基准）的、相互关联且与各种背景相结合的信息，包括收到的变更的分类、识别的范围偏差和原因、偏差对进度和成本的影响，以及对将来范围绩效的预测。

变更请求：分析项目绩效后，可能会就范围基准和进度基准，或项目管理计划的其他组成部分 提出变更请求。

项目管理计划更新：

{

}

项目文件更新：

{

}