Index

第二部分 项目管理标准 / 1 引论 / 1.5 项目生命周期
post_title:项目生命周期
post_content:

项目生命周期项目从开始到完成所经历的一系列阶段。项目阶段是一组具有逻辑关系的项目活动的集合,通常以一个或多个可交付成果的完成为结束。这些阶段之间可能是顺序、迭代或交叠的关系。项目阶段的名称、数量和持续时间取决于参与项目的一个或多个组织的管理与控制需要、项目本身的特征及其所在的应用领域。阶段都有时限,有一个起始点、结束点或控制点(有时称为阶段审查、阶段关口或控制关口,也可以用其他类似名称)。在控制点,需要根据当前环境,重新审查项目章程商业文件。在该时点,把项目绩效与项目管理计划进行比较,以确定项目是否应该变更、终止或按计划继续。

项目生命周期会受组织行业、开发方法或所用技术的独特性质的影响。虽然每个项目都有起点和终点,但具体的可交付成果及工作会因项目的不同而有很大差异。不论项目涉及的具体工作是什么,生命周期都可以为管理项目提供基本框架。

虽然项目规模及复杂程度各不相同,但是典型项目都呈现下列项目生命周期结构(见图 1-2):

图 1-2项目生命周期的通用结构

通用的生命周期结构一般具有以下特征:

  • 成本与人力投入在开始时较低,在工作执行期间逐渐增加,并在项目快要结束时迅速回落。
  • 项目开始时风险最大,如图 1-3 所示。在项目的整个生命周期中,随着决策的制定与可交付成果的验收,风险会逐步降低。
  • 在不显著影响成本和进度的前提下,相关方改变项目产品最终特性的能力在项目开始时最大,并随项目进展而减弱。图 1-3 表明,做出变更和纠正错误的成本,通常会随着项目越来越接近完成而显著增高。

图 1-3随时间而变化的变量影响


ID:74
areaid:0
groupid:0
type:
post_name: 1
post_title: 引论
post_excerpt: 第一部分 项目管理知识体系指南 / 1 引论
post_content:

标准是基于权威、惯例或共识而建立并用作模式或范例的文件。本标准的开发过程遵循协商一致、开放公开、程序公正和各方平衡的基本原则。本标准描述在大多数时候适用于大多数项目的、被视为良好实践的过程,并把这些过程归入相应的过程组。本标准也对关键的项目管理概念进行定义,包括项目管理与组织战略及目标的关系,项目管理与组织治理、项目组合管理、项目集管理、项目环境及项目成功之间的关系。本标准还介绍项目生命周期、项目相关方,以及项目经理的角色。第 1 章介绍一些基本概念,并提供有关项目管理的背景信息。第 2 章至第 6 章对五大过程组进行逐一定义,并描述其下属过程。第 2 章至第 6 章还描述各项目管理过程的主要作用、输入和输出。本标准将作为《项目管理知识体系指南》(《PMBOK® 指南》)1 的基础和框架。《PMBOK® 指南》通过对相关背景、环境及其对项目管理的影响进行更深入的阐述,来扩展本标准的内容。此外,《PMBOK® 指南》也描述项目管理过程的输入和输出,识别项目管理过程的工具和技术,并按知识领域讨论一些重要概念和新趋势。


ID:90
areaid:0
groupid:0
type:
post_name: 1.2.4.1
post_title: 项目和开发生命周期
post_excerpt: 第一部分 项目管理知识体系指南 / 1 引论 / 1.2 基本要素 / 1.2.4 指南的组成部分 / 1.2.4.1 项目和开发生命周期
post_content:

项目生命周期指项目从启动到完成所经历的一系列阶段。它为项目管理提供了一个基本框架。不论项目涉及的具体工作是什么,这个基本框架都适用。这些阶段之间的关系可以顺序、迭代或交叠进行。所有项目都呈现图 1-5 所示的通用的生命周期。

项目生命周期可以是预测型或适应型。项目生命周期内通常有一个或多个阶段与产品、服务或成果的开发相关,这些阶段称为开发生命周期。开发生命周期可以是预测型、迭代型、增量型、适应型或混合型的模式:

由项目管理团队确定各个项目最适合的生命周期。项目生命周期需要足够灵活,能够应对项目包含的各种因素。可以通过以下方法实现生命周期的灵活性:

项目生命周期与产品生命周期相互独立,后者可能由项目产生。产品生命周期指一个产品从概念、交付、成长、成熟到衰退的整个演变过程的一系列阶段。


ID:93
areaid:0
groupid:0
type:
post_name: 1.2.4.4
post_title: 项目管理过程
post_excerpt: 第一部分 项目管理知识体系指南 / 1 引论 / 1.2 基本要素 / 1.2.4 指南的组成部分 / 1.2.4.4 项目管理过程
post_content:

项目生命周期是通过一系列项目管理活动进行的,即项目管理过程。每个项目管理过程通过合适的项目管理工具和技术将一个或多个输入转化成一个或多个输出。输出可以是可交付成果或结果。

结果是过程的最终成果。项目管理过程适用于全球各个行业。

各项目管理过程通过它们所产生的输出建立逻辑联系。过程可能包含了在整个项目期间相互重叠的活动。一个过程的输出通常成为以下二者之一:

图 1-6 的示例说明了一个过程的输入、工具、技术和输出的关系以及与其他过程的关系。

图 1-6过程示例:输入、工具与技术和输出

过程迭代的次数和过程间的相互作用因具体项目的需求而不同。过程通常分为三类:

项目管理通过合理运用与整合按逻辑分组的项目管理过程而得以实现。过程分类方法有很多种,但《PMBOK® 指南》把过程归纳为五大类,即五大过程组。


ID:96
areaid:0
groupid:0
type:
post_name: 1.2.4.7
post_title: 项目管理数据和信息
post_excerpt: 第一部分 项目管理知识体系指南 / 1 引论 / 1.2 基本要素 / 1.2.4 指南的组成部分 / 1.2.4.7 项目管理数据和信息
post_content:

整个项目生命周期需要收集、分析和转化大量的数据。从各个过程收集项目数据,并在项目团队内共享。在各个过程中所收集的数据经过结合相关背景的分析、汇总,并加工成项目信息。信息通过口头形式进行传达,或以各种格式的报告存储和分发。关于这一主题的更多信息,请参见 4.3 节。

在整个项目生命周期中需要定期收集和分析项目数据。关于项目数据和信息的主要术语定义如下:

图 1-7 展示了项目管理各个过程中的项目信息流。

图 1-7项目数据、信息和报告流向


ID:98
areaid:0
groupid:0
type:
post_name: 1.2.6
post_title: 项目管理商业文件
post_excerpt: 第一部分 项目管理知识体系指南 / 1 引论 / 1.2 基本要素 / 1.2.6 项目管理商业文件
post_content:

项目经理需要确保项目管理方法紧扣商业文件的意图。表 1-5 列出了这些文件的定义。在整个项目生命周期中,这两种文件相互依赖并得到反复制定和维护。

表 1-5项目商业文件

项目发起人通常负责项目商业论证文件的制定和维护。项目经理负责提供建议和见解,使项目商业论证、项目管理计划、项目章程和项目效益管理计划中的成功标准相一致,并与组织的目的和目标保持一致。

项目经理应适当地为项目裁剪上述项目管理文件。某些组织会维护项目集层面的商业论证和效益管理计划。项目经理应与相应的项目集经理合作,确保项目管理文件与项目集文件保持一致。图 1-8说明了这些关键项目管理商业文件与需求评估之间的相互关系。图 1-8 展示了项目生命周期内各种文件大概的生命周期。

图 1-8需求评估与关键业务/项目文件的相互关系


ID:99
areaid:0
groupid:0
type:
post_name: 1.2.6.1
post_title: 项目商业论证
post_excerpt: 第一部分 项目管理知识体系指南 / 1 引论 / 1.2 基本要素 / 1.2.6 项目管理商业文件 / 1.2.6.1 项目商业论证
post_content:

项目商业论证指文档化的经济可行性研究报告,用来对尚缺乏充分定义的所选方案的收益进行有效性论证,是启动后续项目管理活动的依据。商业论证列出了项目启动的目标和理由。它有助于在项目结束时根据项目目标衡量项目是否成功。商业论证是一种项目商业文件,可在整个项目生命周期中使用。在项目启动之前通过商业论证,可能会做出继续/终止项目的决策。

需求评估通常是在商业论证之前进行,包括了解业务目的和目标、问题及机会,并提出处理建议。需求评估结果可能会在商业论证文件中进行总结。

定义业务需要、分析形势、提出建议和定义评估标准的过程,适用于任何组织的项目。商业论证可能包括(但不限于)记录以下内容:

用于形势分析的准则可分为:

* 必需。必须践行的准则,可处理问题或机会。

* 预期。希望践行的准则,可处理问题或机会。

* 可选。非必要的准则。这一准则的践行情况可能成为区分备选行动方案的因素。

可选方案也可称为商业场景。例如,商业论证可提供以下三种可选方案:

* 不采取任何行动。亦称为“一切照常”方案。选择这种方案会使项目未被授权。

* 尽最小的努力处理问题或机会。最小的努力可能指确定一系列对处理问题或机会而言极为关键的既定准则。

* 以超过最低限度的努力处理问题或机会。这一方案可满足最低限度的准则以及一些或所有其他在案准则。商业论证可能会提供上述多个方案。

* 潜在方案的分析结果;

* 潜在方案的制约因素、假设、风险和依赖关系;

* 成功标准(见 1.2.6.4 节)。

* 里程碑;

* 依赖关系;

* 角色与职责。

通过将成果与目标和确定的成功标准进行比较,商业论证文件为衡量整个项目生命周期的成功和进展奠定了基础。请参见《从业者商业分析:实践指南》[7]。


ID:100
areaid:0
groupid:0
type:
post_name: 1.2.6.2
post_title: 项目效益管理计划
post_excerpt: 第一部分 项目管理知识体系指南 / 1 引论 / 1.2 基本要素 / 1.2.6 项目管理商业文件 / 1.2.6.2 项目效益管理计划
post_content:

项目效益管理计划描述了项目实现效益的方式和时间,以及应制定的效益衡量机制。项目效益指为发起组织和项目预期受益方创造价值的行动、行为、产品、服务或成果的结果。项目生命周期早期应确定目标效益,并据此制定效益管理计划。它描述了效益的关键要素,可能包括(但不限于)记录以下内容:

