项目管理的目标是在时间表、预算、资源、基础设施和可用的人员和技术的约束下，计划和协调交付令人满意的产品、服务或企业努力所需的工作活动。这个知识领域(KA)的目的是让系统工程师熟悉项目管理的要素，并解释系统工程(SE)和项目管理(PM)之间的关系。

主题

SEBoK的每个部分被划分为知识领域(KAs)，这是具有相关主题的信息分组。KAs又被划分为不同的主题。这个KA包含以下主题:

• 项目管理的本质
• PMBOK®指南概述
• 系统工程与项目管理的关系
• 项目结构和治理对系统工程和项目管理关系的影响
• 采购和收购
• 项目组合管理

项目管理的本质

《项目管理知识体系指南》(PMBOK®指南)为寻求PMI认证的人提供了项目管理的概述，Fairley(2009)和Forsberg(2005)提出了另一种方法来描述项目管理的重要方面:

• 规划和评估
• 测量和控制
• 领导和指挥
• 风险管理

项目经理和系统工程师都关心管理问题，例如计划、测量和控制、领导、指导和管理风险。对于项目经理而言，要管理的项目属性包括项目计划;估计;安排;预算;项目结构;人员配备;资源;基础设施;和风险因素。由系统工程师管理的产品属性包括需求分配和流程;系统架构;技术团队的结构和相互作用;专业工程;集成;验证;和验证。

SE和PM职责的准确分配取决于许多因素，例如客户和涉众的互动、母组织的组织结构，以及与附属承包商和分包商的关系。(参见本KA中关于项目结构和治理对系统工程和项目管理关系的影响的文章。)

计划和评估

计划

计划项目涉及为每个项目的人员、内容、地点、时间和原因提供答案：

• 谁： 解决人员配备问题（能力、员工数量、沟通和协调）
• 内容： 涉及活动范围
• 地点： 解决地区问题（本地，地理分布）
• 时间： 解决调度问题
• 原因： 说明进行项目的基本原理

可在 INCOSE (2012)、NASA (2007) 和 ISO/IEC/IEEE 标准 16326:2009 中找到制定项目计划的指南。 人们经常观察到，在项目规划期间，利益相关者之间的沟通和协调与产生的书面计划同样重要（有时甚至更重要）。

在国防工作中，事件驱动的综合总计划和时间驱动的综合总计划是规划产品。 《国防采办指南》第 11 章提供了详细信息（DAU 2010）。

估计

估算是规划的重要组成部分。 估计是从过去到未来的预测，经过调整以考虑过去和未来之间的差异。 估计技术包括类比、经验法则、专家判断和使用参数模型，例如硬件的 PRICE 模型、软件项目的 COCOMO 和系统项目的 COSYSMO (Stewart 1990; Boehm et al. 2000; Valerdi 2008)。

估计的实体包括（但不限于）进度、成本、绩效和风险。

系统工程通过确保：

• 了解整个系统生命周期；
• 识别对其他系统和组织的依赖；
• 确定开发过程中的逻辑依赖关系；
• 资源和关键技能被识别和计划。

此外，高级系统架构和风险评估为工作分解结构和组织分解结构提供了基础。

测控

测量和控制是实施项目的关键要素。度量包括为工作产品和工作过程收集度量。例如，可以通过审查、分析、原型化和可跟踪性来评估设计规范中需求覆盖的级别。在工作过程中所花费的精力和进度可以被测量，并与估计进行比较;挣值跟踪可用于此目的。控制与分析测量数据和实施纠正措施有关，当实际状态与计划状态不一致时。

系统工程师可能负责管理项目执行的所有技术方面，或者他们可能作为项目经理或项目管理办公室的员工支持。系统工程师和项目经理之间的组织关系在团队能力中有所体现。系统工程和项目管理之间的关系的其他组织考虑因素在启用系统工程知识领域中被涵盖。

关于技术因素的测量和控制的其他信息可以在第3部分:系统工程和管理中的测量和评估与控制文章中找到。

领导和指导

领导和指导需要在所有项目干系人之间进行沟通和协调，包括内部和外部。系统工程师可能负责管理项目执行的所有技术方面，或者他们可能作为项目经理或项目管理办公室的员工支持。系统工程师和项目经理之间的组织关系在第5部分的团队能力一文中有介绍。系统工程和项目管理之间关系的其他组织考虑因素在第5部分:启用系统工程中进行了讨论。

管理风险

风险管理关注的是在潜在问题成为真正的问题之前识别和减轻它们。系统工程项目本质上是高风险的努力，因为项目中存在许多未知和不确定因素。因为新的风险因素通常会在项目过程中出现，因此持续不断的风险管理对于系统工程师和项目经理来说都是一项重要的活动。

