主题 5.2 — 项目群主导型工作

一句话概括： 项目群主导型工作协调一组相互关联的项目和产品，共同迈向一项任何单一项目都无法独自实现的战略性变革，并保持从工作到其旨在实现的收益之间清晰的视线。

为什么这在卫生与照护中至关重要#

卫生与照护中最大的变革从来都不是一个单一项目。在一个整合照护系统（Integrated care system，ICS）推行共享照护记录、将一个区域迁移到单一的电子病历（Electronic health record）系统、改造一条急诊与紧急照护路径，或在多家信托机构中交付一项虚拟病房项目——这些每一项都是一个由若干项目、产品团队、人力变革、院区工作和临床重新设计组成的、协调一致的组合，共同对齐到一个战略成果。若孤立地管理这些部分，它们就会相互冲突：不兼容的数据标准、重复的支出、相互矛盾的临床工作流程，以及从未真正实现的收益。

项目群管理（Program management）之所以存在，就是为了把这个联盟凝聚在一起，并使其始终指向成果和收益，而不仅仅是产出。这在卫生与照护中尤为关键，因为全系统的变革会跨越组织边界触及患者安全，承诺投入数年的大量公共资金，并依赖许多自治组织自愿协调一致地行动。一个项目群提供了让这一切成为可能的领导力、共享的目标状态和收益纪律——同样重要的是，还能让人知道它是否奏效。

它所防范的常见失败，是一个花费数百万、交付了一堆技术产出、却没有为患者或员工带来任何可衡量改变的项目群。本主题使用 Managing Successful Programmes（MSP），这是英国公共部门占主导地位的框架，并说明项目群主导型工作如何与它所协调的项目主导型（主题 5.1——项目主导型工作）和产品主导型（主题 5.0——产品主导型工作）模式共存。主题 5.3——企业级项目组合与项目管理（EPPM）随后说明一个机构如何在众多项目群之间进行优先排序。

核心概念#

项目群（Program）。 一个临时的、灵活的组织，创建目的是协调、指导和监督一组相互关联的项目和活动，以交付与战略目标一致的成果和收益。项目群与项目的不同之处在于，它是由其所追求的成果和收益来定义的，它管理的是协调众多变动部件所带来的不确定性，而不是交付单一的固定产出。

MSP（Managing Successful Programmes）。 英国用于通过多个相关项目管理转型性变革的最佳实践框架。它围绕原则、主题和一套流程的"转型流（transformational flow）"来组织，专为终点方向已知、但路径涉及众多相互依赖的交付物的大型复杂变革而设计。

愿景与蓝图。 愿景是项目群将要创造的、令人信服的未来图景。**蓝图（Blueprint）**使其具体化：它描述了目标运营模式（Target operating model）——流程、组织、技术、信息和角色的未来状态（常被概括为 POTI）。蓝图是每个项目所朝向引导的参照点，从而使各个部分汇聚成一个连贯的整体。

收益实现（Benefits realization）。 项目群管理的核心。收益是证明投资合理性的可衡量改进——延迟出院减少、重复检查减少、诊断更快、行政负担降低。MSP 将在整个生命周期中识别、映射、衡量并积极管理收益，视为一项核心纪律，因为产出只有在被用于改变照护交付方式时才能创造价值。

批次（Tranches）。 MSP 将一个项目群拆分为若干批次——以一个重大审查点结束的工作区块，届时一步能力已交付，收益实现可以开始。一个批次是展示成果、根据现实重新评估蓝图，并决定是继续、调整还是停止的时刻，而不仅仅是进度表的一个切片。

项目群委员会与 SRO。 **高级责任人（Senior Responsible Owner，SRO）**是对项目群达成其目标并实现其收益负全部责任的唯一个人，拥有足够的资历和权力来领导并做出决策。SRO 主持一个项目群委员会——通常包括一位业务变革经理、各项目负责人和高级利益相关者——为跨组织边界提供指导方向。

