プロジェクトマネジメント - ビジネス・ケース

• 大事をなさんと欲せば、小なる事を怠（おこた）らず勤（いそ）しむべし、小積（こづも）りて大となればなり
  

# プロジェクト成功のためのマネジメント手法ービジネスケース

# 目的

• ビジネスケースを通じて、プロジェクト成功の背景や前提条件を理解する。
• プロジェクトにおける意思決定プロセスをビジネスケースから学ぶ。
• 成功・失敗のビジネスケースを分析し、重要な要因を整理する。
• ビジネスケースに含まれる課題、リスク、制約条件の捉え方を習得する。
• 今後のプロジェクト計画やマネジメント検討に活用できる知見を習得する。

# 目次

• はじめに
  • プロジェクト
  • マネジメント
  • パフォーマンス
  • 原則
• ビジネス・ケース
• QA

# はじめに

# プロジェクト

合意されたビジネス・ケースに基づき、一定期間内に 1 つまたは複数のビジネス成果物を提供するために実施される業務である。

# 特徴

• 変更：プロジェクトは変更をもたらすための手段である。
• 一時的：プロジェクトは本質的に一時的なものである。
• 機能横断的：プロジェクトでは、さまざまなスキルを持つ人々がチームとして一時的に連携していく必要があり、組織内の通常の機能別部門の垣根 (かきね) を越えた作業が多く、時には外部の組織にまで広がることもある。プロジェクトに関与する関係者は、それぞれが異なる観点や動機を持っている。
• 独自性：どのプロジェクトも同じではない。(同じもの一つもない)
• 不確実性：プロジェクトでは、一般的に、通常業務を行う場合よりも脅威にさらされ、機会が生まれることが多くなる。

# プロジェクト・マネジメント

プロジェクトが目標を達成できるように、手法、ツール、技法、コンピテンシーを適用することである。

# 課題

• プロジェクトのどの側面に誰が実行責任を負うかが曖昧であり、混乱と説明責任の欠如 (けつじょ) が発生する。
• プロジェクトの提供物、コスト、時期に対して非現実的な期待を抱く。
• プロジェクト作業の労力、期間、コストの見積もりが困難である。
• コントロールされない変更（スコープ・クリープとも呼ばれる)。
• プロジェクト・ライフサイクルにおいて、プロジェクト・マネジメント・チームと利害関係者への通知、エンゲージメント、モチベーションの維持が困難になる。

プロジェクト・マネジメントの目的は、曖昧さを減らしたり管理したりすることより、これらの課題に対処することである。これは、関係者を結束させ、達成目標と作業プラクティスを明確にすることによって達成される。狙い (ねらい) はプロジェクトに必要な成果物を作成するために必要とされる専門的な作業をコントロールすることである。
プロジェクト・マネジメントには、プロジェクトのあらゆる側面を計画立案、委任、モニタリング、コントロールすることと、関係者への動機付けが含まれる。それにより期待されるパフォーマンス最終目標内でプロジェクト目標が達成される。

# パフォーマンス最終目標

期待される成功レベルが設定され、それに対してプロジェクトのマネジメントが判断される。

• ベネフィット：プロジェクトに関与する人々は、「なぜプロジェクトを実行するのか、誰のためにプロジェクトを実行するか」という質問に答えられる必要がある。プロジェクト・マネジメント・チームは、プロジェクトの目的と達成すべきことを明確に理解し、その投資を正当化する必要がある。
• コスト：プロジェクト開発が進行するにつれて、利用可能なコスト予算に影響を与える可能性のある要因や、コス卜予算に対する（潜在的な）支出不足または支出超過につながる可能性のある多くの要因が発生する。
• 時間：プロジェクトはいつ開始され、主な成果物はいつ提供され、プロジェクトはいつ終了する。
• 品質：プロジェクトが期限どおり、かつ予算内で終了したとしても、その結果が仕様どおりでなく満足できるものでなければ意味がない。プロジェクトで提供するものは、目的に適合している必要がある。
• スコープ：プロジェクトは何を提供するか？プロジェクトのスコープについての合意がなければ、何が含まれ、何が除外されるかについて、さまざまな関係者が異なる前提条件を持つ可能性がある。プロジェクト・マネジメント・チームはスコープ外の成果物を提供しないようにする。それは、遅延や過剰なコストの発生、コントロールされない変更（スコープ・クリープとも呼ばれる）の原因になることがよくあるためである。
• 持続可能性：すベてのプロジェクトは環境にインパクトを与えるため、プロジェクト・マネジメン・チームは、プロジェクト作業とプロジェクトに必要な成果物の持続可能性パフォーマンス最終目標を把握する必要がある。
• リスク：すべてのプロジェクトにはリスクが伴う (ともなう)。しかし、具体的にビジネスはどの程度のリスクを覚悟しているでしょうか？ビジネスのリスク選好度についての共通の理解がなければ、プロジェクト・マネジメント・チームはリスク回避的すぎたり、ビジネスが受け入れる準備ができている以上のリスクを負ったりする可能性がある。

プロジェクトのパフォーマンス最終目標に合意することによって、優先度付けを確立できる。
パフォーマンス最終目標には、許容度が狭いものもあれば、許容度が広いものもある。パフォーマンス最終目標とその許容度の合意は、オプションを検討し、プロジェクト・アプローチを決定するための前提条件である。

# プロジェクト環境

プロジェクトは、価値の実現にさまざまな影響を与える内外の環境の中に存在し運営される。内外の環境は、計画とその他のプロジェクト活動に影響を与える。これらの影響は、プロジェクトの特性、ステークホルダー、またはプロジェクト・チームに、好ましい影響、好ましくない影響、または中立的な影響を与える。

