トピック5.1 — プロジェクト主導の仕事

一文で言うと： プロジェクト主導の仕事は、仕事に定義された範囲、有限の寿命、明確な終了状態があるときに適した道具です。合意された時間、コスト、品質で届けられ、そして終結する、一時的で管理された取り組みです。

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

すべてが生きたサービスというわけではありません。医療・ケアの最も重要な仕事のいくつかは、本当に有限です。ある電子患者記録から別のものへの移行、病院の敷地全体へのWi-Fiの展開、寿命の尽きたサーバーの交換、サプライヤー契約が終わる前のレガシーシステムの廃止、新しい病院の建設のデジタル部分の納品。この仕事には、始まりと、途中と、明確な終わりがあります。それを終わりのないプロダクトとして管理することは、お金を浪費し、説明責任をぼやけさせます。プロジェクトの規律が必要です。

プロジェクトマネジメントが真価を発揮するのは、まさに賭け金が高く、制約が厳しいからです。データ移行の切り替えには、固定された稼働の週末があり、記録が失われたり破損したりした場合の患者安全のリスクがあり、古いシステムが停止した場合の契約上の崖があります。公金はビジネスケースに対して投じられ、議会、監査人、取締役会は、それが承認されたとおりに使われたかを問うでしょう。プロジェクト主導の仕事は、取締役会が自信を持って資本を投じ、正当化が失われたときには、きれいに作業を止められるようにするガバナンス、つまりビジネスケース、ステージゲート、管理された終結を提供します。

危険は、この道具を誤った仕事に使うことです。進化するデジタルサービスに適用されたプロジェクト主導のガバナンスは、トピック5.0 — プロダクト主導の仕事で述べた、「作って放置する」という病理を生みます。本トピックは、プロジェクト主導の仕事が適切な道具であるところと、その限界が始まるところを説明します。本トピックは、複数のプロジェクトを調整するトピック5.2 — プログラム主導の仕事と、これらの道具の間で選択するトピック5.3 — エンタープライズ・プロジェクト・ポートフォリオマネジメント（EPPM）と並びます。

中核概念#

プロジェクト。 時間、コスト、品質の制約の範囲内で、合意された仕様に沿って、一つ以上の定義されたアウトプットを届けるために作られる、一時的な組織です。決定的な特徴は、それが一時的であること、つまり、定義された終わりに到達し、その後解散するために存在することです。

鉄の三角形（範囲、時間、コスト）。 古典的な制約のモデルです。範囲、スケジュール、予算は相互依存しており、品質は、それらがどうバランスされるかに影響されます。一つを変えれば、他も変わります。プロジェクトの統制は、おおむね、このトレードオフを透明に管理する規律です。

PRINCE2（PRojects IN Controlled Environments）。 英国政府の構造化されたプロジェクト手法で、NHSと公共部門で広く使われています。原則（継続的な事業上の正当化、定義された役割、ステージによる管理、例外による管理、プロダクトへの焦点、経験からの学習、環境に合わせた調整）の上に築かれ、仕事を、プロジェクトボードが方向を示す、管理されたステージに整理します。

PMI / PMBOK。 Project Management Instituteの*Guide to the Project Management Body of Knowledge*は、規定のステージ化されたプロセスではなく、パフォーマンスの領域と原則を軸にプロジェクトの仕事を枠づける、支配的な国際的な対応物です。PRINCE2とPMBOKは、同じ規律についての、補完的なレンズです。

ビジネスケース。 プロジェクトを正当化する文書です。問題、評価された選択肢、期待される便益、コスト、リスク。PRINCE2では、ビジネスケースは生きたものであり、あらゆるステージの境界で確認され、継続的な正当化が消えたなら、正しい判断は、止めることです。英国の公的機関では、これは通常、HM TreasuryのFive Case Model（戦略、経済、商務、財務、マネジメント）として構造化されます。

ステージゲート。 PRINCE2のプロジェクトは、判断の関門で区切られたマネジメントステージに分けられます。各境界で、プロジェクトボードは、意図的な、停止か続行かの判断を下します。進捗とビジネスケースをレビューし、次のステージ計画を承認し、そのステージのためだけに資源を投じます。これが、取締役会が統制を保ち、良いお金を悪いお金の後に投じることを避ける方法です。

