プロジェクト・マネジメント-計画

計画

ビジネス・ケース（理由）を満たすために、「何を」「誰が」「どのように」「どこで」「いつ」「いくらで」提供することを定義し、コミュニケーションとコントロールを円滑にする。

1. 計画におけるの統合視点
   • ユーザーの期待: 提供される成果物と、それによって実現されるベネフィット。
   • チームの評価: 期待を満たすための最も効果的なアプローチ（手法・手段）。
   • ビジネスの支援: 必要な資金、人員、リソースに対する組織的なコミットメント。
2. 計画書によって明確化される要素（5W2H + α）

   項目	内容
   なぜ（Why）	ユーザーの推進要件、実現を期待するベネフィット
   何を（What）	提供される成果物、受け入れ基準、品質仕様
   どのように（How）	デリバリー手法、制約条件
   いつ（When）	活動の順序、見積もられる期間（スケジュール）
   どこで（Where）	デリバリーや受け入れに関連する場所、施設
   誰が（Who）	必要なスキル、責任、チームの編成方法
   どのくらい（How much）	合意された成果物、関連するデリバリーやマネジメント活動の見積もりコスト
   リスク（Risks）	デリバリー中に発生しうる不確実性
   課題（Issues）	計画の正確性や現実性に影響を及ぼす既知の問題点

3. ベースライン化とコントロール 計画が承認され、ベースラインとなることで、以下の効果が得られる。
   • コミュニケーションの土台: 利害関係者やチーム内での共通認識の形成。
   • 進捗測定の基準: 実際の進捗状況を測定し、課題を評価するための「物差し」。
   • スコープの定義: 合意された「プロジェクト・スコープ」となる(スコープ・クリープの防止)。
     • 階層的な計画: プロジェクト計画（全体）、ステージ計画（段階別）、チーム計画（作業別）により、それぞれの範囲を明確にする。
     • 変更管理: 承認されたスコープに含まれるものと含まれないものを峻別することで、コントロール不能な変更（スコープ・クリープ）を回避する。

定義

• 計画書（Plan）: プロジェクト全体、またはその活動の特定のサブセット（段階など）を対象に、**「何を、どこで、いつ、どのように、誰が」**実行するかを概説する。
• スコープ（Scope）
  、成果物記述書、およびワーク・パッケージ記述書によって規定され、以下の要素をすべて合わせたもの。
  • 成果物: プロジェクトによって作成される最終製品や中間生成物。
  • デリバリー: 成果物を構築・提供するための具体的な作業。
  • マネジメント活動: 計画、監視、報告などの管理プロセス全般。

計画立案のガイダンス

プロジェクト・ライフサイクルの全フェーズ、全成果物、全活動を対象とし、課題の変化に応じて継続的に行われる。

計画期間

計画は見積もりに基づくため、期間が長いほど、また環境が複雑であるほど不確実性が増す。そのため、計画書は合理的な確実性を持って計画可能な期間のみを対象とする。

• 長期計画(プロジェクト計画書): 概要レベルに留める（不確実性によるリスクを回避するため）。
• 短期計画(ステージ計画書): 詳細なレベルまで落とし込むことが可能である。

計画のレベル

各計画書は構造こそ同じだが、目的、スコープ、詳細レベルが異なる。

計画書の種類	概要・目的	作成・承認のタイミング
プロジェクト計画書	プロジェクト全体の目標、主要成果物、リソース、コストの概要を示す。ビジネス・ケースの正当性を確認するためのベースラインとなる。	プロジェクト始動時に作成。プロジェクト委員会が承認・ベースライン化する。
ステージ計画書	現在のステージにおける日々のコントロールのための詳細な計画。ワーク・ブレークダウン・ストラクチャー（WBS）を含む。	前のステージの終了間際に、最新の知見を反映して作成する。
チーム計画書	ワーク・パッケージを実行するチームの作業管理用。組織横断的な一時的チームなどで特に有効。	チーム・マネジャーが作成。必要性はプロジェクトの複雑性に依存する。
例外計画書	許容度（トレランス）を超過（または予測）した場合の是正措置を示す計画。	例外報告の承認後、指示された処置を実施するために作成する。

プロジェクト計画書

プロジェクトの主要成果物、提供時期、手法、およびコストの概要を説明する。

1. 目的と役割
   • 確信の提供: プロジェクトが「ビジネス・ケース」を達成できるという確信をプロジェクト委員会に与える。
   • 実行可能性の通知: 承認されたリソースと許容度（トレードオフ）の範囲内で、成果物を提供するための「実行可能なアプローチ」が存在することをチームに周知する。
   • ベースラインの確立: プロジェクトの全期間を通じて進捗をモニタリングするための基準となる。
2. 主な構成要素 プロジェクト計画書では、以下の要素を具体的に特定する。
   • ステージ設計: プロジェクトを分割するステージの数と、その境界（ステージ境界）の詳細。
   • ワーク・パッケージの提案: 成果物デリバリー活動の集合体(プロジェクトにおける**最上位レベルのWBS（ワーク・ブレークダウン・ストラクチャー）**を構成する。)。
   • 主要成果物と時期: 何を、いつ、いくらで提供するかのロードマップ。
3. ライフサイクルと運用
   • 作成時期: 「プロジェクトを開始する」プロセスの中で策定される。
   • 承認とベースライン化: プロジェクト委員会による承認を経てベースラインとして設定される。
   • 更新プロセス: 「ステージ境界のマネジメント」プロセスにおいて、必要に応じて内容を見直す。変更が生じた場合は、委員会の承認を得てベースラインを更新する。

ステーヅ計画書

ステージ全体を通じて、プロジェクト・マネージャーが日々のコントロールを行うための基準となる詳細な計画書である。

1. 特徴と詳細レベル
   • 構成の類似性: 基本的な構造はプロジェクト計画書と似ているが、記載内容はより具体的である。
   • 日々の管理: プロジェクト・マネージャーが日常的な進捗管理を行うのに十分な詳細レベルまで各要素が分解されている。
   • 追跡可能性（トレーサビリティ）: ステージ計画書内の情報は、上位のプロジェクト計画書まで遡って整合性を確認（追跡）できるように構成する。
2. 含まれるべき構造 ステージ計画書には、そのステージのスコープを明確にするため以下の図表を含める。
   • 成果物ブレークダウン・ストラクチャー (PBS): ステージのスコープ内にある成果物と、それらの相互関係を示す。
   • ワーク・ブレークダウン・ストラクチャー (WBS): そのステージで実施される主な活動、および各活動に必要な人材やリソースを特定する。
3. 作成のタイミングとアプローチ
   • 初期計画: プロジェクトを立ち上げるための最初のステージ計画書は、「プロジェクトを開始する」プロセスで作成される。
   • 後続計画: 第 2ステージ以降の計画書は、現在のステージが終了する間際（ステージ境界）に準備される。
4. 利点 段階的に詳細化する（ローリングウェーブ・プランニング）ことで、以下のメリットが得られる。
   • 直前作成: 活動が実行される直前に作成するため、最新の状況を反映できる。
   • 確実性の向上: プロジェクト計画書に比べて対象期間が短いため、計画期間（プランニング・ホライズン）内に収まり、見積もりの精度が高まる。
   • 学習の反映: それまでのステージで得られたパフォーマンス実績や教訓を、次の計画に活かすことができる。