潜在的和实际的问题可能存在于项目的每个方面。系统工程师通常关注技术风险，而项目经理关注程序性风险。有时，系统工程师识别并面对技术风险因素，项目经理在没有充分沟通的情况下识别并面对程序性风险因素。在这些情况下，可能无法在需求、进度、预算、基础设施和技术之间进行适当的权衡，这为项目的成功结果创造了额外的风险。

在过去的十年中，作为风险管理的反面，人们对机会管理越来越感兴趣。Hillson (2003)， Olsson (2007)， Chapman和Ward(2003)提供了高引用的介绍。

关于系统工程项目风险管理的其他信息可以在第3部分:系统工程和管理的风险管理文章中找到。

PMBOK®指南概述

项目管理知识手册(PMBOK®指南)由项目管理学会(PMI)出版和维护。它被公认为项目管理中良好实践的权威文件。它也是项目管理专业人员(pmp)资格认证考试的基础。许多组织要求PMP认证作为项目经理角色的基本资格。

项目管理知识体系第6版和以前的版本都是以过程为焦点组织的。项目管理知识体系第7版与第6版截然不同，从过程焦点转移到原则焦点。第7版强调了项目经理的心态、行为和行动。第7版也是第6版的三分之一。当前的SEBoK文章引用了第5版。计划在SEBoK的未来版本中进行更新，以反映第6和第7版。

概述

根据 PMBOK® 指南 第 1.3 节，项目管理是 通过 47 个按逻辑分组的项目管理流程的适当应用和集成来完成的，这些流程分为五个流程组 （PMI 2013）。 五个进程组是：

1. 启动进程组
2. 计划过程组
3. 执行进程组
4. 监控过程组
5. 结束进程组

47 个过程中的每一个都由输入、工具和技术以及输出指定。 PMBOK 中使用数据流程图来说明每个流程与每个流程交互的其他流程之间的关系。 这些过程也分为十个知识领域。 这些知识领域是：

1. 项目集成管理
2. 项目范围管理
3. 项目时间管理
4. 项目成本管理
5. 项目质量管理
6. 项目人力资源管理
7. 项目沟通管理
8. 项目风险管理
9. 项目采购管理
10. 项目干系人管理

下一节将更详细地讨论这五个过程组。

启动进程组

在启动过程组中执行的活动包括:获得启动项目的授权;界定项目的高层范围;制定并获得项目章程的批准;执行关键利益相关者分析;并识别和记录高层次的风险、假设和约束。启动过程组包含两个过程:制定项目章程和确定涉众。

计划过程组

计划过程组由24个过程组成，包括:与利益相关者评估详细的项目要求、约束和假设;制定项目管理计划;创建工作分解结构;制定项目时间表;确定项目预算;规划质量管理、人力资源管理、沟通管理、变更和风险管理、采购管理和利益相关者管理。将综合项目管理计划提交给关键干系人。

执行进程组

执行过程组包括八个过程，它们涉及执行必要的工作以实现项目的既定目标。活动包括:获取和管理项目资源;执行项目计划中规定的任务;根据变更管理计划实施已批准的变更;执行质量保证;获取、发展和管理项目团队;管理沟通;进行采购;以及管理利益相关者的参与。

监控过程组

监控过程组由11个过程组成，包括:验证和控制范围;控制计划;控制成本;控制质量;控制通讯;控制风险;控制采购;控制利益相关者的参与。活动包括:测量项目绩效并使用适当的工具和技术;管理项目范围、进度和成本的变更;确保项目可交付成果符合质量标准;更新风险登记册和风险应对计划;评估问题登记册上的纠正措施;与项目干系人沟通项目状态。

结束进程组

结束过程组包括两个过程:结束项目或阶段和结束采购。项目或阶段的结束包括结束所有项目活动，存档文件，获得可交付成果的认可，以及沟通项目的结束。其他活动包括:转让交付物所有权;获得财务、法律和行政上的关闭;分发期末项目报告;整理的经验教训;项目文件和资料的归档;测量客户满意度。

项目管理知识体系指南中规定的项目管理范围，包括有助于取得成功项目结果的所有管理事项。

系统工程与项目管理的关系

本主题讨论了系统工程(SE)和项目管理(PM)之间的关系。与软件工程一样，有很多重叠的地方。根据环境和组织的不同，这两个学科可以是不相交的，部分交叉的，或者一个可以被视为另一个的子集。虽然没有标准的关系，项目经理和系统工程师包含了他们之间项目的技术和管理领导，这需要每个项目经理和系统工程师的企业为他们自己的环境制定出特定的细节。

重叠