RAIDログ。 リスク（Risks）、前提（Assumptions）、課題（Issues）、依存関係（Dependencies）の単一の台帳で、プロジェクトマネージャーの中核の統制の成果物です。RAIDは、不確実性を目に見え、管理可能にします。リスクは起きるかもしれないこと、課題はすでに起きたこと、前提は計画が頼っているもの、依存関係は計画が他から必要とするものです。

ベストプラクティス#

1. 誠実なビジネスケースから始め、それを生かし続ける。 認められた構造（英国の公的機関ではFive Case Model）を使って、あらかじめ決められた単一の答えではなく、本物の選択肢を評価します。そのうえで、ビジネスケースを、あらゆるステージゲートでレビューされる、生きた文書として扱います。継続的な事業上の正当化は、PRINCE2の第一の原則であり、それを失うことは、止める正当な理由です。

2. 範囲を正確に定義し、その変更を管理する。 プロジェクトの価値は、「完了」の明確で境界のある定義です。範囲を合意し、ベースライン化し、提案されるあらゆる変更を変更管理のプロセスに通して、スコープクリープが、予算とスケジュールを静かに食い尽くさないようにします。

3. 本物の判断の関門を伴うステージで管理する。 仕事をマネジメントステージに分け、各境界で、本物の停止か続行かのレビューを行います。常に「続行」と言う関門は芝居です。停止や再計画が、取締役会が実際に行使する本物の選択肢であって初めて、規律は機能します。

4. 生きたRAIDログを運用し、例外によってエスカレーションする。 リスク、前提、課題、依存関係を一か所で管理し、定期的にレビューし、PRINCE2の「例外による管理」を使います。プロジェクトマネージャーは、合意された許容範囲の中で運営し、許容範囲が脅かされたときにのみ取締役会にエスカレーションします。これにより、上級職の時間が、本物の判断に集中し続けます。

5. 明確な、単一の責任点を割り当てる。 PRINCE2は、定義された役割を主張します。ビジネスケースを所有する、上級責任者／エグゼクティブを含むプロジェクトボード、アウトプットを使う人々を代表する上級ユーザー、そして上級サプライヤー。不明確な説明責任は、漂流の最も一般的な原因です。

6. 始める前に、稼働するサービスへの移行を計画する。 プロジェクトはアウトプットを届けますが、その後、誰かがそれを運用しなければなりません。受け取るチーム、サポートモデル、臨床安全の引き継ぎ（導入にはDCB0160）を、プロジェクトの一部として合意し、稼働開始が、所有者の不在という真空への崖にならないようにします。

7. 臨床安全、情報ガバナンス、テストを組み込む。 患者データに触れるあらゆるシステムについて、臨床安全ケース、DPIA、切り替えとロールバックのテストは、任意のおまけではなく、関門となる成果物です。テストされたロールバックの計画のない移行は、稼働する準備ができていません。

8. 意図してプロジェクトを終結し、教訓を捉える。 定義された終わりは、定義された終結を意味します。アウトプットが受け入れられたことを確認し、運用に引き継ぎ、チームを解放し、教訓を記録します（PRINCE2の教訓ログ）。終結されないプロジェクトは、資源と説明責任を、際限なく漏らします。

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

1. 目の前の仕事は、本当に、定義された終了状態を持つ有限のものか。それとも、私たちが知っている資金の経路だからという理由で、プロジェクトのガバナンスに手を伸ばしているのか。 これは、本トピックが拠って立つ決定的な問いです。プロジェクト主導の規律が適切な道具であるのは、仕事が本当に、始まりと、途中と、明確な終わりを持つときだけだからです。医療・ケアの組織では、プロジェクトの形への引力は強く、資本予算、ビジネスケースの機構、取締役会への報告は、すべてそのために作られています。そのため、進化するデジタルサービスが、単にお金がそうやって解放されるからという理由で、プロジェクトの装いをまとい、それが、作って放置するという病理を生みえます。議論では、各候補を誠実に検討すべきです。サプライヤーがサポートを打ち切る前の病理システムの置き換えは、厳しい契約上の崖があり、疑いなく有限ですが、「患者向けアプリを改善する」には終了状態がなく、トピック5.0に属します。稼働のあとにチームが解散すべき本物の稼働開始があるのか、それとも誰かが、それを際限なく改善し続ける必要があるのかを考えます。良い答えは、プロジェクトのガバナンスを習慣として使うことに抵抗し、具体的な終了状態と「完了」を定義する出来事を挙げ、現在プロジェクトとして運用しているものの一部は、そもそもプロジェクトであるべきではなかったと、進んで述べます。