# 内部環境

組織内部の要因は、組織自体、ポートフォリオ、プログラム、別のプロジェクト、またはこれらの組み合わせに由来する。これには、作成物、実務慣行、または内部の知識が含まれる。知識には、以前のプロジェクトからの教訓に加え、完成した作成物が含まれる。知識の例には以下のものが含まれるが、これらに限定されるものではない。

• プロセス資産：プロセス資産には、ツール、方法論、アプローチ、テンプレート、フレームワーク、パターン、または PMO の資源が含まれることがある。
• ガバナンス文書：方針とプロセスが含まれる。
• データ資産：データ資産には、データベース、文書ライブラリー、メトリックス、データ、および以前のプロジェクトの作成物が含まれることがある。
• 知識資産：知識資産には、プロジェクト・チーム・メンバー、当該分野専門家、およびその他の従業員が共有する暗黙知が含まれる。
• セキュリティと安全：セキュリティと安全対策には、施設へのアクセス、データ保護、機密性のレベル、独占している秘密事項に関する手続きと実務慣行が含まれる。
• 組織の文化、構造、ガバナンス：組織のこれらの側面には、ビジョン、ミッション、価値、信条、文化的規範、リーダーシップ・スタイル、階層と権限の関係、組織のスタイル、倫理、および行動規範が含まれる。
• 施設や資源の地理的分布：これらの資源には、職場、バーチャル・プロジェクト・チーム、共有システムが含まれる。
• インフラストラクチャー：インフラストラクチャーには、既存の施設、機器、組織チャネルと通信チャネル、情報技術ハードウェア、可用性、およびキャパシティが含まれる。
• 情報技術ソフトウェア：たとえば、スケジューリング・ソフトウェア、コンフィギュレーション・マネジメント・システム、オンライン自動化システムへのウェブ・インターフェイス、コラボレーション・ツール、および作業認可システムが含まれる。
• 資源の可用性：たとえば、契約および購買の制約条件、承認されたプロバイダーおよびサブコントラクター、提携合意が含まれる。人員と資源の両方に関する可用性には、契約および購買の制約条件、承認されたプロバイダーおよびサブコントラクター、スケジュールが含まれる。
• 従業員の能力：たとえば、一般的な知識や専門知識、スキル、コンピテンシー、技法、知識が含まれる。

# 外部環境

組織の外部要因は、プロジェクトの成果を強化したり、抑制したり、中立的な影響を与えたりしうる。例には以下のものが含まれるが、これらに限定されるものではない。

• 市場 (しじょう) の状況：市場の状況には、競合他社、市場シェア、ブランド認知、技術動向、商標が含まれる。
• 社会的、文化的な影響と事柄：これらの要素には、政治情勢、地域の習慣と伝統、祝日やイベント、行動規範、倫理、および認知が含まれる。
• 規制環境：規制環境には、セキュリティ、データ保護、業務遂行、雇用、ライセンス付与 (ふよ)、および調達に関する国・地域の法律と規制が含まれる。
• 商用データベース：このデータベースには、標準化されたコスト見積りデータと業界のリスク調査情報が含まれる。
• 学術調査：この調査には、業界調査、出版物、およびベンチマーキングの結果が含まれる。
• 業界標準：この標準は、プロダクト、製造、環境、品質、技能に関係する。
• 財務上の考慮事項：この考慮事項には、外国為替 (かわせ) レート、金利、インフレ、税金、関税が含まれる。
• 物理的環境：物理的環境は、作業条件と気候に関係する。

# 原則

過去の成功・失敗したプロジェクトから得られた教訓を基に、プロジェクト関係者が意思決定および問題解決を行う際の体系的な指針を提供する。

# ビジネス正当性の継続の確保

プロジェクトを継続するためには、開始から完了まで一貫したビジネス正当性が不可欠である。(ビジネス正当性がなければプロジェクトを中止するべきである。)

• プロジェクトを開始するためには、明確かつ正当な理由が必要である。また、そのビジネス正当性は、プロジェクト開始時点だけでなく、プロジェクトのライフサイクル全体を通じて有効であり続ける必要があり、継続的に再検証されなければならない。(ビジネス正当性は意思決定の基盤となり、プロジェクトが想定されるベネフィットと整合し、組織のビジネス目標に貢献していることを確保する役割を果たす。)
• 法律や規制によって推進されるような義務的なプロジェクトにも、コストに見合う最大の価値を確保するため、選択したアプローチに正当性が求められる。プロジェクトに関与するすベての関係者は、関与するにあたりビジネス正当性を得るために、予想ベネフィット、コスト、リスクのバランスを取る必要がある。
• プロジェクト完了後には、プロジェクトレビューを実施し、最終的な投資を保証するのに十分なベネフィットが実現したかどうか、プロジエクトからどのような教訓を学ぶことができるかを評価する。
• プロジェクト全体を通して、各投資関係者は自身のビジネス正当性を継続的にモニタリングし、当該プロジェクトが引き続き価値を提供しているかを確認することが求められる。

# 経験からの学習

過去のプロジェクトおよびプロジェクト遂行中に得られた関連する教訓を、改善の機会として積極的に整理して、将来のプロジェクトに適用・共有する。