チーム計画書

ワーク・パッケージを実行する際に、チームレベルでの作業を整理・コントロールするための基礎となる計画書である。

1. 目的と作成主体
   • 作成者: チーム・マネージャーが作成する。
   • 役割: 1つまたは複数のワーク・パッケージの実行を円滑に進めるための詳細なスケジュールやリソース割り当てを定義する。
2. 計画の必要性の判断 チーム計画書を別途作成するかどうかは、以下の要素に基づいて判断される。
   • プロジェクトの規模と複雑性: 大規模なプロジェクトや、複雑な専門作業を伴う場合に有効である。
   • リソースの性質: 特に、組織内のさまざまな部門からメンバーが集まって構成される「一時的なチーム」の場合、共通の作業基盤として役立つ。
3. ステージ計画書との関係
   • 詳細化: ステージ計画書で定義された作業単位（ワーク・パッケージ）を、さらに日単位や担当者単位の活動レベルまで落とし込む。
   • コントロールの委任: プロジェクト・マネージャーはステージ計画書で管理し、チーム・マネージャーはチーム計画書を用いて現場の進捗を管理する。

例外計画書

「例外報告書」が提出された後、特定された例外事象（計画からの逸脱）に対して、どのように対応するかを具体的に説明する計画である。

1. 策定のトリガー
   • 許容度の超過: プロジェクトまたはステージにおいて、あらかじめ合意された「許容度（タイムライン、コストなど）」を実際に超えた、あるいは超えると予想される場合に作成される。
   • 手順:
     1. プロジェクト・マネージャー（PM）が例外報告書をプロジェクト委員会へ提出。
     2. 委員会がその内容を確認し、ステージ内での対処を決定。
     3. PMが指示された処置を具体化した例外計画書を準備する。
2. 対応内容の範囲 例外のインパクトの大きさに応じて、計画の内容は変化する。
   • 軽微・限定的な場合: 品質低下を防ぐための検査頻度の向上など、特定の是正措置（コントロールの強化）に限定される。
   • 重大な場合: 現在のステージのスコープを超える処置が必要な場合は、上位のプロジェクト計画書自体に変更を加え、全体の整合性を再定義しなければならない。
3. 特記事項
   • 対象外: チーム・マネージャーがワーク・パッケージの管理に使用するチーム計画書においては、例外計画書を作成する必要はない（チームレベルの課題はワーク・パッケージの許容度内で解決するか、PMへ報告・相談する形をとるため）。
   • 役割: 承認された例外計画書は、元のステージ計画書（またはプロジェクト計画書）を置き換える、あるいは補完する新たなベースラインとなる。

マネジメント・ステージの設計

プロジェクトを適切な単位（ステージ）に分割することで、コントロールと労力のバランスを最適化する。

1. 分割の判断基準 * デリバリー手法（ウォーターフォール型かアジャイル型か） * 主要な意思決定ポイント（ゲート）の時期 * リスクの量と計画可能な期間の長さ
2. ステージの特性 * 数と長さ: 複雑でリスクが高いほど、ステージを短く分割してコントロールを強める。逆に単純なプロジェクトでは「立ち上げ」と「デリバリー」の2ステージ構成もあり得る。 * 重複の禁止: ステージは重複させない。各境界でビジネス正当性を再評価し、継続の是非を判断するためである。 * ワーク・パッケージとの関係: 作業の重複や無駄を防ぐため、1つのワーク・パッケージがステージ境界をまたぐことは避けるべきである。

ステージの数

プロジェクトをいくつのマネジメント・ステージに分割するかは、成果物の性質やデリバリー活動の内容によって決定される。

1. コントロールと労力のトレードオフ

   • ステージ数が多い場合:
     • メリット: 頻繁にレビューが行われるため、コントロールの度合いが高まり、リスクを早期に発見できる。
     • デメリット: すべてのステージ境界（マネジメントの節目）において、計画立案や承認のための管理労力が必要になる。
   • ステージ数が少ない場合:
     • 管理負荷は軽減されるが、長期的な不確実性に対するコントロールが難しくなる。

2. プロジェクトの規模とステージ構成の例

   プロジェクトの種類	推奨される構成	理由
   単純なプロジェクト	2ステージ	成果物が明確で手法も成熟している場合、「立ち上げ」と「デリバリー」の2 段階で十分である。
   大規模・複雑なプロジェクト	複数のデリバリー・ステージ	成果物が複雑で手法が多岐にわたる場合、段階ごとに個別の成果物と境界を設ける。

3. 利点 複数のデリバリー・ステージを設けることで、以下の効果が得られる。

   • 見積もりの精度向上: 各ステージ計画書を作成する際、それまでの実績に基づいた現実的な見積もりが可能になる。
   • ビジネス正当性の検証: ステージ境界ごとに、プロジェクト委員会が「このまま継続して利益（ビジネス・ケース）が見込めるか」を再確認できる。

4. 外部要因との整合

   • 外部イベントの考慮: 組織の年度末、特定の法規制の施行、あるいは他プロジェクトの完了といった「外部イベント」に合わせてステージ境界を設定し、整合性を保つ必要がある場合もある。

ステージの長さ

ステージの適切な長さを判断するためには、以下の観点からプロジェクトの状況を評価する必要がある。

1. 複雑性 (Complexity)
   • 評価内容: デリバリー活動の数や、タスク間の依存関係の多さ。
   • 戦略: 複雑性が高い場合は、短いステージを設定する。これにより、承認された許容度（タイムラインやコスト）からの逸脱（例外）を早期に発見し、防ぐことができる。
2. リスクのレベル (Risk Level)
   • 評価内容: プロジェクトに伴う不確実性や潜在的な脅威の大きさ。
   • 戦略: リスクが高いプロジェクトでは、主要なポイントでステージを区切り、一時中断してリスクレビューを行う。本格的なリソース投入（コミットメント）の前に、継続の妥当性を再確認する。
3. 計画期間（プランニング・ホライズン）
   • 評価内容: リソースの見積もりや活動期間の確実性。
   • 戦略: 重大な不確実性がある場合、短いステージを採用する。各ステージの終了時に得られた実績データを反映させることで、次ステージ以降の見積もり精度を段階的に改善できる。
4. 適切な意思決定ポイント
   • 評価内容: プロジェクト委員会やビジネス層による重要な判断が必要なタイミング。
   • 戦略: プロトタイプのデリバリー後や、組織の計画立案サイクル（年度更新など）といった、クリティカルな意思決定が必要なイベントにステージ境界を整合させる。
5. プログラム活動との整合性
   • 評価内容: 上位組織である「プログラム」のスケジュールや区分。
   • 戦略: プロジェクトがプログラムの一部である場合、プログラムのデリバリー区分（トランシェ）の終了タイミングとプロジェクトのステージ終了を合わせる必要がある。

ステージとワーク・パッケージ

プロジェクトのガバナンスを維持するためには、マネジメントの節目である「ステージ」と、作業の単位である「ワーク・パッケージ」の境界線を適切に管理することが不可欠である。