2. ステージゲートで、この取締役会は、正当化を失ったプロジェクトを、実際に止めるか再計画するか。そして、そうした時を指し示せるか。 ステージゲートは、停止が、取締役会が実際に行使する本物の選択肢であるときにのみ統制です。常に「続行」と言う関門は芝居であり、継続的な事業上の正当化が、PRINCE2の第一の原則であるのは、まさにそれを失うことが、仕事を終わらせるべきだからです。医療・ケアでの緊張は鋭いものです。途中まで構築されたEPRの移行や検査室システムの切り替えを止めることは、失敗を認め、サンクコストを無駄にし、すでに計画を変えた臨床家を混乱させるように感じられるため、取締役会は、ビジネスケースが静かに蒸発していくときでも、押し進めることを合理化します。本物の例を議論に持ち込んでください。テストによって、データ対応づけのリスクが想定より悪いと判明した、あるいは便益が遅れたプロジェクト。そして、関門が設計どおりに使われたのか、形式的に承認されたのかを問います。どの許容範囲がエスカレーションを引き起こすか、取締役会の誰に停止を宣言する立場があるか、サンクコストの論理が、その場で名指しされ、異議を唱えられているかを考えます。誠実な答えは、関門が形式にすぎなかったところを認め、取締役会が本当に中断または範囲の再設定を行う条件を説明し、公的な損失処理の前に止める権限を、脅威ではなく、規律の本当の価値として扱います。

3. 各プロジェクトのアウトプットを、稼働するサービスとして誰が受け取るか。そして、臨床安全の引き継ぎと継続的な所有を、崖ではなく、関門となる成果物にするには、どうするか。 プロジェクトはアウトプットを届けます。有限の何かが終わりますが、それが生み出したものは、チームが解散したあとも長く、運用され、改善され、安全に保たれなければならず、最も一般的な静かな失敗は、その反対側で誰もそれを所有しないことです。患者データに触れるシステムでは、これは事務的な整頓ではありません。DCB0160の導入の安全ケース、DPIA、テストされたロールバック、名前のある受け取りチームが、管理された稼働開始と、安全のリスクが管理されずに蓄積する所有者の不在の真空との間に立つものです。議論は、稼働の週末ではなく、プロジェクトが始まる前に、移行について明確にするよう迫るべきです。どの運用チームが引き受けるのか、サポートモデルは何か、そしてそのチームが、それを改善し続ける余力と働き方（トピック5.0のプロダクト主導）を持っているか。最近の具体的な稼働を考え、引き継ぎが計画されたものか、即興だったか、そして「プロジェクトは完了した」が、「そして今や誰の仕事でもない」を意味することを許したかを問います。良い答えは、受け取るチームとサポートモデルを最初から挙げ、安全の引き継ぎを、プロジェクトがそれなしには通過できない関門として扱い、稼働するサービスの継続的な改善を、漂流するに任せるのではなく、適切な働き方へ明示的に割り当てます。

4. 鉄の三角形が牙をむき、範囲、時間、コストが衝突するとき、どの制約を柔軟にするか。そして、患者安全が譲る変数になることは、許されるか。 あらゆる本物のプロジェクトは、いつかスケジュール、予算、約束された範囲が、すべては維持できない瞬間に突き当たり、チームがその締めつけをどう解決するかは、それが実際に何を重んじているかを明らかにします。医療・ケアでの罠は特徴的です。終了日が、しばしば、サプライヤーがサポートを打ち切る、リースが切れる、データセンターが閉鎖されるといった、厳しい契約上の崖であるため、時間はしばしば動かせず、圧力は、静かに品質へ落ちます。臨床システムでは、それは、テストの削減、検証の圧縮、既知のデータ対応づけの欠陥を抱えたままの出荷を意味します。議論は、組織が三角形のどの角を守り、どれを犠牲にするかを、あらかじめ名指しし、他のすべてが固定されていても、臨床安全と情報ガバナンスは、逃がし弁ではないことを明示すべきです。最近の切り替えを見て、日付が守られたときに、何が静かに譲られたかを問います。ロールバックの予行か、臨床的な検証の期間か、研修か。安全の余裕を削るのではなく、稼働日を動かす権限を誰が持つか、その会話が取締役会で公然と行われるか、現場で既定として行われるかを考えます。誠実な答えは、厳しい局面の前に優先順位を述べ、遅れた日付や再計画されたステージを正当な結果として扱い、語られないスケジュールの圧力が、記録されない臨床リスクに変わるのを許しません。