• 独自性 (プロジェクトの特徴)
• 教訓はプロジェクトのライフサイクルを通して得られる。
  • 始動時：過去のプロジェクトや類似するプロジェクトをレビューし、適用可能な教訓がないかを確認する。（教訓の特定にあたっては、社内プロジェクトに限らず、社外の人や組織が実施したプロジェクトから得られる知見を含める場合もある。）
  • 進行中：教訓は各ステージの終わりに、関連する報告書やレビューに反映します。プロジェクト期間中に改善を実施できる機会を継続的に探ることである。
  • クローズ時：プロジェクト期間中に得られた情報を整理し、将来のプロジェクトで活用できるよう共有する。
• 学習のニーズや好みは人によって異なるため、プロジェクトに関与するすべての人に対して教訓を効果的に共有できる方法を検討することが重要である。
• 継続的な改善および革新を実現するためには、失敗と成功の双方から学ぶ姿勢が不可欠である。プロジェクトに関与するすべての関係者は、他者から教えられるのを待つのではなく、自ら教訓を見出す意識を持つことが求められる。

# 役割、責任、関係の定義

役割と責任を明確にし、利害関係者間で共通認識を持つことで、プロジェクトの目標達成を支える一貫した構造を確立する。

• プロジェクト期間を通じて個人に割り当てられる役割および責任は、曖昧さのない形で明確に定義され、関係者に受け入れられている必要がある。
• プロジェクトを成功させるためには、明確なプロジェクト・マネジメント・チームの組織体制を構築し、その中で関係者それぞれの役割と責任について合意を形成することが重要である。
• 関係者間の関係性を理解した上で、効果的なコミュニケーションの仕組みを整えることが求められる。

# ステージによるマネジメント

プロジェクトを複数のステージに分割し、各ステージ終了時に承認と意思決定を行いながら進めることで、リスクを管理し、プロジェクトの実行可能性を継続的に確保する。

# 適切なステージを選択する要因

• プロジェクト・ライフサイクル全体を通じて、リスクの影響度を最小化できる
• プロジェクトの規模および複雑性（ステージが短いほどコントロールの機会は増え、ステージが長いほどシニア・マネジメントの負担は軽減される）
• プロジェクト・ライフサイクル全体で必要となる重要な決定ポイントおよびコントロール・ポイント（多くの場合、主要な投資判断、ビジネス上または技術的な意思決定と関連する）
• セクター別または組織の方針・標準

# 利点

• プロジェクトまたはビジネス環境の変化に柔軟に対応できる
• 明確なレビューおよび意思決定ポイントを提供する
• 主要な意思決定を先に行い、その後に必要な詳細作業へ移行することを可能にする
• 組織の予算策定プロセスや法令の最終決定など、外部環境による影響を明確にできる
• ステージごとにプロジェクト・マネージャーへ権限を委任することで、「例外によるマネジメント」の原則を促進する

プロジェクト委員会は、1 回の承認につきプロジェクトの 1 ステージのみを認可し、ステージ内の日常的なコントロール権限を、合意された許容度の範囲でプロジェクト・マネージャーに委任する。
ステージが許容度内に収まると予測される場合に限り、プロジェクト・マネージャーは自身の裁量で必要な調整を行うことができる。
プロジェクト委員会は、十分なビジネス正当性および資金が継続的に確保されている場合にのみ、次のステージを認可する。
有効なビジネス・ケースが失われた場合、プロジェクト委員会はプロジェクトを回復させるか、その方法を検討するか、または途中で終了するかを判断する。

# 例外によるマネジメント

計画に対する許容度をあらかじめ定義し、その範囲内では権限を委任して管理を行い、許容度を超える偏差が予測された場合にのみ、上位のマネジメント・レベルへエスカレーションして意思決定を行う

• プロジェクトを指揮、マネジメント、提供するための明確な役割と責任を定義し、各レベルの説明責任を明確にすることで、適切なガバナンスを実現する。説明責任は、以下の方法によって確立される。
  • 各マネジメント・レベル（プロジェクト、ステージ、チーム）において、パフォーマンスの 7 つの側面（ベネフィット、コスト、時間、品質、スコープ、持続可能性、リスク）に対する許容度を設定し、下位のマネジメント・レベルへ権限を委任する
  • 許容度を超過することが予測される場合には、それを「例外」として明確にし、直ちに 1 つ上位のマネジメント・レベルへエスカレーションして、今後の進め方に関する意思決定を求めるためのコントロールを確立する
  • 各マネジメント・レベルが効果的なコントロールを行えるよう、適切な保証が提供される仕組みを整える
• 計画において許容度を定義するパフォーマンスの 7 つの側面は、以下のとおりである。
  • ベネフィット：計画されたベネフィットに対して、過小または過大に提供することが許容される度合い
  • コスト：合意された予算に対して、支出の超過または不足が許容される度合い
  • 時間：プロジェクト計画書、ステージ計画書、ワーク・パッケージ記述書と比較して、合意されたターゲット完了日より遅延または前倒しとなることが許容される度合い
  • 品質：合意された受け入れ基準と比較して許容される差異の度合い
  • スコープ：計画された成果物に対して許容されるバリエーション
  • 持続可能性：プロジェクト成果物またはプロジェクト活動が、持続可能性目標と比較してどの程度異なることが許容されるかの度合い
  • リスク：計画において集約されたリスクの許容範囲

• 「例外によるマネジメント」を実施することで、コントロールの機会を損なうことなく、シニア・マネジメントの時間的負担を軽減できる。その結果、シニア・マネジメントは戦略的な意思決定に集中でき、組織内の適切なレベルで効率的な意思決定が行われるようになる。(意思決定者は、発生または予測される偏差およびその影響を受け入れるか、またはそれを排除・低減するための対応を取るかを判断する。)
• 各ステージの終了時に許容度をレビューすることで、プロジェクトは変化する運用環境を反映し、次のステージの活動を適応・調整することが可能となる。