1. ステージを分離する意義 ステージを重複させず、明確に区切ることには以下の重要な目的がある。
   • 進捗の厳格なレビュー: プロジェクト・マネジメント・チームとプロジェクト委員会が、現時点での状況を正確に評価できる。
   • ビジネス正当性の再確認: 「このプロジェクトを継続する価値がまだあるか（ビジネス・ケースとの整合性）」を、次のステージへ進む前に判断できる。
   • 次ステージの精緻化: ステージ境界（節目）を利用して、後続ステージの計画を最新の情報に基づいて更新できる。
2. ワーク・パッケージの論理的グループ化 プロジェクトの作業は、以下の要素に基づいて「ワーク・パッケージ」としてグループ化される。
   • デリバリー手法: 使用する開発プロセスや技術的アプローチ。
   • 専門スキル: 実行に必要なスキルセットや専門知識のまとまり。
   • 組織の関係: 外部サプライヤーへの委託範囲や、社内他部署との連携単位。
3. ステージ境界とワーク・パッケージの不整合防止 原則として、ステージ境界をまたぐ（複数のステージにまたがって継続する）ワーク・パッケージは避けるべきである。これには以下の理由がある。
   • 手戻りの防止: ステージ境界での意思決定（例: 仕様変更やプロジェクトの中止）によって、進行中の作業が無駄になったり、やり直し（作業の繰り返し）が発生したりするリスクを最小限に抑えるため。
   • 責任の明確化: ステージごとに作業を完結させることで、各ステージの成果物とコストを正確に把握し、管理を容易にする。

計画立案の許容度

効果的な計画立案には、プロジェクトが直面している制約条件を理解し、どの要素を優先すべきかに基づいて「許容度（Tolerance）」を設定することが不可欠である。

1. プロジェクトの制約条件による分類 プロジェクトは、その主たる制約に基づいて大きく2つの性質に分けられる。
   • スケジュールに基づくプロジェクト: 特定の日付（納期）までの完了が絶対条件となるもの。
   • リソースに基づくプロジェクト: 認可された予算や人員などのリソースを超えないことが最優先されるもの。
2. 主要な許容度 許容度とは、上位のマネジメント層へエスカレーション（報告・指示仰ぎ）を行うことなく、そのレベルの管理者が許容できる「計画からの偏差」を指す。
   • 時間許容度 (Time Tolerance)
     • 定義: 計画されたスケジュールからの許容されるずれ。
     • 適用: 納期厳守のプロジェクトでは、この許容度は非常に狭く（あるいはゼロに）設定される。わずかな遅延もプロジェクトの失敗に直結するリスクがあるためである。
   • コスト許容度 (Cost Tolerance)
     • 定義: 合意された予算からの許容される偏差。
     • 適用: 固定予算で運用されるプロジェクトでは、コスト許容度が厳格に制限される。追加予算の獲得が不可能な場合、コスト超過は許されない。
   • スコープ許容度 (Scope Tolerance)
     • 定義: 計画されたスコープ（作業範囲や成果物の機能）からの許容される偏差。
     • 適用: 例えば、新システムの導入プロジェクトにおいて、主要機能以外の「ユーザー支援」や「追加トレーニング」の範囲に幅を持たせる場合などに設定される。これにより、状況に応じた柔軟なリソース配分が可能になる。
3. 許容度設定の意義 許容度の幅（広いか狭いか）を決定することで、以下の理解が深まる。
   • 優先順位の明確化: 「納期、コスト、品質（スコープ）」のうち、どれが最もクリティカルな制約かをチーム全体で共有できる。
   • 自律的な管理: プロジェクト・マネージャーがどの範囲まで自らの裁量で調整を行えるかが明確になり、迅速な意思決定が可能になる。
   • 計画の現実性: 制約条件を計画に組み込むことで、より現実的で達成可能なベースラインを構築できる。

成果物ベースの計画立案

必要な成果物（プロダクト）の作成とデリバリーを起点として計画を策定する手法である。

1. 成果物重視の利点 ユーザーはプロジェクトが最終的に生み出す「アウトプット」に最も関心を持つ。以下の利点が得られる。
   • 無駄の排除: 必要なアウトプットに直接貢献しない付随的な活動を特定し、避けることができる。
   • 計画策定の指針: プロジェクト・マネージャーにとって、「何から着手すべきか」が明確になる。
   • 判断の容易化: 必要な成果物が定義されることで、プロジェクト・アプローチ、リソース、タイムライン、リスク、課題の特定がスムーズになる。
2. スコープ管理と合意形成 成果物とその相互依存関係を明確に文書化することで、以下のリスクを管理する。
   • スコープ漏れの防止: 成果物間の関係を一貫して特定することで、必要な作業が無視されたり見逃されたりするリスクを軽減できる。
   • 境界の明確化: プロジェクトのスコープに「含めるもの」と「含めないもの」を定義し、関係者間で合意を形成するのに役立つ。
3. 下位計画への展開と例外対応 計画の実行段階やトラブル発生時にも効果を発揮する。
   • ワーク・パッケージの簡素化: 成果物が明確であれば、それを実現するためのワーク・パッケージの特定や順序付けが容易になる。
   • 計画の継承: 成果物ベースの情報は、ステージ計画書やチーム計画書といった従属的な計画にもそのまま引き継がれる。
   • 例外への集中: プロジェクトに例外が発生した際、どの成果物が影響を受けるかを特定できるため、コストやスケジュールへのインパクトを最小限に抑えながら解決策を導き出せる。

プロセス

成果物ベースの計画立案では、活動（タスク）ではなく、まず「何を作るか（成果物）」を起点とする。これにより、スコープの漏れを防ぎ、ユーザーの期待に直結した計画策定が可能になる。

成果物の定義と分析

1. プロジェクト成果物記述書の作成

   1. 目的と作成のタイミング
      • 作成時期: 「プロジェクトの始動（Starting up a Project）」プロセスで策定される。
      • 主要な狙い: ユーザーが期待する結果を得るために必要な「主要成果物」がすべて特定されているかを確認する。
      • 評価の視点: 必要なものが見落とされていないか、逆に不要なものが含まれていないかを厳格に確認・評価する。
   2. 品質と受け入れ基準の定義
      • 期待品質: ユーザーが成果物に求める具体的な品質要件。
      • 受け入れ基準 (Acceptance Criteria): * 成果物が完成したとみなすための要件。
        • 客観的に測定可能な単位で示すことが推奨される。
        • 測定不能な場合は一連の説明書で代用も可能だが、後に正確な基準へ変換することをプロジェクト要約書で明記しておく必要がある。
      • 受け入れ手法: 基準を満たしているかをどのように検証・確認するか（テスト、検査、デモンストレーションなど）。
   3. ステークホルダー間の合意形成
      • 共通理解の構築: プロジェクト・マネージャーとプロジェクト委員会の間で、何をもって「完成」とするかの認識を一致させる。
      • 品質許容度の設定: 許容できる品質の幅を定義することで、効果的なコントロールを可能にする。
   4. アプローチの検討
      • 代替案の評価: ビジネス・ケースを最も確実に満たすソリューションやアプローチを検討する。
      • スコープの最適化: 検討結果に基づき、最適なアプローチと成果物をプロジェクト・スコープに反映させる（この段階では概要レベルの記述に留めることが多い）。