制定效益管理计划需要使用商业论证和需求评估中的数据和信息,例如,成本效益分析数据。

在成本效益分析中已经把成本估算与项目拟实现的效益进行了比较。效益管理计划和项目管理计划描述了项目创造的商业价值如何能够成为组织持续运营的一部分,包括使用的测量指标。测量指标可核实商业价值并确认项目成功与否。

项目效益管理计划的制定和维护是一项迭代活动。它是商业论证、项目章程和项目管理计划的补充性文件。项目经理与发起人共同确保项目章程、项目管理计划和效益管理计划在整个项目生命周期内始终保持一致。请参见《从业者商业分析:实践指南》[7]、《项目集管理标准》[3]和《项目组合管理标准》[2]。


ID:104
areaid:0
groupid:0
type:
post_name: 2.1
post_title: 概述
post_excerpt: 第一部分 项目管理知识体系指南 / 2 项目运行环境 / 2.1 概述
post_content:

项目所处的环境可能对项目的开展产生有利或不利的影响。这些影响的两大主要来源为事业环境因素 (EEF) 和组织过程资产 (OPA)。

事业环境因素源于项目外部(往往是企业外部)的环境,事业环境因素可能对整个企业、项目组合、项目集或项目产生影响。关于事业环境因素的更多信息,请参见 2.2 节。

组织过程资产源于企业内部,可能来自企业自身、项目组合、项目集、其他项目或这些的组合。

图 2-1 分解了事业环境因素和组织过程资产所涵盖的项目影响。关于组织过程资产的更多信息,请参

见 2.3 节。

图 2-1项目影响

除了事业环境因素和组织过程资产,组织系统对项目生命周期也起着重要的作用。组织系统(见2.4 节)进一步讨论了影响了组织系统内部人员的权力、影响力、利益、技能和政治能力的系统因素。


ID:109
areaid:0
groupid:0
type:
post_name: 2.3.1
post_title: 过程、政策和程序
post_excerpt: 第一部分 项目管理知识体系指南 / 2 项目运行环境 / 2.3 组织过程资产 / 2.3.1 过程、政策和程序
post_content:

组织用于执行项目工作的流程与程序,包括(但不限于):


ID:147
areaid:1
groupid:0
type:
post_name: 4
post_title: 项目整合管理
post_excerpt: 第一部分 项目管理知识体系指南 / 4 项目整合管理
post_content:

项目整合管理包括对隶属于项目管理过程组的各种过程和项目管理活动进行识别、定义、组合、统一和协调的各个过程。在项目管理中,整合兼具统一、合并、沟通和建立联系的性质,这些行动应该贯穿项目始终。项目整合管理包括进行以下选择:

项目整合管理过程包括:

4.1 制定项目章程 — 编写一份正式批准项目并授权项目经理在项目活动中使用组织资源的文件的过程。

4.2 制定项目管理计划 — 定义、准备和协调项目计划的所有组成部分,并把它们整合为一份综合项目管理计划的过程。

4.3 指导与管理项目工作 — 为实现项目目标而领导和执行项目管理计划中所确定的工作,并实施已批准变更的过程。

4.4 管理项目知识 — 使用现有知识并生成新知识,以实现项目目标,并且帮助组织学习的过程。

4.5 监控项目工作 — 跟踪、审查和报告整体项目进展,以实现项目管理计划中确定的绩效目标的过程。

4.6 实施整体变更控制 — 审查所有变更请求,批准变更,管理对可交付成果、组织过程资产、项目文件和项目管理计划的变更,并对变更处理结果进行沟通的过程。

4.7 结束项目或阶段 — 终结项目、阶段或合同的所有活动的过程。

图 4-1 概述了项目整合管理的各个过程。虽然在本《PMBOK® 指南》中,各项目整合管理过程

以界限分明和相互独立的形式出现,但在实践中它们会以本指南无法全面详述的方式相互交叠和相互作用。

图 4-1项目整合管理概述

项目整合管理的核心概念项目整合管理由项目经理负责。虽然其他知识领域可以由相关专家(如成本分析专家、进度规划专家、风险管理专家)管理,但是项目整合管理的责任不能被授权或转移。只能由项目经理负责整合所有其他知识领域的成果,并掌握项目总体情况。项目经理必须对整个项目承担最终责任。

项目与项目管理本质上具有整合性质,例如,为应急计划制定成本估算时,就需要整合项目成本管理、项目进度管理和项目风险管理知识领域中的相关过程。在识别出与各种人员配备方案有关的额外风险时,可能需要再次进行上述某个或某几个过程。

项目管理过程组的各个过程之间经常反复发生联系。例如,在项目早期,规划过程组为执行过程组提供书面的项目管理计划;然后,随着项目的进展,规划过程组还将根据变更情况,更新项目管理计划。

项目整合管理指的是:

项目越复杂,相关方的期望越多样化,就需要越全面的整合方法。

项目整合管理的发展趋势和新兴实践项目整合管理知识领域要求整合所有其他知识领域的成果。与整合管理过程相关的发展趋势包括(但不限于):

裁剪时需要考虑的因素因为每个项目都是独特的,所以项目经理可能需要裁剪项目整合管理过程。裁剪时应考虑的因素包括(但不限于):

在敏捷或适应型环境中需要考虑的因素迭代和敏捷方法能够促进团队成员以相关领域专家的身份参与整合管理。团队成员自行决定计划及其组件的整合方式。

在适应型环境下,《整合管理的核心概念》中所述的对项目经理的期望保持不变,但把对具体产品的规划和交付授权给团队来控制。项目经理的关注点在于营造一个合作型的决策氛围,并确保团队有能力应对变更。如果团队成员具备广泛的技能基础而不局限于某个狭窄的专业领域,那么这种合作型方法就会更加有效。


ID:157
areaid:1
groupid:1
type:out
post_name: 4.1.3.2
post_title: 假设日志
post_excerpt: 第一部分 项目管理知识体系指南 / 4 项目整合管理 / 4.1 制定项目章程 / 4.1.3 制定项目章程:输出 / 4.1.3.2 假设日志
post_content:

通常,在项目启动之前编制商业论证时,识别高层级的战略和运营假设条件与制约因素。这些假设条件与制约因素应纳入项目章程。较低层级的活动和任务假设条件在项目期间随着诸如定义技术规范、估算、进度和风险等活动的开展而生成。假设日志用于记录整个项目生命周期中的所有假设条件和制约因素。


ID:174
areaid:1
groupid:2
type:out
post_name: 4.2.3.1
post_title: 项目管理计划
post_excerpt: 第一部分 项目管理知识体系指南 / 4 项目整合管理 / 4.2 制定项目管理计划 / 4.2.3 制定项目管理计划:输出 / 4.2.3.1 项目管理计划
post_content:

项目管理计划是说明项目执行、监控和收尾方式的一份文件,它整合并综合了所有子管理计划和基准,以及管理项目所需的其他信息。究竟需要哪些项目管理计划组件,取决于具体项目的需求。

项目管理计划组件包括(但不限于):

虽然在本过程生成的组件会因项目而异,但是通常包括(但不限于):

项目管理计划是用于管理项目的主要文件之一。管理项目时还会使用其他项目文件。这些其他文件不属于项目管理计划,但它们也是实现高效管理所必需的文件。表 4-1 列出了主要的项目管理计划组件和项目文件。

表 4-1项目管理计划和项目文件


ID:189
areaid:1
groupid:3
type:out
post_name: 4.3.3.3
post_title: 问题日志
post_excerpt: 第一部分 项目管理知识体系指南 / 4 项目整合管理 / 4.3 指导与管理项目工作 / 4.3.3 指导与管理项目工作:输出 / 4.3.3.3 问题日志
post_content:

在整个项目生命周期中,项目经理通常会遇到问题、差距、不一致或意外冲突。项目经理需要采取某些行动加以处理,以免影响项目绩效。问题日志是一种记录和跟进所有问题的项目文件,所需记录和跟进的内容可能包括:

问题日志可以帮助项目经理有效跟进和管理问题,确保它们得到调查和解决。作为本过程的输出,问题日志被首次创建,尽管在项目期间任何时候都可能发生问题。在整个项目生命周期应该随同监控活动更新问题日志。


ID:229
areaid:1
groupid:4
type:
post_name: 4.6
post_title: 实施整体变更控制
post_excerpt: 第一部分 项目管理知识体系指南 / 4 项目整合管理 / 4.6 实施整体变更控制
post_content:

实施整体变更控制是审查所有变更请求、批准变更,管理对可交付成果、项目文件和项目管理计划的变更,并对变更处理结果进行沟通的过程。本过程审查对项目文件、可交付成果或项目管理计划的所有变更请求,并决定对变更请求的处置方案。本过程的主要作用是确保对项目中已记录在案的变更做综合评审。如果不考虑变更对整体项目目标或计划的影响就开展变更,往往会加剧整体项目风险。本过程需要在整个项目期间开展。图 4-12 描述本过程的输入、工具与技术和输出。图 4-13 是本过程的数据流向图。

图 4-12实施整体变更控制:输入、工具与技术和输出

图 4-13实施整体变更控制:数据流向图

实施整体变更控制过程贯穿项目始终,项目经理对此承担最终责任。变更请求可能影响项目范围、产品范围以及任一项目管理计划组件或任一项目文件。在整个项目生命周期的任何时间,参与项目的任何相关方都可以提出变更请求。变更控制的实施程度,取决于项目所在应用领域、项目复杂程度、合同要求,以及项目所处的背景与环境。

在基准确定之前,变更无需正式受控于实施整体变更控制过程。一旦确定了项目基准,就必须通过本过程来处理变更请求。依照常规,每个项目的配置管理计划应规定哪些项目工件受控于配置控制程序。对配置要素的任何变更都应该提出变更请求,并经过正式控制。

尽管也可以口头提出,但所有变更请求都必须以书面形式记录,并纳入变更管理和(或)配置管理系统中。在批准变更之前,可能需要了解变更对进度的影响和对成本的影响。在变更请求可能影响任一项目基准的情况下,都需要开展正式的整体变更控制过程。每项记录在案的变更请求都必须由一位责任人批准、推迟或否决,这个责任人通常是项目发起人或项目经理。应该在项目管理计划或组织程序中指定这位责任人,必要时,应该由变更控制委员会(CCB)来开展实施整体变更控制过程。CCB 是一个正式组成的团体,负责审查、评价、批准、推迟或否决项目变更,以及记录和传达变更处理决定。

