全部展开 全部合拢

9.2.3.1 资源需求

资源需求识别了各个工作包或工作包中每个活动所需的资源类型和数量,可以汇总这些需求,以估算每个工作包、每个 WBS 分支以及整个项目所需的资源。资源需求描述的细节数量与具体程度因应用领域而异,而资源需求文件也可包含为确定所用资源的类型、可用性和所需数量所做的假设。

项目阶段是一组具有逻辑关系的项目活动的集合,通常以一个或多个可交付成果的完成为结束。

生命周期的各个阶段可以通过各种不同的属性来描述。对于特定阶段,属性是可测量且独特的。属性可能包括(但不限于):

  • 名称(例如阶段 A、阶段 B、阶段 1、阶段 2、提建议阶段);
  • 数量(例如项目的三个阶段、项目的五个阶段);
  • 持续时间(例如一个星期、一个月、一个季度);
  • 资源需求(例如人力、建筑、设备);
  • 项目进入某一阶段的准入标准(例如已获得特定批准文件、已完成特定文件);
  • 项目完成某一阶段的退出标准(例如已获得批准文件、已完成文件、已达成可交付成果)。

项目可以分解为不同的阶段或子组件,这些阶段或子组件的名称通常说明了该阶段完成的工作类型。阶段名称的例子包括(但不限于):

  • 概念开发;
  • 可行性研究;
  • 客户要求;
  • 解决方案开发;
  • 设计;
  • 原型法;
  • 建造;
  • 测试;
  • 转换;
  • 试运行;
  • 里程碑审查;
  • 经验教训。

项目阶段可基于各种因素而建立,其中包括(但不限于):

  • 管理需求;
  • 项目性质;
  • 组织、行业或技术的独特性;
  • 项目的组成要素,包括但不限于技术、工程、业务、过程或法律;
  • 决策点(例如资金、继续/终止项目,里程碑审查)。

分为多个阶段的方式有助于更好地掌控项目管理,同时还提供了评估项目绩效并在后续阶段采取必要的纠正或预防措施的机会。项目阶段的其中一个关键组成部分是阶段审查(见 1.2.4.3 节)。

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

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

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

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

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

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

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

很多过程都会输出变更请求。变更请求(见 4.3.3.4 节)可能包含纠正措施、预防措施、缺陷补救,以及对正式受控的项目文件或可交付成果的更新,以反映修改或增加的意见或内容。变更可能影响项目基准,也可能不影响项目基准,而只影响相对于基准的项目绩效。变更决定通常由项目经理做出。

对于会影响项目基准的变更,通常应该在变更请求中说明执行变更的成本、所需的计划日期修改、资源需求以及相关的风险。这种变更应由 CCB(如有)和客户或发起人审批,除非他们本身就是 CCB 的成员。只有经批准的变更才能纳入修改后的基准。

项目进度管理包括为管理项目按时完成所需的各个过程。其过程包括:

6.1 规划进度管理 — 为规划、编制、管理、执行和控制项目进度而制定政策、程序和文档的过程。

6.2 定义活动 — 识别和记录为完成项目可交付成果而需采取的具体行动的过程。

6.3 排列活动顺序 — 识别和记录项目活动之间的关系的过程。

6.4 估算活动持续时间 — 根据资源估算的结果,估算完成单项活动所需工作时段数的过程。

6.5 制定进度计划 — 分析活动顺序、持续时间、资源需求和进度制约因素,创建项目进度模型,从而落实项目执行和监控的过程。

6.6 控制进度 — 监督项目状态,以更新项目进度和管理进度基准变更的过程。

图 6-1 概括了项目进度管理的各个过程。虽然在本《PMBOK® 指南》中,各项目进度管理过程以界限

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

图 6-1项目进度管理概述

项目进度管理的核心概念项目进度计划提供详尽的计划,说明项目如何以及何时交付项目范围中定义的产品、服务和成果,是一种用于沟通和管理相关方期望的工具,为绩效报告提供了依据。

项目管理团队选择进度计划方法,例如关键路径法或敏捷方法。之后,项目管理团队将项目特定数据,如活动、计划日期、持续时间、资源、依赖关系和制约因素等输入进度计划编制工具,以创建项目进度模型。这件工作的成果就是项目进度计划。图 6-2 是进度计划工作的概览,展示如何结合进度计划编制方法、编制工具及项目进度管理各过程的输出来创建进度模型。

在小型项目中,定义活动、排列活动顺序、估算活动持续时间及制定进度模型等过程之间的联系非常密切,以至于可视为一个过程,能够由一个人在较短时间内完成。但本章仍然把这些过程分开介绍,因为每个过程所用的工具和技术各不相同。有关某些过程的更详细的描述,请参见《进度计划实践标准》[2]。

在可能的情况下,应在整个项目期间保持项目详细进度计划的灵活性,使其可以随着知识的获得、对风险理解的加深,以及增值活动的设计而调整。

图 6-2进度规划工作概述

项目进度管理的发展趋势和新兴实践全球市场瞬息万变,竞争激烈,具有很高的不确定性和不可预测性,很难定义长期范围,因此,为应对环境变化,根据具体情景有效采用和裁剪开发实践就日益重要。适应型规划虽然制定了计划,但也意识到工作开始之后,优先级可能发生改变,需要修改计划以反映新的优先级。