业务变革经理（Business change manager，BCM）。 MSP 独有的角色：来自运营业务方（而非交付团队）的人员，负责将变革落实并在现场实现收益。BCM 正是项目群能够交付成果而不仅仅是产出的原因——项目移交能力，BCM 将其转化为收益。

最佳实践#

1. 将项目群锚定在一个愿景和一份蓝图上。 定义战略成果，并将其转化为一个具体的目标运营模式（流程、组织、技术、信息——POTI）。每个组成项目和产品随后都被引导朝向同一个未来状态，这正是防止交付联盟分崩离析的原因。

2. 管理收益，而不仅仅是可交付物。 构建一份收益地图，将每项产出与其应产生的成果和可衡量收益关联起来，配有负责人和基线。在整个项目群中积极审查收益，并愿意停止那些不会带来回报的工作——MSP 对收益实现的重视，正是将一个项目群与一份昂贵的待办事项清单区分开来的纪律。

3. 将工作组织成若干批次，配有真实的审查点。 分批次交付能力，在每个批次边界展示迄今已实现的收益，根据所学到的内容重新检验蓝图，并做出真正的继续/调整/停止决策。早期批次应瞄准可见的速赢成果，为后续更难的部分建立利益相关者的信心。

4. 任命一位被赋权的 SRO 和一个真实的项目群委员会。 指定一位拥有足够资历和权力来指导项目群、并能跨组织边界做出决策的唯一 SRO，并召集一个真正代表受影响组织的委员会。当问责被分散、或 SRO 实际上无法让跨边界决策落地时，项目群就会失败。

5. 将业务变革经理安置在运营业务方。 从一线组织中指派 BCM，负责在照护交付现场拥有采纳和收益实现的所有权。能力已交付但未被采纳，就不会实现任何收益；BCM 角色正是弥合这一缺口的机制。

6. 协调——而不是微观管理——各组成项目和产品。 项目群设定蓝图、相互依赖关系、标准和收益；它让各个项目和产品团队在这个框架内交付。它管理的是接缝——共享数据标准、信息治理、排序和共享基础设施——而不是每项交付的内部细节。

7. 不懈地管理跨领域的风险、依赖关系和利益相关者。 一个项目群相对于独立项目所增加的价值，主要体现在管理各项目之间发生的事情上。维护一个项目群层面的相互依赖关系和共享风险视图，并大力投入到跨自治组织的利益相关者参与（Stakeholder engagement）中，因为对齐是自愿的，而不是被命令的。

8. 当变革已被内化时关闭项目群，并将持续服务移交给产品团队。 一个项目群是临时的。当蓝图已实现、收益正在实现时，审慎地将其关闭，将任何持久性服务转移给持久的产品团队（主题 5.0），并将收益跟踪延续到常态运营中——许多收益是在项目群结束后才产生的。

与团队讨论的问题#

1. 我们的高级责任人是否真的有权在主权伙伴组织之间让决策落地，还是仅仅在决策未能落地时承担问责？ 项目群主导型工作的存亡取决于跨边界的权威，因为这类变革跨越自治的信托机构、初级照护、社区、心理健康和社会照护，这些机构不能简单地被命令协调一致地行动。典型的失败是一位被指定的 SRO，承担着实现收益的个人公开问责，却没有足够的地位去迫使一个不情愿的伙伴采用一项共享数据标准或改变一项临床工作流程——有问责却没有权威。这场讨论应坦诚地面对系统中真正的权力所在：项目群委员会是真正代表受影响的组织，还是一个只是报告用的论坛；SRO 是否资深到足以让其决策在主权边界之间受到尊重；以及当一个伙伴拒绝行动时会发生什么。要考虑一次近期的跨组织决策，并追溯它是否真的落地了。一个好的答案会指明 SRO 是谁，并用一个具体的跨边界冲突来检验其权威，对那些能够有效地选择退出的组织保持诚实，并将一个具有代表性的委员会和嵌入其中的业务变革经理，当作自愿协调的负重机制，而不是治理的装饰。

