スコープクリープ：受注後のプロジェクト採算を守る

提案が承認され、作業が始まりました。その後、顧客から成果物の追加、レビューの追加、元の指示の小さな変更を求められます。一つひとつは妥当に見えても、重なると採算の合う案件が、チームの過負荷と期待外れの結果に変わりかねません。

サービス企業では、スコープクリープを毎週の事業上の話し合いに含める必要があります。目指すのは、必要な負担を共有したうえで意図的に変更することです。

依頼を判断する前に作業を定義する

実務で使える提供の基準から始めます。合意した成果、納品物、前提、顧客の提供資料、レビュー回数、受入基準です。遂行チームが完成の状態を説明できなければ、長い提案書も十分に役立ちません。

営業から遂行へ引き継ぐ際、三つを尋ねます。顧客は何を買ったのか。顧客は何を提供する必要があるか。未決定事項は何か。

答えをプロジェクトの作業場所に記録します。営業時の約束も含め、制作途中で初めて知ることがないようにします。

すべての修正がスコープクリープではありません。合意要件を満たさない成果物を直すことと、新しい要件を加えることは異なります。

シンプルに分類します。

明確化にも注意が必要です。曖昧さが繰り返されるなら、指示をまとめる過程に弱点があるかもしれません。自動的に無償作業とも有償追加とも扱わないでください。

PMIの1996年の範囲変更管理に関する記事は、合意した基準、変更の記録、明確な意思疎通の価値を説明しています。これは新しい動向の証拠ではなく、長く使える管理原則です。

有用な変更手順は一枚にまとめられます。依頼、目的、必要とする人、実施しない場合の影響を記録し、工数、対応余力、依存関係、納期、料金への影響を評価します。

調整、テスト、追加承認、他の成果物の更新など、見落としやすい作業も含めます。新しいプレゼン形式には、新たな品質確認や別の承認順序が必要かもしれません。

依頼の担当者と判断日を設定します。事業上の判断待ちの作業が、誰かのタスク一覧に埋もれないようにします。

回答は単なる拒否でなくても構いません。実行可能な選択肢を示します。

各選択肢の影響を分かりやすく示します。「追加ワークショップを含める場合、最終提言は翌週にお届けできます」のように具体化すると、顧客も判断しやすくなります。

追加作業の前に選択を合意し、共通計画を更新します。遂行チームと顧客が同じ判断を基に動く必要があります。

変更予算は、予想される不確実性に備える内部計画上の余裕です。少量の追加工数や一定の予備枠を含められます。案件ごとに設定し、万能な比率はないと考えてください。

何に使ったかを追います。余裕枠で指示、見積もり、承認の反復的な不備を隠してはいけません。

仮想例： サービス案件の料金がUSD 12,000、予定提供費用がUSD 8,000とします。追加依頼にUSD 1,000の提供費用がかかります。料金と他の条件が変わらなければ、これらの提供費用を引いた残額はUSD 4,000からUSD 3,000へ減ります。

それでも自社負担を選ぶことはあります。重要なのは、対応余力と顧客価値とともに選択を見えるようにすることです。数字は他の間接費控除前のプロジェクト貢献を示す例で、予測ではありません。

営業責任者と遂行責任者で短く週次確認を行います。未完了の変更、合意待ちの判断、予定外工数、まもなく必要な顧客資料を見ます。

各依頼を誰が顧客と話すか、待つ間に何を進められるか、計画が合意作業と一致しているかの三つを解決します。

終了時には原因を振り返ります。レビュー追加が繰り返されるなら提案と承認を改善します。顧客資料が遅れるなら依存条件を明確にし、営業の約束が遂行前提を超えるなら引き継ぎを修正します。

こうして事業成長と変革を日々の遂行判断につなげます。仕事がどう入るか、誰がトレードオフを担うか、追加売上が価値ある仕事になるかを確認するのです。

追加依頼の多い案件を選びます。合意した基準と現在の作業を比べ、未解決の変更を特定し、一枚の判断記録を導入します。

自社が販売した内容と、チームが提供している内容の隔たりについてZendralにご相談ください。一つの案件と最近の変更を用意し、具体的な業務課題から話を始めましょう。