2. 成果物ブレークダウン・ストラクチャー (PBS)

   計画段階で作成される、すべての成果物を階層状に整理した図である。

   1. 目的と機能 提供すべき最終成果物と、それを構成する必須コンポーネント（部品・要素）を明確にするために作成される。
      • 階層的な分解: 最終成果物をトップに置き、それを構成する要素へと順次分解していく。
      • 要件の集約: 各コンポーネント要素に必要な要件をまとめ、全体像を把握しやすくする。
   2. 主な活用方法（グルーピング） PBSには、情報を論理的に整理する2つの主要な機能がある。
      • 固有要件によるグループ化: 特定の成果物やコンポーネントに紐づく固有の要件を、論理的なまとまりとして管理できる。
      • 調達・デリバリー手法によるグループ化: 同じ調達先（サプライヤー）や、共通のデリバリー手法（開発プロセスなど）に関連する要件をまとめて整理できる。
   3. 設計上の考慮事項
      • 成果物の「状態」の定義: 単に成果物の名前を挙げるだけでなく、特定の成果物が経る状態（設計済み、テスト済み、承認済み　など）を別個のコンポーネントとして含めるかどうかを検討することが有効な場合もある。
      • 網羅性の確保: 階層構造にすることで、最終成果物の完成に必要な要素の「漏れ」や「重複」を視覚的にチェックできる。

3. 成果物記述書の作成

   PBSで分解された個々の成果物に対し、詳細な仕様や要件を定義する。

   1. 役割と作成手順

      • 要件の引き出し: プロジェクト・マネージャー（PM）がユーザーから要件を引き出し、文書化する。
      • 専門家との協議: PMは**特定領域専門家（SME）**と連携し、以下の観点から要件を精査する。
        • 調達・開発・テストの方法
        • 実際の使用場面
        • 受け入れ後の支援（サポート）体制
      • 狙い: 主要な成果物の要件を十分に詳細化することで、現実的なスケジューリングと見積もりを可能にする。

   2. デリバリー手法による記述レベルの違い 成果物の定義は反復的なプロセスであり、採用するプロジェクト手法によって記述の深さが異なる。

      手法	記述のレベル	特徴
      直線的・連続的 (Waterfall)	詳細かつ厳密	開発着手前に詳細を固めることで、コストと時間の見積もり精度（信頼度）を高める。
      反復的・段階的 (Agile)	概要レベル	開発と並行して詳細が具体化されるため、次のステージに進むのに必要な最小限の記述に留める。

   3. 品質仕様の優先順位付け プロジェクトにおいて「制約条件（予算・納期）を考慮せずにすべての期待を満たす」ことはほとんどない。

      • 優先度の設定: 各成果物の品質仕様に優先順位を付ける。
      • 効果: 最も重要な要件（Must-have）が確実に満たされるようにリソースを集中させ、効果的なコントロールを実現する。

4. 成果物流れ図の作成

   PBSで特定された各成果物が、どのような順序で作成され、互いにどう依存しているかを示す。

   1. 目的と依存関係の特定 成果物間の依存関係を明確にすることで、計画全体のデリバリー順序を論理的に構成できる。
      • 中間成果物 (Intermediate Products): 最終成果物の完成に不可欠なインプットだが、ユーザーが直接使用しないもの（例: 設計書、テスト用データ）。これらもフローに含める必要がある。
      • 外部成果物 (External Products): 計画のスコープ外だが、成果物作成に不可欠なもの（例: 他部署からの提供資料、外部供給の部品）。これらへの依存関係も明記する。
   2. スケジューリングへの活用 成果物流れ図を作成することで、自然に以下の情報を得ることができる。
      • 活動の順序付け: 成果物を提供するために必要な活動を、論理的な順序で検討できる。
      • 見積もりの精度向上: 依存関係が明確になるため、各ステップの期間やコストの見積もりが容易になる。
   3. 設計上のポイント
      • 明確な始点と終点: どこから始まり、どこで完了するかを定義する。
      • 適切な詳細レベル: 関連するコスト、期間、規模に合わせて、細かすぎず粗すぎないレベルで記述する。
      • 視覚的な工夫: ステージごとに成果物を色分けすることで、どの時期に何が完成するかを直感的に判別可能にする。
   4. ベネフィット実現の予測
      • 成果への影響確認: プロジェクト・マネージャーとシニア・ユーザーは、この図を通じて「いつアウトプットが完成し、いつからユーザーがベネフィット（便益）の測定を開始できるか」を予測できる。

ワーク・パッケージのとりまとめ

成果物流れ図に基づき、関連する活動やリソースを「ワーク・パッケージ」という管理単位にグループ化する。

1. デリバリー手法の決定とパッケージ化
   • 手法の選択: 成果物流れ図を分析することで、プロジェクトを「直線的・連続的（ウォーターフォール）」で行うか、「反復的・段階的（アジャイル）」で行うかを判断できる。
   • 構成要素: 各ワーク・パッケージには、関連する人員、リソース、デリバリー活動を組み合わせる。
   • アウトプット: すべてのワーク・パッケージは、少なくとも1つの「最終成果物」または後続工程へのインプットとなる「中間成果物」を作成する。
2. 依存関係の定義 ある成果物の作成が、別の要素に依存している状態を指す。
   • 内部依存関係: プロジェクト内部の成果物同士の依存関係。プロジェクト・チーム内でコントロールが可能である。
   • 外部依存関係: プロジェクト外の成果物や活動（他部署、外部ベンダー、法規制など）への依存。チームが完全にはコントロールできないリスクを伴う。
3. ワーク・パッケージ記述書による合意 すべての依存関係は「ワーク・パッケージ記述書」に文書化されなければならない。
   • 合意の性格: 契約の有無にかかわらず、プロジェクト・マネージャーと実行責任を負うチーム・マネージャーとの間の公式な合意事項と見なされる。
   • 重複の回避: 複数のワーク・パッケージ間でスコープが重複しないように管理し、セット全体でプロジェクトの全デリバリー・スコープを漏れなく構成する。
4. WBS（ワーク・ブレークダウン・ストラクチャー）の役割
   • 詳細化: WBSは、成果物を提供するために必要な作業を「タスク」と「担当メンバー」の観点から詳細に記述する。
   • 適用範囲: チーム計画書の作成に役立つが、成果物やパッケージが少なく、小規模なチームで動くシンプルなプロジェクトでは、WBSの作成は任意とされる。

見積もりの準備

1. 見積もりの主な対象要素 見積もりは、単なる「時間」だけでなく、リソースやコスト、リスクまで多岐にわたる。

   カテゴリ	見積もりの内容
   人 (People)	必要な特定のスキル、労力のレベル（工数）、いつ・どこで必要になるか。
   リソース (Resources)	材料、機器、施設、アクセス権、天然資源、資金、およびそれぞれの数量。
   活動の期間 (Duration)	スケジュール作成の基となる、各タスクの完了に要する時間。
   コスト (Costs)	人件費（給与・手数料）やリソースの単価。市場レートやサプライヤー契約に基づく。
   ベネフィット (Benefits)	プロジェクト成果物によって実現される成果の価値（定量的・定性的価値）の見積もり。
   リスク (Risks)	接近度、発生確率、影響度（インパクト）、対応策のコスト。