有关项目进度计划方法的新兴实践包括(但不限于):

  • 具有未完项的迭代型进度计划。这是一种基于适应型生命周期的滚动式规划,例如敏捷的产品开发方法。这种方法将需求记录在用户故事中,然后在建造之前按优先级排序并优化用户故事,最后在规定的时间盒内开发产品功能。这一方法通常用于向客户交付增量价值,或多个团队并行开发大量内部关联较小的功能。适应型生命周期在产品开发中的应用越来越普遍,很多项目都采用这种进度计划方法。这种方法的好处在于,它允许在整个开发生命周期期间进行变更。
  • 按需进度计划。这种方法通常用于看板体系,基于制约理论和来自精益生产的拉动式进度计划概念,根据团队的交付能力来限制团队正在开展的工作。按需进度计划方法不依赖于以前为产品开发或产品增量制定的进度计划,而是在资源可用时立即从未完项和工作序列中提取出来开展。按需进度计划方法经常用于此类项目:在运营或持续环境中以增量方式研发产品,其任务可以被设计成相对类似的规模和范围,或者可以按规模和范围进行组合的工作。

按需进度计划方法通常用于产品在运营和维护环境下以增量方式演进,且任务的规模或范围相对类似,或者,可以按照规模或范围对任务进行组合的项目。

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

  • 生命周期方法。哪种生命周期方法最适合制定详细的进度计划?
  • 资源可用性。影响资源可持续时间的因素是什么(如可用资源与其生产效率之间的相关性)?
  • 项目维度。项目复杂性、技术不确定性、产品新颖度、速度或进度跟踪(如挣值、完成百分比、“红黄绿”停止信号灯指示)如何影响预期的控制水平?
  • 技术支持。是否采用技术来制定、记录、传递、接收和存储项目进度模型的信息以及是否易于获取?

有关进度计划的更多信息,参阅《进度计划实践标准》[16]。

关于敏捷/适应型环境的考虑因素适应型方法采用短周期来开展工作、审查结果,并在必要时做出调整。这些周期可针对方法和可交付成果的适用性提供快速反馈,通常表现为迭代型进度计划和拉动式按需进度计划,具体参见“项目进度管理的发展趋势和新兴实践”一节。

在大型组织中,可能同时存在小规模项目和大规模举措,需要制定长期路线图,通过规模参数(如团队规模、地理分布、法规合规性、组织复杂性和技术复杂性)来管理这些项目集。为管理大规模的、全企业系统的、完整的交付生命周期,可能需要采用一系列技术,包括预测型方法、适应型方法或两种方法的混合。组织还可能需要结合几种核心方法,或采用已实践过的方法,并采纳来自传统技术的一些原则和实践。

无论是采用预测型开发生命周期来管理项目,还是在适应型环境下管理项目,项目经理的角色都不变。但是,要成功实施适应型方法,项目经理需要了解如何高效使用相关的工具和技术。

活动属性是指每项活动所具有的多重属性,用来扩充对活动的描述,活动属性随时间演进。在项目初始阶段,活动属性包括唯一活动标识 (ID)、WBS 标识和活动标签或名称;在活动属性编制完成时,活动属性可能包括活动描述、紧前活动、紧后活动、逻辑关系、提前量和滞后量(见 6.3.2.3 节)、资源需求、强制日期、制约因素和假设条件。活动属性可用于识别开展工作的地点、编制开展活动的项目日历,以及相关的活动类型。活动属性还可用于编制进度计划。根据活动属性,可在报告中以各种方式对计划进度活动进行选择、排序和分类。

估算活动持续时间是根据资源估算的结果,估算完成单项活动所需工作时段数的过程。本过程的主要作用是,确定完成每个活动所需花费的时间量。本过程需要在整个项目期间开展。图 6-12 描述本过程的输入、工具与技术和输出。图 6-13 是本过程的数据流程图。

图 6-12估算活动持续时间:输入、工具与技术和输出

图 6-13估算活动持续时间:数据流程图

估算活动持续时间依据的信息包括:工作范围、所需资源类型与技能水平、估算的资源数量和资源日历,而可能影响持续时间估算的其他因素包括对持续时间受到的约束、相关人力投入、资源类型(如固定持续时间、固定人力投入或工作、固定资源数量)以及所采用的进度网络分析技术。

应该由项目团队中最熟悉具体活动的个人或小组提供持续时间估算所需的各种输入,对持续时间的估算也应该渐进明细,取决于输入数据的数量和质量。例如,在工程与设计项目中,随着数据越来越详细,越来越准确,持续时间估算的准确性和质量也会越来越高。

