トピック5.2 — プログラム主導の仕事

一文で言うと： プログラム主導の仕事は、関連するプロジェクトとプロダクトの集合を、どれも単独では実現できない戦略的な変革に向けて調整し、仕事から、それが実現するはずの便益まで、明確な見通しの線を保ちます。

医療・ケアにおいてなぜ重要か#

医療・ケアの最大の変革は、決して単一のプロジェクトではありません。統合ケアシステム（ICS）全体での共有ケア記録の展開、地域を単一の電子患者記録へ移すこと、救急・緊急ケアのパスウェイの変革、複数のトラストにまたがるバーチャルウォードのプログラムの提供。これらのそれぞれは、一つの戦略的な成果に整合した、プロジェクト、プロダクトチーム、労働力の変革、施設の作業、臨床の再設計の、調整された束です。断片を別々に管理すれば、それらは衝突します。互換性のないデータ標準、重複した支出、矛盾する臨床ワークフロー、そして決して実現しない便益。

プログラムマネジメントは、その連合を束ね、単にアウトプットではなく、成果と便益に向け続けるために存在します。これは、医療・ケアで特に重要です。システム全体の変革は、組織の境界をまたいで患者安全に触れ、数年にわたって多額の公金を投じ、歩調を合わせて動くことを選ぶ多くの自律した組織に依存するからです。プログラムは、それを実現し、同じく重要なことに、それがうまくいっているかを知るための、リーダーシップ、共有された目標状態、便益の規律を提供します。

それが防ぐ繰り返される失敗は、何百万も費やし、技術的なアウトプットの山を届けながら、患者や職員にとって測定可能なものを何も変えないプログラムです。本トピックは、英国の公共部門で支配的な枠組みであるManaging Successful Programmes（MSP）を使い、プログラム主導の仕事が、それが調整するプロジェクト主導（トピック5.1 — プロジェクト主導の仕事）とプロダクト主導（トピック5.0 — プロダクト主導の仕事）の様式と、どう共存するかを示します。そのうえで、トピック5.3 — エンタープライズ・プロジェクト・ポートフォリオマネジメント（EPPM）が、組織が多くのプログラムにわたってどう優先順位をつけるかを説明します。

中核概念#

プログラム。 戦略的な目標に整合した成果と便益を届けるために、関連するプロジェクトと活動のグループを調整し、指揮し、監督する、一時的で柔軟な組織です。プログラムがプロジェクトと異なるのは、単一の固定されたアウトプットを届けるのではなく、それが求める成果と便益によって定義され、多くの動く部分を調整する不確実性を管理する点にあります。

MSP（Managing Successful Programmes）。 複数の関連するプロジェクトを通じて、変革的な変化を管理するための、英国のベストプラクティスの枠組みです。原則、テーマ、プロセスの「変革のフロー」を軸に組織され、終了状態の方向は知られているが、道筋が多くの相互依存する納品を伴う、大規模で複雑な変化のために設計されています。

ビジョンとブループリント。 ビジョンは、プログラムが作り出す未来の、説得力のある像です。ブループリントは、それを具体的にします。目標運用モデル、つまりプロセス、組織、技術、情報、役割の将来の状態（しばしばPOTIと要約されます）を記述します。ブループリントは、あらゆるプロジェクトが向かう基準点であり、断片が一貫した全体になるようにします。

便益の実現。 プログラムマネジメントの核心です。便益は、投資を正当化する、測定可能な改善です。減った退院の遅れ、減った重複検査、より速い診断、より低い事務負担。MSPは、アウトプットが、ケアの提供方法を変えるために使われて初めて価値を生むため、ライフサイクル全体にわたる便益の特定、マッピング、測定、積極的な管理を、中核の規律として扱います。

トランシェ。 MSPは、プログラムを、能力の一段階が届けられ、便益の実現が始められる、主要なレビュー地点で終わる仕事のまとまりである、トランシェに分けます。トランシェは、単なるスケジュールの一切れではなく、成果を示し、現実に照らしてブループリントを見直し、続行するか、調整するか、止めるかを決める瞬間です。