2. 見積もりの信頼度 (Confidence Level) すべての見積もりには、その数値がどの程度確かなのかという「信頼度」を付記することが推奨される。

   • バリエーションの抑制: 信頼度が高い見積もりほど、実行フェーズで予期せぬ変動（振れ幅）が発生する可能性が低くなる。
   • 許容度の合意: 高い信頼度の見積もりがあることで、PMとプロジェクト委員会は実態に即した「現実的な許容度（Tolerance）」に合意できるようになる。

3. 見積もりの継続性

   • 見積もりは一度切りではなく、プロジェクトの進行や新しい情報の獲得（学習）に合わせて、各ステージの境界などで継続的に精緻化していく必要がある。

スケジュールの準備

計画を図解ででタスクの順序やリソース割り当てを可視化する。

1. スケジュールの構成要素 ワーク・パッケージおよび関連するタスクの以下の情報を統合して作成する。
   • 順序 (Sequence): どの作業から着手し、次に何を行うか。
   • 相互関係 (Interdependencies): タスク間の依存関係（先行・後行タスク）。
   • 期間 (Duration): 各タスクの完了に要する見積もり時間。
2. ステージ計画書による詳細化 PMは、実行可能性を高めるために以下の点に留意してスケジュールを詳細化する。
   • 網羅性の確保: ステージ内のすべてのワーク・パッケージが、そのステージのスケジュールに漏れなく含まれている必要がある。
   • 活動の分解: 1つのワーク・パッケージには、通常 1つ以上の具体的な「デリバリー活動」が含まれる。
   • 精度の向上: **計画期間（プランニング・ホライズン）**を考慮し、タスクごとの「労力レベル（工数）」と「期間」を誰が見ても理解できるレベルまで具体化する。
3. スケジュールの役割
   • 進捗管理の基準: 計画されたスケジュールと実績を比較することで、遅延の有無を判断するベースラインとなる。
   • リソース管理: いつ、誰が、どの作業に従事するかを明確にし、リソースの競合を未然に防ぐ。

予算の準備

人とリソースの要件をまとめ、各コストを合算することで、計画の予算を策定する。

• 定義
  • リソース (Resource): 計画を完了するために必要な、あらゆる資産の総称(商品、サービス、設備、材料、施設、資金など)。

1. 予算に含めるべき主要要素 予算は単なる作業コストだけでなく、管理費や不確実性への備えを含める。
   • デリバリー活動のコスト: 成果物の作成・提供に直接必要なコスト（人員、機器、材料、施設など）。
   • プロジェクト・マネジメント活動のコスト: 計画、監視、報告などの管理業務に要するコスト。
   • リスク予算: 特定されたリスクへの対応策を実行するための資金。
   • 変更予算: 承認された変更（スコープの追加や修正）に対応するための予備資金。
   • コスト許容度: 予算計画からの許容される偏差の幅。
2. 文書化と運用の柔軟性
   • コンポーネントの使い分け: 必要なリソースの種類（内部リソースか外部調達か等）に応じて、適切な内訳で予算を文書化しなければならない。
   • 任意設定の判断: リスク予算や変更予算を個別に設けるかどうかは、プロジェクトの状況に依存する。
   • 判断基準: 予算を細分化することで得られる「コントロールの価値」が、それにかかる「管理コストや時間」を上回るかどうかで決定する。

リスクの分析

計画の開発プロセスは、常にリスクの特定と分析を伴う。計画の詳細化が進むにつれて、潜在的なリスクを徹底的に調査し、管理下に置く必要がある。

1. 計画立案とリスクの並行作業
   • 継続的な分析: 計画を立てる技法の全工程において、同時並行でリスクを分析する。
   • 詳細化に伴う調査: ワーク・パッケージやタスクが具体的になるほど、実行上の障害や不確実性（リスク）が明確になるため、その都度調査を行う。
   • 記録: 特定されたすべてのリスクは、遅滞なく**プロジェクト・ログ（リスク登録簿）**に登録し、追跡可能な状態にする。
2. 草案から決定版へのプロセス
   • リスクの評価基準: 計画書が完成したように見えても、以下の意思決定がなされるまでは「草案」の段階である。
     • 計画の中にどのようなリスクが内在しているか。
     • それらのリスクをどのように扱うか（回避、転嫁、軽減、受容など）。
   • 承認の条件: プロジェクト委員会などは、内在するリスクとその対応策が「許容範囲内」であると判断して初めて、計画を正式に承認する。
3. リスク分析の重要性
   • 現実的なベースライン: リスクを考慮した計画こそが、真のベースラインとなる。
   • 不確実性の管理: スケジュールやコストの見積もりに「リスク」という不確実性を織り込むことで、計画の信頼性を担保する。

計画書の文書化

プロジェクトの実行と管理の指針となる情報を一元化し、適切に保管・共有するための文書群である。

1. 計画概要文書（サマリー）の重要項目 各ファイルが分かれている場合でも、計画の全体像を把握するために、以下の項目を特定した**「概要文書」**を準備することが推奨される。

   項目	内容
   依存関係	プロジェクト内部の成果物間、および外部要因との依存関係。
   提案された許容度	時間、コスト、スコープなどの許容範囲（エスカレーション基準）。
   管理要件	モニタリング（監視）とコントロール（制御）のための具体的な方法。
   予算	必要な資金の総額とその内訳。
   主要リスク	計画達成に大きな影響を与える可能性がある不確実性。
   前提条件	上記の計画を立てる際の基礎となった「前提」や仮定事項。

2. プロジェクト計画書特有の記載内容 最上位レベルの「プロジェクト計画書」には、以下の情報も包含される。

   • ステージの記述書: 各ステージで何を行い、何を達成するかの定義。
   • 意思決定ポイント: プロジェクト委員会による承認や継続判断が行われるタイミングの特定。

支援技法

優先度付け

プロジェクトにおいて、ステークホルダーの要望をすべて満たすための資金・時間・リソースが完全に揃っていることは稀である。ビジネス正当性が高いものから優先的に提供するという姿勢が不可欠となる。

1. 優先度付けの対象 単なる作業順序だけでなく、以下の要素すべてに優先順位を検討する。
   • スコープ: 実施する作業の範囲。
   • 受け入れ基準: 成果物が満たすべき最低限の条件。
   • 品質仕様: 成果物の詳細な性能や特徴。
2. 技法 関係者間で「何が重要か」の合意を作るために、以下のフレームワークを活用する。

   技法	概要・特徴
   MoSCoW 分析	要件を「Must（必須）」「Should（推奨）」「Could（可能なら）」「Won’t（今回は不要）」の4 階層に分類する。
   プロダクト・バックログ	ユーザーにとって価値のある順に並べ替え、提供する順序を可視化する。アジャイル手法で多用される。
   ペアワイズ比較	2つの要件を直接比較し、どちらがより重要かを全ての組み合わせで判定する。相対的な順位付けに有効。
   狩野モデル	フィーチャーを「当たり前（必須）」「一元的（性能）」「魅力的（感動）」に分類し、顧客満足度への影響を分析する。
   アイゼンハワー・マトリックス	「重要性」と「緊急性」（または価値と実施の容易さ）の2 軸で評価し、着手順位を決定する。