在本过程中,应该首先估算出完成活动所需的工作量和计划投入该活动的资源数量,然后结合项目日历和资源日历,据此估算出完成活动所需的工作时段数(活动持续时间)。在许多情况下,预计可用的资源数量以及这些资源的技能熟练程度可能会决定活动的持续时间,更改分配到活动的主导性资源通常会影响持续时间,但这不是简单的“直线”或线性关系。有时候,因为工作的特性(即受到持续时间的约束、相关人力投入或资源数量),无论资源分配如何(如 24 小时应力测试),都需要花预定的时间才能完成工作。估算持续时间时需要考虑的其他因素包括:

  • 收益递减规律。在保持其他因素不变的情况下,增加一个用于确定单位产出所需投入的因素(如资源)会最终达到一个临界点,在该点之后的产出或输出会随着增加这个因素而递减。
  • 资源数量。增加资源数量,使其达到初始数量的两倍不一定能缩短一半的时间,因为这样做可能会因风险而造成持续时间增加;在某些情况下,如果增加太多活动资源,可能会因知识传递、学习曲线、额外合作等其他相关因素而造成持续时间增加。
  • 技术进步。在确定持续时间估算时,这个因素也可能发挥重要作用。例如,通过采购最新技术,制造工厂可以提高产量,而这可能会影响持续时间和资源需求。
  • 员工激励。项目经理还需要了解“学生综合征”(即拖延症)和帕金森定律,前者指出,人们只有在最后一刻,即快到期限时才会全力以赴;后者指出,只要还有时间,工作就会不断扩展,直到用完所有的时间。

应该把活动持续时间估算所依据的全部数据与假设都记录在案。

可作为本过程输入的项目文件包括(但不限于):

  • 活动属性。见 6.2.3.2 节。活动属性可能描述了确定的紧前或紧后关系、定义的提前量与滞后量以及可能影响持续时间估算的活动之间的逻辑关系。
  • 活动清单。见 6.2.3.1 节。活动清单列出了项目所需的、待估算的全部进度活动,这些活动的依赖关系和其他制约因素会对持续时间估算产生影响。
  • 假设日志。见 4.1.3.2 节。假设日志所记录的假设条件和制约因素有可能生成一个会影响项目进度的风险。
  • 经验教训登记册。见 4.4.3.1 节。与人力投入和持续时间估算有关的经验教训登记册可以运用到项目后续阶段,以提高人力投入和持续时间估算的准确性。
  • 里程碑清单。见 6.2.3.3 节。里程碑清单中可能已经列出特定里程碑的计划实现日期,这可能影响持续时间估算。
  • 项目团队派工单。见 9.3.3.1 节。将合适的人员分派到团队,为项目配备人员。
  • 资源分解结构。见 9.2.3.3 节。资源分解结构按照资源类别和资源类型,提供了已识别资源的层级结构。
  • 资源日历。见 9.2.1.2 节。资源日历中的资源可用性、资源类型和资源性质,都会影响进度活动的持续时间。资源日历规定了在项目期间特定的项目资源何时可用及可用多久。
  • 资源需求。见 9.2.3.1 节。估算的活动资源需求会对活动持续时间产生影响。对于大多数活动来说,所分配的资源能否达到要求,将对其持续时间有显著影响。例如,向某个活动新增资源或分配低技能资源,就需要增加沟通、培训和协调工作,从而可能导致活动效率或生产率下降,由此需要估算更长的持续时间。
  • 风险登记册。见 11.2.3.1 节。单个项目风险可能影响资源的选择和可用性。风险登记册的更新包括在项目文件更新中,见“规划风险应对” (11.5.3.2) 一节。

自下而上估算是一种估算项目持续时间或成本的方法,通过从下到上逐层汇总 WBS 组成部分的估算而得到项目估算。如果无法以合理的可信度对活动持续时间进行估算,则应将活动中的工作进一步细化,然后估算具体的持续时间,接着再汇总这些资源需求估算,得到每个活动的持续时间。活动之间可能存在或不存在会影响资源利用的依赖关系;如果存在,就应该对相应的资源使用方式加以说明,并记录在活动资源需求中。

制定进度计划是分析活动顺序、持续时间、资源需求和进度制约因素,创建进度模型,从而落实项目执行和监控的过程。本过程的主要作用是,为完成项目活动而制定具有计划日期的进度模型。

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

图 6-14制定进度计划:输入、工具与技术和输出

图 6-15制定进度计划:数据流程图

制定可行的项目进度计划是一个反复进行的过程。基于获取的最佳信息,使用进度模型来确定各项目活动和里程碑的计划开始日期和计划完成日期。编制进度计划时,需要审查和修正持续时间估算、资源估算和进度储备,以制定项目进度计划,并在经批准后作为基准用于跟踪项目进度。关键步骤包括定义项目里程碑、识别活动并排列活动顺序,以及估算持续时间。一旦活动的开始和完成日期得到确定,通常就需要由分配至各个活动的项目人员审查其被分配的活动。之后,项目人员确认开始和完成日期与资源日历没有冲突,也与其他项目或任务没有冲突,从而确认计划日期的有效性。最后分析进度计划,确定是否存在逻辑关系冲突,以及在批准进度计划并将其作为基准之前是否需要资源平衡。同时,需要修订和维护项目进度模型,确保进度计划在整个项目期间一直切实可行,见 6.7 节

有关进度规划的更多信息,参阅《进度计划实践标准》。

