全部展开 全部合拢

8.2.2.5 审计

审计是用于确定项目活动是否遵循了组织项目的政策、过程与程序的一种结构化且独立的过程。质量审计通常由项目外部的团队开展,如组织内部审计部门、项目管理办公室 (PMO) 或组织外部的审计师。质量审计目标可能包括(但不限于):

  • 识别全部正在实施的良好及最佳实践;
  • 识别所有违规做法、差距及不足;
  • 分享所在组织和/或行业中类似项目的良好实践;
  • 积极、主动地提供协助,以改进过程的执行,从而帮助团队提高生产效率;
  • 强调每次审计都应对组织经验教训知识库的积累做出贡献。

采取后续措施纠正问题,可以降低质量成本,并提高发起人或客户对项目产品的接受度。质量审计可事先安排,也可随机进行;可由内部或外部审计师进行。

质量审计还可确认已批准的变更请求(包括更新、纠正措施、缺陷补救和预防措施)的实施情况。

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

  • 启动和规划
    • 指南和标准,用于裁剪组织标准流程和程序以满足项目的特定要求;
    • 特定的组织标准,例如政策(如人力资源政策、健康与安全政策、安保与保密政策、质量政策、采购政策和环境政策);
    • 产品和项目生命周期,以及方法和程序(如项目管理方法、评估指标、过程审计、改进目标、核对单、组织内使用的标准化的过程定义);
    • 模板(如项目管理计划、项目文件、项目登记册、报告格式、合同模板、风险分类、风险描述模板、概率与影响的定义、概率和影响矩阵,以及相关方登记册模板);
    • 预先批准的供应商清单和各种合同协议类型(如总价合同、成本补偿合同和工料合同)。
  • 执行、监控:
    • 变更控制程序,包括修改组织标准、政策、计划和程序(或任何项目文件)所须遵循的步骤,以及如何批准和确认变更;
    • 跟踪矩阵;
    • 财务控制程序(如定期报告、必需的费用与支付审查、会计编码及标准合同条款等);
    • 问题与缺陷管理程序(如定义问题和缺陷控制、识别与解决问题和缺陷,以及跟踪行动方案)。
    • 资源的可用性控制和分配管理;
    • 组织对沟通的要求(如可用的沟通技术、许可的沟通媒介、记录保存政策、视频会议、协同工具和安全要求);
    • 确定工作优先顺序、批准工作与签发工作授权的程序;
    • 模板(如风险登记册、问题日志和变更日志);
    • 标准化的指南、工作指示、建议书评价准则和绩效测量准则;
    • 产品、服务或成果的核实和确认程序。
  • 收尾项目收尾指南或要求(如项目终期审计、项目评价、可交付成果验收、合同收尾、资源分配,以及向生产和(或)运营部门转移知识)

项目管理办公室 (PMO) 是对与项目相关的治理过程进行标准化,并促进资源、方法论、工具和技术共享的一个组织结构。PMO 的职责范围可大可小,从提供项目管理支持服务,到直接管理一个或多个项目。

PMO 有几种不同类型,它们对项目的控制和影响程度各不相同,例如:

  • 支持型。支持型 PMO 担当顾问的角色,向项目提供模板、最佳实践、培训,以及来自其他项目的信息和经验教训。这种类型的 PMO 其实就是一个项目资源库,对项目的控制程度很低。
  • 控制型。控制型 PMO 不仅给项目提供支持,而且通过各种手段要求项目服从,这种类型的 PMO对项目的控制程度属于中等。服从可能包括:
  • 采用项目管理框架或方法论;
  • 使用特定的模板、格式和工具;
  • 服从治理。
  • 指令型。指令型 PMO 直接管理和控制项目。项目经理由 PMO 指定并向其报告。这种类型的 PMO对项目的控制程度很高。

项目管理办公室可能会承担整个组织范围的职责,在支持战略调整和创造组织价值方面发挥重要的作用。PMO 从组织战略项目中获取数据和信息,进行综合分析,评估如何实现更高级别的战略目标的。PMO 在组织的项目组合、项目集、项目与组织考评体系(如平衡计分卡)之间建立联系。

除了被集中管理以外,PMO 所支持和管理的项目不一定彼此关联。PMO 的具体形式、职能和结构取决于所在组织的需要。