プログラムボードとSRO。 **上級責任者（SRO）**は、プログラムが目標を達成し便益を実現することに説明責任を負う単一の個人で、リードして判断を下すのに十分な上級性と権限を持ちます。SROは、通常、ビジネスチェンジマネージャー、プロジェクトリード、上級のステークホルダーからなる、組織の境界をまたいで方向を示すプログラムボードの議長を務めます。

ビジネスチェンジマネージャー（BCM）。 MSPに特徴的な役割です。運用の現場（デリバリーチームではなく）から来る、変化を定着させ、現場で便益を実現することに説明責任を負う人です。BCMは、プログラムがアウトプットだけでなく成果を届ける理由です。プロジェクトが能力を引き渡し、BCMがそれを便益に変えます。

ベストプラクティス#

1. プログラムを、ビジョンとブループリントに結びつける。 戦略的な成果を定義し、それを具体的な目標運用モデル（プロセス、組織、技術、情報 — POTI）に落とし込みます。そうすれば、あらゆる構成するプロジェクトとプロダクトが、同じ将来の状態に向かい、納品の連合が断片化するのを防ぎます。

2. 納品物だけでなく、便益を管理する。 各アウトプットを、それが生むはずの成果と測定可能な便益に結びつける、所有者とベースラインを伴う便益マップを作ります。プログラム全体にわたって便益を積極的にレビューし、見返りのない仕事を止める意思を持ちます。MSPの便益の実現への強調は、プログラムを、高価なやることリストから区別する規律です。

3. 仕事を、本物のレビュー地点を伴うトランシェに構造化する。 能力をトランシェで届け、各トランシェの境界で、ここまでに実現した便益を示し、学んだことに照らしてブループリントを再検証し、本物の続行／調整／停止の判断を下します。初期のトランシェは、より難しい後のトランシェへのステークホルダーの信頼を築くため、目に見えるクイックウィンを狙うべきです。

4. 権限を与えられたSROと、本物のプログラムボードを任命する。 プログラムを指揮し、組織の境界をまたいで判断する上級性と権限を持つ単一のSROを名指しし、影響を受ける組織を本当に代表するボードを招集します。説明責任が拡散している、あるいはSROが、境界をまたぐ判断を実際に定着させられないとき、プログラムは失敗します。

5. ビジネスチェンジマネージャーを、運用の現場に置く。 第一線の組織からBCMを割り当て、ケアが提供される場所での採用と便益の実現を所有させます。届けられても採用されない能力は、便益を実現しません。BCMの役割は、そのギャップを埋める仕組みです。

6. 構成するプロジェクトとプロダクトを、マイクロマネジメントではなく調整する。 プログラムは、ブループリント、相互依存、標準、便益を設定し、その枠組みの中で、プロジェクトとプロダクトのチームが納品できるようにします。各納品の内部の詳細ではなく、継ぎ目、つまり共有のデータ標準、情報ガバナンス、順序づけ、共有のインフラを管理します。

7. 横断的なリスク、依存関係、ステークホルダーを、徹底して管理する。 プログラムが、独立したプロジェクトに対して加える価値は、大部分が、それらのあいだで起きることを管理することにあります。相互依存と共有のリスクについて、プログラムレベルの視点を保ち、整合が命じられるものではなく自発的なものであるため、自律した組織をまたぐステークホルダーエンゲージメントに大きく投資します。

8. 変化が定着したらプログラムを終結し、継続的なサービスをプロダクトチームに引き継ぐ。 プログラムは一時的です。ブループリントが達成され、便益が実現されつつあるとき、意図して終結し、継続的なサービスを継続的なプロダクトチーム（トピック5.0）に移し、多くの便益がプログラムの終了後に生じるため、便益を通常業務の中まで追跡し続けます。

チームで話し合うための問い#