变更请求得到批准后,可能需要新编(或修订)成本估算、活动排序、进度日期、资源需求和(或)风险应对方案分析,这些变更可能要求调整项目管理计划和其他项目文件。某些特定的变更请求,在 CCB 批准之后,可能还需要得到客户或发起人的批准,除非他们本身就是 CCB 的成员。


ID:271
areaid:2
groupid:0
type:
post_name: 5
post_title: 项目范围管理
post_excerpt: 第一部分 项目管理知识体系指南 / 5 项目范围管理
post_content:

项目范围管理包括确保项目做且只做所需的全部工作,以成功完成项目的各个过程。管理项目范围主要在于定义和控制哪些工作应该包括在项目内,哪些不应该包括在项目内。

项目范围管理过程包括:

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

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

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

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

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

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

图 5-1 概括了项目范围管理的各个过程。虽然各项目范围管理过程以界限分明、相互独立的形式出

现,但在实践中它们会以《PMBOK® 指南》无法全面叙述的方式相互交叠、相互作用。

图 5-1项目范围管理概述

项目范围管理的核心概念在项目环境中,“范围”这一术语有两种含义:

从预测型方法到适应型或敏捷型方法,项目生命周期可以处于这个连续区间内的任何位置。在预测型生命周期中,在项目开始时就对项目可交付成果进行定义,对任何范围变化都要进行渐进管理。而在适应型或敏捷型生命周期中,通过多次迭代来开发可交付成果,并在每次迭代开始时定义和批准详细的范围。

采用适应型生命周期,旨在应对大量变更,需要相关方持续参与项目;因此,应将适应型项目的整体范围分解为一系列拟实现的需求和拟执行的工作(有时称为产品未完项)。在一个迭代开始时,团队将努力确定产品未完项中,哪些最优先项应在下一次迭代中交付。在每次迭代中,都会重复开展三个过程:收集需求、定义范围和创建 WBS。相反,在预测型项目中,这些过程在项目开始时开展,并在必要时通过实施整体变更控制过程进行更新。

在适应型或敏捷型生命周期中,发起人和客户代表应该持续参与项目,随同可交付成果的创建提供反馈意见,并确保产品未完项反映他们的当前需求。在每次迭代中,都会重复开展两个过程:确认范围和控制范围。相反,在预测型项目中,确认范围在每个可交付成果生成时或者在阶段审查点开展,而控制范围则是一个持续性的过程。

在预测型项目中,经过批准的项目范围说明书、工作分解结构(WBS)和相应的 WBS 词典构成项目范围基准。只有通过正式变更控制程序,才能进行基准变更。在开展确认范围、控制范围及其他控制过程时,基准被用作比较的基础。而采用适应型生命周期的项目,则使用未完项(包括产品需求和用户故事)反映当前需求。

项目范围的完成情况是根据项目管理计划来衡量的,而产品范围的完成情况是根据产品需求来衡量的。在这里,“需求”是指根据特定协议或其他强制性规范,产品、服务或成果必须具备的条件或能力。

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

目范围管理的发展趋势和新兴实践需求一直是项目管理中的重点,并且还将继续得到项目管理从业者的更多关注。随着全球环境变得日益复杂,组织开始认识到如何运用商业分析,通过定义、管理和控制需求活动来提高竞争优势。商业分析活动可在项目启动和项目经理任命之前就开始。根据《需求管理:实践指南》[14],需求管理过程始于需要评估,而需要评估又可能始于项目组合规划、项目集规划或单个项目。

在项目范围管理过程中,收集、记录和管理相关方需求。项目范围管理的范围趋势和新兴实践包括(但不限于)注重与商业分析专业人士的合作,以便:

需求管理过程结束于需求关闭,即把产品、服务或成果移交给接收方,以便长期测量、监控、实现和维持效益。

应该将商业分析的角色连同职责分配给具有足够商业分析技能和专业知识的人员。如果项目已配备商业分析师,那么,与需求管理相关的活动便是该角色的职责。而项目经理则负责确保这些活动在项目管理计划有所安排,并且在预算内按时完成,同时能够创造价值。

项目经理与商业分析师之间应该是伙伴式合作关系。如果项目经理和商业分析师能够理解彼此在促进项目目标实现过程中的角色和职责,项目成功的可能性就更大。

裁剪时需要考虑的因素因为每个项目都是独特的,所以项目经理需要裁剪项目范围管理过程。裁剪时应考虑的因素包括(但不限于):

在敏捷或适应型环境中需要考虑的因素对于需求不断变化、风险大或不确定性高的项目,在项目开始时通常无法明确项目的范围,而需要在项目期间逐渐明确。敏捷方法特意在项目早期缩短定义和协商范围的时间,并为持续探索和明确范围而延长创建相应过程的时间。在许多情况下,不断涌现的需求往往导致真实的业务需求与最初所述的业务需求之间存在差异。因此,敏捷方法有目的地构建和审查原型,并通过多次发布版本来明确需求。这样一来,范围会在在整个项目期间被定义和再定义。在敏捷方法中,把需求列入未完项。


ID:275
areaid:2
groupid:2
type:in
post_name: 5.1.1.2
post_title: 项目管理计划
post_excerpt: 第一部分 项目管理知识体系指南 / 5 项目范围管理 / 5.1 规划范围管理 / 5.1.1 规划范围管理:输入 / 5.1.1.2 项目管理计划
post_content:

见 4.2.3.1 节。项目管理计划组件包括(但不限于):


ID:307
areaid:2
groupid:2
type:out
post_name: 5.2.3.2
post_title: 需求跟踪矩阵
post_excerpt: 第一部分 项目管理知识体系指南 / 5 项目范围管理 / 5.2 收集需求 / 5.2.3 收集需求:输出 / 5.2.3.2 需求跟踪矩阵
post_content:

需求跟踪矩阵是把产品需求从其来源连接到能满足需求的可交付成果的一种表格。使用需求跟踪矩阵,把每个需求与业务目标或项目目标联系起来,有助于确保每个需求都具有商业价值。需求跟踪矩阵提供了在整个项目生命周期中跟踪需求的一种方法,有助于确保需求文件中被批准的每项需求在项目结束的时候都能交付。最后,需求跟踪矩阵还为管理产品范围变更提供了框架。

跟踪需求包括(但不限于):

应在需求跟踪矩阵中记录每个需求的相关属性,这些属性有助于明确每个需求的关键信息。需求跟踪矩阵中记录的典型属性包括唯一标识、需求的文字描述、收录该需求的理由、所有者、来源、优先级别、版本、当前状态(如进行中、已取消、已推迟、新增加、已批准、被分配和已完成)和状态日期。为确保相关方满意,可能需要增加一些补充属性,如稳定性、复杂性和验收标准。图 5-7是需求跟踪矩阵示例,其中列有相关的需求属性。

图 5-7需求跟踪矩阵示例

Programs Portfolios


ID:334
areaid:2
groupid:2
type:tt
post_name: 5.4.2.2
post_title: 分解
post_excerpt: 第一部分 项目管理知识体系指南 / 5 项目范围管理 / 5.4 创建 WBS / 5.4.2 创建 WBS:工具与技术 / 5.4.2.2 分解
post_content:

分解是一种把项目范围和项目可交付成果逐步划分为更小、更便于管理的组成部分的技术;工作包是 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 模板,可以在裁剪后应用于特定领域的具体项目。


ID:386
areaid:3
groupid:2
type:tt
post_name: 6.2.2.3
post_title: 滚动式规划
post_excerpt: 第一部分 项目管理知识体系指南 / 6 项目进度管理 / 6.2 定义活动 / 6.2.2 定义活动:工具与技术 / 6.2.2.3 滚动式规划
post_content:

滚动式规划是一种迭代式的规划技术,即详细规划近期要完成的工作,同时在较高层级上粗略规划远期工作。它是一种渐进明细的规划方式,适用于工作包、规划包以及采用敏捷或瀑布式方法的发布规划。因此,在项目生命周期的不同阶段,工作的详细程度会有所不同。在早期的战略规划阶段,信息尚不够明确,工作包只能分解到已知的详细水平;而后,随着了解到更多的信息,近期即将实施的工作包就可以分解到具体的活动。


ID:482
areaid:4
groupid:2
type:
post_name: 7.2
post_title: 估算成本
post_excerpt: 第一部分 项目管理知识体系指南 / 7 项目成本管理 / 7.2 估算成本
post_content:

估算成本是对完成项目工作所需资源成本进行近似估算的过程。本过程的主要作用是,确定项目所需的资金。本过程应根据需要在整个项目期间定期开展。图 7-4 描述本过程的输入、工具与技术和输出,图 7-5 是本过程的数据流向图。

图 7-4估算成本:输入、工具与技术和输出

图 7-5估算成本的数据流向图

成本估算是对完成活动所需资源的可能成本的量化评估,是在某特定时点,根据已知信息所做出的成本预测。在估算成本时,需要识别和分析可用于启动与完成项目的备选成本方案;需要权衡备选成本方案并考虑风险,如比较自制成本与外购成本、购买成本与租赁成本及多种资源共享方案,以优化项目成本。

通常用某种货币单位(如美元、欧元、日元等)进行成本估算,但有时也可采用其他计量单位,如人时数或人天数,以消除通货膨胀的影响,便于成本比较。

在项目过程中,应该随着更详细信息的呈现和假设条件的验证,对成本估算进行审查和优化。

在项目生命周期中,项目估算的准确性亦将随着项目的进展而逐步提高。例如,在启动阶段可得出项目的粗略量级估算(Rough Order of Magnitude,ROM),其区间为 −25% 到 +75%;之后,随着信息越来越详细,确定性估算的区间可缩小至 −5% 到 +10%。某些组织已经制定出相应的指南,规定何时进行优化,以及每次优化所要达到的置信度或准确度。

进行成本估算,应该考虑将向项目收费的全部资源,包括(但不限于)人工、材料、设备、服务、设施,以及一些特殊的成本种类,如通货膨胀补贴、融资成本或应急成本。成本估算可在活动层级呈现,也可以汇总形式呈现。


ID:529
areaid:4
groupid:4
type:tt
post_name: 7.4.2.2
post_title: 数据分析
post_excerpt: 第一部分 项目管理知识体系指南 / 7 项目成本管理 / 7.4 控制成本 / 7.4.2 控制成本:工具与技术 / 7.4.2.2 数据分析
post_content:

适用于控制成本过程的数据分析技术包括(但不限于):

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)]。

如果已识别的风险没有发生,就可能要从项目预算中扣除未使用的应急储备,为其他项目或运营腾出资源。同时,在项目中开展进一步风险分析,可能会发现需要为项目预算申请额外的储备。


ID:538
areaid:5
groupid:0
type:
post_name: 8
post_title: 项目质量管理
post_excerpt: 第一部分 项目管理知识体系指南 / 8 项目质量管理
post_content:

项目质量管理包括把组织的质量政策应用于规划、管理、控制项目和产品质量要求,以满足相关方目标的各个过程。此外,项目质量管理以执行组织的名义支持过程的持续改进活动。

项目质量管理过程包括:

8.1 规划质量管理 — 识别项目及其可交付成果的质量要求和/或标准,并书面描述项目将如何证明符合质量要求和/或标准的过程。

8.2 管理质量 — 管理质量是把组织的质量政策用于项目,并将质量管理计划转化为可执行的质量活动的过程。

8.3 控制质量 — 为了评估绩效,确保项目输出完整、正确,并满足客户期望,而监督和记录质量管理活动执行结果的过程。

图 8-1 概述了项目质量管理的各个过程。虽然各项目质量管理过程通常以界限分明、相互独立的形

式出现,但在实践中它们会以《PMBOK® 无法全面叙述的方式相互交叠、相互作用。此外,不同行业和公司的质量过程各不相同。

图 8-1项目质量管理概述

图 8-2 概述了项目质量管理过程的主要输入和输出以及这些过程在项目质量管理知识领域中的相

互关系。规划质量管理过程关注工作需要达到的质量,管理质量则关注管理整个项目期间的质量过程。在管理质量过程期间,在规划质量管理过程中识别的质量要求成为测试与评估工具,将用于控制质量过程,以确认项目是否达到这些质量要求。控制质量关注工作成果与质量要求的比较,确保结果可接受。项目质量管理知识领域有两个用于其他知识领域的特定输出,即核实的可交付成果和质量报告。

图 8-2主要项目质量管理过程的相互关系

项目质量管理的核心概念项目质量管理需要兼顾项目管理与项目可交付成果两个方面,它适用于所有项目,无论项目的可交付成果具有何种特性。质量的测量方法和技术则需专门针对项目所产生的可交付成果类型而定,例如,对于软件与核电站建设的可交付成果,项目质量管理需要采用不同的方法和措施。无论什么项目,若未达到质量要求,都会给某个或全部项目相关方带来严重的负面后果,例如:

“质量”与“等级”不是相同的概念。质量作为实现的性能或成果,是“一系列内在特性满足要求的程度”(ISO 9000)[18]。等级作为设计意图,是对用途相同但技术特性不同的可交付成果的级别分类。项目经理及项目管理团队负责权衡,以便同时达到所要求的质量与等级水平。质量水平未达到质量要求肯定是个问题,而低等级产品不一定是个问题。例如:

预防胜于检查。最好将质量设计到可交付成果中,而不是在检查时发现质量问题。预防错误的成本通常远低于在检查或使用中发现并纠正错误的成本。

根据不同的项目和行业领域,项目团队可能需要具备统计控制过程方面的实用知识,以便评估控制质量的输出中所包含的数据。项目管理团队应了解以下术语之间的差别:

质量成本 (COQ) 包括在产品生命周期中为预防不符合要求、为评价产品或服务是否符合要求,以及因未达到要求(返工)而发生的所有成本。失败成本通常分为内部(项目团队发现的)和外部(客户发现的)两类。失败成本也称为劣质成本。第 8.1.2.3 节给出了每类质量成本的一些例子。

组织选择投资缺陷预防,因为它对产品生命周期有利。由于项目的临时性,针对产品生命周期的COQ 决策,通常是项目集管理、项目组合管理、PMO 或运营的关注点。

按有效性递增排列的五种质量管理水平如下:

项目质量管理的趋势和新兴实践现代质量管理方法力求缩小差异,交付满足既定相关方要求的成果。项目质量管理的趋势可能包括(但不限于):

裁剪考虑因素每个项目都是独特的,因此项目经理需要裁剪项目质量管理过程。裁剪时应考虑的因素包括(但不限于):

关于敏捷/适应型环境的考虑因素为引导变更,敏捷方法要求多个质量与审核步骤贯穿整个项目,而不是在面临项目结束时才执行。

循环回顾,定期检查质量过程的效果;寻找问题的根本原因,然后建议实施新的质量改进方法;

后续回顾会议评估试验过程,确定是否可行、是否应继续、或做出调整,或者直接弃用。

为促进频繁的増量交付,敏捷方法关注于小批量工作,纳入尽可能多的项目可交付成果的要素。

小批量系统的目的是在项目生命周期早期(整体变更成本较低)发现不一致和质量问题。


ID:579
areaid:5
groupid:4
type:
post_name: 8.3
post_title: 控制质量
post_excerpt: 第一部分 项目管理知识体系指南 / 8 项目质量管理 / 8.3 控制质量
post_content:

控制质量是为了评估绩效,确保项目输出完整、正确且满足客户期望,而监督和记录质量管理活动执行结果的过程。本过程的主要作用是,核实项目可交付成果和工作已经达到主要相关方的质量要求,可供最终验收。控制质量过程确定项目输出是否达到预期目的,这些输出需要满足所有适用标准、要求、法规和规范。本过程需要在整个项目期间开展。

图 8-10 描述本过程的输入、工具与技术和输出。图 8-11 是本过程的数据流向图。

图 8-10控制质量:输入、工具与技术和输出

图 8-11控制质量的数据流向图

控制质量过程的目的是在用户验收和最终交付之前测量产品或服务的完整性、合规性和适用性。

本过程通过测量所有步骤、属性和变量,来核实与规划阶段所描述规范的一致性和合规性。

在整个项目期间应执行质量控制,用可靠的数据来证明项目已经达到发起人和/或客户的验收标准。

控制质量的努力程度和执行程度可能会因所在行业和项目管理风格而不同。例如,相比其他行业,制药、医疗、运输和核能产业可能拥有更加严格的质量控制程序,为满足标准付出的工作也会更广;在敏捷项目中,控制质量活动可能由所有团队成员在整个项目生命周期中执行,而在瀑布式项目中,控制质量活动由特定团队成员在特定时间点或者项目或阶段快结束时执行。


ID:613
areaid:6
groupid:2
type:tt
post_name: 9.1.2.3
post_title: 组织理论
post_excerpt: 第一部分 项目管理知识体系指南 / 9 项目资源管理 / 9.1 规划资源管理 / 9.1.2 规划资源管理:工具与技术 / 9.1.2.3 组织理论
post_content:

组织理论阐述个人、团队和组织部门的行为方式。有效利用组织理论中的常用技术,可以节约规划资源管理过程的时间、成本及人力投入,提高规划工作的效率。此外,可以根据相关的组织理论灵活使用领导风格,以适应项目生命周期中团队成熟度的变化。重要的是要认识到,组织的结构和文化影响项目组织结构。


ID:616
areaid:6
groupid:2
type:out
post_name: 9.1.3.1
post_title: 资源管理计划
post_excerpt: 第一部分 项目管理知识体系指南 / 9 项目资源管理 / 9.1 规划资源管理 / 9.1.3 规划资源管理:输出 / 9.1.3.1 资源管理计划
post_content:

作为项目管理计划的一部分,资源管理计划提供了关于如何分类、分配、管理和释放项目资源的指南。资源管理计划可以根据项目的具体情况分为团队管理计划和实物资源管理计划。资源管理计划可能包括(但不限于):


ID:658
areaid:6
groupid:3
type:
post_name: 9.4
post_title: 建设团队
post_excerpt: 第一部分 项目管理知识体系指南 / 9 项目资源管理 / 9.4 建设团队
post_content:

建设团队是提高工作能力,促进团队成员互动,改善团队整体氛围,以提高项目绩效的过程。

本过程的主要作用是,改进团队协作、增强人际关系技能、激励员工、减少摩擦以及提升整体项目绩效。本过程需要在整个项目期间开展。

图 9-10 描述本过程的输入、工具与技术和输出。图 9-11 是本过程的数据流向图。

图 9-10建设团队:输入、工具与技术和输出

• Projectcharter图 9-11建设团队:数据流向图

项目经理应该能够定义、建立、维护、激励、领导和鼓舞项目团队,使团队高效运行,并实现项目目标。团队协作是项目成功的关键因素,而建设高效的项目团队是项目经理的主要职责之一。

项目经理应创建一个能促进团队协作的环境,并通过给予挑战与机会、提供及时反馈与所需支持,以及认可与奖励优秀绩效,不断激励团队。通过以下行为可以实现团队的高效运行:

项目经理在全球化环境和富有文化多样性的项目中工作:团队成员经常来自不同的行业,讲不同的语言,有时甚至会在工作中使用一种特别的“团队语言”或文化规范,而不是使用他们的母语;

项目管理团队应该利用文化差异,在整个项目生命周期中致力于发展和维护项目团队,并促进在相互信任的氛围中充分协作;通过建设项目团队,可以改进人际技巧、技术能力、团队环境及项目绩效。在整个项目生命周期中,团队成员之间都要保持明确、及时、有效(包括效果和效率两个方面)的沟通。建设项目团队的目标包括(但不限于):

有一种关于团队发展的模型叫塔克曼阶梯理论 [19,20],其中包括团队建设通常要经过的五个阶段。尽管这些阶段通常按顺序进行,然而,团队停滞在某个阶段或退回到较早阶段的情况也并非罕见;而如果团队成员曾经共事过,项目团队建设也可跳过某个阶段。

某个阶段持续时间的长短,取决于团队活力、团队规模和团队领导力。项目经理应该对团队活力有较好的理解,以便有效地带领团队经历所有阶段。


ID:669
areaid:6
groupid:3
type:tt
post_name: 9.4.2.5
post_title: 认可与奖励
post_excerpt: 第一部分 项目管理知识体系指南 / 9 项目资源管理 / 9.4 建设团队 / 9.4.2 建设团队:工具与技术 / 9.4.2.5 认可与奖励
post_content:

在建设项目团队过程中,需要对成员的优良行为给予认可与奖励。最初的奖励计划是在规划资源管理过程中编制的,只有能满足被奖励者的某个重要需求的奖励,才是有效的奖励。在管理项目团队过程中,可以正式或非正式的方式做出奖励决定,但在决定认可与奖励时,应考虑文化差异。