# 成果物重視

成果物重視とは、作成・提供される成果物を明確に定義し、ユーザーの期待する品質や要件について関係者間で合意した上で、作業ではなくアウトプットのデリバリーに焦点を当ててプロジェクトを管理するアプローチである。
プロジェクトの目的は、ビジネス正当性に基づき、利害関係者の期待に応えることにある。そのため、必要な成果物およびそれらに対するユーザーの期待品質について、関係者間で共通の理解を持つことが不可欠である。

# 成果物

• マネジメント成果物：主にビジネス・ケースや各種計画書など、プロジェクトの管理・統制を支援するために必要な文書や情報。
• スペシャリスト成果物：プロジェクトに必要なベネフィットを実現するために、ユーザーが必要とする成果物。
• プロジェクト成果物：プロジェクト成果物記述書で定義される、プロジェクト全体から生み出される総アウトプット
• 外部成果物：プロジェクトのコントロール外で開発または提供されるが、プロジェクトが依存している成果物

作成される成果物や、それらの承認に用いられる基準が明確に理解されていない場合、関係者間で解釈の相違が生じやすくなる。
これは、プロジェクトが作業重視型ではなく、アウトプット重視型であることを求められているためである。

成果物を重視することにより、以下が実現される。

• プロジェクトでは、成果物のデリバリーに直接貢献する作業のみが実施される（合意された成果物を提供するために必要な作業以上のことは行われない）。
• すべての変更について、成果物およびビジネス・ケースへの影響の観点から合意を行うことで、コントロールされない変更（いわゆる「スコープ・クリープ」）の管理が可能となる。
• プロジェクト開始時に成果物について合意しておくことで、ユーザーの不満や受け入れを巡る紛争のリスクを低減できる。
• プロジェクトの一時中断または終了を容易にする。特定の成果物の完成を区切りとして合意できるため、中断・終了や再開時のコントロールがしやすくなる。

合意された一連の成果物は、以下の基盤となる。

• プロジェクトのスコープ定義
• 計画立案およびプロジェクトコントロール
  そのために、成果物記述書を使用し、以下を判断する。
• 作業見積もり
• リソース要件
• 依存関係
• 活動スケジュール

成果物重視の考え方は、計画立案、責任分担、進捗報告、品質管理、変更コントロール、受け入れ、リスク・マネジメントを強力に支援する。

# 留意点

• 成果物が細分化されるほど、プロジェクト委員会が成果物記述書が正しいかどうかを判断できなくなりる。(理解に専門知識が必要となるため)

# プロジェクトに合わせたテーラリング

プロジェクトの特性に応じて、プロジェクト・マネジメント手法や管理レベルを調整・最適化する

# テーラリングする時、必ずに考慮する要素

• プロジェクトの環境
• 規模・複雑性
• 重要度（ビジネス価値・影響度）
• デリバリー手法（ウォーターフォール／アジャイル等）
• チームの能力・経験
• リスク・レベル

# 目的

• 形式的に手法を守ることではなく、プロジェクト成功に必要な「情報」と「意思決定」を、適切な方法と粒度で確保する

# 責任と役割

• プロジェクト・マネージャーは、テーラリングに対する実行責任を持ち、過去の教訓や組織の標準を参考にして、適切なマネジメント・アプローチの勧告を作成する。
• プロジェクト委員会は説明責任を持ち、立ち上げステージの終了時、およびマネジメント・アプローチの変更が提案されるたびに、その勧告を承認する必要がある。

# ビジネス・ケース

プロジェクトへの投資を継続して行うかどうかの意思決定を支援する手段として、プロジェクトが（継続的に）望ましく、実行可能かつ達成可能であるかどうかを判断するためのメ力二ズムを確立することです。

# 定義

• アウトプット：活動の有形または無形の提供物。PRINCE2 においてアウトプットとは、変更を実現するために使用されるスペシャリスト成果物である。

• 能力：成果を提供するために必要なプロジェクトのアウトプットの全体。

• 成果：変更の結果であり、通常では現状の振る舞いおよび環境に影響を与える。変更は成果を達成するために実施される。成果とは、変更を促進するために行われた活動の結果として達成されたことを指す。

• ベネフィット：投資組織によって利点として認識され、1 つ以上のビジス目標に貢献する、成果によって生じる測定可能な改善。

• ディスベネフィット：投資組織によってマイナスと認識され、1 つ以上のビジネス目標を損なう成果の結果として生じる測定可能な減少。

• ビジネス目標：プロジェクトが貢献すべき測定可能な成果であり、組織の戦略に関連する進捗状況を示す。

• プロジェクトには、ビジネス正当性（ビジネス・ケース）が必要です。ビジネス・ケースはプロジェクトの理由を確立するだけでなく、プロジェクトの以下の内容を確認するものです。

• 望ましい（コスト、ベネフィット、リスクのバランスが取れている)
• 実行可能（成果物を提供できる)
• 達成可能（成果物を使用することで、想定される成果と成果としてのベネフィットが得られる可能性があるか)

• ビジネス正当性をプロジェクトの開始時にビジネス・ケースの作成を通じて確立し、次にプロジェクトの価値の創出、実行可能性、達成可能性にインパクトを与える可能性のある決定やイベントに対応して、定期的にレビューし、更新する必要があります。ビジネス正当性が有効でなくなった場合は、プロジェクトを停止または変更しなければなりません。

# ライフサイクル

