导读:本文主要概括在第七版的PMBOK中提到八大绩效域之一的交付绩效域管理相关内容。项目管理过程仅仅围绕产出的交付物(交付价值)服务,项目交付聚焦干满足需求、范围和质量期望,产生预期的可交付物,以推动想要的项目成果,如何在多重约束条件下管理好交付是项目管理的重中之重。
目录
1、交付绩效域概述
交付绩效域涉及与交付项目要实现的范围和质量相关的活动和功能。项目支持战略执行和商业目标的推进。项目交付聚焦干满足需求、范围和质量期望,产生预期的可交付物,以推动想要的项目成果。
有效执行此绩效域将产生以下预期成果:
- 项目有助于实现业务目标和推进战略。
- 项目实现了启动它们要交付的成果。
- 在规划的时间框架内实现了项目收益。
- 项目团队对需求有清晰的理解。
- 干系人接受项目可交付物,并对其感到满意。
与绩效域有关的定义:
1、需求:为满足业需要,某个产品、服务或结果必须达到的条件或具备的能力。
2、工作分解结构 (WBS):对项目团队为实现项目目标、创建所需可交付物,而需要实施的全部工作范围的层级分解。
3、完成的定义 (DoD):为了考虑可交付物能供客户使用,而须达到的所有准则的检查清单。质量。一系列内在特征满足需求的程度。
4、质量成本 (COQ):在整个产品生命周期所产生的以下所有成本,即:为预防产品或服务不符合要求而进行的投资,为评估产品或服务是否符合要求而产生的成本,以及因产品或服务未达到要求而带来的损失。
2、价值的交付
对于其使用的开发方法支持在整个项目生命周期内发布可交付物的项目,可以在项目期间开始向业务、客户或其他干系人交付价值。在项目生命周期结束时交付大量可交付物的项目会在初始部署后产生价值。
3、可交付物
可交付物是指项目的临时或最终的产品、服务或结果。可交付物有助于取得项目所要实现的成果。可交付物反映了干系人需求、范围和质量,以及对利润、人员和地球环境的长期影响。
3.1 需求
需求是指为满足商业需要,某个产品、服务或结果必须达到的条件或具备的能力。需求可以是非常高层级的,例如商业论证中发现的需求,也可以非常详细,例如在系统组件的验收标准中发现的需求。
3.1.1 需求启发
明确记录的需求符合以下标准:
清晰:只有一种解释需求的方式。
简洁:要用尽可能少的文字表述需求。
可核实:有一种方法可以核实需求是否已得到满足。
一致性:没有相互矛盾的需求。
完整:整组需求代表了当前项目或产品需要的全部。
可跟踪:每个需求都可以由一个唯一的标识码来识别。
3.1.2 不断演变和发现的需求
对于没有预先明确定义需求的项目,可以使用原型、演示、故事板和模型,来演变需求。在这些情况下,干系人更有可能采取"眼见为实"的方法来制定需求。需求演变常见干使用迭代型、增量型或适应型开发方法的项目。在某些情况下,会产生改变需求的新机会。
3.1.3 管理需求
无论需求是否是已预先记录的,不断演变的,还是后来发现的,都需要对其进行管理。无效的需求管理可能导致返工、范围蔓延、客户不满意、预算超支、进度延迟和总体项目失败。因此,许多项目都设有一名需求管理的负责人。此人可以担任商业分析师、产品负责人、价值工程师或其他职务。
需求管理人员可以使用专用软件、待办事项列表、索引卡、跟踪矩阵或其他方法来确保需求
灵活性与稳定性之间处于适当的水平,并且新的和不断变化的需求得到所有相关干系人的同意。
3.2 范围定义
随着需求被识别,满足这些需求的范围也应被定义。范围是项目所提供的产品、服务和结果的总和。随着范围被定义,还需要识别更多的需求。因此,与需求一样,范围可以预先被定义好,也可以随着时间的推移而演变,或可以被发现。
3.2.1 范围分解
可以使用范围说明书来阐明范围,以识别与项目关联的主要可交付物以及每个可交付物的验收标准。还可以通过使用工作分解结构(WBS)将范围分解为较低层级的细节,从而详细说明范围。WBS是对项目团队为实现项目目标、创建所需可交付物,而需要实施的全部工作范围的层级分解。该层级往下的每一个层级代表着关于可交付物的更详细的信息以及生成可交付物所需的工作。
详细说明范围的另一种方法是在敏捷章程、路线图或作为产品层级结构的一部分来确定项目的各个主题。这些代表着大量用户价值的主题可表示为用户故事,该用户故事与诸如功能、数据源,或安全级别等常见因素相关。为了完成这些主题,项目团队会开发史诗故事。史诗故事是一种逻辑容器,用于容纳因太大而无法在一个迭代中完成的较大的用户故事。史诗故事可以分解为多个特性,这些特性是一组通常被描述为简短的短语或功能的相关需求,代表着产品的特定行为。每个特性都有多个用户故事。用户故事是向特定用户提供的成果的简要描述,而且确保可以通过对话澄清细节。项目团队会在负责的最后责任时刻定义故事细节,以避免在范围发生变更时造成规划浪费。故事可清晰且简洁地描述从最终用户的角度编写的需求。
3.2.2 完成可交付物
验收或完成的标准:会记录在范围说明书中。在客户验收可交付物之前,或在项目被视为完成之前需要满足的标准通常
技术绩效测量指标:产品的技术规范可能记录在单独的规范文件中,也可能记录为 WBS 的扩展。这一扩展称为 WBS 字典,它详细说明了 WBS 中每项可交付物(工作包)的信息。
完成的定义:可将完成的定义与适应型方法一起使用,特别是在软件开发项目中。它是为了考虑可交付物能供客户使用,而须达到的所有标准的检查清单。
3.3.3 完成的目标不断移动
在不确定和快速变化的环境中运行的项目面临着"足够好可以发布"或"已完成"的目标可能会发生变化的情况。在竞争对手频繁发布新产品的市场中,新的发布中计划的特性可能会有所更新。同样,新的技术趋势例如移动设备或可穿戴设备)可能会触发方向变化或引入新的需求。这也体现了支持
在更加稳定的环境中运行的项目通常会面临"范围蔓延"。在这种情况下,将接受额外的范围或需求,而不对相应的进度、预算或资源需要等做出调整。为了应对范围蔓延,项目团队会使用变更控制系统,在该系统中评估所有变更,以了解变更为项目带来的潜在价值,及实现该价值所需的潜在资源、时间和预算。然后,项目团队将这些变更提交给项目治理机构、产品负责人或高管发起人,以待其正式批准。
4、质量
交付不仅仅只是范围和需求。范围和需求聚焦于需要交付的内容。质量聚焦于需要达到的绩效水平。质量需求可能会反映在完成标准、完成的定义、工作说明书或需求文件中。
4.1 质量成本
质量成本(COQ)这种方法用于在质量预防和评估之间找到恰当的投资平衡点,以避免缺陷或产品失败。该模型确定了与质量相关的四类成本∶预防、评估、内部失败和外部失败。预防成本和评估成本与质量需求一致性成本有关。内部和外部失败成本与非一致性成本相关。
4.1.1 预防
预防成本的产生是为了防止产品出现缺陷和失败。预防成本可避免质量问题。它们与质量管 理体系的设计、实施和维护相关。它们是在实际运营之前计划和产生的。
- 产品或服务需求:例如制定来料、流程、成品和服务的规范;
- 质量规划:例如制定质量、可靠性、运营、生产和检查的计划;
- 质量保证:例如质量体系的创建和维护;
- 培训:例如项目集的开发、准备和维护。
4.1.2 评估
评估成本的产生是为了确定对质量要求的符合程度。评估成本与质量有关的测量和监督活动相关。这些成本可能与评估采购材料、流程、产品和服务相关,以确保它们符合规范。它们可能包括:
- 少核实:例如根据商定的规范检查来料、流程设置和产品;
- 质量审计:例如确认质量体系是否正常运作;
- 供应商评级:例如对产品和服务供应商的评价和批准。
4.1.3 内部失败
内部失败成本与在客户收到产品之前查找和纠正缺陷相关。工作结果未达到设计质量 标准时就会产生这些成本。
- 浪费:例如执行不必要的工作,或持有过高的库存是因为错误、组织不善或沟通不畅;
- 报废:例如无法修理、使用或出售的缺陷产品或材料;
- 返工或校正:例如纠正缺陷材料或错误; >
- 失败分析:例如确定内部产品或服务失败原因所需的活动。
4.1.4 外部成本
外部失败成本与客户拥有产品后发现的缺陷相关,也与补救工作相关。请注意,要全面考虑这些失败,需要考虑项目产品在数月或数年后运行时的情况,而不仅仅是在移交的日期。当未能达到设计质量标准的产品或服务在交给客户后才被发现,就会发生外部失败成本。
- 修理和服务:这针对的是退回和已部署的产品;
- 保修索赔:例如更换故障产品或在保修期内重新提供的服务;
- 投诉:与处理和服务客户投诉相关的所有工作和成本;
- 退货:用于处理和调查被拒绝或被召回的产品,包括运输成本;
- 声誉:这适用于根据缺陷的类型和严重程度,声誉和公众认知可能会受到损害的情况。
TIPS:
为了优化所交付的价值,聚焦于尽早发现质量问题的早期检查和审查工作都是良好的投入。在开发生命周期的后期尝试"测试质量"可能会失败,因为在开发后期发现质量问题会造成时间的增加和高昂的成本,这是由于高报废率和返工率,伴随着对下游输出和干系人的连锁反应。
4.2 变更成本
发现缺陷的时间越晚,纠正缺陷的成本就越高。这是因为设计和开发工作通常已经基于有缺陷的组件而进行。此外,随着生命周期的进展,活动的调整成本有所增加,因为更多的干系人会受到影响。变更成本曲线可以描述这种现象。
5、次优的成果
所有项目都试图交付成果,尽管有些项目也许未能实现此目标,或可能会产生次优成果。每个项目中都存在次优成果的可能性,在一个完全属于试验性的项目中,组织正在试图取得突破,例如创造一种全新的技术。这需要对不确定的成果进行有意图的投资。生产新药物或化合物的公司在找到成功的配方之前可能会经历多次失败。
有些项目可能无法交付成果,因为市场机会已经擦肩而过,或者竞争对手已抢先推出产品。有效的项目管理可以最小化负面结果,但这种可能性是试图产生独特可交付物所面临的不确定性的一部分。
6、 与其他绩效域的相互作用
交付绩效域是在规划绩效域中所执行所有工作的累积。交付节奏是基于开发方法和生命周期绩效域中工作的结构方式。项目工作绩效域通过建立各种过程、管理实物资源、管理采购等促使交付工作。项目团队成员为有关干系人在此绩效域中执行工作。创建交付的工作性质会影响项目团队驾驭不确定性的方式,该不确定性会对项目产生影响。
7、检查结果
(本文完)