当人们感受到自己在组织中的价值,并且可以通过获得奖励来体现这种价值,他们就会受到激励。通常,金钱是奖励制度中的有形奖励,然而也存在各种同样有效、甚至更加有效的无形奖励。

大多数项目团队成员会因得到成长机会、获得成就感、得到赞赏以及用专业技能迎接新挑战,而受到激励。项目经理应该在整个项目生命周期中尽可能地给予表彰,而不是等到项目完成时。


ID:689
areaid:6
groupid:3
type:tt
post_name: 9.5.2.1
post_title: 人际关系与团队技能
post_excerpt: 第一部分 项目管理知识体系指南 / 9 项目资源管理 / 9.5 管理团队 / 9.5.2 管理团队:工具与技术 / 9.5.2.1 人际关系与团队技能
post_content:

适用于本过程的人际关系与团队技能包括(但不限于):

成功的冲突管理可提高生产力,改进工作关系。同时,如果管理得当,意见分歧有利于提高创造力和改进决策。假如意见分歧成为负面因素,应该首先由项目团队成员负责解决;如果冲突升级,项目经理应提供协助,促成满意的解决方案,采用直接和合作的方式,尽早并且通常在私下处理冲突。如果破坏性冲突继续存在,则可使用正式程序,包括采取惩戒措施。

项目经理解决冲突的能力往往决定其管理项目团队的成败。不同的项目经理可能采用不同的解决冲突方法。影响冲突解决方法的因素包括:

有五种常用的冲突解决方法,每种技巧都有各自的作用和用途。

mm撤退/回避。从实际或潜在冲突中退出,将问题推迟到准备充分的时候,或者将问题推给其他人员解决。

mm缓和/包容。强调一致而非差异;为维持和谐与关系而退让一步,考虑其他方的需要。

mm妥协/调解。为了暂时或部分解决冲突,寻找能让各方都在一定程度上满意的方案,但这种方法有时会导致“双输”局面。

mm强迫/命令。以牺牲其他方为代价,推行某一方的观点;只提供赢 — 输方案。通常是利用权力来强行解决紧急问题,这种方法通常会导致“赢输”局面。

mm合作/解决问题。综合考虑不同的观点和意见,采用合作的态度和开放式对话引导各方达成共识和承诺,这种方法可以带来双赢局面。

有多种领导力理论,定义了适用于不同情形或团队的领导风格。领导力对沟通愿景及鼓舞项目团队高效工作十分重要。


ID:696
areaid:6
groupid:4
type:
post_name: 9.6
post_title: 控制资源
post_excerpt: 第一部分 项目管理知识体系指南 / 9 项目资源管理 / 9.6 控制资源
post_content:

控制资源是确保按计划为项目分配实物资源,以及根据资源使用计划监督资源实际使用情况,并采取必要纠正措施的过程。本过程的主要作用是,确保所分配的资源适时适地可用于项目,且在不再需要时被释放。本过程需要在整个项目期间开展。图 9-14 描述了本过程的输入和输出。图 9-15是本过程的数据流向图。

图 9-14控制资源:输入、工具与技术和输出

• Projectcharter图 9-15控制资源:数据流向图

应在所有项目阶段和整个项目生命周期期间持续开展控制资源过程,且适时、适地和适量地分配和释放资源,使项目能够持续进行。控制资源过程关注实物资源,例如设备、材料、设施和基础设施。管理团队过程关注团队成员。

本节讨论的控制资源技术是项目中最常用的,而在特定项目或应用领域中,还可采用许多其他控制资源技术。

更新资源分配时,需要了解已使用的资源和还需要获取的资源。为此,应审查至今为止的资源使用情况。控制资源过程关注:

进度基准或成本基准的任何变更,都必须经过实施整体变更控制过程的审批(见 4.6 节)。


ID:714
areaid:7
groupid:2
type:
post_name: 10.1
post_title: 规划沟通管理
post_excerpt: 第一部分 项目管理知识体系指南 / 10 项目沟通管理 / 10.1 规划沟通管理
post_content:

规划沟通管理是基于每个相关方或相关方群体的信息需求、可用的组织资产,以及具体项目的需求,为项目沟通活动制定恰当的方法和计划的过程。本过程的主要作用是,为及时向相关方提供相关信息,引导相关方有效参与项目,而编制书面沟通计划。本过程应根据需要在整个项目期间定期开展。图 10-2 描述本过程的输入、工具与技巧和输出。图 10-3 是本过程的数据流向图。

图 10-2规划沟通管理:输入、工具与技术和输出

• Projectcharter图 10-3规划沟通管理:数据流向图

需在项目生命周期的早期,针对项目相关方多样性的信息需求,制定有效的沟通管理计划。应该定期审核沟通管理计划,并进行必要的修改,例如在相关方社区发生变化或每个新项目阶段开始时。

在大多数项目中,都需要很早就开展沟通规划工作,例如在识别相关方及制定项目管理计划期间。

虽然所有项目都需要进行信息沟通,但是各项目的信息需求和信息发布方式可能差别很大。此外,在本过程中,需要考虑并合理记录用来存储、检索和最终处置项目信息的方法。应该在整个项目期间,定期审查规划沟通管理过程的成果并做必要修改,以确保其持续适用。


ID:772
areaid:8
groupid:0
type:
post_name: 11
post_title: 项目风险管理
post_excerpt: 第一部分 项目管理知识体系指南 / 11 项目风险管理
post_content:

项目风险管理包括规划风险管理、识别风险、开展风险分析、规划风险应对、实施风险应对和监督风险的各个过程。项目风险管理的目标在于提高正面风险的概率和(或)影响,降低负面风险的概率和(或)影响,从而提高项目成功的可能性。

项目风险管理的过程是:

11.1 规划风险管理 — 定义如何实施项目风险管理活动的过程。

11.2 识别风险 — 识别单个项目风险,以及整体项目风险的来源,并记录风险特征的过程。

11.3 实施定性风险分析 — 通过评估单个项目风险发生的概率和影响以及其他特征,对风险进行优先级排序,从而为后续分析或行动提供基础的过程。

11.4 实施定量风险分析 — 就已识别的单个项目风险和其他不确定性的来源对整体项目目标的综合影响进行定量分析的过程。

11.5 规划风险应对 — 为处理整体项目风险敞口,以及应对单个项目风险,而制定可选方案、选择应对策略并商定应对行动的过程。

11.6 实施风险应对 — 执行商定的风险应对计划的过程。

11.7 监督风险 — 在整个项目期间,监督商定的风险应对计划的实施、跟踪已识别风险、识别和分析新风险,以及评估风险管理有效性的过程。

图 11-1 概括了项目风险管理的各个过程。虽然在本《PMBOK® 指南》中,各项目管理风险过程

以界限分明和相互独立的形式出现,但在实践中它们会以本指南无法全面详述的方式相互交叠和相互作用。

图 11-1项目风险管理概述

项目风险管理的核心概念既然项目是为交付收益而开展的、具有不同复杂程度的独特性工作,那自然就会充满风险。

开展项目,不仅要面对各种制约因素和假设条件,而且还要应对可能相互冲突和不断变化的相关方期望。组织应该有目的地以可控方式去冒项目风险,以便平衡风险和回报,并创造价值。

项目风险管理旨在识别和管理未被其他项目管理过程所管理的风险。如果不妥善管理,这些风险有可能导致项目偏离计划,无法达成既定的项目目标。因此,项目风险管理的有效性直接关乎项目成功与否。

每个项目都在两个层面上存在风险。每个项目都有会影响项目达成目标的单个风险,以及由单个项目风险和不确定性的其他来源联合导致的整体项目风险。考虑整体项目风险,也非常重要。项目风险管理过程同时兼顾这两个层面的风险。它们的定义如下:

它源于包括单个风险在内的所有不确定性。

一旦发生,单个项目风险会对项目目标产生正面或负面的影响。项目风险管理旨在利用或强化正面风险(机会),规避或减轻负面风险(威胁)。未妥善管理的威胁可能引发各种问题,如工期延误、成本超支、绩效不佳或声誉受损。把握好机会则能够获得众多好处,如工期缩短、成本节约、绩效改善或声誉提升。

整体项目风险也有正面或负面之分。管理整体项目风险旨在通过削弱负面变异的驱动因素,加强正面变异的驱动因素,以及最大化实现整体项目目标的概率,把项目风险敞口保持在可接受的范围之内。

因为风险会在项目生命周期内持续发生,所以,项目风险管理过程也应不断迭代开展。在项目规划期间,就应该通过调整项目策略对风险做初步处理。接着,应该随着项目进展,监督和管理风险,确保项目处于正轨,并且突发性风险也得到处理。

为有效管理特定项目的风险,项目团队需要知道,相对于要追求的项目目标,可接受的风险敞口究竟是多大。这通常用可测量的风险临界值来定义。风险临界值反映了组织与项目相关方的风险偏好程度,是项目目标的可接受的变异程度。应该明确规定风险临界,并传达给项目团队,同时反映在项目的风险影响级别定义中。

项目风险管理的发展趋势和新兴实践项目风险管理的关注面正在扩大,以便确保考虑所有类型的风险,并在更广泛的背景中理解项目风险。项目风险管理的发展趋势和新兴实践包括(但不限于):

关键卖方可能在项目期间停业,客户可能在设计完成后变更需求,或分包商可能要求对标准化操作流程进行优化。

不过,识别并管理非事件类风险的意识正在不断加强。非事件类风险有两种主要类型:

变异性风险可通过蒙特卡洛分析加以处理,即:用概率分布表示变异的可能区间,然后采取行动去缩小可能结果的区间。管理模糊性风险,则需要先定义认知或理解不足之处,进而通过获取外部专家意见或以最佳实践为标杆来填补差距。也可以采用增量开发、原型搭建或模拟等方法来处理模糊性风险。

这就要求每个项目:

裁剪时需要考虑的因素因为每个项目都是独特的,所以有必要对项目风险管理过程的应用方式进行裁剪。裁剪时应考虑的因素包括(但不限于):

根据上述需考虑的因素来裁剪项目风险管理过程,这是规划风险管理过程的一部分工作。裁剪结果将被记录在风险管理计划中。

