主题 5.1 — 项目主导型工作

一句话概括： 当工作有明确的范围、有限的生命周期和清晰的终结状态时，项目主导型工作就是正确的工具——它是一项临时的、受控的努力，按约定的时间、成本和质量交付，然后关闭。

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

并非所有事物都是持续存在的服务。卫生与照护中一些最重要的工作确实是有限的：从一套电子病历（Electronic health record）系统迁移（Data migration）到另一套、在整个医院院区推出 Wi-Fi、更换已到寿命末期的服务器、在供应商合同结束前退役一套遗留系统，或交付一座新医院建设项目中的数字化部分。这类工作有开始、有过程、也有明确的终点。若将其作为一项无限期的产品来管理，会浪费资金并模糊问责；它需要一个项目所具备的纪律性。

项目管理（Project management）之所以在此发挥价值，正是因为利害关系高、约束条件硬。一次数据迁移的切换有一个固定的上线周末、若记录丢失或损坏就会带来患者安全风险，以及一旦旧系统关闭就会出现的合同悬崖式风险。公共资金是依据一份商业论证案（business case）承诺投入的，议会、审计人员和董事会都会追问这笔钱是否按批准的方式花掉。项目主导型工作提供了治理结构——一份商业论证案、阶段关卡（stage gate），以及受控的关闭——使董事会能够有信心地承诺资本投入，并在理由不再成立时干净利落地叫停工作。

危险在于把这个工具用错了地方。将项目主导型治理套用到一个不断演进的数字服务上，会产生主题 5.0——产品主导型工作中所描述的"建好即弃"的病态。本主题说明项目主导型工作在何处是正确的工具，以及其局限从何处开始。它与协调多个项目的主题 5.2——项目群主导型工作，以及在这些工具之间做出选择的主题 5.3——企业级项目组合与项目管理（EPPM）并列。

核心概念#

项目（Project）。 一个临时性组织，其创建目的是在时间、成本和质量的约束下，按约定规格交付一项或多项明确的产出。其定义性特征是它是临时的——它的存在是为了达成一个明确的终点，然后解散。

铁三角（Iron triangle）（范围、时间、成本）。 经典的约束模型：范围、进度和预算是相互依存的，质量则受它们如何被权衡的影响。改变其中一个，就会改变其他两个；项目控制在很大程度上就是透明地管理这种权衡取舍的纪律。

PRINCE2（受控环境中的项目，PRojects IN Controlled Environments）。 英国政府的结构化项目方法，在 NHS 和公共部门中被广泛使用。它建立在若干原则之上（持续的商业论证、明确的角色、按阶段管理、例外管理、聚焦于产品、从经验中学习、因地制宜地裁剪），并将工作组织成若干受控阶段，由一个项目委员会提供指导方向。

PMI / PMBOK。 项目管理协会（Project Management Institute）的《项目管理知识体系指南（Guide to the Project Management Body of Knowledge）》是占主导地位的国际对应方法，它围绕绩效领域和原则来构建项目工作，而不是一套预设的分阶段流程。PRINCE2 与 PMBOK 是对同一学科的互补视角。

商业论证案（Business case）。 为项目提供正当理由的文件：问题、已评估的备选方案、预期收益、成本和风险。在 PRINCE2 中，商业论证案是活的——它在每个阶段边界都会被核查，如果持续的商业理由不再成立，正确的决定就是停止。在英国公共机构中，这通常按 HM Treasury 的五案例模型（Five Case Model，战略、经济、商业、财务、管理）来构建。

阶段关卡（Stage gates）。 一个 PRINCE2 项目被划分为若干管理阶段，由决策关卡分隔。在每个边界，项目委员会都要做出一个审慎的停止/继续决策：它审查进展和商业论证案，批准下一阶段计划，并仅为该阶段承诺资源。这正是董事会保持控制、避免在坏账上不断追加投入的方式。

RAID 日志。 风险（Risk）、假设（Assumption）、问题（Issue）和依赖项（Dependency）的单一登记册——是项目经理的核心控制工具。RAID 使不确定性变得可见和可管理：风险是可能发生的事，问题是已经发生的事，假设是计划所依赖的前提，依赖项是计划需要从其他方获得的东西。

