セクション: ボリューム A

セクション: ボリューム E
Explanation:
5.4.2.1 分解
分解は、プロジェクトの範囲とプロジェクトの成果物をより小さく、より管理しやすい部分に分割および細分化するために使用される手法です。ワーク パッケージは、WBS の最下位レベルで定義された作業であり、コストと期間を見積もって管理することができます。分解のレベルは、多くの場合、プロジェクトを効果的に管理するために必要な制御の程度によって決まります。ワーク パッケージの詳細レベルは、プロジェクトのサイズと複雑さによって異なります。プロジェクト作業全体を作業パッケージに分解するには、通常、次のアクティビティが必要です。
成果物と関連作業の特定と分析。

WBS の構造化と組織化。

上位の WBS レベルを下位レベルの詳細コンポーネントに分解します。

識別コードを開発し、WBS コンポーネントに割り当てます。と

成果物の分解の程度が適切であることの検証。

6.2.2.2 ローリングウェーブ計画
ローリング ウェーブ計画は、短期的に達成される作業を詳細に計画し、将来の作業をより高いレベルで計画する反復計画手法です。これは漸進的な精緻化の形式です。
したがって、プロジェクト ライフ サイクルのどこにあるかに応じて、さまざまな詳細レベルで作業が存在する可能性があります。戦略計画の初期段階で情報があまり定義されていない場合、作業パッケージは既知の詳細レベルに分解されることがあります。近い将来に予定されているイベントについてより多くのことが知られているため、作業パッケージをアクティビティに分解できます。
プロセス: 6.2 活動を定義する
定義: プロジェクトの成果物を作成するために実行する特定のアクションを特定し、文書化するプロセス。
主な利点: このプロセスの主な利点は、作業パッケージを、プロジェクト作業の見積もり、スケジューリング、実行、監視、および制御の基礎となるアクティビティに分割できることです。
入力
1.スケジュール管理計画
2. スコープのベースライン
3. 企業の環境要因
4. 組織プロセス資産
ツールとテクニック
1.分解
2. ローリングウェーブ計画
3.専門家の判断
出力
1. 活動一覧
2. 活動属性
3.マイルストーン一覧

セクション: ボリューム B
Explanation:
12.1.3.1 調達管理計画
調達管理計画は、プロジェクト チームが実行組織の外部から商品やサービスを取得する方法を説明するプロジェクト管理計画の構成要素です。調達文書の作成から契約の締結まで、調達プロセスがどのように管理されるかについて説明します。
調達管理計画には、次のガイダンスを含めることができます。
使用する契約の種類。

リスク管理の問題;

独立した見積もりが使用されるかどうか、および評価基準として必要かどうか。

プロジェクト管理チームが一方的に実行できるアクション。

所定の調達、契約、または購買部門。
必要に応じて、標準化された調達文書。

複数のサプライヤーの管理;

スケジューリングや実績報告など、他のプロジェクトの側面と調達を調整する。

計画された調達に影響を与える可能性のある制約と仮定。

売り手から特定のアイテムを購入するための長いリードタイムを処理し、必要な余分な時間を調整します

プロジェクト スケジュールの作成に合わせてこれらのアイテムを調達します。
作るか買うかの決定を処理し、それらを見積もり活動リソースと開発にリンクする

プロセスのスケジュール
契約成果物の各契約における予定日の設定とスケジュールの調整

開発および管理プロセス;
ある種のプロジェクトを軽減するためのパフォーマンス ボンドまたは保険契約の要件の特定

危険;
作業の内訳の開発と維持に関して売り手に提供される方向性の確立

構造 (WBS);
調達/契約作業明細書に使用するフォームとフォーマットを確立する;

事前に認定された販売者がいる場合は、その販売者を特定します。と

契約の管理と販売者の評価に使用される調達指標。

調達管理計画は、公式または非公式にすることができ、非常に詳細または大まかに構成することができ、各プロジェクトのニーズに基づいています。

解説・参考：
Explanation:
プロセス: 4.1. プロジェクト憲章の作成
定義: プロジェクトの存在を正式に承認し、プロジェクト マネージャに組織のリソースをプロジェクト活動に適用する権限を与える文書を作成するプロセス。
主な利点: このプロセスの主な利点は、明確に定義されたプロジェクトの開始とプロジェクトの境界、プロジェクトの正式な記録の作成、および上級管理職がプロジェクトを正式に受け入れてコミットするための直接的な方法です。
入力
1. プロジェクト作業明細書
2. ビジネスケース
3. 契約
4. 企業の環境要因
5. 組織プロセス資産
ツールとテクニック
1.専門家の判断
2. ファシリテーション テクニック
出力
1. プロジェクト憲章
4.1.1.2 ビジネスケース
ビジネス ケースまたは同様のドキュメントには、プロジェクトが必要な投資に見合うかどうかを判断するために、ビジネスの観点から必要な情報が記載されています。これは、プロジェクト レベルより上のマネージャまたはエグゼクティブによる意思決定に一般的に使用されます。通常、ビジネス ニーズと費用便益分析は、プロジェクトの境界を正当化し、確立するためにビジネス ケースに含まれます。このような分析は通常、さまざまな利害関係者の情報を使用してビジネス アナリストによって完了されます。スポンサーは、ビジネス ケースの範囲と制限に同意する必要があります。ビジネス ケースは、次の 1 つ以上の結果として作成されます。
市場の需要 (例: 自動車会社が、より燃費の良い自動車を製造するプロジェクトを認可する。

ガソリン不足）、
組織の必要性 (例: 間接費が高いため、企業はスタッフ機能と

プロセスを合理化してコストを削減します。)、
顧客の要求 (例: 電力会社が、新しい変電所を建設して新しい電力を供給するプロジェクトを承認する)

工業団地）、
技術の進歩 (例: 航空会社が新しいプロジェクトを承認して、電子チケットを開発する代わりに

技術の進歩に基づく紙のチケット）、
法的要件 (例: 取り扱いのガイドラインを確立するプロジェクトを認可する塗料メーカー)

有毒物質)、
生態系への影響 (例: 環境への影響を軽減するためにプロジェクトを承認する企業)、または

社会的必要性（例えば、開発途上国の非政府組織が、

高率のコレラに苦しんでいるコミュニティに飲料水システム、トイレ、および衛生教育を提供します)。
このリストの各例には、対処すべきリスクの要素が含まれている場合があります。マルチフェーズ プロジェクトの場合、ビジネス ケースを定期的にレビューして、プロジェクトが順調に進んでビジネス上の利益をもたらすことを確認します。プロジェクト ライフ サイクルの初期段階では、スポンサー組織によるビジネス ケースの定期的なレビューも、プロジェクトがまだビジネス ケースと整合していることを確認するのに役立ちます。プロジェクト マネージャーは、ビジネス ケースで定義されているように、プロジェクトが組織の目標と幅広い利害関係者の要件を効果的かつ効率的に満たすようにする責任があります。