在敏捷或适应型环境中需要考虑的因素从本质上讲,越是变化的环境就存在越多的不确定性和风险。要应对快速变化,就需要采用适应型方法管理项目,即:通过跨职能项目团队和经常审查增量式工作产品,来加快知识分享,确保对风险的认知和管理。在选择每个迭代期的工作内容时,应该考虑风险;在每个迭代期间应该识别、分析和管理风险。

此外,应该根据对当前风险敞口的理解的加深,定期更新需求文件,并随项目进展重新排列工作优先级。


ID:773
areaid:8
groupid:2
type:
post_name: 11.1
post_title: 规划风险管理
post_excerpt: 第一部分 项目管理知识体系指南 / 11 项目风险管理 / 11.1 规划风险管理
post_content:

规划风险管理是定义如何实施项目风险管理活动的过程。本过程的主要作用是,确保风险管理的水平、方法和可见度与项目风险程度,以及项目对组织和其他相关方的重要程度相匹配。本过程仅开展一次或仅在项目的预定义点开展。图 11-2 描述本过程的输入、工具与技术和输出。图 11-3 是本过程的数据流向图。

图 11-2规划风险管理:输入、工具与技术和输出

图 11-3规划风险管理:数据流向图

规划风险管理过程在项目构思阶段就应开始,并在项目早期完成。在项目生命周期的后期,可能有必要重新开展本过程,例如,在发生重大阶段变更时,在项目范围显著变化时,或者后续对风险管理有效性进行审查且确定需要调整项目风险管理过程时。


ID:785
areaid:8
groupid:2
type:out
post_name: 11.1.3.1
post_title: 风险管理计划
post_excerpt: 第一部分 项目管理知识体系指南 / 11 项目风险管理 / 11.1 规划风险管理 / 11.1.3 规划风险管理:输出 / 11.1.3.1 风险管理计划
post_content:

风险管理计划是项目管理计划的组成部分,描述如何安排与实施风险管理活动。风险管理计划可包括以下部分或全部内容:

图 11-4风险分解结构(RBS)示例

通过将影响定义为负面威胁(工期延误、成本增加和绩效不佳)和正面机会(工期缩短、成本节约和绩效改善),表格所示的量表可同时用于评估威胁和机会。

表 11-1概率和影响定义示例

图 11-5 是概率和影响矩阵的示例,其中也有数值风险评分的可能方法。

图 11-5概率和影响矩阵示例(有评分方法)


ID:786
areaid:8
groupid:2
type:
post_name: 11.2
post_title: 识别风险
post_excerpt: 第一部分 项目管理知识体系指南 / 11 项目风险管理 / 11.2 识别风险
post_content:

识别风险是识别单个项目风险以及整体项目风险的来源,并记录风险特征的过程。本过程的主要作用是,记录现有的单个项目风险,以及整体项目风险的来源;同时,汇集相关信息,以便项目团队能够恰当应对已识别的风险。本过程需要在整个项目期间开展。图 11-6 描述本过程的输入、工具与技术和输出。图 11-7 是本过程的数据流向图。

图 11-6识别风险:输入、工具与技术和输出

图 11-7识别风险:数据流向图

识别风险时,要同时考虑单个项目风险,以及整体项目风险的来源。风险识别活动的参与者可能包括:项目经理、项目团队成员、项目风险专家(若已指定)、客户、项目团队外部的主题专家、最终用户、其他项目经理、运营经理、相关方和组织内的风险管理专家。虽然这些人员通常是风险识别活动的关键参与者,但是还应鼓励所有项目相关方参与单个项目风险的识别工作。项目团队的参与尤其重要,以便培养和保持他们对已识别单个项目风险、整体项目风险级别和相关风险应对措施的主人翁意识和责任感。

应该采用统一的风险描述格式,来描述和记录单个项目风险,以确保每一项风险都被清楚、明确地理解,从而为有效的分析和风险应对措施制定提供支持。可以在识别风险过程中为单个项目风险指定风险责任人,待实施定性风险分析过程确认。也可以识别和记录初步的风险应对措施,待规划风险应对过程审查和确认。

在整个项目生命周期中,单个项目风险可能随项目进展而不断出现,整体项目风险的级别也会发生变化。因此,识别风险是一个迭代的过程。迭代的频率和每次迭代所需的参与程度因情况而异,应在风险管理计划中做出相应规定。


ID:805
areaid:8
groupid:2
type:
post_name: 11.3
post_title: 实施定性风险分析
post_excerpt: 第一部分 项目管理知识体系指南 / 11 项目风险管理 / 11.3 实施定性风险分析
post_content:

实施定性风险分析是通过评估单个项目风险发生的概率和影响以及其他特征,对风险进行优先级排序,从而为后续分析或行动提供基础的过程。本过程的主要作用是重点关注高优先级的风险。

本过程需要在整个项目期间开展。图 11-8 描述本过程的输入、工具与技术和输出。图 11-9 是本过程的数据流向图。

图 11-8实施定性风险分析:输入、工具与技术和输出

图 11-9实施定性风险分析:数据流向图

实施定性风险分析,使用项目风险的发生概率、风险发生时对项目目标的相应影响以及其他因素,来评估已识别单个项目风险的优先级。这种评估基于项目团队和其他相关方对风险的感知程度,从而具有主观性。所以,为了实现有效评估,就需要认清和管理本过程关键参与者对风险所持的态度。风险感知会导致评估已识别风险时出现偏见,所以应该注意找出偏见并加以纠正。如果由引导者来引导本过程的开展,那么找出并纠正偏见就是该引导者的一项重要工作。同时,评估单个项目风险的现有信息的质量,也有助于澄清每个风险对项目的重要性的评估。

实施定性风险分析能为规划风险应对过程确定单个项目风险的相对优先级。本过程会为每个风险识别出责任人,以便由他们负责规划风险应对措施,并确保应对措施的实施。如果需要开展实施定量风险分析过程,那么实施定性风险分析也能为其奠定基础。

根据风险管理计划的规定,在整个项目生命周期中要定期开展实施定性风险分析过程。在敏捷开发环境中,实施定性风险分析过程通常要在每次迭代开始前进行。


ID:834
areaid:8
groupid:2
type:out
post_name: 11.4.3.1
post_title: 项目文件更新
post_excerpt: 第一部分 项目管理知识体系指南 / 11 项目风险管理 / 11.4 实施定量风险分析 / 11.4.3 实施定量风险分析:输出 / 11.4.3.1 项目文件更新
post_content:

可作为本过程输出的项目文件包括(但不限于)风险报告(见 11.2.3.2 节)。更新风险报告,反映定量风险分析的结果,通常包括:


ID:883
areaid:9
groupid:0
type:
post_name: 12
post_title: 项目采购管理
post_excerpt: 第一部分 项目管理知识体系指南 / 12 项目采购管理
post_content:

项目采购管理包括从项目团队外部采购或获取所需产品、服务或成果的各个过程。项目采购管理包括编制和管理协议所需的管理和控制过程,例如,合同、订购单、协议备忘录 (MOA),或服务水平协议 (SLA)。被授权采购项目所需货物和(或)服务的人员可以是项目团队、管理层或组织采购部(如果有)的成员。

项目采购管理过程包括:

12.1 规划采购管理 — 记录项目采购决策、明确采购方法,及识别潜在卖方的过程。

12.2 实施采购 — 获取卖方应答、选择卖方并授予合同的过程。

12.3 控制采购 — 管理采购关系、监督合同绩效、实施必要的变更和纠偏,以及关闭合同的过程。

虽然在本指南中,采购过程以界限分明和相互独立的形式出现,但在实践中,采购过程相当复杂且相互作用,还与其他知识领域的过程相互作用。本指南无法全面详述这些相互作用。本章以从项目外部获取货物或服务的视角来叙述采购过程。

图 12-1 概括了项目采购管理的各个过程。虽然在本《PMBOK® 指南》中,各项目采购管理过程

以界限分明和相互独立的形式出现,但在实践中它们会以本指南无法全面详述的方式相互交叠和相互作用。

图 12-1项目采购管理概述

项目采购管理的核心概念与采购过程相关的重大法律义务和惩罚,通常超出大多数其他的项目管理过程。虽然项目经理不必成为采购管理法律法规领域的专家,但应该对采购过程有足够了解,以便做出与合同及合同关系相关的明智决定。通常情况下,项目经理无权签署对组织有约束力的法律协议,这项工作仅由具备相关职权的人员执行。

项目采购管理过程涉及到用协议来描述买卖双方之间的关系。协议可以很简单,如以特定人工单价购买所需的工时,也可以很复杂,如多年的国际施工合同。合同签署的方法和合同本身应体现可交付成果或所需人力投入的简单性或复杂性,其书写形式也应符合当地、所在国或国际法中关于合同签署的规定。

合同应明确说明预期的可交付成果和结果,包括从卖方到买方的任何知识转移。合同中未规定的任何事项则不具法律强制力。开展国际合作的项目经理应牢记,无论合同规定如何详尽,文化和当地法律对合同及其可执行性均有影响。

采购合同中包括条款和条件,也可包括买方就卖方应实施工作或应交付产品的其他规定。在与采购办公室协作确保遵守组织的采购政策的同时,项目管理团队必须确定所有采购都能满足项目的具体需要。因应用领域不同,协议可以是合同、服务水平协议(SLA)、谅解备忘录、协议备忘录(MOA)或订购单。

大多数组织都有相关的书面政策和程序,来专门定义采购规则,并规定谁有权代表组织签署和管理协议。在世界各地,组织虽然用不同的名称来称呼负责采购的单位或部门,如购买部、合同部、采购部或收购部,但其实际职责大同小异。

虽然所有项目文件可能都要经过某种形式的审查与批准,但是,鉴于其法律约束力,合同或协议需要经过更多的审批程序,而且通常会涉及到法务部。在任何情况下,审批程序的主要目标都是确保合同充分描述将由卖方提供的产品、服务或成果,且符合法律法规关于采购的规定。通常把描述产品、服务或成果的文件作为独立的附件或附录,以便合同正文使用标准化的法律合同用语。

在复杂项目中,可能需要同时或先后管理多个合同。这种情况下,不同合同的生命周期可在项目生命周期的任何阶段开始与结束。买卖方关系是采购组织与外部组织之间的关系,可存在于项目的许多层次上。

因应用领域不同,卖方可以是承包商、供货商、服务提供商或供应商;买方可能为最终产品的所有人、分包商、收购机构、服务需求者或购买方。在合同生命周期中,卖方首先是投标人,然后是中标人,之后是签约供应商或供货商。

中标人可将所承揽的工作当作一个项目加以管理。在这种情况下:

在合同中,可实际列出各种输入(如,主要可交付成果、关键里程碑、成本目标),或者可限制项目团队的选择余地(如,在 IT 整合项目中,关于人员配备的决定往往要征得买方的批准)。另外,采购工作说明书可能使用其他名称,如技术工作说明书。

本节假设项目所需物品或服务的买方是项目团队,或者是组织内部的某个部门,同时假设卖方是为项目提供物品或服务的一方,且通常来自执行组织外部。在某些项目上,卖方可能是项目执行组织内部但属于项目外部的某个小组或部门。在大型复杂的项目上,卖方可能在授予合同后才成为整合式项目团队的一部分。

在小型组织或初创企业,以及未设置购买、合同或采购部门的组织,项目经理可以拥有采购职权,能够直接谈判并签署合同(分散式采购)。在更成熟的组织中,由专设部门开展实际的采购和合同签署工作,即采购、谈判和签署合同(集中式采购)。

在签署国际合同时,应该在合同中明确规定对合同的法律管辖权。在大多数情况下,卖方是受正式合同关系约束的外部承包商。

采购管理的发展趋势和新兴实践不同行业各方面(软件工具、风险、过程、物流和技术)的一些重大趋势,会影响项目的成功率。项目采购管理的发展趋势和新兴实践包括(但不限于):

裁剪时需要考虑的因素因为每个项目都是独特的,所以项目经理需要裁剪项目采购管理过程。裁剪时应考虑的因素包括(但不限于):

在敏捷或适应型环境中需要考虑的因素在敏捷型环境中,可能需要与特定卖方协作来扩充团队。这种协作关系能够营造风险共担式采购模型,让买方和卖方共担项目风险和共享项目奖励。

在大型项目上,可能针对某些可交付成果采用适应型方法,而对其他部分则采用更稳定的方法。

在这种情况下,可以通过主体协议,如主要服务协议(MSA),来管辖整体协作关系,而将适应型工作写入附录或补充文件。这样一来,变更只针对适应型工作,而不会对主体协议造成影响。


ID:971
areaid:10
groupid:1
type:out
post_name: 13.1.3.1
post_title: 相关方登记册
post_excerpt: 第一部分 项目管理知识体系指南 / 13 项目相关方管理 / 13.1 识别相关方 / 13.1.3 识别相关方:输出 / 13.1.3.1 相关方登记册
post_content:

相关方登记册是识别相关方过程的主要输出。它记录关于已识别相关方的信息,包括(但不限于):


ID:975
areaid:10
groupid:2
type:
post_name: 13.2
post_title: 规划相关方参与
post_excerpt: 第一部分 项目管理知识体系指南 / 13 项目相关方管理 / 13.2 规划相关方参与
post_content:

规划相关方参与是根据相关方的需求、期望、利益和对项目的潜在影响,制定项目相关方参与项目的方法的过程。本过程的主要作用是,提供与相关方进行有效互动的可行计划。本过程应根据需要在整个项目期间定期开展。

图 13-4 描述本过程的输入、工具与技术和输出。图 13-5 是本过程的数据流向图。

图 13-4规划相关方参与:输入、工具与技术和输出

图 13-5规划相关方参与:数据流向图

• Projectcharter为满足项目相关方的多样性信息需求,应该在项目生命周期的早期制定一份有效的计划;然后,随着相关方社区的变化,定期审查和更新该计划。在通过识别相关方过程明确最初的相关方社区之后,就应该编制第一版的相关方参与计划,然后定期更新相关方参与计划,以反映相关方社区的变化。会触发该计划更新的典型情况包括(但不限于):

这些情况都可能导致已识别相关方的相对重要性发生变化。


ID:1032
areaid:0
groupid:0
type:
post_name: 1.4
post_title: 项目成功与效益管理
post_excerpt: 第二部分 项目管理标准 / 1 引论 / 1.4 项目成功与效益管理
post_content:

启动项目旨在抓住与组织的战略目标相符的商业机会。在启动项目之前,通常需要编制商业论证,以概述项目目标、所需投资,以及用于测量项目成功的财务标准和其他量化标准。商业论证为在整个项目生命周期中衡量项目成功和进展奠定了基础,以便把实际结果与预定的目标和成功标准进行比较。

项目的启动通常出于以下一项或多项战略考虑:

效益管理计划描述项目效益的实现方法和时间及其衡量方式。效益管理计划可能包括以下内容:

根据项目目标和成功标准考核项目的成功程度。在许多情况下,产品、服务或成果的成功只有在项目完成后一段时间方能知晓。例如,在项目产品、服务或成果交付运营时,市场份额增加、运营成本降低或新产品成功可能都是未知的。在这些情况下,项目管理办公室 (PMO)、项目组合指导委员会或组织内的其他职能部门,应该在稍晚时间才对项目成功进行评估,以确定结果是否符合业务目标。

商业论证和效益管理计划都是在项目启动之前编制的,并且要成为项目完成之后评估项目成功的依据。因此,它们被视为商业文件,而非项目文件,或者项目管理计划的组成部分。这些商业文件可能成为某些项目管理过程的输入,例如,制定项目章程。


ID:1034
areaid:0
groupid:0
type:
post_name: 1.6
post_title: 项目相关方
post_excerpt: 第二部分 项目管理标准 / 1 引论 / 1.6 项目相关方
post_content:

相关方是指可能影响项目决策、活动或结果的个人、群体或组织,以及会受或自认为会受项目决策、活动或结果影响的个人、群体或组织。项目相关方可能来自项目内部或外部,可能主动或被动参与项目,甚至完全不了解项目。项目相关方可能对项目施加积极或消极影响,也可能受项目的积极或消极影响。相关方包括(但不限于):

图 1-4项目相关方示例

图 1-4 为项目相关方的示例。有些相关方只是偶尔参与项目调查或焦点小组活动,有些则为项目提

供全方位资助,包括资金支持、政治支持或其他类型的支持。在整个项目生命周期内,他们参与项目的方式和程度可能差别很大,因此,在整个项目生命周期中,有效识别和分析相关方,引导他们合理参与,并有效管理他们对项目的期望和参与,对项目成功至关重要。


ID:1037
areaid:0
groupid:0
type:
post_name: 1.9
post_title: 项目管理过程组
post_excerpt: 第二部分 项目管理标准 / 1 引论 / 1.9 项目管理过程组
post_content:

本标准描述用于实现项目目标的项目管理过程。项目管理过程可归为五大项目管理过程组:

监控过程组详见第 5 章。

这五大过程组与应用领域(如营销、信息服务或会计)或行业(如建筑、航天、电信)无关。

在阶段或项目完成之前,往往需要反复实施过程组中的单个过程。过程迭代的次数和过程间的相互作用因具体项目的需求而不同。过程通常分为三类:

一个过程的输出通常成为另一个过程的输入,或者成为项目或项目阶段的可交付成果。例如,需要把规划过程组编制的项目管理计划和项目文件(如风险登记册、责任分配矩阵等)及其更新,提供给执行过程组作为输入。图 1-4 是各过程组在项目或阶段期间的重叠关系示例。

过程组不同于项目阶段。如果将项目划分为若干阶段,则各过程组中的过程会在每个阶段内相互作用。在一个阶段内可能需要使用所有的过程组,如图 1-5 所示。当项目被分为不同的阶段(例如概念开发、可行性研究、设计、原型、构建或测试等)时,各过程组中的过程根据需要在每个阶段中重复,直到达到该阶段的完工标准。

图 1-5项目或阶段中的过程组相互作用示例

过程组和知识领域涵盖的 49 个过程如表 1-1 所示。

表 1-1项目管理过程组与知识领域


ID:1039
areaid:0
groupid:0
type:
post_name: 1.11
post_title: 裁剪项目工件
post_excerpt: 第二部分 项目管理标准 / 1 引论 / 1.11 裁剪项目工件
post_content:

在本标准中,术语“工件”包括项目管理过程、输入、工具、技术、输出、事业环境因素和组织过程资产。项目经理和项目管理团队需要选择和调整合适的工件,用于其特定项目。这种选择和调整活动称为裁剪。每个项目的独特性决定了必须进行裁剪,因此,并非每个项目都需要每个过程、输入、工具、技术或输出。

项目管理计划是最常用的工件,有许多组成部分,如子管理计划、基准和项目生命周期描述。

子管理计划是与项目特定方面或知识领域相关的计划,如进度管理计划、风险管理计划和变更管理计划。进行裁剪时,需要确定特定项目所需的项目管理计划组件。项目管理计划是一种输入,而项目管理计划更新是本标准中许多过程的输出。在本标准中,不会在输入和输出表中直接列出单个项目管理计划组件,而是在该表下方的正文中列出每个过程可能用到的项目管理计划组件(输入)或可能得到的项目管理计划组件更新(输出)。所列出的组件仅为示例而已。在开展每个特定过程时,项目经理既非必须、也非限于用到上述输入或得到上述输出。

项目管理计划是主要的项目工件之一。另外,还有不属于项目管理计划但也可用于管理项目的其他文件。这些其他文件称为项目文件。与项目管理计划组件类似,过程所需的项目文件会因具体项目而异。项目经理负责确定过程所需的项目文件,以及将作为过程输出的项目文件更新。在本标准中,在输入和输出表下方的正文中列出的项目文件,仅为项目文件的可能示例,而非完整列表。

表 1-2 列出了项目管理计划的主要组件和主要的项目文件。虽然该表并未穷尽所有的计划组件和项

目文件,但的确列出了有助于管理项目的常用计划组件和项目文件。

表 1-2项目管理计划和项目文件

商业文件通常是在项目之外创建的文件,用作项目的输入。商业文件包括商业论证和效益管理计划。如何应用商业文件,将取决于公司文化和项目启动过程。

会影响项目的事业环境因素,以及可用于项目的组织过程资产,将因项目及其所处环境而异,所以并未在本标准中列出。


ID:1047
areaid:0
groupid:2
type:
post_name: 3
post_title: 规划过程组
post_excerpt: 第二部分 项目管理标准 / 3 规划过程组
post_content:

规划过程组包括明确项目全部范围、定义和优化目标,并为实现目标制定行动方案的一组过程。规划过程组中的过程制定项目管理计划的组成部分,以及用于执行项目的项目文件。取决于项目本身的性质,可能需要通过多轮反馈来做进一步分析。随着收集和掌握更多的项目信息或特性,项目很可能需要进一步规划。项目生命周期中发生的重大变更,可能引发重新开展一个或多个规划过程,甚至一个或全部两个启动过程。这种对项目管理计划的持续精细化叫做“渐进明细”,表明项目规划和文件编制是迭代或持续开展的活动。本过程组的主要作用是,确定成功完成项目或阶段的行动方案。