1. 私たちの上級責任者は、主権を持つパートナー組織にまたがって判断を定着させる権限を、実際に持っているか。それとも、定着しなかったときの説明責任だけを持っているのか。 プログラム主導の仕事は、境界をまたぐ権限で生き死にが決まります。変化は、単に歩調を合わせて動くよう命じることのできない、自律したトラスト、プライマリケア、コミュニティ、精神保健、社会的ケアにまたがるからです。典型的な失敗は、便益について個人的で公的な説明責任を負いながら、共有のデータ標準を採用したり、臨床のワークフローを変えたりするよう、乗り気でないパートナーに強いる立場を欠く、名前のあるSROです。権限のない説明責任です。議論は、システムの中の本当の力がどこにあるかについて、率直であるべきです。プログラムボードは、影響を受ける組織を本当に代表しているのか、単なる報告の場か、SROは、主権を持つ境界を越えて、その判断が尊重されるほど上級か、そして一つのパートナーが動くことを拒んだとき、何が起きるか。最近の組織間の判断を考え、それが実際に定着したかをたどります。良い答えは、SROが誰かを挙げ、具体的な境界をまたぐ対立に照らして、その権限を試し、事実上オプトアウトできる組織について誠実で、代表性のあるボードと組み込まれたビジネスチェンジマネージャーを、ガバナンスの飾りではなく、自発的な整合のための荷重を支える仕組みとして扱います。

2. このプログラムが、アウトプットを届けただけでなく、便益を実現したことを、どうやって知るか。そして、運用の現場で、能力を便益に変えることに説明責任を負うのは誰か。 アウトプットの芝居は、本トピックが警告する、繰り返される病理です。プログラムが何百万も費やし、相互運用性のプラットフォームと連携の山を作りながら、患者や職員にとって測定可能なものが何も変わらない。それを防ぐ区別が、ビジネスチェンジマネージャーです。デリバリーチームではなく、第一線の運用から来る、ケアが提供される場所で、変化を定着させ便益を実現することに説明責任を負う人です。この問いは、チームにそれらの人々を名指しさせ、彼らが存在することを確認させます。緊張は、デリバリーは目に見えて満足感があり、一方で採用は、遅く、地味で、ひとりでに起きると想定しやすいことです。余計なログインの陰に埋もれた共有ケア記録は、どれだけよく作られていても、便益を実現しません。便益マップを議論に持ち込み、各アウトプットが、所有され、ベースライン化された、測定可能な便益（重複検査の減少、退院の遅れの減少）に結びついているか、便益が単に主張されているだけかを、ストレステストします。誠実な答えは、各パートナー組織のBCMを挙げ、便益が現在、所有されていない、あるいは測定されていないところを認め、一部の便益が、プログラムの終結後にのみ生じ、通常業務の中まで追跡されなければならないことを受け入れます。

3. このプログラムを、早期の便益を確保し、本物の続行／調整／停止の地点を作るためにトランシェ化しているか。それとも、すべてのリスクを遅い一つの瞬間に先送りする、ビッグバンの納品へ流れているか。 トランシェは、プログラムを、高価な凍結された計画から区別するものです。各トランシェの境界は、能力の一段階を届け、ここまでに実現した便益を示し、実際に学んだことに照らしてブループリントを再検証し、続行、調整、停止の本物の判断を支えるべきです。医療・ケアの誘惑は、エンジニアリングの都合で順序づけ、目に見える価値を先送りすることです。誰かが何かを使えるようになる前に、すべてのトラストを接続する、というように。それは、すべてのリスクを、遅い単一の納品に載せ、取締役会に、会計年度と政治のサイクルを通じて継続的な投資を擁護するエビデンスを残しません。議論は、初期のトランシェが、より難しい後の仕事へのステークホルダーの信頼を築く、意図的なクイックウィンを狙っているか、そしてレビューの地点が本物の判断か、スケジュールのチェックポイントかを検討すべきです。最初に実証できる便益は何か、それがどれだけ早く着地するか、そして採用が遅れたり、ブループリントが誤りと判明したりしたとき、取締役会がトランシェのレビューで実際に何をするかを考えます。良い答えは、早期の測定可能な成果を伴う具体的なトランシェを説明し、各境界を、ブループリントが本当に修正に開かれた、本物の実施可否の判断として扱い、価値を終わりに先送りする圧力について誠実です。