可作为本过程输入的项目文件包括(但不限于):

  • 活动属性。见 6.2.3.2 节。活动属性提供了创建进度模型所需的细节信息。
  • 活动清单。见 6.2.3.1 节。活动清单明确了需要在进度模型中包含的活动。
  • 假设日志。见 4.1.3.2 节。假设日志所记录的假设条件和制约因素可能造成影响项目进度的单个项目风险。
  • 估算依据。见 6.4.3.2 节。持续时间估算所需的支持信息的数量和种类,因应用领域而异。不论其详细程度如何,支持性文件都应该清晰、完整地说明持续时间估算是如何得出的。
  • 持续时间估算。见 6.4.3.1 节。持续时间估算包括对完成某项活动所需的工作时段数的定量评估,用于进度计划的推算。
  • 经验教训。见 4.4.3.1 节。与创建进度模型有关的经验教训登记册可以运用到项目后期阶段,以提高进度模型的有效性。
  • 里程碑清单。见 6.2.3.3 节。里程碑清单列出特定里程碑的实现日期。
  • 项目进度网络图。见 6.3.3.1 节。项目进度网络图中包含用于推算进度计划的紧前和紧后活动的逻辑关系。
  • 项目团队派工单。见 9.3.3.1 节。项目团队派工单明确了分配到每个活动的资源。
  • 资源日历。见 9.2.1.2 节。资源日历规定了在项目期间的资源可用性。
  • 资源需求。见 9.2.3.1 节。活动资源需求明确了每个活动所需的资源类型和数量,用于创建进度模型。
  • 风险登记册。见 11.2.3.1 节。风险登记册中的所有已识别的会影响进度模型的风险的详细信息及特征。进度储备则通过预期或平均风险影响程度,反映了与进度有关的风险信息。

资源优化用于调整活动的开始和完成日期,以调整计划使用的资源,使其等于或少于可用的资源。资源优化技术是根据资源供需情况,来调整进度模型的技术,包括(但不限于):

  • 资源平衡。为了在资源需求与资源供给之间取得平衡,根据资源制约因素对开始日期和完成日期进行调整的一种技术。如果共享资源或关键资源只在特定时间可用,数量有限,或被过度分配,如一个资源在同一时段内被分配至两个或多个活动(见图 6-17),就需要进行资源平衡。

也可以为保持资源使用量处于均衡水平而进行资源平衡。资源平衡往往导致关键路径改变。

而可以用浮动时间平衡资源。因此,在项目进度计划期间,关键路径可能发生变化。

  • 资源平滑。对进度模型中的活动进行调整,从而使项目资源需求不超过预定的资源限制的一种技术。相对于资源平衡而言,资源平滑不会改变项目关键路径,完工日期也不会延迟。也就是说,活动只在其自由和总浮动时间内延迟,但资源平滑技术可能无法实现所有资源的优化。

图 6-17资源平衡

见 4.3.2.2 节。项目管理信息系统包括进度计划软件,这些软件用活动、网络图、资源需求和活动持续时间等作为输入,自动生成开始和完成日期,从而可加快进度计划的编制过程。

项目进度模型中的进度数据是用以描述和控制进度计划的信息集合。进度数据至少包括进度里程碑、进度活动、活动属性,以及已知的全部假设条件与制约因素,而所需的其他数据因应用领域而异。经常可用作支持细节的信息包括(但不限于):

  • 按时段计列的资源需求,往往以资源直方图表示;
  • 备选的进度计划,如最好情况或最坏情况下的进度计划、经资源平衡或未经资源平衡的进度计划、有强制日期或无强制日期的进度计划;
  • 使用的进度储备。

进度数据还可包括资源直方图、现金流预测,以及订购与交付进度安排等其他相关信息。

可在本过程更新的项目文件包括(但不限于):

  • 活动属性。见 6.2.3.2 节。更新活动属性以反映在制定进度计划过程中所产生的对资源需求和其他相关内容的修改。
  • 假设日志。见 4.1.3.2 节。可能需要更新假设日志,以反映创建进度模型时发现的有关持续时间、资源使用、排序或其他信息的假设条件的变更。
  • 持续时间估算。见 6.4.3.1 节。资源的数量和可用性以及活动依赖关系可能会引起持续时间估算的变更。如果资源平衡分析改变了资源需求,就可能需要对持续时间估算做出相应的更新。
  • 经验教训登记册。见 4.4.3.1 节。在更新经验教训登记册时,可以增加能够有效和高效制定进度模型的技术。
  • 资源需求。见 9.2.3.1 节。资源平衡可能对所需资源类型与数量的初步估算产生显著影响。如果资源平衡分析改变了资源需求,就需要对资源需求做出相应的更新。
  • 风险登记册。见 11.2.3.1 节。可能需要更新风险登记册,以反映进度假设条件所隐含的机会或威胁。

可作为本过程输入的项目文件包括(但不限于):

  • 经验教训登记册。见 4.4.3.1 节。项目早期与制定成本估算有关的经验教训可以运用到项目后期阶段,以提高成本估算的准确度和精确度。
  • 项目进度计划。见 6.5.3.2 节。进度计划包括项目可用的团队和实物资源的类型、数量和可用时间长短。如果资源成本取决于使用时间的长短,并且成本出现季节波动,则持续时间估算(见 6.4.3.1 节)会对成本估算产生影响。进度计划还为包含融资成本(包括利息)的项目提供有用信息。
  • 资源需求。见 9.2.3.1 节。资源需求明确了每个工作包或活动所需的资源类型和数量。
  • 风险登记册。见 11.2.3.1 节。风险登记册包含了已识别并按优先顺序排列的单个项目风险的详细信息,及针对这些风险采取的应对措施。风险登记册还提供了可用于估算成本的详细信息。

项目资源管理包括识别、获取和管理所需资源以成功完成项目的各个过程,这些过程有助于确保项目经理和项目团队在正确的时间和地点使用正确的资源。

项目资源管理过程包括:

9.1 规划资源管理 — 定义如何估算、获取、管理和利用实物以及团队项目资源的过程。

9.2 估算活动资源 — 估算执行项目所需的团队资源,以及材料、设备和用品的类型和数量的过程。

9.3 获取资源 — 获取项目所需的团队成员、设施、设备、材料、用品和其他资源的过程。

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

9.5 管理团队 — 跟踪团队成员工作表现,提供反馈,解决问题并管理团队变更,以优化项目绩效的过程。

9.6 控制资源 — 确保按计划为项目分配实物资源,以及根据资源使用计划监督资源实际使用情况,并采取必要纠正措施的过程。

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

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

图 9-1项目资源管理概述

团队资源管理相对于实物资源管理,对项目经理提出了不同的技能和能力要求。实物资源包括设备、材料、设施和基础设施,而团队资源或人员指的是人力资源。项目团队成员可能具备不同的技能,可能是全职或兼职的,可能随项目进展而增加或减少。项目资源管理与项目相关方管理之间有重叠的部分(见 13 节),本节(第 9 节)则重点关注组成项目团队的部分相关方。

项目资源管理的核心概念项目团队由承担特定角色和职责的个人组成,他们为实现项目目标而共同努力。项目经理因此应在获取、管理、激励和增强项目团队方面投入适当的努力。尽管项目团队成员被分派了特定的角色和职责,但让他们全员参与项目规划和决策仍是有益的。团队成员参与规划阶段,既可使他们对项目规划工作贡献专业技能,又可以增强他们对项目的责任感。

项目经理既是项目团队的领导者又是项目团队的管理者。除了项目管理活动,例如启动、规划、执行、监控和关闭各个项目阶段,项目经理还负责建设高效的团队。项目经理应留意能够影响团队的不同因素,例如:

  • 团队环境;
  • 团队成员的地理位置;
  • 相关方之间的沟通;
  • 组织变更管理;
  • 内外部政治氛围;
  • 文化问题和组织的独特性;
  • 其他可能改变项目绩效的因素。

作为领导者,项目经理还负责积极培养团队技能和能力,同时提高并保持团队的满意度和积极性,项目经理还应留意并支持职业与道德行为,确保所有团队成员都遵守这些行为。

实物资源管理着眼于以有效和高效的方式,分配和使用成功完成项目所需的实物资源,如材料、设备和用品。为此,组织应当拥有如下数据:(当前和合理的未来的)资源需求、(可以满足这些需求的)资源配置,以及资源供应。不能有效管理和控制资源是项目成功完成的风险来源。例如:

  • 未能确保关键设备或基础设施按时到位,可能会推迟最终产品的制造;
  • 订购低质量材料可能会损害产品质量,导致大量召回或返工;
  • 保存太多库存可能会导致高运营成本,使组织盈利下降;另一方面,如果库存量太低,就可能无法满足客户需求,同样会造成组织盈利下降。

项目资源管理的趋势和新兴实践项目管理风格正在从管理项目的命令和控制结构,转向更加协作和支持性的管理方法,通过将决策权分配给团队成员来提高团队能力。此外,现代的项目资源管理方法致力于寻求优化资源使用。

有关项目资源管理的趋势和新兴实践包括(但不限于):

  • 资源管理方法。过去几年,由于关键资源稀缺,在某些行业中出现了一些普遍的趋势,涌现出很多关于精益管理、准时制 (JIT) 生产、Kaizen(持续改善)、全员生产维护 (TPM)、约束理论等方法的文献资料。项目经理应确定执行组织是否采用了一种或多种资源管理工具,从而对项目做出相应的调整。
  • 情商 (EI)。项目经理应提升内在(如自我管理和自我意识)和外在(如关系管理)能力,从而提高个人情商。研究表明,提高项目团队的情商或情绪能力可提高团队效率,还可以降低团队成员离职率。
  • 自组织团队。随着敏捷方法在 IT 项目中的应用越来越普遍,自组织团队(无需集中管控运作)越来越多。对于拥有自组织团队的项目,“项目经理”(可能不称为“项目经理”)的角色主要是为团队创造环境、提供支持并信任团队可以完成工作。成功的自组织团队通常由通用的专才而不是主题专家组成,他们能够不断适应变化的环境并采纳建设性反馈。
  • 虚拟团队/分布式团队。项目全球化推动了对虚拟团队的需求的增长。这些团队成员致力于同一个项目,却分布在不同的地方。沟通技术(如电子邮件、电话会议、社交媒体、网络会议和视频会议等)的使用,使虚拟团队变得可行。虚拟团队管理有独特的优势,例如能够利用项目团队的专业技术,即使相应的专家不在同一地理区域;将在家办公的员工纳入团队;以及将行动不便者或残疾人纳入团队。而虚拟团队管理面临的挑战主要在于沟通,包括可能产生孤立感、团队成员之间难以分享知识和经验、难以跟进进度和生产率,以及可能存在时区和文化差异。

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

  • 多元化。团队的多元化背景是什么?
  • 物理位置。团队成员和实物资源的物理位置在哪里?
  • 行业特定资源。所在行业需要哪些特殊资源?
  • 团队成员的获得。如何获得项目团队成员?项目团队资源是全职还是兼职?
  • 团队管理。如何管理项目团队建设?组织是否有管理团队建设的工具或是否需要创建新工具?