最佳实践#

1. 从一份诚实的商业论证案开始，并让它保持鲜活。 使用一种公认的结构（英国公共机构中的五案例模型）来评估真实的备选方案，而不是一个预先设定好的单一答案。然后将商业论证案作为一份活文档对待，在每个阶段关卡都进行审查——持续的商业论证是 PRINCE2 的第一条原则，失去它就是合理的停止理由。

2. 精确地界定范围，并控制对它的变更。 一个项目的价值在于对"完成"有一个清晰、有边界的定义。就范围达成一致，将其设为基线，并让每一项拟议的变更都经过变更控制流程，以免范围蔓延（Scope creep）悄悄吞噬预算和时间表。

3. 按阶段管理，并设置真正的决策关卡。 将工作拆分为若干管理阶段，在每个边界举行真正的停止/继续审查。一个总是说"继续"的关卡只是表演；只有当停止或重新规划是董事会真的会采取的选项时，这种纪律才有效。

4. 维护一份实时的 RAID 日志，并按例外情况上报。 将风险、假设、问题和依赖项维护在一处，定期审查，并使用 PRINCE2 的"例外管理"——项目经理在约定的容差范围内运作，只有当某项容差受到威胁时才上报给董事会。这使高层的时间聚焦于真正的决策。

5. 分配清晰的、单一责任点的问责制。 PRINCE2 坚持要求明确角色：一个项目委员会，包括一位拥有商业论证案所有权的高级责任人/执行官（Senior Responsible Owner/Executive）、一位代表使用该产出者的高级用户，以及一位高级供应商。模糊的问责制是最常见的漂移原因。

6. 在开始之前就规划好向实时服务的过渡。 项目交付的是一项产出；此后必须有人来运营它。作为项目的一部分，就接收团队、支持模式和临床安全交接（部署阶段的 DCB0160）达成一致，使上线不会变成跌入所有权真空的悬崖。

7. 将临床安全、信息治理和测试内嵌其中。 对任何涉及患者数据的系统，临床安全案例、DPIA 以及切换/回滚测试都不是可选的附加项——它们是关卡型交付物。没有经过测试的回滚计划的迁移，还没准备好上线。

8. 审慎地关闭项目，并汲取经验教训。 一个明确的终点意味着一次明确的关闭：确认产出已被验收、移交给运营方、解散团队，并记录经验教训（PRINCE2 的经验教训日志）。一个未被正式关闭的项目会无限期地泄漏资源和问责。

与团队讨论的问题#

1. 我们面前的工作真的是有限的、有明确终结状态的，还是我们只是因为熟悉这条资金渠道才套用项目治理？ 这是本主题所围绕的决定性问题，因为项目主导型纪律只有在工作确实有开始、有过程、有明确终点时才是正确的工具。在一个卫生与照护机构中，向项目形态靠拢的拉力很强——资本预算编制、商业论证案机制和董事会报告都是为此而建的——因此一个不断演进的数字服务可能仅仅因为这是资金被释放的方式，就被包装成一个项目，进而产生建好即弃的病态。这场讨论应诚实地审视每一个候选对象：一次在供应商撤回支持之前的病理系统更换，有一个硬性的合同悬崖式截止期，明确无疑是有限的，而"改进患者应用程序"没有终结状态，属于主题 5.0 的范畴。要考虑是否存在一个真正的上线之后团队就应该解散的时刻，还是会有人需要无限期地持续改进这件事。一个好的答案会拒绝把项目治理当作一种习惯来使用，指明具体的终结状态和定义"完成"的事件，并愿意承认我们目前作为项目运行的某些工作，本就不应该是项目。