5. 私たちのRAIDログは、私たちの行動を変える生きた道具か。それとも、統治されているように見せるために維持する文書か。そして、プロジェクトを実際に沈めるリスクを表面化させるか。 RAIDログがその場所に値するのは、それをレビューすることが判断を変える場合だけです。よくある病理は、キックオフで書かれ、取締役会で提示され、重要なリスクが見られないまま成熟するあいだ、本当に行動に移されない台帳です。移行や切り替えでは、決定的なリスクは、しばしば具体的で知りうるものです。新しい基準範囲にきれいに対応づけられない過去の結果、別のチームのファイアウォールの変更への依存、臨床的な検証の資源が必要なときに空いているという前提。そして問いは、ログがそれらを具体的に名指ししているのか、「リソースの制約」のような一般的な項目の陰に隠れているのかです。議論は、例外によるエスカレーションが本物かを試すべきです。プロジェクトマネージャーは、合意された許容範囲の中で運営し、それが脅かされたときにのみ取締役会の注意を求めるのか、それとも、すべてが沈黙を保つか、危機になるか、どちらかなのか。ヒヤリハットと顕在化した課題が、次のステージの計画の仕方にフィードバックされるのか、単に記録されて忘れられるのかを考えます。良い答えは、RAIDログが実際に変えた判断を示し、プロジェクトを本当に止めうる二つか三つのリスクを、軽微なものの長い裾野から区別し、ログを、保証のために作られる成果物ではなく、働く統制として扱います。

6. 終結して解散したあと、ビジネスケースの便益が実際に実現したかを確認する人はいるか。そして、実現しなかったとして、私たちはそれを知るか。 ビジネスケースは、支出を正当化するために便益を約束しますが、プロジェクト主導の仕事は、当然、稼働とチームの解放で終わるため、決定的な瞬間、つまり移行が本当にリスクを減らし、コストを削減し、ケアを改善したかは、通常、全員が次へ移ったあとに訪れ、それを確認する責任を負う人は誰もいません。これは、公的な医療・ケアで特に重大です。議会、監査人、取締役会が、特定の成果を届けると伝えられたFive Caseのビジネスケースに対して、お金が投じられているにもかかわらず、便益の実現は、それを所有するはずだったプロジェクトがもう存在しないため、最も頻繁に飛ばされるステップだからです。議論は、プロジェクトが終結するとき、誰が便益の追跡を引き継ぐか、どの期間にわたって、そしてどのベースラインの測定に対してかを決めるべきで、それらは、稼働の前に取得されなければ、失われます。最近完了したプロジェクトを考え、誰かがその後、約束された便益を確認したか、不足が、それを承認した取締役会に届くことがあるかを率直に問います。誠実な答えは、終結後の便益の所有を、解散したチームではなく常設の機能に割り当て、プロジェクトがまだ生きているあいだにベースラインを取得し、プロジェクトが期限と予算どおりにアウトプットを届けながら、それを正当化した価値を届けなかったと、進んで記録します。

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

ある急性期トラストは、既存のサプライヤーが14か月後にサポートを打ち切る前に、老朽化した病理検査室情報管理システムを置き換えなければなりません。これは、教科書どおりのプロジェクト主導の仕事です。固定された終了日、定義された範囲、厳しい契約上の崖、そして移行中に結果が失われた場合の深刻な患者安全のリスク。