2. 我们将如何知道这个项目群已经实现了收益，而不仅仅是交付了产出——运营业务方中，谁对将能力转化为收益负责？ 产出表演是本主题所警示的一个反复出现的病态：一个项目群花费数百万，产出一堆互操作性平台和集成，却没有为患者或员工带来任何可衡量的改变。防止这一点的关键区分因素，是业务变革经理——来自一线运营方而非交付团队的人，负责在照护交付现场落实变革并实现收益——因此这个问题迫使团队指明这些人是谁，并确认他们确实存在。这里的张力在于，交付是可见且令人满意的，而采纳则缓慢、不起眼，容易被想当然地认为会自然发生；一份被埋在额外登录步骤背后的共享照护记录，无论建得多好都不会实现任何收益。把收益地图带到讨论中，压力测试每项产出是否与一项有负责人、有基线、可衡量的收益（更少的重复检查、更少的延迟出院）相关联，还是收益仅仅是被断言的。一个诚实的答案会指明每个伙伴组织中的 BCM 是谁，承认目前哪些收益尚无负责人或未被衡量，并接受某些收益只有在项目群关闭之后才会产生，必须被跟踪到常态运营中。

3. 我们是否正在把这个项目群分批次，以尽早锁定收益并创造真正的继续/调整/停止决策点，还是正在漂向一场把所有风险都推迟到最后一刻的大爆炸式交付？ 批次正是将一个项目群与一份昂贵的冻结计划区分开来的关键：每个批次边界都应交付一步能力，展示迄今已实现的收益，根据实际学到的内容重新检验蓝图，并支持一个真正的继续、调整或停止决策。卫生与照护中的诱惑，是为了工程上的便利而排序，并推迟可见的价值——在任何人能使用任何东西之前先连接每一家信托机构——这会把所有风险都装进单一的最后交付中，让董事会没有证据来在财政和政治周期中为持续投资辩护。这场讨论应审视早期批次是否瞄准了刻意设计的速赢成果，以便为后续更难的工作建立利益相关者的信心，以及审查点是真正的决策还是仅仅是进度检查。要考虑第一个可展示的收益是什么、它多快落地，以及如果采纳滞后或蓝图被证明是错的，董事会在一次批次审查中真的会做什么。一个好的答案会描述具体的批次及其早期、可衡量的成果，把每个边界当作一次真正的是/否决策，蓝图真正对修订保持开放，并对任何将价值推迟到最后的压力保持诚实。

4. 我们是否有一份单一的、持续维护的目标运营模式蓝图，还是每个项目都在悄悄地朝着自己版本的未来优化？ 蓝图——流程、组织、技术和信息的具体 POTI 目标运营模式——正是使各个部分汇聚成一个连贯整体、而不是一堆局部看似合理的决策相互碰撞的关键所在。没有蓝图，每个组成项目都会理性地为自己的范围进行优化：一家信托机构选择适合其现有 EPR 的数据标准，另一家围绕自己的人员配置设计临床工作流程，共享照护记录就会分裂成技术上互相连接、却并不连贯一致的一堆集成。这里的张力在于，维护一份蓝图对承受交付压力的团队而言感觉像是额外负担，而它必须是一份在每个批次都被重新检验的活参照，而不是一份只写一次就被束之高阁的文档。这场讨论应确立蓝图是否真的以可用的形式存在、谁拥有它，以及真实的项目决策是被它引导的，还是事后才被拿来对照调和。要考虑某个项目中一项近期的设计选择，并问蓝图是塑造了它，还是被悄悄地绕开了。一个诚实的答案能指出一份当前的蓝图、指明它的所有者，并对局部优化目前正在把目标状态拉散的地方保持坦诚。