在系统工程的范围之间有大量重要的重叠，如这里(在SEBoK中)，CMMI(2011)，以及其他资源和项目管理的范围之间，如项目管理知识体系®指南(PMI 2013)， CMMI(2011)，以及图1中所示的其他资源。

图 1. PM 和 SE 的重叠。 （SEBoK 原创）

这些来源描述了理解手头工作范围的重要性，如何计划关键活动，如何在降低风险的同时管理工作，以及如何成功地向客户交付价值。从事项目工作的系统工程师将计划、监控、面对风险，并交付项目的技术方面，而项目经理则关心整个项目的相同种类的活动。由于这些共同的关注，在一个给定的项目中，项目经理和系统工程师的角色之间有时可能会出现混淆和紧张。如图2所示，在一些项目中，职责并没有重叠。在其他项目中，可能有计划和管理活动的共同责任。在某些情况下，特别是对于较小的项目，项目经理也可能是团队的主要技术成员，同时扮演项目经理和系统工程师的角色。

图 2. 项目角色的重叠。 （SEBoK 原创）

定义角色和职责

不管在给定的项目中角色是如何划分的，减少混乱的最好方法是明确地描述项目经理和系统工程师，以及其他关键团队成员的角色和职责。项目管理计划(PMP)和系统工程管理计划(SEMP)是用于定义项目将用于构建和交付产品或服务的过程和方法的关键文件。

项目规划文件是项目的主要规划文件。它描述了程序生命周期中要整合和控制的所有活动，包括技术活动。SEMP是系统工程技术要素的主规划文件。它定义了项目中使用的SE过程和方法，以及SE活动与其他项目活动的关系。SEMP必须与PMP一致并与PMP协调发展。此外，一些客户有技术管理计划，并期望项目的SEMP与客户计划和活动相集成。在美国国防部，大多数政府项目团队都有一个系统工程计划(SEP)，期望承包商的SEMP将集成并保持与客户技术活动的一致性。在项目正在开发较大系统的组件的情况下，组件项目的SEMP将需要与整个项目的SEMP集成。

考虑到计划和管理项目的技术方面的重要性，一个有效的系统工程师将需要有一个强大的管理技能和经验的基础，以及强大的技术深度。从开发和维护评估的基础、计划和监控技术活动、识别和降低技术风险，以及在项目生命周期中识别并包括相关的利益相关者，系统工程师成为项目管理和领导团队的关键成员。关于系统工程管理和涉众需求的其他信息可以在第3部分:系统工程和管理中找到。

实际考虑

项目经理和系统工程师之间的有效沟通是完成任务的必要条件。这种沟通需要尽早建立，并经常发生。

资源重新分配、进度变更、产品/系统变更和影响、风险变更:所有这些都需要在PM和SE之间快速而清晰地讨论。

项目结构和治理对系统工程和项目管理关系的影响

本文回顾了影响或提供项目治理的各种项目结构，这些结构需要项目经理和系统工程师的关键参与。这些结构包括:组织本身的结构(功能、项目、矩阵，和专门的团队，如集成产品团队(IPTs)、变更控制委员会(CCBs)，和工程审查委员会(ERBs))。本文还讨论了进度驱动项目和需求驱动项目对这些结构的影响。

系统工程和项目管理之间的关系将在相关的文章中介绍。

项目结构概述

项目管理和系统工程治理依赖于组织的结构。对于某些项目，系统工程隶属于项目管理，而在其他情况下，项目管理为系统工程提供支持。这些备选方案在团队能力组织团队部分的图1和图2中进行了说明。

项目存在于组织的结构模型中。项目是一次性的、短暂的事件，它是为实现特定目的而发起的，并在项目目标实现时终止。有时，在小型项目中，同一个人同时完成项目管理和系统工程的工作活动。因为工作活动的性质是显著不同的，有时让两个人执行项目管理和系统工程是更有效的，每个人都是兼职的。在更大的项目中，通常有太多的任务需要一个人来完成所有必要的工作。非常大的项目可能有项目管理和系统工程办公室，有一个指定的项目经理和一个指定的首席系统工程师。

项目通常以三种方式之一来组织:(1)通过功能结构，(2)通过项目结构，和(3)通过矩阵结构(参见系统工程组织战略的第四种结构和相关的讨论)。在职能结构的组织中，工人按他们执行的职能分组。系统工程的功能可以是:(1)分布在一些职能组织中，(2)集中在一个组织中，或(3)混合，其中一些功能分布到项目中，一些集中，一些分布到职能组织中。下图提供了一个组织结构连续体，并说明了功能性组织和项目之间的治理级别。