4. 私たちには、目標運用モデルの、単一の維持されるブループリントがあるか。それとも、各プロジェクトが、静かに、それぞれ自分の未来の版に向けて最適化しているか。 ブループリント、つまりプロセス、組織、技術、情報の具体的なPOTI目標運用モデルは、断片が、局所的に賢明な判断の衝突ではなく、一貫した全体になるようにするものです。それがなければ、構成する各プロジェクトは、合理的に自分の範囲のために最適化します。あるトラストは、既存のEPRに合うデータ標準を選び、別のトラストは、自分の人員配置に合わせて臨床ワークフローを設計し、共有ケア記録は、技術的には接続するが、まとまりのない連携へと断片化します。緊張は、ブループリントの維持が、出荷の圧力の下にあるデリバリーチームには間接費のように感じられ、それが、一度書かれて棚上げされる文書ではなく、あらゆるトランシェで再検証される生きた参照でなければならないことです。議論は、ブループリントが使える形で実際に存在するか、誰がそれを所有するか、そして実際のプロジェクトの判断が、それによって導かれているのか、あとから単にそれに調整されているだけなのかを確立すべきです。あるプロジェクトの最近の設計上の選択を考え、ブループリントがそれを形づくったのか、静かに覆されたのかを問います。誠実な答えは、現在のブループリントを示し、その所有者を挙げ、局所最適がすでに目標状態を引き裂いているところについて率直です。

5. プログラムが終結したとき、何が残るか。そして、能力を運用し、便益を通常業務の中まで追跡し続ける、継続的なプロダクトチームを、名指ししているか。 プログラムは、定義上、一時的ですが、共有ケア記録、相互運用性のプラットフォーム、それらが生む便益はそうではないため、終結は、後付けではなく、最初から計画すべき設計上の問題です。スペクトルのそれぞれの端での、繰り返される失敗は本物です。一部のプログラムは決して終結せず、変化が定着したあとも長く、恒久的な官僚機構に固まり、他のプログラムは突然終結して、継続的な所有者のいない、稼働中の臨床サービスを取り残します。本トピックは、継続的なサービスが、継続的なプロダクトチーム（トピック5.0）に移されるべきこと、そして多くの便益が、プログラムの終了後にのみ生じ、BAUの中まで追跡されなければならないことを明確にしています。つまり、受け取るチームと継続的な便益の所有が、プログラムがまだそれらを確立する権限と資金を持つあいだに、特定されなければなりません。議論は、各継続的な能力を誰が運用するか、変革のお金が止まったあと、それにどう資金を出すか、そしてプログラムボードが解散したあと、誰が便益を測定し続けるかを表に出すべきです。良い答えは、具体的なプロダクトチームとBAUの所有者を挙げ、資金の移行を誠実に説明し、終結と便益の追跡を、期待に満ちた引き継ぎではなく、計画されたトランシェとして扱います。

6. 各納品の内部ではなく、プロジェクト間の継ぎ目、つまり共有の標準、情報ガバナンス、順序づけ、共有のインフラを、どう管理しているか。 プログラムが、独立したプロジェクトの集合に対して加える価値は、ほぼ完全に、それらのあいだの空間にあります。相互依存、共有のデータ標準、情報ガバナンスと同意の枠組み、単一のプロジェクトが所有しないが、すべてが依存する共通のインフラ。プログラムチームの誘惑は、快適で目に見える仕事である、各納品の内部のマイクロマネジメントへ流れ、本当に難しい横断的な継ぎ目が、稼働時の連携の失敗や情報ガバナンス上の障害として表面化するまで、管理されないままになることです。医療・ケアでは、これらの継ぎ目は、異例なほど荷重を支えています。データの流れと同意が、整合が自発的で、法的義務が共有されているが資源の裏づけが不均等な、主権を持つ組織的・規制的な境界をまたぐからです。議論は、相互依存と共有のリスクについて、プログラムレベルの視点があるか、共有の標準とインフラを誰が所有するか、そしてプログラムが、継ぎ目を調整しているのか、プロジェクトの細部に口を出しているのかを試すべきです。誠実な答えは、成果を最も脅かす具体的な継ぎ目を特定し、その所有者を挙げ、プログラムが、境界で価値を加えているのか、支えるべきプロジェクトの仕事を重複させているのかについて率直です。