5. 当项目群关闭时，什么会持续存在——我们是否已经指明了将运行这项能力、并继续把收益跟踪到常态运营中的那些持久产品团队？ 一个项目群按定义是临时的，但共享照护记录、互操作性平台以及它们产生的收益却不是，因此关闭是一个从一开始就应规划的设计问题，而不是事后的补充。光谱两端反复出现的失败都是真实的：有些项目群从不关闭，在变革已被内化很久之后硬化为永久性的官僚机构，而另一些则戛然关闭，让一项实时的临床服务陷入无持久所有者的困境。本主题明确指出，持久性服务应转移给持久的产品团队（主题 5.0），并且许多收益只有在项目群结束后才会产生，必须被跟踪到常态运营中——这意味着接收团队和持续的收益所有权，必须在项目群仍拥有权力和资金来建立它们时就被确定下来。这场讨论应揭示谁将运行每项持久性能力、一旦转型资金停止后它将如何获得资金，以及在项目群委员会解散后谁继续衡量收益。一个好的答案会指明具体的产品团队和常态运营所有者，诚实地描述资金过渡，并将关闭和收益跟踪当作有计划的批次，而不是一次寄希望于顺利的移交。

6. 我们是如何管理各项目之间的接缝——共享标准、信息治理、排序和共享基础设施——而不是每项交付的内部事务的？ 一个项目群相对于一组独立项目所增加的价值，几乎完全存在于它们之间的空间中：相互依赖关系、共享数据标准、信息治理与知情同意框架，以及没有任何单一项目拥有、却都依赖的共同基础设施。对项目群团队而言，诱惑在于漂向微观管理每项交付的内部事务——这是舒适、可见的工作——而真正困难的跨领域接缝则无人管理，直到它们在上线时以一次集成失败或一个信息治理阻碍的形式浮现。在卫生与照护中，这些接缝异常承重，因为数据流动和知情同意跨越了自愿对齐、法律责任共担却资源分配不均的主权组织和监管边界。这场讨论应检验是否存在一个项目群层面的相互依赖关系和共享风险视图、谁拥有共享标准和基础设施，以及项目群是在协调接缝，还是在干涉项目细节。一个诚实的答案会识别出最威胁成果的具体接缝，指明其所有者，并对项目群是在边界处增加价值、还是在重复它本应促成的那些项目的工作，保持坦诚。

实践中：一个卫生与照护案例#

一个 ICS 着手交付一份共享照护记录，让急症、社区、心理健康、初级照护和社会照护领域的临床医生都能获得对一个人的统一视图。没有任何单一项目能交付这一切：它跨越多家信托机构、多个源系统、信息治理协议、临床工作流程重新设计和公众参与。它被作为一个 MSP 项目群来协调。

SRO——一位拥有真正跨系统权威的 ICS 高管——主持一个由每个伙伴组织的代表组成的项目群委员会，每个组织都指定了业务变革经理。该项目群设定了一个愿景（"关于正确的人的正确信息，在照护的那一刻，提供给正确的临床医生"）和一份蓝图，描述目标运营模式：基于 HL7 FHIR 的互操作性（Interoperability）数据共享架构和标准、信息治理框架、知情同意模式，以及重新设计的临床工作流程。

工作被组织成若干批次。第一批次连接两家愿意参与的急症信托机构，交付一份只读记录，这是一次刻意设计的速赢，证明了这种方法的可行性，让董事会能够展示一项早期收益——重复检查的可衡量减少——从而建立信心。在第一批次审查会上，董事会了解到，当记录被埋在额外的登录步骤后面时，临床医生的采纳会滞后，因此它调整了蓝图，在扩大推广之前优先实施单点登录（Single sign-on）集成。

在这个项目群之下，各种工作方式共存。互操作性平台由一个持久的产品团队（主题 5.0）运行，持续改进它，贯穿整个项目群乃至之后。每家信托机构的接入都是一个有边界的项目（主题 5.1），有自己的商业论证案和上线。项目群本身协调蓝图、标准、相互依赖关系，并通过 BCM 协调收益实现。当蓝图已实现、重复检查和延迟出院方面的收益正在流入时，该项目群关闭；平台产品团队持续存在，收益跟踪则延续到常态运营中。

行业视角#

初创企业#