为了保证项目符合组织的业务目标,PMO 可能有权在每个项目的生命周期中充当重要相关方和关键决策者。PMO 可以:

  • 提出建议;
  • 领导知识传递;
  • 终止项目;
  • 根据需要采取其他行动。

PMO 的一个主要职能是通过各种方式向项目经理提供支持,这些方式包括(但不限于):

  • 对 PMO 所辖的全部项目的共享资源进行管理;
  • 识别和制定项目管理方法、最佳实践和标准;
  • 指导、辅导、培训和监督;
  • 通过项目审计,监督对项目管理标准、政策、程序和模板的遵守程度;
  • 制定和管理项目政策、程序、模板和其他共享的文件(组织过程资产);
  • 对跨项目的沟通进行协调。

为了便于开展配置和变更管理,可以使用一些手动或自动化的工具。配置控制重点关注可交付成果及各个过程的技术规范,而变更控制则着眼于识别、记录、批准或否决对项目文件、可交付成果或基准的变更。

工具的选择应基于项目相关方的需要,包括考虑组织和环境情况和(或)制约因素。工具应支持以下配置管理活动:

  • 识别配置项。识别与选择配置项,从而为定义与核实产品配置、标记产品和文件、管理变更和明确责任提供基础。
  • 记录并报告配置项状态。关于各个配置项的信息记录和报告。
  • 进行配置项核实与审计。通过配置核实与审计,确保项目的配置项组成的正确性,以及相应的变更都被登记、评估、批准、跟踪和正确实施,从而确保配置文件所规定的功能要求都已实现。

工具还应支持以下变更管理活动:

  • 识别变更。识别并选择过程或项目文件的变更项。
  • 记录变更。将变更记录为合适的变更请求。
  • 做出变更决定。审查变更,批准、否决、推迟对项目文件、可交付成果或基准的变更或做出其他决定。
  • 跟踪变更。确认变更被登记、评估、批准、跟踪并向相关方传达最终结果。

也可以使用工具来管理变更请求和后续的决策,同时还要格外关注沟通,以帮助变更控制委员会的成员履行职责,以及向相关方传达决定。

结束项目或阶段是终结项目、阶段或合同的所有活动的过程。本过程的主要作用是,存档项目或阶段信息,完成计划的工作,释放组织团队资源以展开新的工作。它仅开展一次或仅在项目的预定义点开展。图 4-14 描述本过程的输入、工具与技术和输出。图 4-15 是本过程的数据流向图。

图 4-14结束项目或阶段:输入、工具与技术和输出

图 4-15结束项目或阶段:数据流向图

• Projectcharter在结束项目时,项目经理需要回顾项目管理计划,确保所有项目工作都已完成以及项目目标均已实现。项目或阶段行政收尾所需的必要活动包括(但不限于):

  • 为达到阶段或项目的完工或退出标准所必须的行动和活动,例如:
  • 确保所有文件和可交付成果都已是最新版本,且所有问题都已得到解决;
  • 确认可交付成果已交付给客户并已获得客户的正式验收;
  • 确保所有成本都已记入项目成本账;
  • 关闭项目账户;
  • 重新分配人员;
  • 处理多余的项目材料;
  • 重新分配项目设施、设备和其他资源;
  • 根据组织政策编制详尽的最终项目报告。
  • 为关闭项目合同协议或项目阶段合同协议所必须开展的活动,例如nn确认卖方的工作已通过正式验收;
  • 最终处置未决索赔;
  • 更新记录以反映最后的结果;
  • 存档相关信息供未来使用。
  • 为完成下列工作所必须开展的活动:
  • 收集项目或阶段记录;
  • 审计项目成败;
  • 管理知识分享和传递;
  • 总结经验教训;
  • 存档项目信息以供组织未来使用。
  • 为向下一个阶段,或者向生产和(或)运营部门移交项目的产品、服务或成果所必须开展的行动和活动。
  • 收集关于改进或更新组织政策和程序的建议,并将它们发送给相应的组织部门。
  • 测量相关方的满意程度。

如果项目在完工前就提前终止,结束项目或阶段过程还需要制定程序,来调查和记录提前终止的原因。为了实现上述目的,项目经理应该引导所有合适的相关方参与本过程。