是否存在有特殊需求的团队成员?是否需要为团队提供有关多元化管理的特别培训?

  • 生命周期方法。项目采用哪些生命周期方法?

在敏捷或适应型环境中需要考虑的因素易变性高的项目得益于最大限度地集中和协作的团队结构,例如拥有通才的自组织团队。

协作旨在提高生产率和促进创新的问题解决方式。协作型团队可以促进不同工作活动的加速整合、改善沟通、增加知识分享,以及提供工作分配的灵活性和其他优势。

虽然协作的优势也适用于其他项目环境,协作型团队对于易变性高且快速变化的项目成功而言通常是至关重要的,因为集中分配任务和决策所需的时间更少。

对于易变性高的项目,实物和人力资源规划的可预测性要低得多。在这些环境中,关于快速供应和精益方法的协议,对控制成本和实现进度而言至关重要。

可作为本过程输入的项目文件包括(但不限于):

  • 活动属性。见 6.2.3.2 节。活动属性为估算活动清单中每项活动所需的团队和实物资源提供了主要数据来源,这些属性的例子包括资源需求、强制日期、活动地点、假设条件和制约因素。
  • 活动清单。见 6.2.3.1 节。活动清单识别了需要资源的活动。
  • 假设日志。见 4.1.3.2 节。假设日志可能包含有关生产力因素、可用性、成本估算以及工作方法的信息,这些因素会影响团队和实物资源的性质和数量。
  • 成本估算。见 7.2.3.1 节。资源成本从数量和技能水平方面会影响资源选择。
  • 资源日历。资源日历识别了每种具体资源可用时的工作日、班次、正常营业的上下班时间、周末和公共假期。在规划活动期间,潜在的可用资源信息(如团队资源、设备和材料)用于估算资源可用性。资源日历还规定了在项目期间确定的团队和实物资源何时可用、可用多久。这些信息可以在活动或项目层面建立,这考虑了诸如资源经验和/或技能水平以及不同地理位置等属性。
  • 风险登记册。见 11.2.3.1 节。风险登记册描述了可能影响资源选择和可用性的各个风险。

可在本过程更新的项目文件包括(但不限于):

  • 活动属性。见 6.2.3.2 节。活动属性依据资源需求而更新。
  • 假设日志。见 4.1.3.2 节。关于项目所需资源的类型和数量的假设条件,更新在假设日志中。此外,任何资源制约因素,包括集体劳资协议、连续工作时间、计划休假等,也应当相应更新。
  • 经验教训登记册。见 11.2.3.1 节。能够有效和高效地估算资源的技术,以及有关那些无效或低效的技术信息,更新在经验教训登记册中。

可作为本过程输入的项目文件包括(但不限于):

  • 项目进度计划。见 6.5.3.2 节。项目进度计划展示了各项活动及其开始和结束日期,有助于确定需要提供和获取资源的时间。
  • 资源日历。见 9.3.3.3 节。资源日历记录了每个项目资源在项目中的可用时间段。编制出可靠的进度计划,应依据对各个资源的可用性和时间限制(包括时区、工作时间、休假时间、当地节假日、维护计划和在其他项目的工作时间)的良好了解。资源日历需要在整个项目过程中渐进明细和更新。资源日历是本过程的输出,在重复本过程时随时可用。
  • 资源需求。见 9.2.3.1 节。资源需求识别了需要获取的资源。
  • 相关方登记册。见 13.1.3.1 节。相关方登记册可能会发现相关方对项目特定资源的需求或期望,在获取资源过程中应加以考虑。

可在本过程更新的项目文件包括(但不限于):

  • 经验教训登记册。见 4.4.3.1 节。项目中遇到的挑战、本可以规避这些挑战的方法,以及良好的资源获取方式更新在经验教训登记册中。
  • 项目进度计划。见 6.5.3.2 节。所需资源的可用性可能会导致项目进度的变更。
  • 资源分解结构。见 9.2.3.3 节。在本过程中获取的资源应记录到资源分解结构中。
  • 资源需求。见 9.2.3.1 节。可更新资源需求文件,以反映获取的项目资源。
  • 风险登记册。见 11.2.3.1 节。本过程中识别的新风险记录在风险登记册中,并通过风险管理过程进行管理。
  • 相关方登记册。见 13.1.3.1 节。增加的任何新的相关方,以及在本过程中获得的有关现有相关方的新信息更新在相关方登记册中。

见 4.5.3.1 节。工作绩效报告是为制定决策、采取行动或引起关注所形成的实物或电子工作绩效信息,它包括从进度控制、成本控制、质量控制和范围确认中得到的结果,有助于项目团队管理。

绩效报告和相关预测报告中的信息,有助于确定未来的团队资源需求,认可与奖励,以及更新资源管理计划。

可作为本过程输入的项目文件包括(但不限于):

  • 问题日志。见 4.3.3.3 节。问题日志用于识别有关缺乏资源、原材料供应延迟,或低等级原材料等问题。
  • 经验教训登记册。见 4.4.3.1 节。在项目早期获得的经验教训可以运用到后期阶段,以改进实物资源控制。
  • 实物资源分配。见 9.3.3.1 节。实物资源分配描述了资源的预期使用情况以及资源的详细信息,例如类型、数量、地点以及属于组织内部资源还是外购资源。
  • 项目进度计划。见 6.5.3.2 节。项目进度计划展示了项目在何时何地需要哪些资源。
  • 资源分解结构。见 9.2.3.3 节。资源分解结构为项目过程中需要替换或重新获取资源的情况提供了参考。
  • 资源需求。见 9.2.3.1 节。资源需求识别了项目所需的材料、设备、用品和其他资源。
  • 风险登记册。见 11.2.3.1 节。风险登记册识别了可能会影响设备、材料或用品的单个风险。