很少有初创企业以 MSP 意义上运行项目群——它们缺乏定义一个项目群所需的多组织范围——但一家在多家信托机构中部署的成长型企业，实际上会成为一个项目群的参与者。它现实的角色是作为别人项目群内部的一个供应商：使其产品与项目群蓝图对齐，达成批次里程碑，并为 SRO 必须证明的收益案例提供支撑。资金和生存都依赖于项目群的持续，因此这家初创企业会把批次审查当作生死攸关的是/否节点，并投入到业务变革经理的成功之中，因为现场的采纳正是续约的关键。它必须借用的纪律是收益语言——将其价值表述为已实现的成果，而不是已发布的功能。

小型企业#

一家成熟的小型服务提供者——一家全科诊所、一家社区药房、一家养老院，或一家已过初创阶段的小型健康科技供应商——几乎从不运行一个项目群，但当一个 ICS 在辖区内推行共享照护记录或统一系统时，它会常态化地被卷入其中，成为一个受影响的参与者。它实际关心的是项目群所拥有的那条接缝：它必须在几乎没有专职 IT 能力、也没有余力吸收工作流程变革的情况下，采用被规定的数据标准、信息治理协议和知情同意模式，却承担着与周围大型信托机构相同的法律责任。它拥有的最有价值的关系，是与负责其所在地区的业务变革经理的关系，因为一次得到良好支持的采纳——培训、单点登录、一套真正适合该诊所实际运作方式的工作流程——是项目群的收益能否落地、与变革被悄悄绕开之间的区别。它对项目群的现实诉求，是不假定企业级资源的相称支持和排序，而它诚实的贡献，则是在批次审查中及早、坦率地反馈现场哪些东西行不通。

大型机构#

一个 ICS 或一家大型信托机构是项目群主导型工作的天然归宿：共享照护记录、EPR 统一和路径改造本质上都是多组织、多年期的。困难之处在于权威——SRO 必须让决策在无法被简单命令的主权伙伴组织之间落地，因此一个真正具有代表性的项目群委员会和嵌入每个伙伴组织的业务变革经理，是承重结构，而不是装饰。资金是混合的（系统转型资金、信托机构资本、国家拨款），这使得收益地图和批次审查对向系统领导者和监管机构证明持续投资的正当性至关重要。这种规模下反复出现的风险是产出表演：技术上的交付，却没有人对将其转化为收益负责。

政府#

在国家规模上，项目群承受着最重的治理：它们通常会进入政府重大项目组合（Government Major Projects Portfolio），接受 Infrastructure and Projects Authority 的保证和关口审查，并向大臣、Public Accounts Committee 和 National Audit Office 负责。SRO 对整个系统的收益实现承担个人和公开的问责，蓝图必须协调国家标准（互操作性、信息治理、作为共同入口的 NHS App）与地方自治之间的关系。资金通过多年期的 Spending Review 拨款来运作，因此分批次和收益证据是在财政和政治周期中维持或叫停投资的机制。利害关系是人口规模级别的：一个国家级项目群的收益——或其失败——是以数百万患者和数十亿英镑来衡量的。

常见失败模式#

• 产出表演。 项目群交付技术产出，但没有人拥有将其转化为收益的所有权，因此对患者而言什么都没有改变。纠正：配有负责人的收益地图，以及运营业务方中的 BCM。
• 一个只是大项目的项目群。 将固定范围、以产出为中心的治理，套用到真正充满不确定性的多组织变革上。纠正：按成果/收益和批次来管理，而不是一份单一的冻结计划。
• 一个无权的 SRO。 有问责，却没有跨边界决策的权威。纠正：任命一位足够资深、能让跨系统决策落地的 SRO，并由一个具有代表性的委员会作为后盾。
• 没有蓝图/目标状态。 各项目局部优化，各部分从未连贯一致。纠正：定义并维护一份所有工作都朝其引导的 POTI 蓝图。
• 大爆炸式交付而非分批次。 所有风险都被推迟到最后一次交付。纠正：将工作分批次，尽早锁定收益，并在审查点重新规划。
• 一个从不关闭的项目群。 在变革已被内化很久之后，它变成了一个永久性的官僚机构。纠正：审慎地关闭，将持久性服务移交给产品团队，继续在常态运营中跟踪收益。