能够影响结束项目或阶段过程的组织过程资产包括(但不限于):

  • 项目或阶段收尾指南或要求(如经验教训、项目终期审计、项目评价、产品确认、验收标准、合同收尾、资源重新分配、团队绩效评估,以及知识传递);
  • 配置管理知识库,包括组织标准、政策、程序和项目文件的各种版本及基准。

见 4.1.2.1 节。应该就以下主题,考虑具备相关专业知识或接受过相关培训的个人或小组的意见:

  • 管理控制;
  • 审计;
  • 法规与采购;
  • 法律法规。

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

项目范围管理过程包括:

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

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

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

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

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

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

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

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

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

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

  • 产品范围。某项产品、服务或成果所具有的特征和功能。
  • 项目范围 。为交付具有规定特性与功能的产品、服务或成果而必须完成的工作。项目范围有时也包括产品范围。

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

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

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

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

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

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

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

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

  • 确定问题并识别商业需要;
  • 识别并推荐能够满足这些需要的可行解决方案;
  • 收集、记录并管理相关方需求,以满足商业和项目目标;
  • 推动项目集或项目的产品、服务或最终成果的成功应用 [7]。

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

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

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

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

  • 知识和需求管理。组织是否拥有正式或非正式的知识和需求管理体系?为了在未来项目中重复使用需求,项目经理应建立哪些指南?
  • 确认和控制。组织是否拥有正式或非正式的与确认和控制相关的政策、程序和指南?
  • 开发方法。组织是否采用敏捷方法管理项目?开发方法属于迭代型还是增量型?是否采用预测型方法?混合型方法是否有效?
  • 需求的稳定性。项目中是否存在需求不稳定的领域?是否有必要采用精益、敏捷或其他适应型技术来处理不稳定的需求,直至需求稳定且定义明确?
  • 治理。组织是否拥有正式或非正式的审计和治理政策、程序和指南?

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

项目成本管理包括为使项目在批准的预算内完成而对成本进行规划、估算、预算、融资、筹资、管理和控制的各个过程,从而确保项目在批准的预算内完工。项目成本管理过程包括:

7.1 规划成本管理 — 确定如何估算、预算、管理、监督和控制项目成本的过程。

7.2 估算成本 — 对完成项目活动所需货币资源进行近似估算的过程。

7.3 制定预算 — 汇总所有单个活动或工作包的估算成本,建立一个经批准的成本基准的过程。

7.4 控制成本 — 监督项目状态,以更新项目成本和管理成本基准变更的过程。

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

限分明和相互独立的形式出现,但在实践中它们会以本指南无法全面详述的方式相互交叠和相互作用。这些过程不仅彼此相互作用,而且还与其他知识领域中的过程相互作用。

在某些项目,特别是范围较小的项目中,成本估算和成本预算之间的联系非常紧密,以至于可视为一个过程,由一个人在较短时间内完成。但本章仍然把这两个过程分开来介绍,因为它们所用的工具和技术各不相同。对成本的影响力在项目早期最大,因此尽早定义范围就至关重要(见 5.3 节)。

图 7-1项目成本管理概述

项目成本管理的核心概念项目成本管理重点关注完成项目活动所需资源的成本,但同时也应考虑项目决策对项目产品、服务或成果的使用成本、维护成本和支持成本的影响。例如,限制设计审查的次数可降低项目成本,但可能增加由此带来的产品运营成本。

成本管理的另一个方面是认识到不同的相关方会在不同的时间,用不同的方法测算项目成本。

例如,对于某采购品,可在做出采购决策、下达订单、实际交货、实际成本发生或进行项目会计记账时,测算其成本。在很多组织中,预测和分析项目产品的财务效益是在项目之外进行的,但对于有些项目,如固定资产投资项目,可在项目成本管理中进行这项预测和分析工作。在这种情况下,项目成本管理还需使用其他过程和许多通用财务管理技术,如投资回报率分析、现金流贴现分析和投资回收期分析等。

项目成本管理的趋势和新兴实践在项目成本管理的实践中,通过对挣值管理 (EVM)的扩展,引入挣得进度 (ES) 这一概念。