2. 在我们的阶段关卡上，如果一个项目已失去其正当理由，这个董事会真的会叫停或重新规划吗——我们能举出一次这样做过的例子吗？ 阶段关卡只有在停止是董事会真的会行使的一个真实选项时，才算一种控制；一个总是说"继续"的关卡只是表演，而持续的商业论证之所以是 PRINCE2 的第一条原则，正是因为失去它就应该结束这项工作。在卫生与照护中，这种张力十分尖锐：叫停一个已建到一半的 EPR 迁移或一次实验室系统切换，感觉像是承认失败、浪费沉没成本、并扰乱已经改变了计划的临床医生，因此董事会会为继续推进找理由，即使商业论证案正在悄悄蒸发。带一个真实的例子来讨论——一个测试揭示数据映射风险比假设的更糟的项目，或一个收益已经滑坡的项目——并问这个关卡是被按设计使用了，还是被走过场地盖了章。要考虑哪些容差会触发上报、董事会中谁有权叫停，以及沉没成本推理是否在会议室里被明确指出并受到质疑。一个诚实的答案会承认哪些关卡一直只是形式，描述董事会真的会叫停或重新界定范围的条件，并把在公开注销之前叫停的权力，当作这套纪律的真正价值，而不是一种威胁。

3. 谁接收每个项目的产出作为一项实时服务，我们如何让临床安全交接和持续所有权成为一项关卡型交付物，而不是一道悬崖？ 一个项目交付的是一项产出；某件有限的事情结束了，但它所产生的东西必须在团队解散之后很长时间里被运营、改进并保持安全——而最常见的悄然失败是，另一边没有人拥有它。在一个涉及患者数据的系统中，这不是行政上的整洁问题：DCB0160 部署安全案例、DPIA、经过测试的回滚，以及一个指定的接收团队，正是受控上线与安全风险不受管理地积累的所有权真空之间的分界。这场讨论应迫使在项目开始之前——而不是在上线周末——就明确过渡方案：哪个运营团队接手、支持模式是什么，以及那个团队是否有能力和合适的工作方式（按主题 5.0 的产品主导型）来持续改进它。要考虑近期的具体上线情况，交接是有计划的还是临时拼凑的，以及"项目完成了"是否被允许意味着"现在这不是任何人的工作了"。一个好的答案会预先指明接收团队和支持模式，把安全交接当作项目若不通过就无法通过的一道关卡，并明确地将实时服务的持续改进分配给正确的工作方式，而不是任其漂移。

4. 当铁三角发威、范围、时间和成本互相冲突时，我们让哪个约束条件让步，患者安全是否永远不被允许成为可以让步的变量？ 每个真实的项目最终都会遇到进度、预算和承诺的范围无法同时守住的时刻，而团队如何解决这种挤压，揭示了它真正重视的是什么。在卫生与照护中，陷阱是独特的：因为终结日期往往是一个硬性的合同悬崖式截止期——供应商撤回支持、租约到期、数据中心关闭——所以时间往往无法移动，压力于是悄悄落到质量上，而在一个临床系统中这意味着削减测试、压缩验证，或带着已知的数据映射缺陷发布。这场讨论应事先明确说明机构将保护三角形的哪个角、将牺牲哪个角，并明确表示即便其他一切都固定不变，临床安全和信息治理也不是那个泄压阀。看一次近期的切换，问当日期保持不变时，悄悄让步的是什么：是回滚演练、临床验证窗口，还是培训？要考虑谁有权移动上线日期，而不是侵蚀安全余量，以及这场对话是在董事会公开进行的，还是在现场默认发生的。一个诚实的答案会在压力到来之前就说明优先次序，把一个延迟的日期或一个重新规划的阶段当作一个合理的结果，并拒绝让未言明的进度压力转化为未被记录的临床风险。