トラストは、三つの選択肢（その場でのアップグレード、新システムの調達、地域のインスタンスの共有）を評価するFive Caseのビジネスケースを書き、調達を選び、ビジネスケースを所有するエグゼクティブ、上級ユーザー（主任臨床検査技師）、上級サプライヤーという、明確なボードを伴うPRINCE2のプロジェクトを立ち上げます。仕事は、調達、構築と設定、データ移行、テスト、稼働開始というマネジメントステージに分けられ、それぞれが判断の関門で終わります。

プロジェクトマネージャーは、RAIDログを運用します。主要なリスクは、過去の結果が、新しいシステムの基準範囲にきれいに対応づけられないかもしれないこと、依存関係は、ネットワークチームのファイアウォールの変更、前提は、テストのために臨床的な検証の資源が利用できることです。移行のステージゲートで、テストは、データ対応づけのリスクが想定より悪いことを明らかにし、取締役会は、関門を設計どおりに使います。盲目的に続行するのではなく、検証の期間を延ばし、テストされたロールバックの計画を伴う、再計画されたステージを承認し、元のスケジュールよりも患者安全を守ります。

稼働は、ロールバックの計画を待機させ、DCB0160の臨床安全の承認を得た、管理された週末に行われます。システムは受け入れられ、それを運用する運用チームに引き継がれ、教訓が記録され、プロジェクトは正式に終結されます。チームは解散します。仕事が本当に完了したので、それは正しいことです。次に来るもの、つまり稼働するサービスの継続的な改善は、別の働き方であり、トラストは、そのために、完全なプロジェクトチームを永続的に動かし続けないよう、注意を払います。

セクター別の視点#

スタートアップ#

小さなデジタルヘルス企業が、正式なPRINCE2のプロジェクトを運営することはまれですが、本当に有限の仕事は依然として現れます。新しいクラウドプラットフォームへの一回限りのデータ移行、Cyber EssentialsやDTACの認証取得の推進、大きなNHSの契約の前のペネトレーションテストの是正。スタートアップは、これらを、名前のある所有者と明確な完了の定義を伴う、軽量で期限付きの取り組みとして扱い、儀式なしに（正式なプロジェクトボードも、5段階の関門もなし）、規律（固定された範囲、終了日、実施可否の判断）を借ります。資金は、実際には創業者の注意と滑走路であるため、リスクは、有限の仕事がプロダクトのスプリントの間に押しつぶされ、実際には決して終結されないことです。是正策は、単一の所有者と厳しい期限を名指しし、認証や移行を、永遠に「進行中」ではなく、完了し片づいたものとして扱うことです。

小規模事業者#

確立した小規模の提供者、つまり一般診療所、地域薬局、介護施設、単独拠点のクリニックは、プロジェクト主導の仕事に、まれだが避けられない出来事として出会います。臨床システムのサプライヤーの切り替え、新しい診療所管理プラットフォームへの移行、サポートが切れる前の寿命の尽きた機器の交換。組織には実際の患者と継続的な運用がありますが、専任のプロジェクトやITの機能はないため、「プロジェクトチーム」は、通常、日常業務と並行してこれを行う診療所のマネージャーや登録管理者であり、しばしば、移行を運営するために、新たなサプライヤーに頼ります。この現実との接触に耐える規律は、軽量な中核です。明確な終了状態、サプライヤーが静かに拡大しないようベースライン化された範囲、名前のある説明責任者、そして患者記録に触れるあらゆる切り替えの前の、テストされたロールバック。罠は、仕事だけでなく判断まで外注することです。サプライヤーの稼働日とデータ対応づけの保証を、独立した確認なしに受け入れるのです。組織がどれだけ小さくても、同じ臨床安全と情報ガバナンスの義務（DCB0160、DPIA）が適用されるからです。是正策は、他のすべての手がベンダーのものであっても、実施可否の判断と受け入れ基準の所有を、社内に保つことです。

大企業#

大規模なNHSトラストや統合ケアシステム（ICS）は、プロジェクト主導の仕事が最もなじむ場所です。EPRの置き換え、敷地全体のWi-Fi、データセンターからの撤退、切り替えは、いずれも、厳しい契約上・患者安全上の崖を伴います。ここでは、全面的な仕組みが正当化されます。Five Caseのビジネスケース、名前のあるエグゼクティブ／SRO、上級ユーザー、上級サプライヤーを伴うPRINCE2のボード、本物の関門を伴うマネジメントステージ、生きたRAIDログです。金額が大きく、安全への露出が深刻で、内部監査と取締役会が支出を精査するからです。この規模での典型的な失敗は、同じガバナンスを、生きたサービス（トピック5.0 — プロダクト主導の仕事）と有限の仕事に、無差別に適用することであり、そのため、各仕事を適切な様式へ振り分ける、ポートフォリオの視点（トピック5.3 — エンタープライズ・プロジェクト・ポートフォリオマネジメント）が重要です。臨床安全（DCB0160）とテストされたロールバックは、任意のおまけではなく、関門となる成果物です。