• 在功能结构的组织中，项目经理是协调员，通常对系统工程功能的控制有限。 在这种类型的组织中，职能经理通常控制项目预算并对项目资源拥有权力。 但是，组织可能有也可能没有系统工程的功能单元。 在有系统工程的功能单元的情况下，系统工程师被分配到现有项目中。 可以在他们的项目之间进行交易，以将特定系统工程项目的优先级置于其他项目之前； 从而减少了该选定项目的名义进度。 但是，在没有系统工程的功能单元的情况下，
• 在项目结构的组织中，项目经理拥有管理预算和资源以满足进度要求的全部权力和责任。 系统工程师服从项目经理的指导。 项目经理可以与人力资源或人事经理一起工作，也可以在组织之外为项目配备人员。
• 矩阵结构的组织可以同时具有功能结构和项目结构的优点。 对于进度驱动的项目，职能专家会根据需要分配给项目，以便项目经理将他们的专业知识应用于项目。 一旦不再需要它们，它们就会返回其职能组（例如家庭办公室）。 在弱矩阵中，职能经理有权将工人分配给项目，而项目经理必须接受分配给他们的工人。 在一个强矩阵中，项目经理控制项目预算，如果职能部门没有足够的可用和训练有素的工人，则可以拒绝职能部门的工人并雇用外部工人。

图 1. 组织连续统一体 (2)。 （SEBoK 原创，改编自 Fairley 2009）。 经 IEEE 计算机协会许可转载。 所有其他权利均由版权所有者保留。

在所有情况下，澄清组织和治理关系并与所有项目干系人进行沟通是至关重要的，项目经理和系统工程师以合议的方式共同工作。

项目管理办公室(PMO)为一组项目提供集中控制。项目管理办公室(PMO)的重点是利用一组项目来实现业务目标，而项目经理的重点则是满足那些属于他们职权范围内的项目的目标。pmo通常管理共享的资源，协调项目之间的通信，提供监督和管理相互依赖关系，并推动项目相关的政策、标准和过程。PMO也可以提供培训和监督合规性(PMI 2013)。

进度驱动与需求驱动对结构和治理的影响

本文讨论了项目经理和系统工程师对治理关系的影响。建立这种关系的一个因素是项目是计划驱动的还是需求驱动的。

一般来说，项目经理负责在规定的交付日期内，在规定的时间表、预算、资源和技术的限制下交付可接受的产品/服务。

系统工程师负责收集和界定运作需求、订明系统需求、发展系统设计、协调组件开发小组、在系统组件可用时把它们整合在一起、核实要交付的系统是否正确、完整及符合其技术规格，以及核实系统在预期环境中的运作情况。

从治理的角度来看，项目经理通常被认为是一个电影制片人，负责平衡进度、预算和资源约束，以满足客户的需求。系统工程师负责产品内容;因此，系统工程师类似于电影导演。

前面讨论过的组织结构为项目经理和系统工程师提供了不同级别的治理权限。此外，进度和需求约束会影响治理关系。进度驱动的项目是指满足项目进度比满足所有项目需求更重要的项目;在这些情况下，较低优先级的需求可能不会被执行以满足进度要求。

这类项目的典型例子有:

• 一个有合同交付日期的外部客户和不断升级的延迟交付罚款的项目
• 系统交付必须满足一个重要里程碑的项目(例如，一个由市场因素驱动的手机产品发布的项目)。

对于进度驱动的项目，项目经理负责计划和协调项目的工作活动和资源，使团队能够协调地完成工作以满足进度。 系统工程师与项目经理一起确定符合进度的技术方法。 集成主进度表 (IMS) 通常用于协调项目。

需求驱动的项目是满足需求比进度约束更重要的项目。 这些类型的项目的经典示例是：

1. 探索性开发减轻潜在威胁所需的新系统（例如军事研究项目）和
2. 必须符合政府法规才能使交付的系统安全运行的项目（例如，航空和医疗器械法规）。

对于时间表驱动的项目，项目经理负责计划和协调项目的工作活动和资源，以便团队能够以协调的方式完成工作，以满足时间表。系统工程师与项目经理一起确定满足进度要求的技术方法。一个集成的主计划(IMS)经常被用来协调项目。

需求驱动的项目是一个满足需求比进度约束更重要的项目。这类项目的典型例子有:

探索开发一个新系统，需要减轻潜在威胁(例如军事研究项目)和

为保证交付系统的安全运行，必须符合政府法规的项目(如航空和医疗器械法规)。

综合总体计划通常用于协调事件驱动的项目。

为了满足产品需求，系统工程师负责做出技术决策并进行适当的技术交易。当交易空间包括成本、进度或资源时，系统工程师与项目经理进行交互，项目经理负责提供实现满足技术需求的系统所需的资源和设施。