ES 是 EVM 理论和实践的延伸。挣得进度理论用 ES 和实际时间 (AT) 替代了传统 EVM 所使用的进度偏差测量指标(挣值 – 计划价值),使用这种替代方法计算进度偏差 ES - AT,如果挣得进度大于 0,则表示项目进度提前了;换句话说,在某个给定的时间点,项目的挣值大于计划价值。使用挣得进度测量指标的进度绩效指数 (SPI) 为 ES 与 AT 之比,表示完成项目的工作效率。此外,挣得进度理论通过挣得进度、实际时间和估算持续时间,提供了预测项目完成日期的计算公式。

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

  • 知识管理。组织是否拥有易于使用的、正式的知识管理体系和财务数据库,并要求项目经理使用?
  • 估算和预算。组织是否拥有正式或非正式的,与成本估算和预算相关的政策、程序和指南?
  • 挣值管理。组织是否采用挣值管理来管理项目?
  • 敏捷方法的使用。组织是否采用敏捷方法管理项目?这对成本估算有什么影响?
  • 治理。组织是否拥有正式或非正式的审计和治理政策、程序和指南?

关于敏捷/适应型环境的考虑因素对易变性高、范围并未完全明确、经常发生变更的项目,详细的成本计算可能没有多大帮助。

在这种情况下,可以采用轻量级估算方法快速生成对项目人力成本的高层级预测,在出现变更时容易调整预测;而详细的估算适用于采用准时制的短期规划。

如果易变的项目也遵循严格的预算,通常需要更频繁地更改范围和进度计划,以始终保持在成本制约因素之内。

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

项目质量管理过程包括:

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 或运营的关注点。

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

  • 通常,代价最大的方法是让客户发现缺陷。这种方法可能会导致担保问题、召回、商誉受损和返工成本。
  • 控制质量过程包括先检测和纠正缺陷,再将可交付成果发送给客户。该过程会带来相关成本,主要是评估成本和内部失败成本。
  • 通过质量保证检查并纠正过程本身,而不仅仅是特殊缺陷。
  • 将质量融入项目和产品的规划和设计中。
  • 在整个组织内创建一种关注并致力于实现过程和产品质量的文化。

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

  • 客户满意。了解、评估、定义和管理要求,以便满足客户的期望。这就需要把“符合要求”(确保项目产出预定的成果)和“适合使用”(产品或服务必须满足实际需求)结合起来。在敏捷环境中,相关方与项目管理团队合作可确保在整个项目期间始终做到客户满意。
  • 持续改进。由休哈特提出并经戴明完善的“计划 — 实施 — 检查 — 行动 (PDCA)”循环是质量改进的基础。另外,诸如全面质量管理(TQM)、六西格玛和精益六西格玛等质量改进举措也可以提高项目管理的质量以及最终产品、服务或成果的质量。
  • 管理层的责任。项目的成功需要项目团队全体成员的参与。管理层在其质量职责内,肩负着为项目提供具有足够能力的资源的相应责任。
  • 与供应商的互利合作关系。组织与其供应商相互依赖。相对传统的供应商管理而言,与供应商建立合作伙伴关系对组织和供应商都更加有益。组织应着眼于长期关系而不是短期利益。互利合作关系增强了组织和供应商互相为对方创造价值的能力,推动他们共同实现客户的需求和期望,并优化成本和资源。

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

  • 政策合规与审计。组织有哪些质量政策和程序?组织使用哪些质量工具、技术和模板?
  • 标准与法规合规性。是否存在必须遵守的行业质量标准?需要考虑哪些政府、法律或法规方面的制约因素?
  • 持续改进。如何管理项目中的质量改进?是在组织层面还是在单个项目层面进行管理?
  • 相关方参与。项目环境是否有利于与相关方及供应商合作?

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

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

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

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

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

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

  • 成本效益分析。成本效益分析是用来估算备选方案优势和劣势的财务分析工具,以确定可以创造最佳效益的备选方案。成本效益分析可帮助项目经理确定规划的质量活动是否有效利用了成本。达到质量要求的主要效益包括减少返工、提高生产率、降低成本、提升相关方满意度及提升赢利能力。对每个质量活动进行成本效益分析,就是要比较其可能成本与预期效益。
  • 质量成本。与项目有关的质量成本 (COQ) 包含以下一种或多种成本(图 8-5 提供了各组成本的例子):
  • 预防成本。预防特定项目的产品、可交付成果或服务质量低劣所带来的相关成本。
  • 评估成本。评估、测量、审计和测试特定项目的产品、可交付成果或服务所带来的相关成本。
  • 失败成本(内部/外部)。因产品、可交付成果或服务与相关方需求或期望不一致而导致的相关成本。

