プロジェクト変更要求のプレゼン：範囲・費用・判断事項を整理する

プロジェクトの変更要求を説明するプレゼンでは、承認済み計画と変更案の差を示します。現在の約束事項、追加したい内容、その影響、選択肢を判断者に伝えましょう。最新のスライドに載っているだけで、新しい要件が承認されたことにはなりません。

関係する担当者と影響の見積もりを確認できたら、Presentiで変更要求の原稿をスライドの下書きに整理できます。入力には、前提条件と承認状況も含めます。これらは要求の一部であり、要約時に省いてよい細部ではありません。

承認済みの計画を最初に示す

社内予約システムの試験運用を準備するチームを考えてみましょう。合意済みの範囲は、予約フォーム、確認メール、週次の利用状況レポートです。試験運用の開始は第6週末、承認済み予算は40,000米ドルとします。ここでスポンサーから、開始前にシングルサインオンを追加したいという依頼がありました。

この例で使う計画数値はすべて架空です。チームの見積もりは説明用の前提であり、実際の連携開発の価格や納期を約束するものではありません。

最初のスライドでは、すでに約束している内容と、新たに求められている内容を示します。対象範囲の横に、基準となる計画の版や承認記録の参照先を付け、参加者が確認できるようにします。現行計画がすでに変わっているなら、新しい提案と比べる前に記録の整合を取ってください。

Microsoftのプロジェクト変更評価ガイド（英語）では、要件、資金、日程への影響と、承認に必要な権限を扱っています。資料は実際のプロジェクトの承認ルールに従って作ります。一般的なテンプレートでは、誰が承認権限を持つかは決まりません。

新しい合計だけでなく、増分を示す

この例では、技術担当責任者がシングルサインオンの追加に、承認済み予算とは別に8,000米ドル、現在の日程に加えて10営業日が必要と見積もったとします。認証設定、テストアカウント、レビュー担当者の時間を、必要な時点で確保できることが前提です。見積もりのすぐ横に、この条件を記します。

追加額は8,000 ÷ 40,000で、当初予算の20%です。この割合は判断材料であって、自動的な承認基準ではありません。また、作業量の見積もりが10日だからといって、開始も必ず10日遅れるわけではありません。この例では、追加作業によって開始までの工程が延びると明示しています。実際の計画では、日程への影響を裏付ける依存関係と稼働余力を示してください。

チームから示されているのが作業期間と未確定の前提だけなら、正確な開始日まで決まったように書くのは避けます。実際の日付が必要な場合は、日程担当者とプロジェクトの稼働カレンダーで計算します。

実際に承認できる選択肢を並べる

「採用か却下か」の二択では、有用な中間案を見落とすことがあります。この要求では、次の三つを同じ基準で比較します。

三つ目の案が、自動的に「同じ予算、同じ日程」になるわけではありません。レポートを一つ削っても、その担当者や時間を連携開発へ移せるとは限りません。見積もっていない案は未見積もりとし、有力な選択肢なら影響の確認を依頼します。

二つ目の案にも条件が必要です。新しい要件が試験運用を行うための必須条件なら、後回しにできない可能性があります。都合はよくても実行できない選択肢を表に残すのではなく、その制約を明示しましょう。

変更要求を6枚で説明する構成

1. 求める判断。 変更内容、推奨案、判断が必要な期限を示します。
2. 現在の約束事項。 承認済みの対象範囲、予算、節目となる日程を、基準計画の参照先とともに示します。
3. 要求の理由。 誰が変更を必要としているか、延期すると何が起きるかを説明します。必須要件と希望を分けます。
4. 影響。 増える費用、期間、作業、依存条件を示し、各見積もりの担当責任者を明記します。
5. 代替案。 実行可能な選択肢と、それぞれの未解決事項を比較します。
6. 判断の記録。 実際の判断、条件、判断者、日付を記入する欄を用意します。

技術設計の詳細と見積もりの内訳は付録に置きます。すべての作業を点検しなくても、承認者が影響を理解できる流れにしてください。一般的なロードマップの既存作業に新要件を埋め込むより、変更前後の対象範囲を比べる方が分かりやすい場合があります。

会議中の不確実性や追加情報を扱う

会議中に依存条件が変わったら、推奨案のどの部分に影響するかを示します。例えば、テストアカウントを用意できないなら、10日の延長という見積もりが成り立たなくなるかもしれません。古くなった数値を守ろうとせず、再見積もりが必要だと記録します。

条件付きの判断も具体的に書きます。「技術担当責任者が見積もりを確認し、スポンサーが追加予算を承認した場合に進める」は、「承認済み」とは異なります。両方を同じ緑色で表示したり、最後のスライドから条件を削ったりしないでください。

会議後は、議論した版の変更要求を保存し、判断記録と結び付けます。実行計画の更新は、プロジェクトで合意した変更手続きを通して行います。プレゼン資料を書き換えただけでは、どの範囲、日程、予算が正式なものかはチームに伝わりません。

承認状況を保った原稿で下書きする

確認済みの原稿をPresentiに貼り付け、編集可能なスライドの下書きに整理します。基準計画、見積もり、前提条件を入力に含めてください。「変更要求」というテーマだけでは、判断に必要な材料があまりに不足します。

架空の社内予約システムの試験運用について、変更要求を説明する6枚のプレゼン資料を作成してください。承認済みの範囲は予約フォーム、確認メール、週次の利用状況レポートです。承認済み予算は40,000米ドル、開始予定は第6週末です。追加要求は、試験運用開始前のシングルサインオン導入です。技術担当責任者の見積もりは追加費用8,000米ドルと、開始までの工程を延ばす10営業日です。認証設定、テストアカウント、レビュー担当者の時間を確保できることが前提です。この例に限り、祝日のない週5日稼働として計算します。今すぐ追加する案、現行の試験運用を維持して後続リリースを検討する案、新たな見積もりを条件に対象範囲を入れ替える案を比較してください。未見積もりの入れ替え案に費用や日付を付けないでください。必須要件、前提条件、承認条件を明示します。実際の判断と承認者の欄は空欄とし、承認を作らないでください。

下書きを確認するときは、小さな意味の変化に注意します。「見積もり」が「確定」に、条件付きの選択肢が約束に、空欄の判断が承認に変わっていないでしょうか。こうした確認は、テーマの選択より重要です。元の約束事項を保ちながら、変更要求を判断しやすい資料に仕上げましょう。