时间表驱动的项目更有可能拥有一个项目经理扮演中心角色的管理结构，如图1中团队能力组织团队部分所描述的那样。需求驱动的项目更有可能拥有一个管理结构，其中系统工程师扮演中心角色，如图2中团队能力组织团队部分所描述的那样。

与项目管理计划和系统工程管理计划一样，IMP/IMS对这个过程至关重要。

相关结构

集成产品团队(IPTs)、变更控制委员会(CCBs)和工程审查委员会(ERBs)是项目结构的主要例子，它们在项目治理中扮演着重要的角色，并需要项目经理、系统工程师和团队其他成员之间的协调。

综合产品团队

集成产品团队(IPT)确保政府和行业代表之间以及不同产品组之间开放的沟通流程(参见规划中的良好实践)。有一个典型的顶级IPT，有时被称为系统工程和集成团队(SEIT)(参见系统工程组织战略)，它监督较低级别的IPT。SEIT可以由特定项目的项目经理领导，也可以由系统工程职能经理或多个项目的职能主管领导。每个IPT都由来自适当的管理和技术团队的代表组成，这些团队需要在系统工程、项目管理和其他活动上进行协作，以创建高质量的产品。这些代表定期开会，以确保技术要求得到理解，并在设计中适当地实现。有关更多信息，请参见团队能力。

变更控制委员会

有效的系统工程方法包括将变更控制作为配置管理更大目标的一部分的有纪律的过程。配置管理的主要目标是跟踪项目工件的变更，这些工件包括软件、硬件、计划、需求、设计、测试和文档。或者，建立一个变更控制委员会(CCB)，由来自项目适当领域的代表组成，以有效地分析、控制和管理向项目提出的变更。CCB通常会从设计/开发、生产或运营/支持部门收到一份工程变更提案(ECP)，并对变更的可行性进行初步评审。ECP也可能是工程审查委员会(ERB)的输出(见下一节)。如果确定可行，建设控制局确保有可接受的变更实施计划和适当的修改和安装程序，以支持生产和运营。

在一个大型项目中可能有多个ccb。ccb可以由来自客户和供应商的成员组成。与ipt一样，可以有多个级别的CCB，从最高级别的CCB开始，CCB也存在于子系统级别。技术主管通常担任CCB的主席;然而，由于建设银行的决定将对进度、预算和资源产生影响，因此董事会包括了来自项目管理层的代表。

参见配置管理下的图2，了解变更控制过程的流程，来自Blanchard和Fabrycky(2011)。另请参阅功能更新、升级和现代化，以及在启用团队下包含的主题。另请参阅英国西海岸现代化项目，该项目提供了一个例子，其中变更控制是一个重要的成功因素。

工程审查委员会

另一个需要技术和管理合作的董事会的例子是工程审查委员会(ERB)。再培训局的例子包括管理安全评审委员会(MSRB)(见《安全工程》)。雇员再培训局的职责可能包括对待更改的要求进行技术影响分析(如建行)、裁定工程行业研究的结果，以及检讨项目基线的更改。在某些情况下，再培训局可能是管理评审委员会，而建设局可能是技术评审委员会。或者，在需求驱动的组织中，ERB可能有更大的影响，而在进度驱动的组织中，CCB可能有更大的影响。

采购和收购

采购是购买商品和服务的行为。采办包括武器和其他系统的概念化、启动、设计、开发、测试、承包、生产、部署、后勤支持、修改和处置，以及满足组织需求(包括建设)，用于或支持指定任务(DAU 2010;国防部2001)。

采办涉及的主题比采购要广泛得多。采集过程贯穿所采集系统的整个生命周期。适当的系统工程(SE)采购活动和SE支持水平对于组织应对开发和维护复杂系统的挑战至关重要。

《将系统工程集成到国防部采买合同指南》阐述了系统工程活动如何集成到采买和采购的各种要素中(国防部2006a)。

采集过程模型

存在多种采集过程模型。图1显示了工业和国防主要系统的采办过程。获取过程是由一系列阶段定义的，在此期间，技术被定义并成熟为可行的概念。这些概念随后被开发并准备用于生产，之后生产的系统将在现场得到支持。

采办计划是确定和描述需求、能力和需求，以及确定满足这些需求的最佳方法的过程(例如，规划采办策略)。这个过程包括采购;因此，采购与采购过程模型直接相关。图1中所示的流程模型允许给定的采购在任何开发阶段进入流程。

例如，使用未经验证的技术的系统将在过程的开始阶段进入，并将经过漫长的技术成熟期。另一方面，基于成熟和成熟技术的系统可能直接进入工程开发，有时甚至进入生产。

图 1. 采购流程模型（DAU 2010）。 由国防采办大学 (DAU)/美国国防部 (DoD) 发布。

系统工程在采购过程中的作用