ビジネス・ケースは、プロジェクト権限委任で提供された情報に基づいて、プロジェクトの開始時にアウトラインとして作成されます。ビジネス・ケースにはプロジェクト委員会がビジネス正当性を確認し、プロジェクト・マネージャーがプロジェクトを立ち上げるのを認可するのに十分な情報を含める必要があります。ビジネス・ケース概要は、プロジェクト要約書に文書化されます。
プロジェクトのコスト、期間、成果物、リスク、ターゲットがこの時点で十分に理解されることはなく、プロジェクト全体の確実な正当性を提供するには至りません。したがって、プロジェクトがより詳細に計画され、情報がより明確になるにつれて、ビジネス・ケース概要はより 詳細なビジネス・ケースへと発展します。
プロジェクトがステージを経て進歩し、実際のコストが発生して予測ベネフィットの達成が見込まれ、情報についての理解が深まると、ビジネス・ケースがさらに詳細化される可能性があります。

# 成果物をビジネス目標と許容度に整合させる

ビジネス・ケースを支援するベネフィット・マネジメント・アプローチには、プロジェクトによって達成される予測ベネフィットの量と時期、およびこれらのターゲットに対する許容度に関する追加のガイダンスが含まれます。予測ベネフィットはプロジェクトを通じて（少なくとも各ステージの終了時に）確認され、設定された許容度に収まらない場合は、レビューと処置のために適切なレベルにエスカレーションします。ベネフィットが測定可能であることを確認することで、それらを実証できることも確認できます。プロジェクトに測定できないベネフィットが含まれている場合、それが成功したのか、または投資に見合う価値を提供したのかを判断することは不可能です。

ベネフィット・持続可能性許容度のパフォーマンス最終目標からの許容される偏差であり、次のマネジメント・レベルにエスカレーション不要な範囲を示す。

# 技法

ビジネス・ケースを作成するとき、プロジェクトのパフォーマンス最終目標の 7 つの側面すべてとそれらの相互関係は、ビジネス正当性を評価する一環として考慮しなければなりませんが、多くの場合、異なるパフォーマンス側面の間でトレードオフが発生します。ビジネス・ケースでは、必要とされる成果を達成するためのオプションを検討し、異なるパフォーマンス側面の間で最適なバランスを提供するオプションを選択します。(7 つのすべてのパフォーマンス側面に設定された許容度内でビジネス・ケースを構築できないプロジェクトは、その正当性が疑わしい可能性があります。)
ビジネス・ケースにはそのプロジェクト成果物の開発コストだけでなく、プロジエクト終了後の運用コストの変更も含めます。
ビジネス・ケースは概要として作成され、プロジェクトの開始時に詳細化されます。プロジェクトのライフサイクルを通じてその発展や変化に応じてレビューされ、更新されます。ステージ境界などの重要な意思決定ポイントごとに、プロジェクト委員会によって確認され、ベネフィットが発生する期間を通じて実証されます。

• 開発：オプションを検討し、投資評価の決定を下すため適切な情報を得ることを意味する
• 確認：プロジェクトが（現在も）価値があるものかどうかを評価することを意味する
• 維持：実際の進捗と現在の予測（予測ベネフィットを含む）により、ビジネス・ケースを最新の状態に保つことを意味する
• 実証：意図したべネフィットが実現された（または実現される）かどうかを評価することを意味する。ベネフィットの実証は主にプロジェクトがクローズした後に行われるが、プロジェクト期間中に成果物が提供または反復的リリースされたときにベネフィットが実現される場合もある。

# 開発

プロジェクト権限委任の提供により、プロジェクトの始動プロセスが有効化されます。その後、プロジェクト権限委任は、プロジェクト要約書のー部としてビジネス・ケース概要に文書化されたプロジェクトの初回のビジネス正当性を作成するためのインプットとして使用されます。プロジェクトの指揮プロセスで、プロジェクト要約書はプロジェクト立ち上げを認可するときに、プロジェクト委員会によって承認されます。ビジネス・ケース概要は、プロジェクトの立ち上げプロセス中に完全なビジネス・ケースへと詳細化されます。プロジェクト委員会はプロジェクトを認可するときにこれを承認します。

基本的なビジネス上のオプション

• 特に何もしない
• 最低限のことを行う
• 最低限以上のことを行う

「特に何もしない」オプションを常に最初のオプションとし、それに基づいてその他の選択肢を定量的に評価します。「特に何もしない」場合と「最低限のことを行う」または「最低限以上のことを行う」との差が、投資で得られるベネフィットとなります。

# 開発

選択したオプションに基づき作成されたビジネス・ケースは、価値の創出、実行可能性、達成可能性という観点から継続的に評価しなければなりません。(新たなリスクや変更の発生に伴い、他のオプションに切り替えることが正当化される場合があるためです。)

ビジネス正当性の継続により、ビジネス目標とベネフィットが継続的に実現可能であることを確認できるため、あらゆる意思決定が促進されます。プロジェクト委員会は、少なくとも以下のタイミングでビジネス・ケースを確認すベきです。

• プロジェクトの始動プロセスの終了時に、プロジェクト立ち上げを認可するとき
• プロジェクトの立ち上げプロセスの終了時に、プロジェクトを認可するとき
• 各ステージの終了時に、次のステージやプロジェクトの継続を認可するとき
• 例外計画書を評価して、プロジェクトの改訂されたステージと継続を認可するとき

プロジェクト・マネージャーは、以下のタイミングでもビジネス・ケースを確認します。