最优 COQ 能够在预防成本和评估成本之间找到恰当的投资平衡点,以规避失败成本。有关模型表明,最优项目质量成本,指在投资额外的预防/评估成本时,既无益处又不具备成本效益。

图 8-5质量成本

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

本过程的主要作用是,提高实现质量目标的可能性,以及识别无效过程和导致质量低劣的原因。

管理质量使用控制质量过程的数据和结果向相关方展示项目的总体质量状态。本过程需要在整个项目期间开展。

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

图 8-7管理质量:输入、工具与技术和输出

图 8-8管理质量:数据流向图

管理质量有时被称为“质量保证”,但“管理质量”的定义比“质量保证”更广,因其可用于非项目工作。在项目管理中,质量保证着眼于项目使用的过程,旨在高效地执行项目过程,包括遵守和满足标准,向相关方保证最终产品可以满足他们的需求、期望和要求。管理质量包括所有质量保证活动,还与产品设计和过程改进有关。管理质量的工作属于质量成本框架中的一致性工作。

管理质量过程执行在项目质量管理计划中所定义的一系列有计划、有系统的行动和过程,有助于:

  • 通过执行有关产品特定方面的设计准则,设计出最优的成熟产品;
  • 建立信心,相信通过质量保证工具和技术(如质量审计和故障分析)可以使未来输出在完工时满足特定的需求和期望;
  • 确保使用质量过程并确保其使用能够满足项目的质量目标;
  • 提高过程和活动的效率与效果,以获得更好的成果和绩效并提高相关方的满意程度。

项目经理和项目团队可以通过组织的质量保证部门或其他组织职能执行某些管理质量活动,例如故障分析、实验设计和质量改进。质量保证部门在质量工具和技术的使用方面通常拥有跨组织经验,是良好的项目资源。

管理质量被认为是所有人的共同职责,包括项目经理、项目团队、项目发起人、执行组织的管理层,甚至是客户。所有人在管理项目质量方面都扮演一定的角色,尽管这些角色的人数和工作量不同。参与质量管理工作的程度取决于所在行业和项目管理风格。在敏捷项目中,整个项目期间的质量管理由所有团队成员执行;但在传统项目中,质量管理通常是特定团队成员的职责。

能够影响管理质量过程的组织过程资产包括(但不限于):

  • 包括政策、程序及指南的组织质量管理体系;
  • 质量模板,例如核查表、跟踪矩阵、测试计划、测试文件及其它模板;
  • 以往审计的结果;
  • 包含类似项目信息的经验教训知识库。

问题解决发现解决问题或应对挑战的解决方案。它包括收集其他信息、具有批判性思维的、创造性的、量化的和/或逻辑性的解决方法。有效和系统化地解决问题是质量保证和质量改进的基本要素。问题可能在控制质量过程或质量审计中发现,也可能与过程或可交付成果有关。使用结构化的问题解决方法有助于消除问题和制定长久有效的解决方案。问题解决方法通常包括以下要素:

  • 定义问题;
  • 识别根本原因;
  • 生成可能的解决方案;
  • 选择最佳解决方案;
  • 执行解决方案;
  • 验证解决方案的有效性。

质量改进的开展,可基于质量控制过程的发现和建议、质量审计的发现,或管理质量过程的问题解决。计划 — 实施 — 检查 — 行动和六西格玛是最常用于分析和评估改进机会的两种质量改进工具。

