セクション：ボリュームE

セクション：ボリュームC
Explanation:
1.4.4プロジェクト管理事務所
プロジェクト管理オフィス（PMO）は、プロジェクト関連のガバナンスプロセスを標準化し、リソース、方法論、ツール、および手法の共有を容易にする管理構造です。PMOの責任は、プロジェクト管理サポート機能の提供から、1つ以上のプロジェクトの直接管理を実際に担当することまで多岐にわたります。
組織にはいくつかのタイプのPMO構造があり、それぞれが組織内のプロジェクトに対する制御と影響の程度が異なります。たとえば、次のようなものです。
協力的。支援的なPMOは、テンプレート、ベストプラクティス、

トレーニング、情報へのアクセス、他のプロジェクトから学んだ教訓。このタイプのPMOは、プロジェクトリポジトリとして機能します。PMOによって提供される制御の程度は低いです。
制御。PMOの制御はサポートを提供し、さまざまな手段によるコンプライアンスを必要とします。

コンプライアンスには、特定のプロジェクト管理フレームワークまたは方法論の採用が含まれる場合があります

テンプレート、フォーム、ツール、またはガバナンスへの準拠。PMOによって提供される制御の程度は中程度です。
指令。ディレクティブPMOは、プロジェクトを直接管理することによってプロジェクトを制御します。の程度

PMOによって提供される制御は高いです。
PMOは、企業の戦略プロジェクトからのデータと情報を統合し、より高いレベルの戦略目標がどのように達成されているかを評価します。PMOは、組織のポートフォリオ、プログラム、プロジェクト、および企業の測定システム（バランススコアカードなど）の間の自然な連絡窓口です。
PMOによってサポートまたは管理されているプロジェクトは、一緒に管理されている場合を除いて、関連していない場合があります。
PMOの特定の形式、機能、および構造は、PMOがサポートする組織のニーズによって異なります。
PMOは、各プロジェクトの存続期間を通じて、不可欠な利害関係者および主要な意思決定者として行動し、ビジネス目標との整合性を維持するために、必要に応じて、推奨事項を作成したり、プロジェクトを終了したり、その他のアクションを実行したりする権限を持っている場合があります。さらに、PMOは、共有または専用のプロジェクトリソースの選択、管理、および展開に関与する場合があります。
PMOの主な機能は、以下を含むがこれらに限定されないさまざまな方法でプロジェクトマネージャーをサポートすることです。
PMOが管理するすべてのプロジェクトで共有リソースを管理する。

プロジェクト管理の方法論、ベストプラクティス、および標準を特定して開発する。

コーチング、メンタリング、トレーニング、および監視。

プロジェクト管理の標準、ポリシー、手順、およびテンプレートへの準拠を監視する

プロジェクト監査;
プロジェクトのポリシー、手順、テンプレート、およびその他の共有ドキュメントの開発と管理

（組織プロセス資産）;
と
プロジェクト間のコミュニケーションを調整します。

プロジェクトマネージャーとPMOは異なる目的を追求し、そのため、異なる要件によって推進されます。これらの取り組みはすべて、組織の戦略的ニーズに沿ったものです。プロジェクトマネージャーとPMOの役割の違いには、次のようなものがあります。
プロジェクトマネージャーは指定されたプロジェクトの目的に焦点を合わせ、PMOは主要なプログラムを管理します

スコープの変更。これは、ビジネス目標をより適切に達成するための潜在的な機会と見なされる場合があります。
プロジェクトマネージャーは、割り当てられたプロジェクトリソースを制御して、プロジェクトの目標を最もよく満たすようにします。

すべてのプロジェクトで共有される組織リソースの使用を最適化します。
プロジェクトマネージャーは、個々のプロジェクトの制約（範囲、スケジュール、コスト、品質など）を管理します。

PMOは、方法論、標準、全体的なリスク/機会、メトリック、および企業レベルでのプロジェクト間の相互依存性を管理します。