• 進歩、リスク、課題を評価して、ビジネス正当性へのインパクトを判断するとき
• 最終ステージ中に、プロジェクトのクローズのー環として、要件や、成果が予想ベネフィットを提供する可能性に照らし合わせてプロジェクトのパフォーマンスを評価するとき
• 利害関係者と協議して、ゴールが変更されたかどうか（ビジネスによって追加の持続可能性目標が確立されたかどうかなど）を判断するとき

# 維持

各ステージの終了時に、プロジェクト・マネージャーは、進捗データと最新の予測ベネフィットおよびパフォーマンス最終目標を使用してビジネス・ケースを更新します。(適切なバージョン・コントロールを使用してビジネス・ケースを維持し、参照や比較のために以前のバージョンにアクセスできるようにすることが重要です。)

# 実証

ビジネスは、プロジェクト終了後のベネフィット・レビューのー環としてビジネス・ケースをレビューし、ベネフィットの実現に向けたプロジェクトの成果を判断します。プロジェクト中は、ステージ境界でベネフィット・レビューを実施し、プロジェクト中に達成される予測ベネフィットが実現に向けて順調に進んでいることを確認しなければなりません。
シニア・ユーザーは、プロジェクトから得られるベネフィットを特定する実行責任を負うと同時に、予測ベネフィットが実現されることを実証する説明責任も負います。多くの場合、ベネフィットはプロジェクトのクローズ後まで実現されないため、プロジェクト期間を超えるコミットメントが伴う場合があります。
ベネフィット・マネジメント・アプローチは、プロジェクトの成果を確実に達成し、プロジェクトのベネフィットが実現されることを実証するために確立されるマネジメント・アクションを定義します。ビジネスがベネフィット・レビューを管理するかそれに参加する場合、プロジェクト委員会はビジネスの承認を得ることを求められる場合があります。ベネフィット・マネジメント・アプローチは、プロジェクトまたはビジネスによって管理される場合があり、多くの場合、プロジェクト期間終了後も管理されます。
プロジェクト期間中に測定可能なベネフイットは、シニア・ユーザーが実証し、プロジェクト・マネージャーがステージ終了報告書とプロジェクト終了報告書で正式に報告します。
プロジェクト終了後のベネフィット・レビューでは、ビジネスがシニア・ユーザーに割り当てられた個々のベネフィットがどのように実現されたかについての証拠や、完全には実現されていないべネフィットを達成するために実施した是正処置を確認することで、シニア・ユーザーに説明責任を負わせます。
プロジェクト終了後のベネフィット・レビューでは、運用中のプロジェクト成果物のパフォーマンスもレビューし、その他のプロジェクトに役立つ教訓を提供する（有益または有害な）副次的影響の有無を特定します。
プロジェクト・エグゼクティブは、ベネフィット・レビューが計画および実行されていることを確認する実行責任を負います。プロジェクト終了後の測定活動については、ベネフィット・レビューの責任は、プロジェクト終了の時点でプロジェクト・エグゼクティブからビジネス（特にシニア・ユーザー）に転移されます。これは、レビューには資金やリソースが必要になるためです。

# 支援技法

投資評価では、プロジェクト成果物の開発、運用、保守のコストと、一定期間にわたるベネフィットの価値を比較します。投資評価では、ベネフィット、コスト、リスクの関係を確認します。プロジェクトのコストと、継続的な運用コストと保守コストの両方を含めます。

# 投資評価技法

• ライフサイクル全体のコスト：実施および段階的な移行コスト、運用コスト、保守コストを含む総コストを分析する
• 正味ベネフィット：ベネフィットの総額から、一定の期間を定めて計算した実施、移行、継続的な運用コストを引いたものを分析する
• 投資収益率 (ROI): 投資の結果生じる利益や削減額を、初期投資額に対する割合で表す
• 回収：現金やその他のりソースの投資から価値が得られる時間の尺度
• 正味現在価値 (NPV): 特定の時点までに投資によって得られる金額。割引率を使用して割引キャッシュ・フ口一を判断することで金銭の時間的価値を考慮する（例えば、割引率が 6%⊘ 場合、金銭価値は約 12 年ごとに半減するため、プロジェクトが 12 年で 50 万ポンドのベネフィットを実現することを予測している場合、現在の貨幣価値では 25 万ポンドにしかならない)
• 内部収益率 (IRR): NPV がゼ口の場合の投資収益率を割合で示したもの
• オプション分析：重み付けされた評価基準に対して各オプションをスコアリングする方法によるオプションの比較。望ましいオプションを特定するのに役立つ（ペアワイズ比較を使用してオプションを区別し、候補リストと優先オプションを確立することもできる)
• 感度分析：インプット要因を調整して、アウトプット要因が投資を正当化できなくなるポイントを探る
  • 例えば、4 か月で完了できれば価値があるプロジェクトでも、6 か月かかった時点で価値がなくなる場合がある。
  • ビジネス・ケースは不確定な予測に基づいている。ビジネス・ケースの健全性を判断するには、とアウトプット要因（運用コストと保守コスト、ビジネスのベネフィットとリスクなど）の関係を理解することが有効。

# マルチケース・モデル

財務上のリターンだけに焦点を当てるのではなく、さまざまな観点から投資を評価することで、投資が望ましく、実行可能で、達成可能かどうかを包括的に確認できます。

• 戦略的観点：変更の推進要因を理解し、投資によってどのように戦略的適合性を提供できるかを示す・経済的観点：より広範な社会、環境、持続可能性への配慮を含む、最適な価値を提供するオプションを特定する
• 財務的観点：プロジェクトおよびプロジェクト成果物の存続期間にわたる採算性、資金調達、予算編成、キャッシュフローを評価する
• 実施と商業的観点：望ましいオプションがサービス提供者によって提供されること、およびプロジェクトのデリバリーを成功させるための確実な取り決めが確立されていることを示す

