分解是一种把项目范围和项目可交付成果逐步划分为更小、更便于管理的组成部分的技术;工作包是 WBS 最低层的工作,可对其成本和持续时间进行估算和管理。分解的程度取决于所需的控制程度,以实现对项目的高效管理;工作包的详细程度则因项目规模和复杂程度而异。要把整个项目工作分解为工作包,通常需要开展以下活动:
图 5-12 显示了某工作分解结构的一部分,其中若干分支已经向下分解到工作包层次。
图 5-12分解到工作包的 WBS 示例
创建 WBS 的方法多种多样,常用的方法包括自上而下的方法、使用组织特定的指南和使用 WBS模板。自下而上的方法可用于归并较低层次组件。WBS 的结构可以采用多种形式,例如:
图 5-13 WBS 示例:以阶段作为第二层
图 5-14 WBS 示例:以主要可交付成果作为第二层
对 WBS 较高层组件进行分解,就是要把每个可交付成果或组件分解为最基本的组成部分,即可核实的产品、服务或成果。如果采用敏捷方法,可以将长篇故事分解成用户故事。WBS 可以采用提纲式、组织结构图或能说明层级结构的其他形式。通过确认 WBS 较低层组件是完成上层相应可交付成果的必要且充分的工作,来核实分解的正确性。不同的可交付成果可以分解到不同的层次。某些可交付成果只需分解到下一层,即可到达工作包的层次,而另一些则须分解更多层。工作分解得越细致,对工作的规划、管理和控制就越有力。但是,过细的分解会造成管理努力的无效耗费、资源使用效率低下、工作实施效率降低,同时造成 WBS 各层级的数据汇总困难。
要在未来远期才完成的可交付成果或组件,当前可能无法分解。项目管理团队因而通常需要等待对该可交付成果或组成部分达成一致意见,才能够制定出 WBS 中的相应细节。这种技术有时称做滚动式规划。
WBS 包含了全部的产品和项目工作,包括项目管理工作。通过把 WBS 底层的所有工作逐层向上汇总,来确保既没有遗漏的工作,也没有多余的工作。这有时被称为 100% 规则。
关于 WBS 的详细信息,可参考《工作分解结构实践标准》(第 2 版)[15]。该标准列举了一些具体行业的 WBS 模板,可以在裁剪后应用于特定领域的具体项目。
项目阶段是一组具有逻辑关系的项目活动的集合,通常以一个或多个可交付成果的完成为结束。
生命周期的各个阶段可以通过各种不同的属性来描述。对于特定阶段,属性是可测量且独特的。属性可能包括(但不限于):
项目可以分解为不同的阶段或子组件,这些阶段或子组件的名称通常说明了该阶段完成的工作类型。阶段名称的例子包括(但不限于):
项目阶段可基于各种因素而建立,其中包括(但不限于):
分为多个阶段的方式有助于更好地掌控项目管理,同时还提供了评估项目绩效并在后续阶段采取必要的纠正或预防措施的机会。项目阶段的其中一个关键组成部分是阶段审查(见 1.2.4.3 节)。
项目所处的环境可能对项目的开展产生有利或不利的影响。这些影响的两大主要来源为事业环境因素 (EEF) 和组织过程资产 (OPA)。
事业环境因素源于项目外部(往往是企业外部)的环境,事业环境因素可能对整个企业、项目组合、项目集或项目产生影响。关于事业环境因素的更多信息,请参见 2.2 节。
组织过程资产源于企业内部,可能来自企业自身、项目组合、项目集、其他项目或这些的组合。
图 2-1 分解了事业环境因素和组织过程资产所涵盖的项目影响。关于组织过程资产的更多信息,请参
见 2.3 节。
图 2-1项目影响
除了事业环境因素和组织过程资产,组织系统对项目生命周期也起着重要的作用。组织系统(见2.4 节)进一步讨论了影响了组织系统内部人员的权力、影响力、利益、技能和政治能力的系统因素。
项目管理计划是说明项目执行、监控和收尾方式的一份文件,它整合并综合了所有子管理计划和基准,以及管理项目所需的其他信息。究竟需要哪些项目管理计划组件,取决于具体项目的需求。
项目管理计划组件包括(但不限于):
虽然在本过程生成的组件会因项目而异,但是通常包括(但不限于):
项目管理计划是用于管理项目的主要文件之一。管理项目时还会使用其他项目文件。这些其他文件不属于项目管理计划,但它们也是实现高效管理所必需的文件。表 4-1 列出了主要的项目管理计划组件和项目文件。
表 4-1项目管理计划和项目文件
可作为本过程输入的项目文件包括(但不限于):
项目范围管理包括确保项目做且只做所需的全部工作,以成功完成项目的各个过程。管理项目范围主要在于定义和控制哪些工作应该包括在项目内,哪些不应该包括在项目内。
项目范围管理过程包括:
5.1 规划范围管理 — 为记录如何定义、确认和控制项目范围及产品范围,而创建范围管理计划的过程。
5.2 收集需求 — 为实现项目目标而确定、记录并管理相关方的需要和需求的过程。
5.3 定义范围 — 制定项目和产品详细描述的过程。
5.4 创建 WBS — 将项目可交付成果和项目工作分解为较小的、更易于管理的组件的过程。
5.5 确认范围 — 正式验收已完成的项目可交付成果的过程。
5.6 控制范围 — 监督项目和产品的范围状态,管理范围基准变更的过程。
图 5-1 概括了项目范围管理的各个过程。虽然各项目范围管理过程以界限分明、相互独立的形式出
现,但在实践中它们会以《PMBOK® 指南》无法全面叙述的方式相互交叠、相互作用。
图 5-1项目范围管理概述
项目范围管理的核心概念在项目环境中,“范围”这一术语有两种含义:
从预测型方法到适应型或敏捷型方法,项目生命周期可以处于这个连续区间内的任何位置。在预测型生命周期中,在项目开始时就对项目可交付成果进行定义,对任何范围变化都要进行渐进管理。而在适应型或敏捷型生命周期中,通过多次迭代来开发可交付成果,并在每次迭代开始时定义和批准详细的范围。
采用适应型生命周期,旨在应对大量变更,需要相关方持续参与项目;因此,应将适应型项目的整体范围分解为一系列拟实现的需求和拟执行的工作(有时称为产品未完项)。在一个迭代开始时,团队将努力确定产品未完项中,哪些最优先项应在下一次迭代中交付。在每次迭代中,都会重复开展三个过程:收集需求、定义范围和创建 WBS。相反,在预测型项目中,这些过程在项目开始时开展,并在必要时通过实施整体变更控制过程进行更新。
在适应型或敏捷型生命周期中,发起人和客户代表应该持续参与项目,随同可交付成果的创建提供反馈意见,并确保产品未完项反映他们的当前需求。在每次迭代中,都会重复开展两个过程:确认范围和控制范围。相反,在预测型项目中,确认范围在每个可交付成果生成时或者在阶段审查点开展,而控制范围则是一个持续性的过程。
在预测型项目中,经过批准的项目范围说明书、工作分解结构(WBS)和相应的 WBS 词典构成项目范围基准。只有通过正式变更控制程序,才能进行基准变更。在开展确认范围、控制范围及其他控制过程时,基准被用作比较的基础。而采用适应型生命周期的项目,则使用未完项(包括产品需求和用户故事)反映当前需求。
项目范围的完成情况是根据项目管理计划来衡量的,而产品范围的完成情况是根据产品需求来衡量的。在这里,“需求”是指根据特定协议或其他强制性规范,产品、服务或成果必须具备的条件或能力。
确认范围是正式验收已完成的项目可交付成果的过程。从控制质量过程输出的核实的可交付成果是确认范围过程的输入,而验收的可交付成果是确认范围过程的输出之一,由获得授权的相关方正式签字批准。因此,相关方需要在规划阶段早期介入(有时需要在启动阶段就介入),对可交付成果的质量提出意见,以便控制质量过程能够据此评估绩效并提出必要的变更建议。
目范围管理的发展趋势和新兴实践需求一直是项目管理中的重点,并且还将继续得到项目管理从业者的更多关注。随着全球环境变得日益复杂,组织开始认识到如何运用商业分析,通过定义、管理和控制需求活动来提高竞争优势。商业分析活动可在项目启动和项目经理任命之前就开始。根据《需求管理:实践指南》[14],需求管理过程始于需要评估,而需要评估又可能始于项目组合规划、项目集规划或单个项目。
在项目范围管理过程中,收集、记录和管理相关方需求。项目范围管理的范围趋势和新兴实践包括(但不限于)注重与商业分析专业人士的合作,以便:
需求管理过程结束于需求关闭,即把产品、服务或成果移交给接收方,以便长期测量、监控、实现和维持效益。
应该将商业分析的角色连同职责分配给具有足够商业分析技能和专业知识的人员。如果项目已配备商业分析师,那么,与需求管理相关的活动便是该角色的职责。而项目经理则负责确保这些活动在项目管理计划有所安排,并且在预算内按时完成,同时能够创造价值。
项目经理与商业分析师之间应该是伙伴式合作关系。如果项目经理和商业分析师能够理解彼此在促进项目目标实现过程中的角色和职责,项目成功的可能性就更大。
裁剪时需要考虑的因素因为每个项目都是独特的,所以项目经理需要裁剪项目范围管理过程。裁剪时应考虑的因素包括(但不限于):
在敏捷或适应型环境中需要考虑的因素对于需求不断变化、风险大或不确定性高的项目,在项目开始时通常无法明确项目的范围,而需要在项目期间逐渐明确。敏捷方法特意在项目早期缩短定义和协商范围的时间,并为持续探索和明确范围而延长创建相应过程的时间。在许多情况下,不断涌现的需求往往导致真实的业务需求与最初所述的业务需求之间存在差异。因此,敏捷方法有目的地构建和审查原型,并通过多次发布版本来明确需求。这样一来,范围会在在整个项目期间被定义和再定义。在敏捷方法中,把需求列入未完项。
收集需求是为实现目标而确定、记录并管理相关方的需要和需求的过程。本过程的主要作用是,为定义产品范围和项目范围奠定基础,且仅开展一次或仅在项目的预定义点开展。图 5-4 描述本过程的输入、工具与技术和输出。图 5-5 是本过程的数据流向图。
图 5-4收集需求:输入、工具与技术和输出
图 5-5收集需求:数据流向图
《PMBOK® 指南》并没有专门讨论产品需求,因为产品需求因行业而异。《从业者商业分析:
实践指南》[7] 提供了有关产品需求的更深入信息。让相关方积极参与需求的探索和分解工作(分解成项目和产品需求),并仔细确定、记录和管理对产品、服务或成果的需求,能直接促进项目成功。需求是指根据特定协议或其他强制性规范,产品、服务或成果必须具备的条件或能力。它包括发起人、客户和其他相关方的已量化且书面记录的需要和期望。应该足够详细地探明、分析和记录这些需求,将其包含在范围基准中,并在项目执行开始后对其进行测量。需求将成为工作分解结构(WBS)的基础,也将成为成本、进度、质量和采购规划的基础。
产品分析可用于定义产品和服务,包括针对产品或服务提问并回答,以描述要交付的产品的用途、特征及其他方面。
每个应用领域都有一种或几种普遍公认的方法,用以把高层级的产品或服务描述转变为有意义的可交付成果。首先获取高层级的需求,然后将其细化到最终产品设计所需的详细程度。产品分析技术包括(但不限于):
创建工作分解结构(WBS)是把项目可交付成果和项目工作分解成较小、更易于管理的组件的过程。本过程的主要作用是,为所要交付的内容提供架构,它仅开展一次或仅在项目的预定义点开展。图 5-10 描述本过程的输入、工具与技术和输出。图 5-11 是本过程的数据流向图。
图 5-10创建 WBS:输入、工具与技术和输出
图 5-11创建 WBS:数据流向图
WBS 是对项目团队为实现项目目标、创建所需可交付成果而需要实施的全部工作范围的层级分解。
WBS 组织并定义了项目的总范围,代表着经批准的当前项目范围说明书中所规定的工作。
WBS 最低层的组成部分称为工作包,其中包括计划的工作。工作包对相关活动进行归类,以便对工作安排进度、进行估算、开展监督与控制。在“工作分解结构”这个词语中,“工作”是指作为活动结果的工作产品或可交付成果,而不是活动本身。
范围基准是经过批准的范围说明书、WBS 和相应的 WBS 词典,只有通过正式的变更控制程序才能进行变更,它被用作比较的基础。范围基准是项目管理计划的组成部分,包括:
进度管理计划是项目管理计划的组成部分,为编制、监督和控制项目进度建立准则和明确活动。
根据项目需要,进度管理计划可以是正式或非正式的,非常详细或高度概括的,其中应包括合适的控制临界值。
进度管理计划会规定:
定义活动是识别和记录为完成项目可交付成果而须采取的具体行动的过程。本过程的主要作用是,将工作包分解为进度活动,作为对项目工作进行进度估算、规划、执行、监督和控制的基础。
本过程需要在整个项目期间开展。图 6-5 描述本过程的输入、工具与技术和输出,图 6-6 是本过程的数据流程图。
图 6-5定义活动:输入、工具与技术和输出
图 6-6定义活动:数据流程图
滚动式规划是一种迭代式的规划技术,即详细规划近期要完成的工作,同时在较高层级上粗略规划远期工作。它是一种渐进明细的规划方式,适用于工作包、规划包以及采用敏捷或瀑布式方法的发布规划。因此,在项目生命周期的不同阶段,工作的详细程度会有所不同。在早期的战略规划阶段,信息尚不够明确,工作包只能分解到已知的详细水平;而后,随着了解到更多的信息,近期即将实施的工作包就可以分解到具体的活动。
可作为本过程输入的项目文件包括(但不限于):
项目团队可能会召开会议来估算活动持续时间。如果采用敏捷方法,则有必要举行冲刺或迭代计划会议,以讨论按优先级排序的产品未完项(用户故事),并决定团队在下一个迭代中会致力于解决哪个未完项。然后团队将用户故事分解为按小时估算的底层级任务,然后根据团队在持续时间(迭代)方面的能力确认估算可行。该会议通常在迭代的第一天举行,参会者包括产品负责人、开发团队和项目经理,会议结果包括迭代未完项、假设条件、关注事项、风险、依赖关系、决定和行动。
成本管理计划是项目管理计划的组成部分,描述将如何规划、安排和控制项目成本。成本管理过程及其工具与技术应记录在成本管理计划中。
例如,在成本管理计划中规定:
关于挣值管理的更多信息,参见《挣值管理实践标准》(第 2 版)[17]。
见 4.2.3.1 节。项目管理计划组件包括(但不限于):
适用于控制成本过程的数据分析技术包括(但不限于):
EV 常用于计算项目的完成百分比,应该为每个 WBS 组件规定进展测量准则,用于考核正在实施的工作。项目经理既要监测 EV 的增量,以判断当前的状态,又要监测 EV 的累计值,以判断长期的绩效趋势。
它是指在某个给定的时点,项目提前或落后的进度,它是测量项目进度绩效的一种指标,等于挣值(EV)减去计划价值(PV)。EVA 进度偏差是一种有用的指标,可表明项目进度是落后还是提前于进度基准。当项目完工时,全部的计划价值都将实现(即成为挣值),所以 EVA 进度偏差最终将等于零。最好把进度偏差与关键路径法 (CPM) 和风险管理一起使用。
公式:SV = EV – PV。
项目结束时的成本偏差,就是完工预算(BAC)与实际成本之间的差值。由于成本偏差指明了实际绩效与成本支出之间的关系,所以非常重要。负的 CV 一般都是不可挽回的。公式:CV = EV – AC。
图 7-12挣值、计划价值和实际成本
预测要根据项目执行过程中所提供的工作绩效数据(见 4.3.3.2 节)来产生、更新和重新发布。工作绩效信息包含项目过去的绩效,以及可能在未来对项目产生影响的任何信息。
在计算 EAC 时,通常用已完成工作的实际成本,加上剩余工作的完工尚需估算(ETC)。
项目团队要根据已有的经验,考虑实施 ETC 工作可能遇到的各种情况。把挣值分析与手工预测 EAC 方法联合起来使用,效果会更佳。由项目经理和项目团队手工进行的自下而上汇总方法,就是一种最普通的 EAC 预测方法。
项目经理所进行的自下而上的 EAC 估算,就是以已完成工作的实际成本为基础,并根据已积累的经验来为剩余项目工作编制一个新估算。公式:EAC = AC + 自下而上的 ETC。
可以很方便地把项目经理手工估算的 EAC 与计算得出的一系列 EAC 作比较,这些计算得出的EAC 代表了不同的风险情景。在计算 EAC 值时,经常会使用累计 CPI 和累计 SPI 值。尽管可以用许多方法来计算基于 EVM 数据的 EAC 值,但下面只介绍最常用的三种方法:
mm假设将按预算单价完成 ETC 工作。这种方法承认以实际成本表示的累计实际项目绩效(不论好坏),并预计未来的全部 ETC 工作都将按预算单价完成。如果目前的实际绩效不好,则只有在进行项目风险分析并取得有力证据后,才能做出“未来绩效将会改进”的假设。
公式:EAC = AC +(BAC – EV)。
mm假设以当前 CPI 完成 ETC 工作。这种方法假设项目将按截至目前的情况继续进行,即 ETC工作将按项目截至目前的累计成本绩效指数(CPI)实施。公式:EAC = BAC/CPI。
mm假设 SPI 与 CPI 将同时影响 ETC 工作。在这种预测中,需要计算一个由成本绩效指数与进度绩效指数综合决定的效率指标,并假设 ETC 工作将按该效率指标完成。如果项目进度对 ETC 有重要影响,这种方法最有效。使用这种方法时,还可以根据项目经理的判断,分别给 CPI 和 SPI 赋予不同的权重,如 80/20、50/50 或其他比率。公式:EAC =AC +[(BAC – EV)/(CPI x SPI)]。
如果已识别的风险没有发生,就可能要从项目预算中扣除未使用的应急储备,为其他项目或运营腾出资源。同时,在项目中开展进一步风险分析,可能会发现需要为项目预算申请额外的储备。
适用于本过程的数据表现技术包括(但不限于):
图 8-9因果图
适用于本过程的数据表现技术包括(但不限于)图表。数据表现有多种格式来记录和阐明团队成员的角色与职责。大多数格式属于层级型、矩阵型或文本型。有些项目人员安排可以在子计划(如风险、质量或沟通管理计划)中列出。无论使用什么方法来记录团队成员的角色,目的都是要确保每个工作包都有明确的责任人,确保全体团队成员都清楚地理解其角色和职责。层级型可用于表示高层级角色,而文本型则更适合用于记录详细职责。
图 9-4 RACI 矩阵示例
见 4.3.2.2 节。项目管理信息系统可以包括资源管理软件,这些软件有助于规划、组织与管理资源库,以及编制资源估算。根据软件的复杂程度,可以确定资源分解结构、资源可用性、资源费率和各种资源日历,有助于优化资源使用。
资源分解结构是资源依类别和类型的层级展现(见图 9-7)。资源类别包括(但不限于)人力、材料、设备和用品,资源类型则包括技能水平、要求证书、等级水平或适用于项目的其他类型。在规划资源管理过程中,资源分解结构用于指导项目的分类活动。在这一过程中,资源分解结构是一份完整的文件,用于获取和监督资源。
图 9-7资源分解结构示例
可在本过程更新的项目文件包括(但不限于):
适用于本过程的人际关系与团队技能包括(但不限于):
成功的冲突管理可提高生产力,改进工作关系。同时,如果管理得当,意见分歧有利于提高创造力和改进决策。假如意见分歧成为负面因素,应该首先由项目团队成员负责解决;如果冲突升级,项目经理应提供协助,促成满意的解决方案,采用直接和合作的方式,尽早并且通常在私下处理冲突。如果破坏性冲突继续存在,则可使用正式程序,包括采取惩戒措施。
项目经理解决冲突的能力往往决定其管理项目团队的成败。不同的项目经理可能采用不同的解决冲突方法。影响冲突解决方法的因素包括:
有五种常用的冲突解决方法,每种技巧都有各自的作用和用途。
mm撤退/回避。从实际或潜在冲突中退出,将问题推迟到准备充分的时候,或者将问题推给其他人员解决。
mm缓和/包容。强调一致而非差异;为维持和谐与关系而退让一步,考虑其他方的需要。
mm妥协/调解。为了暂时或部分解决冲突,寻找能让各方都在一定程度上满意的方案,但这种方法有时会导致“双输”局面。
mm强迫/命令。以牺牲其他方为代价,推行某一方的观点;只提供赢 — 输方案。通常是利用权力来强行解决紧急问题,这种方法通常会导致“赢输”局面。
mm合作/解决问题。综合考虑不同的观点和意见,采用合作的态度和开放式对话引导各方达成共识和承诺,这种方法可以带来双赢局面。
有多种领导力理论,定义了适用于不同情形或团队的领导风格。领导力对沟通愿景及鼓舞项目团队高效工作十分重要。
可作为本过程输入的项目文件包括(但不限于):
见 8.2.2.7 节。问题解决可能会用到一系列工具,有助于项目经理解决控制资源过程中出现的问题。问题可能来自组织内部(组织中另一部门使用的机器或基础设施未及时释放,因存储条件不当造成材料受损等)或来自组织外部(主要供应商破产或恶劣天气使资源受损)。项目经理应采取有条不紊的步骤来解决问题,包括:
可在本过程更新的项目文件包括(但不限于):
会影响规划风险管理过程的组织过程资产包括(但不限于):
风险管理计划是项目管理计划的组成部分,描述如何安排与实施风险管理活动。风险管理计划可包括以下部分或全部内容:
图 11-4风险分解结构(RBS)示例
通过将影响定义为负面威胁(工期延误、成本增加和绩效不佳)和正面机会(工期缩短、成本节约和绩效改善),表格所示的量表可同时用于评估威胁和机会。
表 11-1概率和影响定义示例
图 11-5 是概率和影响矩阵的示例,其中也有数值风险评分的可能方法。
图 11-5概率和影响矩阵示例(有评分方法)
见 4.2.3.1 节。项目管理计划组件包括(但不限于):
还包括工作分解结构,可用作安排风险识别工作的框架。
适用于本过程的数据收集技术包括(但不限于):
提示清单是关于可能引发单个项目风险以及可作为整体项目风险来源的风险类别的预设清单。在采用风险识别技术时,提示清单可作为框架用于协助项目团队形成想法。可以用风险分解结构底层的风险类别作为提示清单,来识别单个项目风险。某些常见的战略框架更适用于识别整体项目风险的来源,如 PESTLE(政治、经济、社会、技术、法律、环境)、TECOP(技术、环境、商业、运营、政治),或 VUCA(易变性、不确定性、复杂性、模糊性)
见 4.2.3.1 节。项目管理计划组件包括风险管理计划(见 11.1.3.1 节)。本过程中需要特别注意的是风险管理的角色和职责、预算和进度活动安排,以及风险类别(通常在风险分解结构中定义)、概率和影响定义、概率和影响矩阵和相关方的风险临界值。通常已经在规划风险管理过程中把这些内容裁剪成适合具体项目的需要。如果还没有这些内容,则可以在实施定性风险分析过程中编制,并经项目发起人批准之后用于本过程。
项目风险可依据风险来源(如采用风险分解结构 [RBS],见图 11-4)、受影响的项目领域(如采用工作分解结构 [WBS],见图 5-12、5-13 和 5-14),以及其他实用类别(如项目阶段、项目预算、角色和职责)来分类,确定哪些项目领域最容易被不确定性影响;风险还可以根据共同的根本原因进行分类。应该在风险管理计划中规定可用于项目的风险分类方法。
对风险进行分类,有助于把注意力和精力集中到风险敞口最大的领域,或针对一组相关的风险制定通用的风险应对措施,从而有利于更有效地开展风险应对。
可在本过程更新的组织过程资产包括(但不限于):
项目管理计划的任何变更都以变更请求的形式提出,且通过组织的变更控制过程进行处理。可能需要变更的项目管理计划组件包括(但不限于):
创建工作分解结构 (WBS) 是把项目可交付成果和项目工作分解为较小的、更易于管理的组件的过程。本过程的主要作用是,为所要交付的内容提供架构。本过程仅开展一次或仅在项目的预定义点开展。图 3-6 描述了本过程的输入和输出。
图 3-6创建 WBS:输入和输出
究竟需要哪些项目管理计划组件和项目文件,取决于具体项目的需求。
定义活动是识别和记录为完成项目可交付成果而须采取的具体行动的过程。本过程的主要作用是,将工作包分解为进度活动,作为对项目工作进行进度估算、规划、执行、监督和控制的基础。
本过程需要在整个项目期间开展。图 3-8 描述了本过程的输入和输出。
图 3-8定义活动:输入和输出
究竟需要哪些项目管理计划组件,取决于具体项目的需求。
可用作本过程输入的项目文件包括(但不限于):
可用作本过程输入的项目文件包括(但不限于):
可在本过程更新的项目文件包括(但不限于):
可用作本过程输入的项目文件包括(但不限于):
可在本过程更新的项目文件包括(但不限于):
适应型项目往往可分解为一系列先后顺序进行的、被称为“迭代期”的阶段。在每个迭代期都要利用相关的项目管理过程。这些迭代期构成了可预测、时间固定、预先商定、连贯和有助于制定进度计划的时段节拍。
重复开展项目管理过程组会产生管理费用。为了有效管理高度复杂且充满不确定性和变更的项目,这种管理费用是必要的。在基于迭代的各个阶段,所需的投入水平,见图 X3-2 所示。
图 X3-2跨迭代周期的过程组重复开展所需的投入水平