检查是指检验工作产品,以确定是否符合书面标准。检查的结果通常包括相关的测量数据,可在任何层面上进行。可以检查单个活动的成果,也可以检查项目的最终产品。检查也可称为审查、同行审查、审计或巡检等,而在某些应用领域,这些术语的含义比较狭窄和具体。检查也可用于确认缺陷补救。

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

  • 风险管理战略。描述用于管理本项目的风险的一般方法。
  • 方法论。确定用于开展本项目的风险管理的具体方法、工具及数据来源。
  • 角色与职责。确定每项风险管理活动的领导者、支持者和团队成员,并明确他们的职责。
  • 资金。确定开展项目风险管理活动所需的资金,并制定应急储备和管理储备的使用方案。
  • 时间安排。确定在项目生命周期中实施项目风险管理过程的时间和频率,确定风险管理活动并将其纳入项目进度计划。
  • 风险类别。确定对单个项目风险进行分类的方式。通常借助风险分解结构 (RBS)来构建风险类别。风险分解结构是潜在风险来源的层级展现(示例见图 11-4)。风险分解结构有助于项目团队考虑单个项目风险的全部可能来源,对识别风险或归类已识别风险特别有用。组织可能有适用于所有项目的通用风险分解结构,也可能针对不同类型项目使用几种不同的风险分解结构框架,或者允许项目量身定制专用的风险分解结构。如果未使用风险分解结构,组织则可能采用某种常见的风险分类框架,既可以是简单的类别清单,也可以是基于项目目标的某种类别结构。

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

  • 相关方风险偏好。应在风险管理计划中记录项目关键相关方的风险偏好。他们的风险偏好会影响规划风险管理过程的细节。特别是,应该针对每个项目目标,把相关方的风险偏好表述成可测量的风险临界值。这些临界值不仅将联合决定可接受的整体项目风险敞口水平,而且也用于制定概率和影响定义。以后将根据概率和影响定义,对单个项目风险进行评估和排序。
  • 风险概率和影响定义。根据具体的项目环境,组织和关键相关方的风险偏好和临界值,来制定风险概率和影响定义。项目可能自行制定关于概率和影响级别的具体定义,或者用组织提供的通用定义作为出发点。应该根据拟开展项目风险管理过程的详细程度,来确定概率和影响级别的数量,即:更多级别(通常为五级)对应于更详细的风险管理方法,更少级别(通常为三级)对应于更简单的方法。表 11-1 针对三个项目目标提供了概率和影响定义的示例。

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

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

  • 概率和影响矩阵。见 11.3.2.6 节。组织可在项目开始前确定优先级排序规则,并将其纳入组织过程资产,或者也可为具体项目量身定制优先级排序规则。在常见的概率和影响矩阵中,会同时列出机会和威胁;以正面影响定义机会,以负面影响定义威胁。概率和影响可以用描述性术语(如很高、高、中、低和很低)或数值来表达。如果使用数值,就可以把两个数值相乘,得出每个风险的概率 - 影响分值,以便据此在每个优先级组别之内排列单个风险相对优先级。

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

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

  • 报告格式。确定将如何记录、分析和沟通项目风险管理过程的结果。在这一部分,描述风险登记册、风险报告以及项目风险管理过程的其他输出的内容和格式。
  • 跟踪。跟踪是确定将如何记录风险活动,以及将如何审计风险的管理过程。

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

  • 假设日志。见 4.1.3.2 节。在监督风险过程中,可能做出新的假设、识别出新的制约因素,或者现有假设条件或制约因素可能被重新审查和修改。需要更新假设日志,记录这些新信息。
  • 问题日志。见 4.3.3.3 节。作为监督风险过程的一部分,已识别的问题会记录到问题日志中。
  • 经验教训登记册。见 4.4.3.1 节。更新经验教训登记册,记录风险审查期间得到的任何与风险相关的经验教训,以便用于项目的后期阶段或未来项目。
  • 风险登记册。见 11.2.3.1 节。更新风险登记册,记录在监督风险过程中产生的关于单个项目风险的信息,可能包括添加新风险、更新已过时风险或已发生风险,以及更新风险应对措施,等等。
  • 风险报告。见 11.2.3.2 节。应该随着监督风险过程生成新信息,而更新风险报告,反映重要单个项目风险的当前状态,以及整体项目风险的当前级别。风险报告还可能包括有关的详细信息,诸如最高优先级单个项目风险、已商定的应对措施和责任人,以及结论与建议。风险报告也可以收录风险审计给出的关于风险管理过程有效性的的结论。

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