投資が堅牢であるためには、投資がこれらのすべての観点を満たしていることを示さなければなりません。

# 各シナリオ

ビジネス・ケースのスコープとベネフィットについてさまざまなシナリオを提示することです。

• 最良のケースシナリオ：すべての（対応必須、対応推奨、できれば対応）要件が満たされた場合に期待されるベネフィットを説明する
• 期待されるケースシナリオ：対応必須と対応推奨の要件が満たされた場合に期待されるベネフィットを説明する
• 最悪のケースシナリオ：対応必須の要件のみが満たされた場合に期待されるベネフィットを説明する

提供されるスコープの期待量が最も低い最悪のシナリオでは、プロジェクトがまだ実行可能であることも示さなければなりません。

# 備考

• ベネフィットはプログラム・マネジメント・チームによって定義、トラッキング、管理され、プロジェクトのベネフィット・マネジメント・アプローチは、プログラムのベネフィット実現計画書の一部となります。
• プロジェクト委員会 - で、ユーザー、ビジネス、サプライヤーの三者のプロジェクトに対する関心の整合性を通じて互換性を確保するのは、プロジェクト・エグゼクティブの責任です。
• ビジネス・ケースを作成するときは、成果物の段階的デリバリーやそれに伴う価値が、プロジェクトの実行可能性にどのようなインパクトを与えるか（肯定的か否定的か）や、一部のベネフィットを早期に実現する能力にどのようなインパクトを与えるかを理解することが重要です。
• ビジネス・ケースの形式と詳細は、プロジェクトのサイズと複雑性に合わせて調整する必要があります。

# マネジメント成果物

# インプット

# プロジェクト要約書

• 目的：プロジェクトを開始するための完全かつ確固たる基盤を提供する
• コンテンツ概要
  • 定義：プロジェクトが達成すベきことの説明で、以下の内容が含まれる。
    • 背景
    • プロジェクト目標
    • 期待される成果
    • プロジェクト・スコープおよび除外項目
    • 制約条件および前提条件
    • プロジェクト許容度
    • ユーザー、およびその他の既知の利害関係者
  • ビジネス・ケース概要：プロジェクトが必要とされる理由と、選択されたビジネス上のオプション
  • プロジェクト成果物記述書：ユーザーの期待品質と受け入れ基準を含む
  • プロジェクト・アプローチ：ビジネス・ケース概要で選択されたビジネス上のオプションを提供するためのアプローチを定義する
  • プロジェクト・マネジメント・チーム組織と役割記述書：誰がどのような役割で、どのような委任と報告のスキームでプロジェクトに取り組むか

# アウトプット

# プロジェクト要約書

• 目的：獲得が予測される予想ベネフィットと関係するあらゆるリスクに対して、コスト見積もりが見合っているかに基づいて、実施されるプロジェクトのビジネス正当性を文書化することです。ビジネス・ケースには、予想ベネフィットの測定方法と測定するタイミングのアウトラインを記載します。
• コンテンツ概要
  • エグゼクティブ要約：ビジネス・ケースの主要ポイントを取り上げる（重要なベネフィットと投資収益率を含める）
  • 理由：プロジェクトを実施する理由を定義し、プロジェクトがどのようにしてビジネス目標を達成するかを説明する
  • ビジネス上のオプション：オプションの基盤となる前提条件を含む、オプションの分析と合理的な勧告
  • 予想ベネフィットとディスベネフィット：プロジェクト実施前の状況と比較した、測定可能な単位で示されたベネフィットとディスベネフィット。測定にはベネフィット許容度が含まれる
  • 持続可能性目標：プロジェクトが達成する必要がある持続可能性に関連する目標。目標には持続可能性の許容度が含まれる
  • 時間：プロジェクトを実行する期間、およびベネフィットが実現されるまでの期間
  • コスト：プロジェクト・コスト、継続的な運用と保守コスト、資金調達の取り決めの要約
  • 投資評価：集約されたベネフィットとディスベネフィットを、プロジェクト・コスト、継続的な段階的運用、保守コストと比較し、投資としてのプロジェクトの価値を定義する
  • 主要リスク：プロジェクトに関連する主要な脅威と機会、およびこれらが発生した場合に考えられるインパクトと対応の要約

# ベネフィット・マネジメント・アプローチ

• 目的：プロジェクトの成果の達成を確保し、プロジェクトのベネフィットの実現を確認するために確立されるベネフィット・マネジメント・アクションとベネフィット・レビューを定義することです。
• コンテンツ概要
  • スコープ：管理および測定するベネフィットの説明
  • ベネフィットを実現する手順：プロジェクトの成果を確実に達成するために必要なマネジメント・アクションについて説明する（これには、プロジェクトがクローズした後にビジネス・レイヤーによって実施されるベネフィットを実現する活動の取り決めを含む。）
  • ベネフィットの測定：予想ベネフィットの達成度を測定する方法、測定するタイミング、改善を計算するうえで指標となるベースラインの測定について説明する
  • ベネフィット許容度ガイダンス：ビジネス・ケースでプロジェクトに対して定義されたベネフィット許容度レベルに追加のガイダンスを提供する
  • 成果物のパフォーマンス：プロジェクト成果物のパフォーマンスをレビューする方法を説明する
  • 責任：予想ベネフィットに対して誰が説明責任を負うかなど、ビジネス・ケースの活動の責任を定義する
  • リソース：ベネフィット・マネジメント活動（調査の実施など）用
  • 支援ツールと技法：ベネフィット・マネジメント活動（シミュレーターの使用など）用
  • 標準：ベネフィットの測定に適用される標準