5. 我们的 RAID 日志是一个会改变我们所做之事的实时工具，还是一份为了看起来受到治理而维护的文档——它是否真的能揭示出真正会让项目沉没的风险？ 一份 RAID 日志只有在审查它会改变决策时才有其价值；常见的病态是，一份在启动会上写就、在董事会上展示、却从未被真正采取行动的登记册，而真正重要的风险则在无人留意中成熟。在一次迁移或切换中，决定性的风险往往是具体的、可知的——历史结果无法干净地映射到新的参考范围、依赖另一个团队的防火墙变更、假设临床验证资源在需要时会有空——问题在于日志是否具体地指明了这些，还是躲在"资源限制"之类的泛泛条目背后。这场讨论应检验按例外上报是否真实存在：项目经理是否在约定的容差范围内运作、只有当某项容差受到威胁时才引起董事会的注意，还是一切要么保持沉默、要么变成危机？要考虑险情和已发生的问题是否会反馈到下一阶段的规划方式中，还是仅仅被记录后遗忘。一个好的答案能指出 RAID 日志真正改变过的一项决策，将真正可能让项目停摆的两三个风险与一大堆次要风险区分开来，并将该日志当作一种正在发挥作用的控制手段，而不是为了保证而制作的一件展品。

6. 在我们关闭并解散之后，是否有人核查商业论证案中的收益是否真的实现了——如果没有实现，我们会知道吗？ 商业论证案承诺了收益以证明支出的合理性，但项目主导型工作天然会在上线和团队解散时结束，因此真相揭晓的时刻——这次迁移是否真的降低了风险、削减了成本，或改善了照护——通常发生在所有人都已转向他处之后，也没有人对确认这一点负责。这在公共卫生与照护中尤为关键，因为资金是依据一份五案例商业论证案承诺的，议会、审计人员和董事会被告知这将带来特定成果，然而收益实现却是最常被跳过的一步，因为本应拥有它的那个项目已不复存在。这场讨论应决定，当项目关闭时，谁继承收益跟踪工作，跟踪多长时间，依据哪些基线测量——这些基线必须在上线前就被采集，否则就会丢失。要考虑一个近期完成的项目，坦率地问一问此后是否有人核查过它承诺的收益，以及一个短缺是否会传达到批准该项目的董事会。一个诚实的答案会将关闭后的收益所有权分配给一个常设职能，而不是已解散的团队，在项目仍处于运行状态时就采集基线数据，并愿意记录下这样的情况：一个项目按时、按预算交付了其产出，却没有交付证明其正当性的价值。

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

一家急症信托机构必须在现任供应商撤回支持前的 14 个月内，更换其老化的病理实验室信息管理系统。这是教科书式的项目主导型工作：固定的终结日期、明确的范围、硬性的合同悬崖式截止期，以及若结果在迁移中丢失就会带来的严重患者安全风险。

该信托机构撰写了一份五案例商业论证案，评估了三个备选方案（原地升级、采购新系统、共享一个区域实例），选择了采购方案，并成立了一个拥有明确委员会的 PRINCE2 项目：一位拥有商业论证案所有权的执行官、一位高级用户（首席生物医学科学家），以及一位高级供应商。工作被拆分为若干管理阶段——采购、构建与配置、数据迁移、测试和上线——每个阶段都以一次决策关卡结束。

项目经理维护着一份 RAID 日志。一项关键风险是历史结果可能无法干净地映射到新系统的参考范围；一项依赖是网络团队的防火墙变更；一项假设是临床验证资源在测试时将会可用。在迁移阶段关卡上，测试揭示数据映射风险比假设的更严重，因此董事会按设计使用了这个关卡：它没有盲目地继续下去，而是批准了一个重新规划的阶段，延长了验证窗口，并制定了经过测试的回滚计划，将患者安全置于原定进度之上。

上线在一个受控的周末进行，回滚计划处于待命状态，并获得了 DCB0160 临床安全签核。该系统被验收，移交给将运营它的运营团队，经验教训被记录，项目被正式关闭。团队解散——这是正确的，因为工作确实完成了。接下来的事情（实时服务的持续改进）是一种不同的工作方式，该信托机构谨慎地避免为此永久保留一个满编的项目团队。

行业视角#

初创企业#

一家小型数字健康公司很少运行正式的 PRINCE2 项目，但确实有限的工作依然会出现——一次性迁移到一个新的云平台、一次网络基础认证（Cyber Essentials）或 DTAC 认证冲刺、在一份重大 NHS 合同之前的渗透测试整改。这家初创企业将这些当作轻量级的、有时限的工作来处理，指定一位负责人和一个清晰的完成定义，借用其纪律（固定范围、一个终结日期、一次是/否决策），但不要繁文缛节（没有正式的项目委员会，没有五阶段关卡）。资金实际上就是创始人的注意力和资金跑道，因此风险在于有限的工作被挤压在产品冲刺之间，从未真正被关闭。纠正措施是指定一位负责人和一个硬性截止期，并将认证或迁移当作已彻底完成的事，而不是永远"进行中"。