在规划项目、制定项目管理计划和项目文件时,项目管理团队应当征求适当相关方的意见,并鼓励相关方参与。初始规划工作完成时,经批准的项目管理计划就被视为基准。在整个项目期间,监控过程将把项目绩效与基准进行比较。

规划过程组(图 3-1)包括第 3.1 节至 3.24 节所列的项目管理过程。

图 3-1规划过程组


ID:1050
areaid:2
groupid:2
type:
post_name: 3.2.1
post_title: 项目管理计划组件
post_excerpt: 第二部分 项目管理标准 / 3 规划过程组 / 3.2 规划范围管理 / 3.2.1 项目管理计划组件
post_content:

可用作本过程输入的项目管理计划组件包括(但不限于):


ID:1252
areaid:0
groupid:0
type:
post_name: 附录 X3
post_title: 敏捷型、迭代型、适应型和混合型项目环境
post_excerpt: 第三部分 附录、术语表、索引 / 附录 X3 敏捷型、迭代型、适应型和混合型项目环境
post_content:

本附录探讨如何根据具体的项目环境和生命周里,而略有不同地实施《项目管理标准》中所述的项目管理过程组。

《PMBOK® 指南》的1.2.4.1 节指出“项目生命周期需要足够灵活,能够应对项目包含的各种因素”。

随可用信息更加详细和具体而逐渐演进,这正是项目的性质。在高度变化和不确定的环境中,或在相关方的理解与期望差异较大的环境中,这种演进和适应能力就更加重要。


ID:1253
areaid:0
groupid:0
type:
post_name: X3.1
post_title: 项目生命周期的连续区间
post_excerpt: 第三部分 附录、术语表、索引 / 附录 X3 敏捷型、迭代型、适应型和混合型项目环境 / X3.1 项目生命周期的连续区间
post_content:

要理解适应型项目中的过程应用,就要先理解项目生命周期的连续区间。《PMBOK® 指南》的术语表将项目生命周期定义为项目从开始到结束所经历的一系列阶段。项目生命周期内通常有一个或多个阶段与产品、服务或成果的开发相关。这些阶段称为开发生命周期。开发生命周期可分为预测型(计划驱动型)、适应型(敏捷型)、迭代型、增量型或混合型。

图 X3-1 显示了根据采用的生命周期类型,处理需求和计划的各种方式、如何管理风险和成本、进度考虑因素,以及如何处理关键相关方的参与。

图 X3-1项目生命周期的连续区间强调在项目开始阶段就明确需求和进行详细规划,这是预测型项目生命周期的特点。基于已知需求和制约因素而制定的详细计划,可以降低风险和成本。计划中也规定了需要关键相关方参与的里程碑时点。随着项目按详细计划逐渐推进,监控过程将重点限制可能影响范围、进度或预算的变更。

基于短期迭代规划和实施周期而对需求进行渐进明细,这是高适应型或敏捷型项目生命周期的特点。风险和成本随着对初始计划的渐进明细而逐渐降低。关键相关方持续参与,并频繁提供反馈,使项目能够更快地应对变更且获得更好的质量。

以下两点适用于处于连续区间中间位置的项目生命周期:(a) 风险和成本随着对初始计划的迭代演进而逐渐降低;以及 (b) 在增量型、迭代型和敏捷型周期中,相关方的参与机会更多,相比在高度预测型生命周期中只在项目里程碑时点参与。

处于连续区间中间位置的项目生命周期,可以更倾向于预测型或敏捷型。这取决于需求的确定方式、风险与成本的管理方式,以及关键相关方的参与性质。处于连续区间中间位置的项目可以采用混合型项目方法。

应该强调的是,开发生命周期具有复杂性和多维性。特定项目的不同阶段往往采用不同的生命周期,正如特定项目集内的每个项目都可用不同的方法去执行。


ID:1256
areaid:0
groupid:0
type:
post_name: X3.2.2
post_title: 持续进行的交叠阶段
post_excerpt: 第三部分 附录、术语表、索引 / 附录 X3 敏捷型、迭代型、适应型和混合型项目环境 / X3.2 项目阶段 / X3.2.2 持续进行的交叠阶段
post_content:

高度适应型项目往往在整个项目生命周期内持续实施所有的项目管理过程组。受来自精益思维的技术的启发,这种方法往往被称为“持续且适应式规划”。它承认:工作一旦开始,计划就需根据新情况而改变。其目的是,不断调整和改进项目管理计划的所有要素,而不局限在迭代中的预定检查点。这种方法中的过程组相互作用,见图 X3-3 所示。

图 X3-3持续阶段中的过程组关系这种高度适应型方法要求不断地从工作优先级清单中提取任务。其目的在于通过删去迭代期的开始活动和结束活动,将用于重复管理过程组的管理费用最小化。不断提取任务的做法可被视为“微型迭代”,旨在最大化用于执行而非管理的时间。不过,这种做法仍然需要有自身的规划、跟踪和调整机制,以确保其既不脱离正轨又能适应变更。


ID:1257
areaid:0
groupid:0
type:
post_name: X3.3
post_title: 适应型环境中的过程组
post_excerpt: 第三部分 附录、术语表、索引 / 附录 X3 敏捷型、迭代型、适应型和混合型项目环境 / X3.3 适应型环境中的过程组
post_content:

如上节所述,无论所用的项目生命周期是处于连续区间的哪一个位置,每个项目都需要使用每一个项目管理过程组。在适应型和高度适应型生命周期中,过程组之间相互作用的方式会有所不同。


ID:1259
areaid:0
groupid:0
type:
post_name: X3.3.2
post_title: 规划过程组
post_excerpt: 第三部分 附录、术语表、索引 / 附录 X3 敏捷型、迭代型、适应型和混合型项目环境 / X3.3 适应型环境中的过程组 / X3.3.2 规划过程组
post_content:

规划过程组是明确项目范围、细化目标,为实现目标制定行动方针的一组过程。

通常,高预测型项目生命周期的特点是,项目范围变更很少,以及相关方之间有高度共识。这类项目会受益于前期的详细规划。而适应型生命周期的特点是,先基于初始需求制定一套高层级的计划,再逐渐把需求细化到适合特定规划周期所需的详细程度。因此,预测型和适应型生命周期的主要区别在于:做多少规划工作,以及什么时间做。

另外,在高度复杂和不确定的项目中,应该让尽可能多的团队成员和相关方参与规划过程,以便依据很广泛的信息开展规划,降低不确定性。


ID:1260
areaid:0
groupid:0
type:
post_name: X3.3.3
post_title: 执行过程组
post_excerpt: 第三部分 附录、术语表、索引 / 附录 X3 敏捷型、迭代型、适应型和混合型项目环境 / X3.3 适应型环境中的过程组 / X3.3.3 执行过程组
post_content:

执行过程组是完成项目管理计划中确定的工作,以满足项目要求的一组过程。

在敏捷型、迭代型和适应型项目生命周期中,通过迭代对工作进行指导和管理。每次迭代都是在一个很短的固定时间段内开展工作,然后演示所形成的功能或设计。有关的相关方和团队再基于演示来开展回顾性审查。这种演示和审查有助于对照计划检查进展情况,确定是否有必要对项目范围、进度或执行过程做任何变更;也有助于通过展示已完成的工作增量,以及讨论未来工作,更好地管理相关方参与。进行回顾性审查,有利于及时发现和讨论与执行方法有关的问题,以及提出改进建议。通过讨论富有成效的做法以及依靠团队解决问题,回顾性审查也是管理项目知识和建设项目团队的主要工具。

虽然工作是通过短期迭代进行的,但是也需要对照长期的项目交付时间框架对其进行跟踪和管理。先在迭代期层面上追踪开发速度、成本支出、缺陷率和团队能力的走势,再汇总并推算到项目层面,来跟踪完工绩效。高度适应型方法旨在利用团队的专业知识去完成任务。有别于由项目经理确定工作内容和排定工作顺序,在这种方法中,项目经理解释高层级的目标,同时授权团队成员作为一个小组用最能实现目标的方式自行安排具体工作。这就使团队成员能够高度投入,制定出切合实际的计划。

对于高度适应型项目上的初级团队,在其达到适合授权的状态之前,通常都需要进行辅导和分配工作。可以在一个短暂迭代期中开展渐进式试验,然后在回顾性审查会上对团队进行审查,确定团队是否已具备无需辅导即能开展工作的技能。


ID:1265
areaid:0
groupid:0
type:
post_name: X4.1
post_title: 项目整合管理的核心概念
post_excerpt: 第三部分 附录、术语表、索引 / 附录 X4 知识领域关键概念总结 / X4.1 项目整合管理的核心概念
post_content:

项目整合管理的核心概念包括:


ID:1266
areaid:0
groupid:0
type:
post_name: X4.2
post_title: 项目范围管理的核心概念
post_excerpt: 第三部分 附录、术语表、索引 / 附录 X4 知识领域关键概念总结 / X4.2 项目范围管理的核心概念
post_content:

项目范围管理的核心概念包括:


ID:1272
areaid:0
groupid:0
type:
post_name: X4.8
post_title: 项目风险管理的核心概念
post_excerpt: 第三部分 附录、术语表、索引 / 附录 X4 知识领域关键概念总结 / X4.8 项目风险管理的核心概念
post_content:

项目风险管理的核心概念包括:


ID:1276
areaid:0
groupid:0
type:
post_name: X5.1
post_title: 项目整合管理
post_excerpt: 第三部分 附录、术语表、索引 / 附录 X5 知识领域裁剪考虑因素总结 / X5.1 项目整合管理
post_content:

裁剪项目整合管理时要考虑的因素包括(但不限于):


ID:1294
areaid:0
groupid:0
type:
post_name: X1.5
post_title: 项目管理计划
post_excerpt: 第三部分 附录、术语表、索引 / 附录 X1 第 6 版更新 / X1.5 项目管理计划
post_content:

并非每个项目管理计划组成部分都在独立的过程中创建,部分组件将在制定项目管理计划的过程中创建。它们包括变更管理计划、配置管理计划、绩效测量基准、项目生命周期、开发方法和管理审查。