セクション：ボリュームE
Explanation:
11.5.2.1負のリスクまたは脅威に対する戦略
プロジェクトの目的が発生した場合に悪影響を与える可能性のある脅威またはリスクに通常対処する3つの戦略は、回避、転送、および軽減です。4番目の戦略であるacceptは、負のリスクまたは脅威だけでなく、正のリスクまたは機会にも使用できます。これらのリスク対応戦略​​はそれぞれ、リスク条件にさまざまな独自の影響を及ぼしています。これらの戦略は、リスクの確率とプロジェクトの全体的な目的への影響に一致するように選択する必要があります。回避と軽減の戦略は、通常、影響が大きい重大なリスクに対する優れた戦略ですが、転移と受け入れは、通常、重大度が低く、全体的な影響が少ない脅威に対する優れた戦略です。負のリスクまたは脅威に対処するための4つの戦略は、次のようにさらに説明されます。
避ける。リスク回避は、プロジェクトチームが脅威を排除するために行動する、または

プロジェクトをその影響から保護します。通常、脅威を完全に排除するためにプロジェクト管理計画を変更する必要があります。プロジェクトマネージャーは、プロジェクトの目的をリスクの影響から分離したり、危険にさらされている目的を変更したりする場合もあります。この例には、スケジュールの延長、戦略の変更、または範囲の縮小が含まれます。最も根本的な回避戦略は、プロジェクトを完全にシャットダウンすることです。プロジェクトの初期に発生するリスクの中には、要件を明確にしたり、情報を入手したり、コミュニケーションを改善したり、専門知識を習得したりすることで回避できるものがあります。
移行。リスク移転は、プロジェクトチームが脅威の影響をシフトするリスク対応戦略​​です。

応答の所有権とともに、第三者に。リスクを移転することは、単にその管理に対する他の当事者の責任を与えるだけであり、それはそれを排除するものではありません。譲渡とは、リスクを後のプロジェクトまたは他の人に知らないうちに譲渡することによってリスクを勘当することを意味するものではありません。リスク移転には、ほとんどの場合、リスクを負う当事者へのリスクプレミアムの支払いが含まれます。リスクに対する責任の移転は、財務リスクのエクスポージャーに対処する上で最も効果的です。移転ツールは非常に多様であり、保険、履行保証、保証、保証などの使用が含まれますが、これらに限定されません。特定のリスクに対する責任を他の当事者に移転するために契約または合意が使用される場合があります。たとえば、買い手が売り手が持っていない機能を持っている場合、一部の作業とその同時リスクを契約上購入者に戻すことが賢明な場合があります。多くの場合、原価プラス契約を使用すると、コストリスクが買い手に移転する可能性がありますが、固定価格契約を使用すると、リスクが売り手に移転する可能性があります。
軽減する。リスク軽減は、プロジェクトチームが確率を下げるために行動するリスク対応戦略​​です。

リスクの発生または影響の。これは、不利なリスクの確率および/または影響が許容可能なしきい値の範囲内に収まるように減少することを意味します。プロジェクトで発生するリスクの可能性や影響を減らすために早期の行動を取ることは、リスクが発生した後に損傷を修復しようとするよりも効果的であることがよくあります。より複雑でないプロセスを採用する、より多くのテストを実施する、またはより安定したサプライヤーを選択することは、緩和措置の例です。緩和策では、プロセスまたは製品のベンチスケールモデルからスケールアップするリスクを軽減するために、プロトタイプの開発が必要になる場合があります。確率を下げることができない場合、緩和対応は、重大度を決定するリンケージをターゲットにすることによってリスクへの影響に対処する可能性があります。たとえば、システムに冗長性を設計することで、元のコンポーネントの障害による影響を減らすことができます。
承認。リスク受け入れは、プロジェクトチームが承認することを決定するリスク対応戦略​​です。

リスクがあり、リスクが発生しない限り、何の行動も取らないでください。この戦略は、他の方法で特定のリスクに対処することが不可能または費用効果が高い場合に採用されます。この戦略は、プロジェクトチームがリスクに対処するためにプロジェクト管理計画を変更しないことを決定したか、他の適切な対応戦略を特定できないことを示しています。この戦略は、パッシブまたはアクティブのいずれかになります。受動的な受け入れには、戦略を文書化する以外のアクションは必要ありません。プロジェクトチームは、発生したリスクに対処し、脅威が大幅に変化しないように定期的に確認します。最も一般的な積極的な受け入れ戦略は、リスクを処理するための時間、お金、またはリソースの量を含む、予備費を確立することです。

セクション：ボリュームE