小型企业#

一家成熟的小型服务提供者——一家全科诊所、一家社区药房、一家养老院，或一家单点诊所——把项目主导型工作当作偶尔发生但无法回避的事件来遇到：更换临床系统供应商、迁移到一个新的诊所管理平台，或在支持到期前更换到寿命末期的设备。该机构有真实的患者和持续的运营，但没有专职的项目或 IT 职能，因此"项目团队"通常就是诊所经理或一位注册经理在日常工作之外兼顾此事，往往依赖接手的供应商来运行迁移。在与这一现实接触后仍能存活下来的纪律是那个轻量级核心：一个清晰的终结状态、一个基线化的范围以免供应商悄悄扩大它、一位指定的问责人，以及在任何触及患者记录的切换之前经过测试的回滚。陷阱在于不仅外包了工作，还外包了判断——不经独立核查就接受供应商的上线日期和数据映射保证——因为同样的临床安全和信息治理责任（DCB0160、一份 DPIA）无论机构多小都同样适用。纠正措施是将是/否决策和验收标准的所有权留在内部，即使其他每一双手都属于供应商。

大型机构#

一家大型 NHS 信托机构或一个整合照护系统（ICS）正是项目主导型工作最得心应手之处：EPR 更换、全院区 Wi-Fi、数据中心退出，以及各类切换都带有硬性的合同和患者安全悬崖式截止期。在这里，整套完整的机制是有正当理由的——一份五案例商业论证案、一个拥有指定执行官/SRO、高级用户和高级供应商的 PRINCE2 委员会、带有真实关卡的管理阶段，以及一份实时的 RAID 日志——因为涉及金额巨大、安全风险严重，内部审计和董事会都会审视这笔支出。在这种规模下的典型失败，是将同一套治理不加区分地套用到持续存在的服务（主题 5.0——产品主导型工作）和有限的工作上，因此一种能将每项工作导向正确工作方式的项目组合视角（主题 5.3——企业级项目组合与项目管理）就很重要。临床安全（DCB0160）和经过测试的回滚是关卡型交付物，而非可选的附加项。

政府#

在国家级或重大项目规模上，项目主导型工作处于政府保证机制之中：Infrastructure and Projects Authority 运行关口审查（gateway review），HM Treasury 的绿皮书（Green Book）和五案例模型规范商业论证案，最大的项目会进入政府重大项目组合（Government Major Projects Portfolio），并向议会和 National Audit Office 承担公开的问责。问责是高度公开的——高级责任人（senior responsible owner）个人承担责任，可能被要求出席特别委员会作证——因此阶段关卡和备选方案评估是法定级别的控制，而不是表演。资金是依据已批准的商业论证案分批次释放的，风险偏好很低，因为失败会成为头条新闻。这套纪律在此处的真正价值，是在一个失败的项目变成公开的注销损失之前，叫停或重新界定其范围的权力。

常见失败模式#

• 对一项不断演进的服务进行项目式管理。 将固定范围、终点解散的治理套用到一个持续存在的数字产品上，会产生弃置病态。纠正：对持续存在的服务使用产品主导型工作（主题 5.0）。
• 商业论证案只是获取资金的一次性入场券。 只写一次以解锁资金，之后再也不重新审视。纠正：在每个阶段关卡审查它；愿意叫停。
• 走过场的阶段关卡。 从不说"停止"的关卡不提供任何控制。纠正：让停止或重新规划成为董事会一个真实的选项，并使用它。
• 没有变更控制的范围蔓延。 不受控制的增补会拖垮时间和成本。纠正：将范围设为基线，让每项变更都经过变更控制。
• 没有服务过渡计划。 项目结束了，却没有人拥有其产出。纠正：在上线之前就接收团队和支持模式达成一致。
• 把 RAID 当作文件柜。 一份被写下却从未被采取行动的日志。纠正：定期审查 RAID，并按例外情况上报。
• 从未真正关闭。 无止境地消耗资源的僵尸项目。纠正：一次审慎的关闭，包括验收、移交和经验教训记录。