由于SE活动的广度和深度，复杂系统的采购通常要求报价方和供应商SE团队之间保持密切的关系。SE是规划团队应用的一个总体过程，目的是从确定的能力需求过渡到一个负担得起的、操作有效的、合适的系统。

SE对收购过程的每个阶段都很重要。SE包含了整个采买生命周期中SE过程的应用，并旨在成为解决能力需求、设计考虑和约束的平衡解决方案的集成机制。它还旨在解决技术、预算和进度所造成的限制。

SE是一种跨学科方法;也就是说，它是一种结构化的、严格的、文档化的技术工作，同时设计和开发系统产品和过程，以满足客户的需求。无论项目的范围和类型如何，或者在什么时候进入项目获取生命周期，项目的技术方法都需要与获取策略相结合，以获得最佳的项目解决方案。

商业部门的收购和采购与政府承包领域的收购和采购有许多共同的特点，尽管商业世界的过程通常不像政府与承包商之间的互动那样严格。离岸外包通常在商业软件领域进行，目的是降低劳动力成本。商业组织有时会与其他商业组织进行分包，以提供缺失的专业知识，并平衡人员需求的潮起潮落。

在某些情况下，承包组织和分包商之间的关系很紧张，因为承包组织希望保护其知识产权和开发实践，使其不受分包商的潜在影响。商业组织通常有被批准的供应商名单，用于加快所需设备、产品和服务的采购。在这些情况下，商业组织有评估和批准供应商的过程，类似于政府承包商的资格。许多商业组织应用SE原则和程序，即使他们可能没有将人员和工作功能确定为“系统工程师”或“系统工程”。

采购策略在采购过程中的重要性

采办策略通常是在采办生命周期的前端制定的。(例如，请参阅图1中的技术开发阶段。)采办策略为采办计划在整个生命周期的所有方面提供了综合策略。

本质上，采买策略是一种高级的业务和技术管理方法，旨在在指定的资源约束下实现项目目标。它作为计划、组织、配备人员、控制和领导项目的框架，以及建立适当的合同机制。它为研究、开发、测试、生产、部署和其他对项目成功至关重要的SE相关活动，以及制定功能战略和计划提供了一个主时间表。

供应商的计划团队，包括系统工程，负责开发和记录收购策略，该策略传达了基于战略、技术和资源考虑的整合的计划目标、方向和控制手段。采收策略的一个主要目标是开发一个计划，该计划将最小化时间和成本，以满足确定的、确认的需求，同时保持与常识和可靠的业务实践相一致。合约主任负责订立合约的所有事宜，包括决定哪种合约最合适，以及遵守机构的现行规例、指示、指示及政策备忘录的规定。而项目经理则与合约主任合作，制定最佳的合约/采购策略及合约类型。

将收购与征求建议书和技术属性相关联

有几种格式可用于向提供者请求构建复杂系统的建议。 图 2 将采购计划元素与国防部已使用的代表性提案请求 (RFP) 主题大纲和关键计划技术属性相关联。 一般来说，当报价方和供应商都了解项目的技术性质和相关 SE 活动的需要时，项目的成功机会就更大。

报价方和供应商需要在整个采购过程中清楚地传达计划的技术方面。 要约人的 RFP 和相关的供应商提案代表了正式的沟通途径之一。 图 2 显示了关键程序技术属性的部分列表。

图 2. 将收购与征求建议书和技术属性相关联。 （国防部 2006a）。 由美国国防部长办公室发布。

与合同相关的活动和供应商的系统工程和项目管理角色

通过系统工程计划(SEP)的开发，对技术需求的清晰理解得到了加强。SEP记录了项目或计划的系统工程战略，并作为实施、管理和控制采运计划技术方面的蓝图(国防部2011年)。SEP记录了SE结构，并解决了政府和承包商的边界问题。它总结了计划所选择的获取策略，并识别和链接到计划风险。它还描述了如何管理承包商，有时是分包商和供应商的技术工作。

一旦了解了技术要求，就可以拟订合同，然后招标供应商。供应商的项目经理、首席或首席系统工程师和CO必须一起工作，将项目的采买策略和相关的技术方法(通常在SEP中定义)转化为一个紧密的、可执行的合同。

表1显示了一些与合同相关的关键任务，其中包含PM和LSE角色的指标。

表 1. 供应商的系统工程和项目管理角色（DoD 2006）。 由美国国防部长办公室发布。

供应商和供应商互动

在正式的来源选择过程之前应该有一个开放的沟通环境。 这确保了供应商了解供应商的要求，供应商了解供应商的能力和限制，并加强供应商参与项目采购战略的制定。 在预招标阶段，要约人制定招标文件，并可能要求供应商提供有关技术挑战、计划技术方法和关键业务动机的重要见解。