3. マネジメントへの活用 優先度付けを明確にすることは、単なる順序決め以上の意味を持つ。
   • スコープ許容度の定義: 「Could（できれば対応）」の項目を特定しておくことで、リソースが不足した際に「どこまでなら削ってもよいか」という許容範囲を事前に合意できる。
   • 例外によるマネジメント: 優先順位に基づいた許容度が設定されていれば、軽微なスコープの調整を現場の裁量で行えるようになり、過度なエスカレーションを防ぐことができる。

スケジューリング

マイルストーンとともに活動の順序、依存関係、期間に関する情報を提供する。

1. 技法 プロジェクトの規模やデリバリー手法（ウォーターフォール/アジャイル）に応じて、最適な表示方法を選択する。

   技法	特徴	適したケース
   ガント・チャート	時間軸に対してタスクの所要期間を図示する。多くのツールと互換性がある。	多数の活動やマイルストーンを持つプロジェクト
   スプレッドシート	タスクとタイムラインを一覧表示する。維持コストが低い。	シンプルなプロジェクト（大規模・頻繁な変更には不向き）
   成果物チェックリスト	主要成果物とデリバリー期日の一覧。予定と実績の対比が可能。	デリバリー・パフォーマンスの概要把握
   活動フロー・ボード	カンバン・ボード等。成果物が開発工程をどう進行するかを示す。	反復的・段階的なプロジェクト（アジャイルなど）

2. 余裕時間とネットワーク分析 効率的な管理のためには、時間の余裕と活動間の関係性を把握することが不可欠である。
   • フロート（余裕時間）: 計画の完了時期に影響を与えずに、活動を遅延させることができる時間。
     • リスク: フロートがゼロの活動ばかりのスケジュールは、わずかな遅延が即座に納期遅延に直結する。
   • クリティカル・パス: プロジェクトの開始から終了まで、合計フロートが最も少ない活動の順序。
     • 特性: クリティカル・パス上の活動が計画以上に遅延すると、プロジェクト全体の完了日が直接的に後ろ倒しになる。
3. リソースの制約とクリティカル・チェーン クリティカル・パス分析だけでは不十分な場合、以下の視点が必要となる。
   • クリティカル・チェーン（Critical Chain）: リソースの制限を考慮した一連のタスク。利用可能なリソースの制約下で、プロジェクトの最短完了を妨げる経路を指す。
   • スケジュールの調整: プロジェクト・マネージャーは、フロートやリソースの柔軟性を活用して活動時期を調整し、納期の例外を回避する。
4. スケジュール・コントロール PMは、これらの情報を以下の管理に活用する。
   • 例外の回避: 利用可能なフロートやリソースの柔軟性を使い、活動時期を調整することで、許容度オーバーを防ぐ。
   • 焦点の絞り込み: クリティカル・パスやクリティカル・チェーン上の活動に注視し、潜在的な例外に対して先回りして対策を講じる。

見積もり

プロジェクトの性質や利用可能な情報の詳細度に応じて、最適な技法を選択または併用する。

1. 構造的なアプローチ
   • トップダウン (Top-down): * 概要レベルの信頼度で全体の見積もりを行い、それを下位要素（WBS 等）に割り振る。
     • 適したシーン: 期間やリソースが固定されているアジャイル（スプリント）形式のプロジェクト。
   • ボトムアップ (Bottom-up): * 最下位レベルのタスクやコンポーネントの見積もりを積み上げて、全体の数値を算出する。
     • 適したシーン: 個々の要素は理解されているが、その組み合わせが新しいプロジェクト。精度は高いが労力がかかる。
2. 比較とデータに基づくアプローチ
   • 比較 (Comparative): * 同様の過去プロジェクトや公開されている市場情報をベースに見積もる。
     • 適したシーン: 一般的なプラクティスに基づいた、標準的な作業や材料。
   • パラメーター (Parametric): * 単位、サイズ、数などのプロジェクト値と、経験的なデータモデルを掛け合わせて算出する。
     • 適したシーン: 建設業界のように、標準化された見積もりモデルが存在する分野。
   • データ解析 (Data Analysis): * タスクの特徴（記述的）や傾向（予測的）を分析して精度を向上させる。
     • 必要条件: 組織内や外部データ・トラストが保有するデータへのアクセス。
3. 専門家と合意に基づくアプローチ
   • 特定領域の専門知識 (Subject Matter Expertise):
     • Delphi 法: 専門家たちが匿名で回答を繰り返し、意見を収束させる。
     • プランニング・ポーカー: チームメンバーがカードを使って見積もりを提示し、合意形成を行う（アジャイルで一般的）。

ポイント

• 技法の併用: 大規模で複雑なプロジェクトでは、一つの技法に頼らず、複数の技法を組み合わせて「ダブルチェック」を行うことが一般的である。
• 専門家の活用: プロジェクト・マネージャーだけで抱え込まず、必要に応じてコスト見積もりの専門家や、特定領域の専門家（SME）の支援を仰ぐべきである。
• 信頼度の明示: どの技法を用いたかによって見積もりの信頼度（精度）が変わるため、それをプロジェクト委員会に明示することが、現実的な「許容度」の合意につながる。

プラクティスの適用

組織的な状況

プロジェクト計画は、組織の方針、手順、支援体制という枠組みの影響を強く受ける。特にプロジェクトがプログラムの一部である場合、その関係性はより密接になる。

1. プログラム・マネジメントによる支援 プロジェクトがプログラム内に位置づけられる場合、プログラム側が計画立案において主導的な役割を果たすことがある。
   • 計画担当者の役割: プログラム専属の計画担当者がいる場合、以下の支援を受けられる。
     • 標準テンプレートの提供: マネジメント成果物（計画書等）の統一フォーマット。
     • 作成・維持のサポート: PMによるプロジェクト計画書やステージ計画書の策定を実務面で支援。
   • ガバナンスの統一: 組織全体で一貫した計画立案の手法を適用することで、プロジェクト間の比較や統合管理が容易になる。
2. プログラム・デリバリー計画との整合 プログラム全体の成功のために、個々のプロジェクト計画は「プログラム・デリバリー計画」と同期していなければならない。
   • 成果物の相互利用: プログラム内では、あるプロジェクトの成果物が、別のプロジェクトの不可欠なインプットになることが多い。
   • 相互依存関係の組み込み:
     • プログラム・デリバリー計画には、どの成果物がどのプロジェクトで使用されるかが詳述されている。
     • PMは、これらの**「他プロジェクトとの依存関係」**を自プロジェクトの計画書（内部・外部依存関係）に正しく組み込む責任がある。
3. 計画立案における制約と自由度
   • 組織方針の遵守: 組織が定めるリスク許容度や品質基準は、プロジェクト計画の「許容度」設定に直接影響する。
   • リソースの競合: プログラム内でのリソース配分決定に基づき、プロジェクトのスケジュールや予算が制約を受ける場合がある。

商業的な状況