项目采购管理过程包括:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • 买方就变成了承包商、供应商及服务提供商的客户,因此也就是卖方的关键项目相关方。
  • 卖方的项目管理团队就需要关注工作执行或服务提供所涉及的所有过程。
  • 对于卖方来说,合同条款和条件以及采购工作说明书 (SOW) 都是其许多管理过程的重要输入。

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

  • 卖方本身也可能成为更低层级的产品、服务和材料分包商及供应商的买方。

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

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

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

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

  • 工具的改进。用于管理项目采购和项目执行的工具已经取得重大发展。现在,买方能够使用在线工具集中发布采购广告;卖方也能够使用在线工具集中查找采购文件,并直接在线填写。在施工、工程和基础设施领域,建筑信息模型(BIM) 软件的应用日益广泛,为工程项目节省了大量时间和资金。它能够大幅减少施工索赔,从而降低成本、缩短工期,因此世界各地的主要公司和政府都开始要求在大型项目中使用 BIM。
  • 更先进的风险管理。在风险管理领域日益流行的一个趋势,就是在编制合同时准确地将具体风险分配给最有能力对其加以管理的一方。没有任何承包商有能力管理项目的所有重大风险,买方因而必须接受承包商无法掌控的风险,例如,采购方公司政策的不断变化、法规要求的不断变化,以及项目以外的其他风险。在合同中可以明确规定风险管理是合同工作的一部分。
  • 变化中的合同签署实践。在过去几年时间内,超大型项目的数量显著增加,尤其是在基础设施建设和工程项目领域。数十亿美元的项目现在已十分常见。大部分此类项目都要求与多个国家的多家承包商签署国际合同,因此肯定比仅使用当地承包商的项目具有更大的风险。承包商越来越重视在采购过程中与客户开展密切合作,以便对批量采购或有其他特殊关系的客户给予折扣优惠。对于此类项目来说,为了减少执行过程中的问题和索赔,采用国际公认的标准合同范本也日益普遍。
  • 物流和供应链管理。因为如此多的大型工程、施工和基础设施建设项目都由多家跨国承包商来完成,材料物流管理对于项目成功完成至关重要。对采购周期较长的产品,制造环节和运输(到项目现场)环节都是项目进度的决定因素。在 IT 领域,有些产品可能需要提前 2 至 3 个月订购;在复杂的施工项目上,订购时间可能需要提前 1-2 年,甚至更长。在这些项目上,可能需要在签订其他采购合同之前就采购这些订购周期长的产品,以便项目如期完成。在最终产品的最终设计完成之前,就可能需要根据总体设计中已确定的要求开始订购采购周期较长的材料、用品或设备。供应链管理也是承包商的项目团队日益重视的一个领域。在项目早期,不仅要明确主要的采购渠道,通常还需要明确次要和备选渠道。全球很多国家会要求跨国承包商至少向当地供应商采购一定比例的材料和用品。
  • 技术和相关方关系。公共资助的项目正受越来越多的关注。基础设施和商业建设项目正日益采用包括网络摄像(webcams)在内的技术,以改善与相关方的沟通和关系。在施工期间,施工现场会安装一台或多台网络摄像机,定期更新并发布到公开的网站上,方便所有相关方在互联网上查看项目进展。另外,视频资料可以储存,有助于在索赔发生时进行分析。有些项目显示,使用网络摄像机记录现场情况,能够避免对事实的分歧,从而能够把与现场施工有关的争议降到最低程度。
  • 试用采购。并非每一个卖方都能很好地适应买方组织的环境,因此,在决定大批量采购之前,有些项目会试用多个候选卖方,向他们采购少量的可交付成果和工作产品。这样一来,买方可以在推进项目工作的同时,对潜在合作伙伴进行评估。

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

  • 采购的复杂性。只开展一次主要的采购,或者需要在不同时间向不同卖方进行多次采购(会提高采购的复杂性)?
  • 物理地点。买方和卖方在同一或邻近地点,或者位于不同时区、国家或大洲?
  • 治理和法规环境。组织的采购政策是否和当地相关的法律法规兼容?当地的法律法规会如何影响合同审计工作?
  • 承包商的可用性。是否有具备工作执行能力的承包商可供选择?

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

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

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