见 4.5.1.3 节。工作绩效信息包括项目工作进展信息,这一信息将资源需求和资源分配与项目活动期间的资源使用相比较,从而发现需要处理的资源可用性方面的差异。

可作为本过程输入的项目文件包括(但不限于):

  • 假设日志。见 4.1.3.2 节。假设日志所记录的假设条件和制约因素可能引发单个项目风险,还可能影响整体项目风险的级别。
  • 成本估算。见 7.2.3.1 节。成本估算是对项目成本的定量评估,理想情况下用区间表示,区间的大小预示着风险程度。对成本估算文件进行结构化审查,可能显示当前估算不足,从而引发项目风险。
  • 持续时间估算。见 6.4.3.1 节。持续时间估算是对项目持续时间的定量评估,理想情况下用区间表示,区间的大小预示着风险程度。对持续时间估算文件进行结构化审查,可能显示当前估算不足,从而引发项目风险。
  • 问题日志。见 4.3.3.3 节。问题日志所记录的问题可能引发单个项目风险,还可能影响整体项目风险的级别。
  • 经验教训登记册。见 4.4.3.1 节。可以查看与项目早期所识别的风险相关的经验教训,以确定类似风险是否可能在项目的剩余时间再次出现。
  • 需求文件。见 5.2.3.1 节。需求文件列明了项目需求,使团队能够确定哪些需求存在风险。
  • 资源需求。见 9.2.3.1 节。资源需求是对项目所需资源的定量评估,理想情况下用区间表示,区间的大小预示着风险程度。对资源需求文件进行结构化审查,可能显示当前估算不足,从而引发项目风险。
  • 相关方登记册。见 13.1.3.1 节。相关方登记册规定了哪些个人或小组可能参与项目的风险识别工作,还会详细说明哪些个人适合扮演风险责任人角色。

可作为本过程输入的项目文件包括(但不限于):

  • 假设日志。见 4.1.3.2 节。如果认为假设条件会引发项目风险,那么就应该把它们列作定量风险分析的输入。在定量风险分析期间,也可以建立模型来分析制约因素的影响。
  • 估算依据。见 6.4.3.2 节和 7.2.3.2 节。开展定量风险分析时,可以把用于项目规划的估算依据反映在所建立的变异性模型中。可能包括估算目的、分类、准确性、方法论和资料来源。
  • 成本估算。见 7.2.3.1 节。成本估算提供了对成本变化性进行评估的起始点。
  • 成本预测。见 7.4.3.2 节。成本预测包括项目的完工尚需估算 (ETC)、完工估算 (EAC)、完工预算(BAC) 和完工尚需绩效指数(TCP)。把这些预测指标与定量成本风险分析的结果进行比较,以确定与实现这些指标相关的置信水平。
  • 持续时间估算。见 6.4.3.1 节。持续时间估算提供了对进度变化性进行评估的起始点。
  • 里程碑清单。见 6.2.3.3 节。项目的重大事件决定着进度目标。把这些进度目标与定量进度风险分析的结果进行比较,以确定与实现这些目标相关的置信水平。
  • 资源需求。见 9.2.3.1 节。资源需求提供了对变化性进行评估的起始点。
  • 风险登记册。见 11.2.3.1 节。风险登记册包含了用作定量风险分析的输入的单个项目风险的详细信息。
  • 风险报告。见 11.2.3.2 节。风险报告描述了整体项目风险的来源,以及当前的整体项目风险状态。
  • 进度预测。见 6.6.3.2 节。可以将预测与定量进度风险分析的结果进行比较,以确定与实现预测目标相关的置信水平。

要开展定量风险分析,就需要建立能反映单个项目风险和其他不确定性来源的定量风险分析模型,并为之提供输入。

如果活动的持续时间、成本或资源需求是不确定的,就可以在模型中用概率分布来表示其数值的可能区间。概率分布可能有多种形式,最常用的有三角分布、正态分布、对数正态分布、贝塔分布、均匀分布或离散分布。应该谨慎选择用于表示活动数值的可能区间的概率分布形式。

单个项目风险可以用概率分布图表示,或者,也可以作为概率分支包括在定量分析模型中。在后一种情况下,应在概率分支上添加风险发生的时间和(或)成本影响,以及在特定模拟中风险发生的概率情况。如果风险的发生与任何计划活动都没有关系,就最适合将其作为概率分支。如果风险之间存在相关性,例如有某个共同原因或逻辑依赖关系,那么应该在模型中考虑这种相关性。

其他不确定性来源也可用概率分支来表示,以描述贯穿项目的其他路径。