商業的な状況のプロジェクトでは、サプライヤーが参加する場合、計画をいかに同期させるかが重要な検討事項となる。

1. バックツーバック契約 ユーザーの期待とサプライヤーの成果を一致させるため、以下の管理が推奨される。
   • トレーサビリティの確保: サプライヤーの計画書が、プロジェクト計画書の該当要素（成果物や工程）と明確に紐付いている（追跡可能）ことを合意内容で要求する。
   • 品質の同期: プロジェクト委員会が承認した受け入れ基準および品質仕様と、サプライヤーとの契約内容が完全に整合していなければならない。
   • 権利の明記: 契約（合意内容）には、計画書の作成方法だけでなく、行う検査・監査の権利を具体的に記載する。
2. 計画の共有と詳細レベル 双方が円滑にコントロールを行うために、適切な情報開示が必要である。
   • モニタリングに必要な情報: サプライヤーの計画書には、ユーザー側のPMが進捗を維持・管理するのに十分な活動やマイルストーンを明記させる。
   • 機密情報の取り扱い: 計画書には相手方に見せられない機密情報が含まれる場合がある。
     • 対策: 個人情報や機密事項を除外した**共有用バージョン（サンタイズ版）**を別途準備する。
3. 調達マイルストーンの組み込み プロジェクト計画書には、単なる制作工程だけでなく、以下の調達関連イベントをマイルストーンとして含める必要がある。
   • 入札・選定の時期
   • 契約締結日
   • 資材・サービスの納入予定日
   • 検収（受け入れ完了）日

デリバリー手法

プロジェクトの確実性や成果物の性質に応じて、ウォーターフォールとアジャイルの2つのアプローチを使い分ける。

1. ウォーターフォール 十分に理解された成果物と、成熟したデリバリー活動を特徴とするプロジェクトに適している。

   • 計画のタイミング: プロジェクトの始動および立ち上げフェーズで、前もって詳細な計画を策定する。
   • 見積もりの精度: 類似プロジェクトの過去データが豊富なため、期間、労力、コストを高い信頼度で見積もることが可能。
   • 構造: 必要な成果物、ワーク・パッケージ、ステージを最初から明確に定義する。

2. アジャイル 最初の成果物を迅速に提供し、フィードバックを得ながら継続的に改善することをゴールとする。

   • フォーカス: 固定された期間（スプリントやタイムボックス）の中で「どれだけの価値を作成できるか」に焦点を当てる。
   • 計画のアプローチ:
     • 制約の固定: 時間とコストを固定し、代わりに**スコープに柔軟性（許容度）**を持たせる。
     • 成果物定義: 詳細な仕様書の代わりに、ユーザー・ストーリー、エピック、プロダクト・バックログを活用する。
     • ステージ設定: リリース単位やタイムボックスを「ステージ」として定義し、そのリソース要件から予算を算出する。
     • 協働ツール: チーム計画書の代わりに、カンバン・ボード等のツールを使い、チーム全体でリアルタイムに計画を更新する。

3. 手法による計画管理の比較

   項目	ウォーターフォール	アジャイル
   主な成果物定義	プロジェクト成果物記述書	プロジェクト成果物記述書 + プロダクト・バックログ
   詳細化のタイミング	立ち上げ時に一括	各イテレーション（サイクル）ごとに実施
   許容度（トレードオフ）	スコープを固定し、時間・コストを調整	時間・コストを固定し、スコープを調整
   チームレベルの計画	チーム計画書 (文書)	活動フロー・ボード (カンバン等)

   どちらの手法であっても、定期的な計画のレビューと更新は不可欠である。

持続可能性

計画書では、異なる方法で持続可能性に対処でる。

1. 成果物の持続可能性 成果物そのものが環境や社会に与える影響を管理する。
   • ライフサイクル視点: 単に完成だけでなく、使用期間中から最終的な廃棄・リサイクルに至るまでの全工程で環境インパクトを判断する。
   • 要件定義への反映: 成果物記述書において、環境負荷の低い素材の選定や、エネルギー効率などの仕様を明確にする。
2. デリバリーの持続可能性 プロジェクトの実行（作業）プロセスにおける負荷を管理する。
   • 活動の選択: ワーク・パッケージやステージの計画時、気候への影響を考慮した手法を選択する（例: 輸送手段の最適化、ペーパーレス化）。
   • 持続可能性の許容度: 燃料消費量や生産廃棄物の排出量について、PMが自律的に管理できる許容範囲をプロジェクト委員会と合意する。組織の環境戦略との整合性を保つ。
3. ベネフィットの持続可能性 プロジェクト終了後、成果が生み出す価値を長期的に維持する。
   • 成果の定着: プロジェクトが終了しても、ベネフィットが維持できなければ投資は失敗となる。
   • 見落としの防止: 計画段階で継続的なトレーニングやユーザー支援をスコープに含めることが重要である。これらが検討されないと、時間の経過とともに成果が形骸化し、予想ベネフィットを達成できなくなるリスクがある。
   • 要件の特定: ベネフィットを維持し続けるために必要な運用要件を、あらかじめプロジェクトの要件定義に組み込んでおく。

メリット

• リスク低減: 法規制の変化や社会的評価の低下というリスクを未然に防ぐ。
• 長期的価値の最大化: 一時的な成功ではなく、組織にとって真に持続可能な利益をもたらす。
• ステークホルダーの信頼: 組織の社会的責任）を果たしていることを明確に示せる。

規模

成果物ベースの計画立案という原則は不変だが、計画に投じる労力や詳細度は、プロジェクトの特徴とニーズに基づいて柔軟に調整する

1. 規模を左右する側面

   側面	計画への影響と対応策
   期間	長期化するほど内外の変化への適応が不可欠となる。複数年にわたる場合は、メンバーの離職や交代（PM 含む）を想定し、継続性を担保する計画書が必要。
   チームサイズ	大規模・分散型チームでは、より手厚いプロジェクト支援が必要。共通のツールや文書への容易なアクセスが、チームの生産性を左右する。
   複雑性	成果物や作業単位（WP）が多岐にわたる場合、スライドやリストのみの管理は限界がある。専用のスケジューリング・ツールによる変更分析が有効。
   新規性	組織にとって未経験の分野では、見積もりの不確実性が高まる。プロトタイピングによるリスク軽減や、反復的なアプローチの採用を検討する。
   コスト	計画立案は失敗のリスクを低減する投資である。計画立案コストはプロジェクト総予算の10%を超える場合もあり、プロジェクトの重要性に見合った労力を投入する。

2. 計画の最適化（テーラリング）
   • スモール・プロジェクト:
     • スケジュールは「主要マイルストーンのリスト」程度に簡略化。
     • ツールは汎用的な文書作成ソフトやプレゼン資料で対応可能。
   • ラージ・プロジェクト:
     • 変更予算（バッファ）を詳細に見積もり、環境変化に備える。
     • 専用のプロジェクト管理ソフトウェアを導入し、複雑な依存関係やリソース競合を自動計算・可視化する。
3. マネジメント上の重要性
   • リスクとコストのバランス: 計画立案の労力がプロジェクト全体のコストや重要性と釣り合っていることを確保する。過剰な計画はスピードを削ぎ、過少な計画は失敗を招く。
   • 離職への備え: 長期プロジェクトにおける計画書の準備は、単なる進捗管理だけでなく、将来の担当者変更時における**知の継承（ナレッジ・トランスファー）**の役割も果たす。