実践例：医療・ケアの事例#

あるICSは、急性期、コミュニティ、精神保健、プライマリケア、社会的ケアにまたがる臨床家に、一人の人の統合されたビューを与える、共有ケア記録を届けようとしています。単一のプロジェクトでは、これを届けられません。それは、複数のトラスト、いくつかのソースシステム、情報ガバナンスの合意、臨床ワークフローの再設計、国民の関与にまたがります。これはMSPのプログラムとして調整されます。

SROは、真のシステム横断の権限を持つICSのエグゼクティブで、各パートナー組織の代表と、それぞれに名前のあるビジネスチェンジマネージャーを伴うプログラムボードの議長を務めます。プログラムは、ビジョン（「適切な人についての適切な情報が、ケアの現場で適切な臨床家に利用できること」）と、目標運用モデルを記述するブループリントを設定します。データ共有のアーキテクチャと標準（HL7 FHIRに基づく相互運用性）、情報ガバナンスの枠組み、同意のモデル、再設計された臨床ワークフロー。

仕事は、トランシェに整理されます。最初のトランシェは、意欲のある二つの急性期トラストを接続し、読み取り専用の記録を届けます。これはアプローチを証明し、取締役会が、信頼を築くために、早期の便益、つまり重複検査の測定可能な減少を示せる、意図的なクイックウィンです。最初のトランシェのレビューで、取締役会は、記録が余計なログインの陰に埋もれているところで臨床家の採用が遅れていることを知り、展開を広げる前に、シングルサインオンの統合を優先するよう、ブループリントを調整します。

プログラムの下で、様式は共存します。相互運用性のプラットフォームは、継続的なプロダクトチーム（トピック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のブループリントを定義し、維持する。
• トランシェではなくビッグバン。 すべてのリスクが、遅い一つの納品に先送りされる。対策：仕事をトランシェ化し、早期の便益を確保し、レビューの地点で再計画する。
• 決して終結しないプログラム。 変化が定着したあとも長く、恒久的な官僚機構になる。対策：意図して終結し、継続的なサービスをプロダクトチームに引き継ぎ、BAUの中で便益を追跡し続ける。

成熟度モデル#

チェックリスト#

• これは、一つの戦略的な成果に向けた、本当に複数プロジェクト・複数組織にわたる変革か。
• 明確なビジョンと、具体的なブループリント（目標運用モデル／POTI）があるか。
• アウトプットを、測定可能で、所有され、ベースライン化された便益に結びつける便益マップがあるか。
• 仕事が、本物の続行／調整／停止のレビュー地点を伴うトランシェに構造化されているか。
• 組織の境界をまたいで判断する権限を持つ、権限を与えられたSROがいるか。
• プログラムボードが、影響を受ける組織を本当に代表しているか。
• ビジネスチェンジマネージャーが、採用を所有するために運用の現場に組み込まれているか。
• 横断的な標準、相互依存、共有のリスクが、プログラムレベルで管理されているか。
• プロダクト主導、プロジェクト主導、プログラム主導の様式が、明確な役割で共存しているか（第5.0〜10トピック）。
• 継続的なサービスを継続的なプロダクトチームに引き継ぎ、便益をBAUの中まで追跡する、意図した終結があるか。

主要な情報源#

• 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/