可作为本过程输入的项目文件包括(但不限于):

  • 里程碑清单。见 6.2.3.3 节。重要里程碑清单说明卖方需要在何时交付成果。
  • 项目团队派工单。见 9.3.3.2 节。项目团队派工单包含关于项目团队技能和能力的信息,以及他们可用于支持采购活动的时间。如果项目团队不具备开展采购活动的能力,则需要外聘人员或对现有人员进行培训,或者二者同时进行。
  • 需求文件。见 5.2.3.1 节。需求文件可能包括:
  • 卖方需要满足的技术要求;
  • 具有合同和法律意义的需求,如健康、安全、安保、绩效、环境、保险、知识产权、同等就业机会、执照、许可证,以及其他非技术要求。
  • 需求跟踪矩阵。见 5.2.3.2 节。需求跟踪矩阵将产品需求从其来源连接到能满足需求的可交付成果。
  • 资源需求。见 9.2.3.1 节。资源需求包含关于某些特定需求的信息,例如,可能需要采购的团队及实物资源。
  • 风险登记册。见 11.2.3.1 节。风险登记册列明风险清单,以及风险分析和风险应对规划的结果。有些风险应通过采购协议转移给第三方。
  • 相关方登记册。见 13.1.3.1 节。相关方登记册提供有关项目参与者及其项目利益的详细信息,包括监管机构、合同签署人员和法务人员。

可在本过程更新的项目文件包括(但不限于):

  • 经验教训登记册。见 4.4.3.1 节。更新经验教训登记册,记录能有效维护采购工作的范围、进度和成本的技术。对于出现的偏差,经验教训登记册应该记录曾采取的纠正措施及其有效性。

如果已经发生索赔,则应记录相关信息以避免重蹈覆辙,其他关于如何改善采购过程的信息也应记录在内。

  • 资源需求。见 9.2.3.1 节。随着承包商的工作进展,可能因工作执行不符合原定计划而需要变更资源需求。
  • 需求跟踪矩阵。见 5.2.3.2 节。更新需求跟踪矩阵,记录已实现的需求。
  • 风险登记册。见 11.2.3.1 节。取决于卖方的组织、合同的持续时间、外部环境、项目交付方法、所选合同类型,以及最终商定的价格,每个被选中的卖方都会带来特殊的风险。随着早期风险的过时以及新风险的出现,在项目执行期间对风险登记册进行变更。
  • 相关方登记册。见 13.1.3.1 节。随着执行阶段的工作进展,承包商和供应商可能发生变更,应该把承包商和供应商的变更情况记录在相关方登记册中。

可用作本过程输入的项目文件包括(但不限于):

  • 活动属性;
  • 活动清单;
  • 假设日志;
  • 经验教训登记册;
  • 里程碑清单;
  • 项目团队派工单;
  • 资源分解结构;
  • 资源日历;
  • 资源需求;
  • 风险登记册。

制定进度计划是分析活动顺序、持续时间、资源需求和进度制约因素,创建进度模型,从而落实项目执行和监控的过程。本过程的主要作用是,为完成项目活动而制定具有计划日期的进度模型。

本过程需要在整个项目期间开展。图 3-11 描述了本过程的输入和输出。

图 3-11制定进度计划:输入和输出

究竟需要哪些项目管理计划组件和项目文件,取决于具体项目的需求。

可用作本过程输入的项目文件包括(但不限于):

  • 活动属性;
  • 活动清单;
  • 假设日志;
  • 估算依据;
  • 持续时间估算;
  • 经验教训登记册;
  • 里程碑清单;
  • 项目进度网络图;
  • 项目团队派工单;
  • 资源日历;
  • 资源需求;
  • 风险登记册。

可在本过程更新的项目文件包括(但不限于):

  • 活动属性;
  • 假设日志;
  • 持续时间估算;
  • 经验教训登记册;
  • 资源需求;
  • 风险登记册。

可用作本过程输入的项目文件包括(但不限于):

  • 经验教训登记册;
  • 项目进度计划;
  • 资源需求;
  • 风险登记册。

可用作本过程输入的项目文件包括(但不限于):

  • 假设日志;
  • 成本估算;
  • 持续时间估算;
  • 问题日志;
  • 经验教训登记册;
  • 需求文件;
  • 资源需求;
  • 相关方登记册。

可用作本过程输入的项目文件包括(但不限于):

  • 假设日志;
  • 估算依据;
  • 成本估算;
  • 成本预测;
  • 持续时间估算;
  • 里程碑清单;
  • 资源需求;
  • 风险登记册;
  • 风险报告;
  • 进度预测。

可用作本过程输入的项目文件包括(但不限于):

  • 里程碑清单;
  • 项目团队派工单;
  • 需求文件;
  • 需求跟踪矩阵;
  • 资源需求;
  • 风险登记册;
  • 相关方登记册。

可用作本过程输入的项目文件包括(但不限于):

  • 项目进度计划;
  • 资源日历;
  • 资源需求;
  • 相关方登记册。

可在本过程更新的项目文件包括(但不限于):

  • 经验教训登记册;
  • 项目进度计划;
  • 资源分解结构;
  • 资源日历;
  • 资源需求;
  • 风险登记册;
  • 相关方登记册。

可用作本过程输入的项目文件包括(但不限于):

  • 问题日志;
  • 经验教训登记册;
  • 物质资源分配单;
  • 项目进度计划;
  • 资源分解结构;
  • 资源需求;
  • 风险登记册。

可在本过程更新的项目文件包括(但不限于):

  • 经验教训登记册;
  • 资源需求;
  • 需求跟踪矩阵;
  • 风险登记册;
  • 相关方登记册。