成熟度模型#

检查清单#

• 这项工作是否真正有限，有明确的范围和终结状态（而不是一项持续的服务）？
• 是否有一份活的商业论证案（五案例模型），在每个阶段关卡都被审查？
• 范围是否已设为基线，配有可运作的变更控制流程？
• 工作阶段是否已明确界定，每个阶段都以一次真实的停止/继续决策关卡结束？
• 项目委员会角色是否清晰——执行官/SRO、高级用户、高级供应商？
• 是否维护着一份实时的 RAID 日志，并按例外情况上报？
• 临床安全（DCB0160）、DPIA 以及切换/回滚测试是否是关卡型交付物？
• 接收运营团队和支持模式是否已在上线前达成一致？
• 是否有一次审慎的关闭：验收、移交、团队解散、记录经验教训？
• 实时服务的持续改进是否已被分配给正确的工作方式？

关键资料来源#

• AXELOS / PeopleCert — 《使用 PRINCE2 管理成功的项目（Managing Successful Projects with PRINCE2）》（第 7 版）及 PRINCE2 的原则、主题和流程。
• 项目管理协会（Project Management Institute，PMI）— 《项目管理知识体系指南（A Guide to the Project Management Body of Knowledge，PMBOK Guide）》及《项目管理标准（The Standard for Project Management）》。
• HM Treasury — 《制定项目商业论证案指南（Guide to Developing the Project Business Case）》（五案例模型 / 绿皮书）。
• Infrastructure and Projects Authority（IPA），内阁办公室 — 重大项目的保证与关口审查指导。
• NHS Digital 临床安全标准 DCB0160（卫生信息技术系统的部署）。
• NHS England — NHS 服务手册与数字服务标准（用于服务过渡和用户需求背景）。

参考文献#

1. Project management — Wikipedia — https://en.wikipedia.org/wiki/Project_management
2. PRINCE2 — Wikipedia — https://en.wikipedia.org/wiki/PRINCE2
3. Project management triangle (iron triangle) — Wikipedia — https://en.wikipedia.org/wiki/Project_management_triangle
4. Project Management Institute — Wikipedia — https://en.wikipedia.org/wiki/Project_Management_Institute
5. Project Management Body of Knowledge — Wikipedia — https://en.wikipedia.org/wiki/Project_Management_Body_of_Knowledge
6. Business case — Wikipedia — https://en.wikipedia.org/wiki/Business_case
7. Phase-gate process (stage gates) — Wikipedia — https://en.wikipedia.org/wiki/Phase-gate_process
8. Scope creep — Wikipedia — https://en.wikipedia.org/wiki/Scope_creep
9. Data migration — Wikipedia — https://en.wikipedia.org/wiki/Data_migration
10. Electronic health record — Wikipedia — https://en.wikipedia.org/wiki/Electronic_health_record
11. HM Treasury — Wikipedia — https://en.wikipedia.org/wiki/HM_Treasury
12. Managing Successful Projects with PRINCE2 (7th edition) — AXELOS / PeopleCert — https://www.peoplecert.org/browse-certifications/project-programme-and-portfolio-management/PRINCE-2-1005
13. A Guide to the Project Management Body of Knowledge (PMBOK Guide) — Project Management Institute — https://www.pmi.org/
14. The Green Book and Guide to Developing the Project Business Case (Five Case Model) — HM Treasury — https://www.gov.uk/government/publications/the-green-book-appraisal-and-evaluation-in-central-governent
15. Assurance and gateway review guidance for major projects — Infrastructure and Projects Authority, Cabinet Office — https://www.gov.uk/government/organisations/infrastructure-and-projects-authority
16. Clinical risk management standard DCB0160 — NHS England — https://digital.nhs.uk/services/clinical-safety