pmp项目需求变更

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 词典，只有通过正式的变更控制程序才能 进行变更，它被用作比较的基础范围基准是项目管理计划的组成部分，包括：

{

}

项目文件更新：

{

}

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

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

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

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

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

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

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

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

输入：

项目管理计划：

{

}

项目文件：

{

}

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

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

工具与技术：

检查：

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

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

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

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

输出：

验收的可交付成果：

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

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

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

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

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

项目文件更新：

{

}

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

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

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

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

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

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

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

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

输入：

项目管理计划：

{

}

项目文件：

{

}

工作绩效数据：

组织过程资产：

{

}

工具与技术：

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

{

}

输出：

工作绩效信息：

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

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

项目管理计划更新：

{

}

项目文件更新：

{

}

pmp正式项目验收后,可以提变更吗首先所有的项目都应当做好充分的准备迎接变更，响应变更，这个是一定的
但至于如何处理这样的变更，这个问题就没有标准答案了，要看组织项目管理的具体流程要求了
一般情况下，项目验收交付一段时间后，还会有一个并短暂的保障期，这个保障期一般会写在客户合同或服务协议中在这个保障期内，提交变更还是正常的，毕竟这时调集资源还是方便的，可以将成本算在原项目中但是，过了这个保障期，就要看项目组性质了，如果是职能型组织的方式，项目组可能都解散了，那么可能就要将变更升级为项目需求按新项目流程走；或升级为运营问题，按运营问题走如果是项目式组织的方式，项目组可能会长期存在，项目成本中心一直不撤销，那么按变更形成一些工作量也不是不可以
建议验收后的变更尽量按新项目开展原因一，如果项目刚验收，说明项目的成果用户还在熟悉或学习使用的过程中，很多变更的提出都是流程变化引起的不适导致的，可能过一段时间就不存在了原因二，如果项目管理过程很标准，项目管理也代表组织的项目财务管理的比较标准，那么如果一个项目都已经验收了，项目的控制账户就应该临近收尾或关闭了，这时如果再频繁的引起财务账变动，那么从财务角度项目就一直没有完成其实作为项目经理要充分掌握项目成本，到底能够承受多大多少变更，要有一个清晰的概念在验收后的保障期内，可以考虑动用一点应急储备（可能是预留的资金人员时间软硬件设施等）完成一些工作，但是不能太多

pmp 只要有变更就会变更请求么需要分清楚，变更日志和变更请求
只要有人提出变更，那就要记录进变更日志，但是只有审批（经过变更控制委员会审批）过的变更才能提交变更请求