# 持続可能性マネジメント・アプローチ

• 目的：プロジェクトの持続可能性パフォーマンス最終目標の達成を確保するために確立する処置、レビュー、コントロールを定義することです。
• コンテンツ概要
  • スコープ：管理および測定する持続可能性目標の説明
  • 測定：持続可能性目標の達成度を測定する方法、測定するタイミング、目標を計算するうえで指標となるベースラインの測定について説明する
  • 責任：持続可能性目標の達成度の測定について誰が説明責任を負うかなど、持続可能性の活動の責任を定義する
  • リソース：持続可能性マネジメント活動（調査の実施など）用
  • 支援ツールと技法：持続可能性マネジメント活動用
  • 標準：持続可能性マネジメントに適用される標準

# 主要な役割

# ビジネス・レイヤーの責任

• プロジェクト権限委任を提供し、ビジネス・ケース策定時に守るべき基準を定義する
• シニア・ユーザーに対して、プロジェクト成果物によって可能となるプロジェクト終了後のベネフィット実現の説明責任を割り当てる
• ベネフィット・マネジメント・アプローチに対する説明責任を負う（プロジェクト終了後）
• プロジェクト・レベルのベネフィット許容度を設定する

# プロジェクト・エグゼクティブの責任

• プロジェクト期間中、ビジネス・ケースについての説明責任を負う
• ベネフィット・マネジメント・アプローチと持続可能性マネジメント・アプローチを承認し、プロジェクト期間中の説明責任を負う
• ステージ・レベルのベネフィット許容度を設定する
• 実行可能なビジネス・ケースの開発を監督し、プロジェクトがビジネス目標と整合していることを確認する
• プロジェクトが継続的に望ましく、実行可能で、達成可能であることを確認する
• プロジェクトの資金調達を確保する
• シニア・ユーザーが特定したベネフィットが投資に見合う価値を持ち、ビジネス目標と整合しており、実現できることを確認する

# シニア・ユーザーの責任

• ビジネス・ケース承認の根拠となる望ましい成果とベネフィットを特定する説明責任を負う
• ベネフィット・マネジメント・アプローチと持続可能性マネジメント・アプローチに合意する
• ベネフィットの実現に対する説明責任を負い、プロジェクトで望ましい成果を提供する成果物を作成し、その成果が望ましいベネフィットを生み出すことを確保する
• （プロジェクトの成果から得られる）予想ベネフィットが実現されたこと、または実現できることを確認する
• ベネフィット・レビュー時に、実際のベネフィットの達成と予測ベネフィットを比較した文書を提供する

# シニア・サプライヤーの責任

• ビジネス・ケース承認の根拠となる望ましい成果とベネフィットを特定する説明責任を負う
• ベネフィット・マネジメント・アプローチと持続可能性マネジメント・アプローチに合意する
• ベネフィットの実現に対する説明責任を負い、プロジェクトで望ましい成果を提供する成果物を作成し、その成果が望ましいベネフィットを生み出すことを確保する
• （プロジェクトの成果から得られる）予想ベネフィットが実現されたこと、または実現できることを確認する
• ベネフィット・レビュー時に、実際のベネフィットの達成と予測ベネフィットを比較した文書を提供する

# プロジェクト・マネージャーの責任

• プロジェクト・エグゼクティブから委任されたビジネス・ケース、ベネフィット・マネジメント・アプローチ、持続可能性マネジメント・アプローチを開発する実行責任を負う
• ビジネス・ケースの継続的な実行可能性に対する課題とリスクのインパクトをレビューする
• 各ステージの終了時に、ビジネス・ケース、ベネフィット・マネジメント・アプローチ、持続可能性マネジメント・アプローチを評価し、更新する
• プロジェクトのクローズ時にプロジェクトのパフォーマンスを評価し、報告する
• プロジェクト期間中、利害関係者と協議して、ゴールが変更されたかを確認する

# チーム・マネージャーの責任

• ワーク・パッケージ記述書で合意されたベネフィット・マネジメント手順を実施する

# プロジェクト保証の責任

• プロジェクトが全体的なビジネス目標に適合していることを確認する
• ベネフィット・マネジメント・アプローチと持続可能性マネジメント・アプローチについて、プロジェクト・マネージャーに助言する
• ベネフィット・マネジメント・アプローチと持続可能性マネジメント・アプローチがビジネスの方針に準拠していることをプロジェクト委員会に確認する
• 外部イベントとプロジェクト進捗に対して、ビジネス・ケースを確認し、モニタリングする
• ビジネスを代理してプロジェクトの財務状況をモニタリングする
• プロジェクト計画書の変更をモニタリングし、ビジネスやビジネス・ケースのニーズに対するインパクトを特定する
• ビジネス・ケースおよびプロジェクト計画書に対する潜在的な変更のインパクト評価をレビューする
• ベネフィット・マネジメント・アプローチと持続可能性マネジメント・アプローチの実施についてプロジェクト委員会に保証する（投資に見合う価値をもたらすソリューションが継続的に再評価されているかどうか など）

# プロジェクト支援の責任

• ビジネス・ケース、ベネフィット・マネジメント・アプローチ、持続可能性マネジメント・アプローチのベースラインと変更コントロールを維持する
• ビジネス・ケースに影響を及ぼす成果物に対して提案された変更、または実際の変更をプロジェクト・マネージャーに助言する