控制采购是管理采购关系,监督合同绩效,实施必要的变更和纠偏,以及关闭合同的过程。本过程的主要作用是,确保买卖双方履行法律协议,满足项目需求。本过程应根据需要在整个项目期间开展。图 12-6 描述本过程的输入、工具与技术和输出,图 12-7 是本过程的数据流向图。

图 12-6控制采购:输入、工具与技术和输出

• Projectcharter图 12-7控制采购:数据流向图

买方和卖方都出于相似的目的来管理采购合同,每方都必须确保双方履行合同义务,确保各自的合法权利得到保护。合同关系的法律性质,要求项目管理团队必须了解在控制采购期间所采取的任何行动的法律后果。对于有多个供应商的较大项目,合同管理的一个重要方面就是管理各个供应商之间的沟通。

鉴于其法律意义,很多组织都将合同管理视为独立于项目的一种组织职能。虽然采购管理员可以是项目团队成员,但通常还向另一部门的经理报告。

在控制采购过程中,需要把适当的项目管理过程应用于合同关系,并且需要整合这些过程的输出,以用于对项目的整体管理。如果涉及多个卖方,以及多种产品、服务或成果,就往往需要在多个层级上开展这种整合。

合同管理活动可能包括:

  • 收集数据和管理项目记录,包括维护对实体和财务绩效的详细记录,以及建立可测量的采购绩效指标;
  • 完善采购计划和进度计划;
  • 建立与采购相关的项目数据的收集、分析和报告机制,并为组织编制定期报告;
  • 监督采购环境,以便引导或调整实施;
  • 向卖方付款。

控制措施的质量,包括采购审计的独立性和可信度,是采购系统可靠性的关键决定因素。组织的道德规范、内部法律顾问和外部法律咨询,包括持续的反腐计划,都有助于实现适当的采购控制。

在控制采购过程中,需要开展财务管理工作,包括监督向卖方付款。这是要确保合同中的支付条款得到遵循,确保按合同规定,把付款与卖方的工作进展联系起来。需要重点关注的一点是,确保向卖方的付款与卖方实际已经完成的工作量之间有密切的关系。如果合同规定了基于项目输出及可交付成果来付款,而不是基于项目输入(如工时),那么就可以更有效地开展采购控制。

在合同收尾前,若双方达成共识,可以根据协议中的变更控制条款,随时对协议进行修改。通常要书面记录对协议的修改。

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

  • 知识和需求管理。组织是否拥有正式或非正式的知识和需求管理体系?为了可在未来的项目中重复使用需求,项目经理应建立哪些指导原则?
  • 确认和控制。组织是否拥有正式或非正式的确认和控制相关政策、程序和指南?
  • 敏捷方法的使用。组织是否采用敏捷方法管理项目?开发方法属于迭代型还是增量型?是否采用预测型方法?混合型方法是否有效?
  • 治理。组织是否拥有正式或非正式的审计和治理政策、程序和指南?

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

  • 知识管理。组织是否拥有正式的知识管理体系和财务数据库,并提供给项目经理使用?
  • 估算和预算。组织是否拥有正式或非正式的,与成本估算和预算相关的政策、程序和指南?
  • 挣值管理。组织是否采用挣值管理来管理项目?
  • 敏捷方法的使用。组织是否采用敏捷方法管理项目?这对成本估算有什么影响?
  • 治理。组织是否拥有正式或非正式的审计和治理政策、程序和指南?

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

  • 政策合规与审计。组织有哪些质量政策和程序?组织使用哪些质量工具、技术和模板?
  • 标准与法规合规性。是否存在必须遵守的行业质量标准?需要考虑哪些政府、法律或法规方面的制约因素?
  • 持续改进。如何管理项目中的质量改进?是在组织级别还是在单个项目级别进行管理?
  • 相关方参与。项目环境是否有利于与相关方及供应商合作?

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

  • 采购的复杂性。是否只有一次主要的采购,还是需要在不同时间向不同卖方进行多次采购,从而增加采购的复杂性?
  • 物理位置。买方和卖方是否在同一个地方,或在合理范围内相距较近,还是位于不同时区、国家/地区,或大洲?
  • 治理和法规环境。组织的采购政策是否参考当地相关的采购活动法律和法规?如何影响合同审计要求?
  • 承包商的可用性。是否有其他具备工作执行能力的承包商可供选择?