例如，可能会要求潜在投标人根据新技术和现有技术的成熟度评估拟议系统的性能。

合同和分包合同

典型的合同类型包括：

• 固定价格 ：在固定价格合同中，要约人为实施项目的所有产品和服务提出单一价格。 这个单一的价格有时被称为低价或一次性付款。 固定价格合同将项目风险转移给供应商。 当成本超支时，供应商会吸收它。 如果供应商的表现比计划好，他们的利润就会更高。 由于供应商承担了所有风险，因此固定价格投标可能会更高以反映这一点。

• 成本补偿 [成本加成]：在成本补偿合同中，要约人提供固定费用，但也补偿承包商的人工、材料、间接费用和管理成本。 当项目风险和不确定性很高时，使用成本补偿型合同。 对于这种类型的合同，风险主要存在于要约人身上。 供应商将获得所有费用的报销。 由于变更或返工而产生的额外费用由要约人承担。 当存在利益相关者更改系统的风险时，通常建议将此类合同用于硬件和软件开发的系统定义。

• 分包合同 ：分包商为另一家公司执行工作，作为更大项目的一部分。 总承包商（也称为主承包商或主承包商）雇用分包商来执行作为整个项目一部分的一组特定任务。 雇用分包商的动机是降低成本或降低项目风险。 系统工程团队参与制定技术合同要求、技术选择标准、验收要求以及技术监控过程。

• 外包合同 ：外包合同用于通过与外部供应商签订合同来获得商品或服务。 外包通常涉及将业务功能（例如软件设计和代码开发）外包给外部供应商。

• Exclusively Commercial Off-the-Shelf (COTS) ：Exclusive COTS 合同完全满足商业解决方案，无需修改即可使用。 COTS 解决方案在环境中使用，无需修改 COTS 系统。 它们集成到现有用户平台或集成到现有操作环境中。 系统工程团队参与制定技术合同要求、技术验收和技术选择标准。

• 集成 COTS ：集成 COTS 合约使用商用产品并将其集成到现有用户平台或操作环境中。 在某些情况下，集成的 COTS 解决方案会修改系统的解决方案。 将商业 COTS 产品集成到运营环境中的成本可能会超过 COTS 产品本身的成本。 因此，系统工程团队通常参与制定技术外包合同要求、技术选择标准、技术监控过程以及技术验收和集成过程。

• COTS 修改 ：COTS 修改需要最多的时间和成本，因为修改 COTS 产品并将其集成到系统中需要额外的工作。 根据需求的复杂程度和重要性，系统工程团队通常参与建立技术外包合同要求、技术选择标准、技术监控过程和技术验收要求。

• IT 服务 ：IT 服务提供能够支持企业、应用程序或 Web 服务解决方案的功能。 IT 服务可以由外包服务提供商提供。 在许多情况下，这些 Web 服务的用户界面就像 Web 浏览器一样简单。 根据需求的复杂程度和关键程度，系统工程团队可以参与建立技术外包合同要求、技术选择标准和技术验收过程。

项目组合管理

系统工程师需要了解并理解系统工程在项目、计划和项目组合管理(PfM)过程中的角色，以实现涉众价值的最大化。一般来说，规划和项目管理实践有助于确保组织以“正确”的方式执行规划和项目。项目组合管理可以帮助确保他们选择“正确的”程序和项目，而系统工程确保他们使用“正确的”系统思维(Specking et al. 2020)。不使用项目组合管理实践会增加组织风险，并可能降低涉众的价值。

本文提供：

• 对与项目组合管理有关的 ISO/IEC/IEEE 15288 活动和任务的描述；
• 基于 PMI 的项目管理知识体系指南 (PMI 2017a) 对项目管理协会 (PMI) 的项目组合生命周期过程的描述；
• PMI 的项目组合生命周期过程与 ISO/IEC/IEEE 15288 的连接；
• 参考 PfM 标准中的项目组合管理原则；
• 将 SE 手册的常用方法/技巧与 PfM 标准的六个领域重新调整；
• 讨论以更好地阐明系统工程与项目组合管理的关系，以及系统工程与其他主题的关系，例如项目管理和项目管理；
• 描述系统工程师支持项目组合经理的角色，明确说明系统工程师如何 (a) 帮助评估项目的价值以授权、继续或终止企业项目，以及 (b) 管理他们的系统工程活动组合以支持项目组合管理人员并支持企业流程、产品和服务。

项目组合管理概述