政府#

国や大規模プロジェクトの規模では、プロジェクト主導の仕事は、政府の保証の体制の内側にあります。Infrastructure and Projects Authorityがゲートウェイレビューを運営し、HM TreasuryのGreen BookとFive Case Modelがビジネスケースを統べ、最大のプロジェクトは、議会とNational Audit Officeに対する公表された説明責任を伴う、Government Major Projects Portfolioに入ります。説明責任は強烈に公的です。上級責任者は個人的に説明責任を負い、特別委員会に呼ばれることもあるため、ステージゲートと選択肢の評価は、芝居ではなく、法定グレードの統制です。資金は、承認されたビジネスケースに対して、トランシェごとに解放され、失敗が一面記事になるため、リスク選好は低くなります。この規律の本当の価値は、失敗しているプロジェクトが公的な損失処理になる前に、止めるか範囲を再設定する権限です。

よくある失敗パターン#

• 進化するサービスをプロジェクト管理する。 範囲が固定され、最後に解散するガバナンスを、生きたデジタルプロダクトに適用すると、放置という病理を生む。対策：サービスが継続的なところでは、プロダクト主導の仕事（トピック5.0）を使う。
• 資金への一度限りの切符としてのビジネスケース。 お金を解放するために一度書かれ、二度と見直されない。対策：あらゆるステージゲートでレビューし、進んで止める。
• 形式的に承認されるステージゲート。 決して「停止」と言わない関門は、統制にならない。対策：停止や再計画を、取締役会の本物の選択肢にして、実際に使う。
• 変更管理のないスコープクリープ。 統制されない追加が、時間とコストを吹き飛ばす。対策：範囲をベースライン化し、あらゆる変更を変更管理に通す。
• サービスへの移行計画がない。 プロジェクトが終わり、誰もアウトプットを所有しない。対策：稼働前に、受け取るチームとサポートモデルを合意する。
• 資料棚としてのRAID。 書かれても決して行動に移されないログ。対策：RAIDを定期的にレビューし、例外によってエスカレーションする。
• 実際には決して終結しない。 終わりなく資源を消費する、ゾンビのプロジェクト。対策：受け入れ、引き継ぎ、教訓の記録を伴う、意図した終結。

成熟度モデル#

チェックリスト#

• 仕事は、本当に有限で、定義された範囲と終了状態を持つか（継続的なサービスではなく）。
• 各ステージゲートでレビューされる、生きたビジネスケース（Five Case Model）があるか。
• 範囲がベースライン化され、機能する変更管理のプロセスがあるか。
• 仕事のステージが定義され、それぞれが本物の停止／続行の判断の関門で終わるか。
• プロジェクトボードの役割、つまりエグゼクティブ／SRO、上級ユーザー、上級サプライヤーが明確か。
• 生きたRAIDログが維持され、例外によるエスカレーションがあるか。
• 臨床安全（DCB0160）、DPIA、切り替えとロールバックのテストが、関門となる成果物か。
• 稼働前に、受け取る運用チームとサポートモデルが合意されているか。
• 受け入れ、引き継ぎ、チームの解放、教訓の記録を伴う、意図した終結があるか。
• 稼働するサービスの継続的な改善が、適切な働き方に割り当てられているか。

主要な情報源#

• AXELOS / PeopleCert — 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（Five Case Model / Green Book）。
• Infrastructure and Projects Authority (IPA)、内閣府 — 大規模プロジェクトの保証とゲートウェイレビューのガイダンス。
• NHS Digitalの臨床安全標準DCB0160（医療ITシステムの導入）。
• NHS England — NHS Service ManualとDigital Service Standard（サービスへの移行とユーザーニーズの文脈のため）。

参考文献#

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