→スコープを縮小し、スケジュールをクラッシュする。
クラッシング、ファスト・トラッキング、変更管理、およびその他の手法ではタイムフレームを短縮することでリスクが増大し、課題が発生する可能性が高いため、スポンサーおよび主要なステークホルダーでプロジェクトの要求事項を削減できる場合は、それが望ましい選択肢です。
答えの解説
- スコープ縮小とクラッシングを同時に行うと、短期間で大きな変更が発生し、品質低下・コスト増加・リスク増大の可能性が高くなります。
- プロジェクト短縮の要求が出た場合は、いきなりリスクの高い圧縮策を取らず、まずは要求事項の再交渉や安全なスケジュール調整を検討するのが望ましい。
他の選択肢が答えでない理由
- a. チーム・メンバーを追加する
→ クラッシングの一部ではあるが、単体での資源追加はリスクが比較的低く、短縮策として検討可能。 - b. タイムラインを修正しないようアドバイスする
→ 要望を無視するのは適切ではないため、変更の可否は検討すべき。 - c. 要求事項削減を交渉する
→ スコープ調整による短縮は、リスクを抑えつつ対応できる可能性が高い。
むしろ短縮を依頼されているのに対して「タイムラインを修正しないようアドバイスする。」は実施すべきではないのでは？
ChatGPT:
そうですね、その視点はかなり妥当です。
ステークホルダーから短縮の要望が出ている状況で
「タイムラインを修正しないようアドバイスする」 というのは、
- 要望を即座に却下しているように見える
- 調整や代替策の検討をせずに現状維持を押し通す形になる
- ステークホルダー・エンゲージメントや信頼関係を損なう可能性が高い
といった理由から、PMI的にも「実施すべきではない」行動になります。
ただ今回の問題文の正答が「スコープを縮小し、スケジュールをクラッシュする」だったのは、
リスクが非常に高い行為を、十分な検討や合意なしにいきなり実施することはNG という観点で選ばれているのだと思います。
まとめると：
- 「タイムラインを修正しないようアドバイス」 → ステークホルダー要求を無視してしまうリスクが高い
- 「スコープ縮小＋クラッシング」 → 実行自体は可能だが、最終手段であり慎重な評価と合意が必要
なので、実務的には前者も後者もそのまま実施は望ましくなく、
試験問題では「どちらがよりNGか」を問うているようなニュアンスです。
PMI提供 クローン問題（ウォーターフォール型５）3
コメント