マネジメント成果物

アウトプット

計画書

• 目的: プロジェクト全体（またはその活動のサブセット）の何を、どこで、いつ、どのように、誰が実施するかを概説する提案を提供する。承認された計画は、進歩状況を測定し、課題を評価するベースラインを提供する。
• コンテンツ概要
  • スコープ: 計画書のスコープ（プロジェクト、ステージ、チーム、例外）の説明
  • 依存関係: 計画が依存している外部成果物または活動
  • 計画立案の前提条件と必須条件: 計画のベースになる前提条件と、計画を成功させるために確立または維持する必要がある基本的な側面
  • 参照した教訓: 過去の類似したプロジェクトからの関連する教訓の詳細。レビューされた後、この計画書に組み込まれる
  • 提供される成果物: 計画のスコープに含まれる成果物ブレークダウン・ストラクチャー、成果物流れ図、成果物記述書
  • 実施する作業: ワーク・ブレークダウン・ストラクチャーと関連するワーク・パッケージ記述書によって示される、計画のスコープ内で実施する作業
  • 予算: プロジェクトのコスト（リスク予算、変更予算など）
  • スケジュール: プロジェクトのステージと活動、その期間、および順序の図示（ガント・チャートなど）
  • ターゲットと許容度: 計画レベルでのスコープ、コスト、時間の許容される偏差。ステージ計画書とチーム計画書には、持続可能性とリスク許容度が含まれる場合もある
  • モニタリング、コントロール、および報告の取り決め: プロジェクトをモニタリングし、コントロールする方法と、報告の手順と責任についての説明

プロジェクト成果物記述書

• 目的: プロジェクトの主要成果物と意図した目的について、プロジェクトに対するユーザーの期待品質、受け入れ基準、受け入れ手法を含めて記述する。これはプロジェクトの始動プロセスで作成し、プロジェクトの立ち上げプロセス中に詳細化する。
• コンテンツ概要
  • 目的: プロジェクト成果物が果たす目的と、プロジェクト成果物を使用する人員の説明
  • 主要成果物: 提供される主要成果物の説明
  • 派生: 既存の成果物または新しい能力の要件など、成果物のベースになっているもの
  • ユーザーの期待品質: プロジェクト成果物に期待される品質と、その品質を達成するために適用すべき標準および手順の説明
  • 受け入れ基準: ユーザーに受け入れてもらうために満たす必要のあるプロジェクト成果物の優先順位を付けたリスト
  • 受け入れ手法と責任: 受け入れを確認する手段と、受け入れを決定する実行責任者
  • プロジェクト・レベルの品質許容度: 受け入れ基準に適用する許容度

ワーク・パッケージ記述書

• 目的: 1つまたは複数の成果物を作成して提供する方法を記述する。これは作業の責任をPMまたはチーム・メンバーに正式に引き継ぐために使用される。
• コンテンツ概要
  • 実施する作業の記述書: 作業指示書および関連するワーク・ブレークダウン・ストラクチャー
  • チーム・マネージャーまたは認可された人: チーム・マネージャーまたはワーク・パッケージの実行責任者の名前
  • 成果物記述書: ワーク・パッケージに関連付けられている成果物の記述
  • 技法と手順: 実施する作業方法の要件
  • 変更コントロールの要件: ワーク・パッケージのスコープ内にあるプロジェクトおよび成果物ベースラインをコントロールするための取り決め
  • 制約: 認可された労働時間、安全性、セキュリティ対策など、作業に対する制限または許容範囲
  • モニタリング、コントロール、報告: ワーク・パッケージのモニタリング、コントロール、報告方法の説明
  • ターゲットと許容度: ワーク・パッケージのスコープ、コスト、時間の許容される偏差
  • 参照: より概要での計画書からの適用可能な参照
  • 承認: 完成した成果物を承認する担当者
  • 合意: プロジェクト・マネージャーおよびチーム・マネージャー間でのワーク・パッケージの初期認可と最終完了のレコード

主要な役割

役割	責任
ビジネス・レイヤー	ビジネス・レイヤーの責任
プロジェクト・エグゼクティブ	プロジェクト・エグゼクティブの責任
シニア・ユーザー	シニア・ユーザーの責任
シニア・サプライヤー	シニア・サプライヤーの責任
プロジェクト・マネージャー	プロジェクト・マネージャーの責任
チーム・マネージャー	チーム・マネージャーの責任
プロジェクト保証	プロジェクト保証の責任
プロジェクト支援	プロジェクト支援の責任

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

• プロジェクト許容度を設定してプロジェクト権限委任で文書化するか、プロジェクト委員会に確認してプロジェクト要約書に含める
• プロジェクト・レベルの許容度を超えると予測される場合、例外計画書を承認する
• ビジネスに必要な計画基準を提供する

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

• プロジェクト計画書を承認する
• 各ステージの許容度を設定し、ステージ計画書を承認する
• ステージ・レベルの許容度を超えると予測される場合、例外計画書を承認する
• ステージ計画書に人とビジネス・リソースをコミットする（財務チームやシステムなど）

シニアユーザーの責任

• プロジェクト・マネージャーが、プロジェクト計画書とステージ計画書を準備するときに助言と支援をする
• ユーザーの観点で、プロジェクト計画書とステージ計画書に一貫性があることを確認する
• ステージ計画書に人、ユーザー・リソースをコミットする（トレーニング、テスト、テスト環境の運用スタッフなど）

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

• プロジェクト・マネージャーがプロジェクト計画書、ステージ計画書、ワーク・パッケージ記述書を作成するときに助言と支援をする
• サプライヤーの観点で、プロジェクト計画書とステージ計画書に一貫性があることを確認する
• ステージ計画書に人とサプライヤー・リソースをコミットする（開発者や機械など）

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

• 計画書を設計する
• プロジェクト計画書、ステージ計画書、ワーク・パッケージ記述書を準備し、必要に応じて更新する
• ステージとデリバリー・ステップをどのように適用するかを決定する
• ワーク・パッケージ・レベルの許容度を超えると予測される場合、是正処置を指示する
• 例外報告書に関するプロジェクト委員会の決定に応じて例外計画書を準備する

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

• プロジェクト・マネージャーがワーク・パッケージ記述書を作成するのを支援する
• チーム計画書を準備する
• 各ワーク・パッケージに対するスケジュールを準備する

プロジェクト保証の責任

• 合意されたターゲットとその許容度に対するステージ計画書およびプロジェクト計画書の実行可能性をレビューする
• ビジネス・ニーズへのインパクトがあるか、あるいはプロジェクトのビジネス・ケースへのインパクトがあるかを判断するために、プロジェクト計画書の変更をレビューする

プロジェクト支援の責任

• プロジェクト計画書、ステージ計画書、ワーク・パッケージ記述書、チーム計画書の編集を支援する
• 専門知識（計画立案ツールなど）を提供する
• プロジェクト計画書、ステージ計画書、チーム計画書、ワーク・パッケージ記述書を、ベースライン化し、保管、配布する