ISO/IEC/IEEE 15288 (ISO/IEC/IEEE 2015)通过将项目组合管理包括为组织项目使能过程，确立了项目组合管理对系统工程的重要性。这个组织项目启动过程使用组织的战略计划、项目组合方向和约束、供应策略和项目状态报告作为输入，而项目组合管理计划、组织基础设施需求、项目方向、项目组合、组织经验教训、项目组合管理报告和项目组合管理记录是输出(INCOSE 2015)。项目组合管理使用这些输入来执行帮助企业定义和授权项目的过程;评估项目和计划的组合;并终止项目以开发项目组合管理输出。这些活动发生在投资组合生命周期中，包括优化、启动、计划和执行(PMI 2017b)。

项目组合管理流程实施

项目组合管理流程的正确实施会产生七个主要的项目组合管理成果： 1) 确定商业风险机会、投资或必需品的资格和优先级； 2) 项目识别； 3) 项目资源和预算的分配； 4) 项目管理职责、责任和权限的描述； 5) 项目会议协议和利益相关者要求的维持； 6) 不合格项目的改道或终止； 7) 关闭成功完成的项目（ISO/IEC/IEEE，2015）。 如果一个项目有助于组织战略，它应该继续下去； 在实现预定目标方面取得进展； 遵守组织项目指令； 按其预先批准的计划执行；

组织可以通过整个项目组合生命周期的六个绩效管理领域成功实施项目组合管理流程来增加项目组合价值（PMI 2017b）。 表 1 中描述的这些领域包括项目组合战略管理、项目组合治理、项目组合容量和能力管理、项目组合利益相关者参与、项目组合价值管理和项目组合风险管理。

表 1. 项目组合管理的绩效管理领域描述 (Specking et al. 2020)

这些领域使用 PMI 七项基本原则中的部分或全部进行项目组合管理（PMI 2017b）。 项目组合管理的 7 项 PMI 基本原则包括：

• 力求在战略执行上做到卓越；
• 提高透明度、责任感、问责制、可持续性和公平性；
• 平衡项目组合价值与整体风险；
• 确保项目组合组件的投资与组织的战略保持一致；
• 获得并保持高级管理层和关键利益相关者的赞助和参与；
• 为优化资源利用发挥积极果断的领导作用；
• 培养一种拥抱变化和风险的文化；
• 驾驭复杂性以实现成功的结果。

项目组合管理流程最佳实践

INCOSE 的系统工程手册 (INCOSE 2015) 提供了执行项目组合管理流程的几个最佳实践。 这些最佳实践连接到表 2 中的六个绩效管理领域中的一个或多个。

表 2. 项目组合管理的 SE 手册最佳实践 （修改自 (Specking et al. 2020)）

系统工程、组合管理和项目管理之间的关系

系统工程师通常很难理解系统工程、项目组合管理和项目管理之间的关系，因为它们的过程重叠并且使用了类似的工具。 图 1 显示了项目管理、系统工程和项目组合管理在开发和改进企业架构以向许多利益相关者提供产品或服务方面的作用。 项目和项目经理以及系统工程师都与利益相关者和企业架构进行交互，企业架构由产品或服务以及制造它们的系统组成。 系统工程师使用企业架构来开发用户和系统功能层次结构，从而实现能力开发。 这些功能可帮助系统工程师评估企业当前和未来的状态。 从该评估中，项目管理办公室（项目组合经理）可以制定一个潜在的项目或计划清单来资助。 项目组合经理使用决策分析中的最佳实践（Parnell 等人，2013 年）来开发项目优先级价值模型（例如单目标或多目标决策分析模型）。 然后，项目组合经理使用优化技术根据优先价值模型确定要资助哪些项目或计划。 然后，项目经理执行受资助的项目，以确保项目按计划进行并在预算限制范围内，同时满足所需的绩效指标。 从资助项目中发现的影响系统工程文档的信息更新了功能层次结构和系统架构。 在整个项目中， 项目组合经理接收项目经理关于项目进度的最新信息。 项目组合经理使用进度信息来评估项目的继续或终止。 如果项目在项目成功完成后终止，项目的结果会更新企业的架构。 否则（即提前终止或未成功完成），项目组合经理更新他们的潜在项目和/或计划列表以重新确定优先级。 这个循环会根据企业的战略继续并随着时间的推移而发展。 提前终止或未成功完成），项目组合经理更新其潜在项目和/或计划的列表以重新确定优先级。 这个循环会根据企业的战略继续并随着时间的推移而发展。 提前终止或未成功完成），项目组合经理更新其潜在项目和/或计划的列表以重新确定优先级。 这个循环会根据企业的战略继续并随着时间的推移而发展。

图 1：系统工程、项目管理和项目组合管理在 DevOps 环境中的作用

除了帮助系统工程师了解系统工程、项目组合管理和项目管理的角色之外，图 1 还从企业DevOps环境的角度提供了对流程之间关系的洞察。