成熟度模型#

检查清单#

• 这是否是真正的多项目、多组织变革，共同迈向一个战略成果？
• 是否有一个清晰的愿景和一份具体的蓝图（目标运营模式/POTI）？
• 是否有一份收益地图，将产出与可衡量的、有负责人的、有基线的收益关联起来？
• 工作是否被组织成若干批次，配有真实的继续/调整/停止审查点？
• 是否有一位被赋权的 SRO，拥有跨组织边界做出决策的权威？
• 项目群委员会是否真正代表受影响的组织？
• 业务变革经理是否嵌入运营业务方，拥有采纳的所有权？
• 跨领域标准、相互依赖关系和共享风险是否在项目群层面得到管理？
• 产品主导型、项目主导型和项目群主导型的工作方式是否以清晰的角色共存（主题 5.0–10）？
• 是否有一次审慎的关闭，持久性服务被移交给持久的产品团队，收益被跟踪到常态运营中？

关键资料来源#

• AXELOS / PeopleCert — 《管理成功的项目群（Managing Successful Programmes，MSP）》：原则、主题和转型流（包括蓝图、批次、收益管理，以及 SRO/BCM 角色）。
• 内阁办公室 / Infrastructure and Projects Authority（IPA）— 关于重大项目群、SRO 问责制和保证/关口审查的指导。
• HM Treasury — 《绿皮书（The Green Book）》及收益管理指导（收益的评估与评价）。
• AXELOS — 《项目组合管理（Management of Portfolios，MoP）》，用于在一个项目组合中定位项目群（参见主题 5.3——EPPM）。
• NHS England — 关于整合照护系统和共享照护记录（互操作性、HL7 FHIR 标准）的指导，作为领域背景。
• Mik Kersten — 《从项目到产品（Project to Product）》，论述从以产出为基础到以成果/收益为基础的投资转变。

参考文献#

1. Program management — Wikipedia — https://en.wikipedia.org/wiki/Program_management
2. Benefits realisation management — Wikipedia — https://en.wikipedia.org/wiki/Benefits_realisation_management
3. Target operating model — Wikipedia — https://en.wikipedia.org/wiki/Target_operating_model
4. Executive sponsor (Senior Responsible Owner) — Wikipedia — https://en.wikipedia.org/wiki/Executive_sponsor
5. Integrated care system — Wikipedia — https://en.wikipedia.org/wiki/Integrated_care_system
6. Electronic health record — Wikipedia — https://en.wikipedia.org/wiki/Electronic_health_record
7. Fast Healthcare Interoperability Resources (HL7 FHIR) — Wikipedia — https://en.wikipedia.org/wiki/Fast_Healthcare_Interoperability_Resources
8. Interoperability — Wikipedia — https://en.wikipedia.org/wiki/Interoperability
9. Single sign-on — Wikipedia — https://en.wikipedia.org/wiki/Single_sign-on
10. Stakeholder management — Wikipedia — https://en.wikipedia.org/wiki/Stakeholder_management
11. Managing Successful Programmes (MSP): principles, themes, and the transformational flow — AXELOS / PeopleCert — https://www.peoplecert.org/browse-certifications/project-programme-and-portfolio-management/MSP-1006
12. Guidance on major programmes, SRO accountability, and assurance/gateway reviews — Cabinet Office / Infrastructure and Projects Authority — https://www.gov.uk/government/organisations/infrastructure-and-projects-authority
13. The Green Book and benefits-management guidance — HM Treasury — https://www.gov.uk/government/publications/the-green-book-appraisal-and-evaluation-in-central-governent
14. Management of Portfolios (MoP) — AXELOS / PeopleCert — https://www.peoplecert.org/
15. Integrated care systems and shared care records (interoperability, HL7 FHIR standards) — NHS England — https://www.england.nhs.uk/integratedcare/
16. Project to Product — Mik Kersten, IT Revolution (2018) — https://itrevolution.com/product/project-to-product/