スコープ クリープとは、時間、予算、リソースの変更が承認されずに、プロジェクト要件が制御されずに拡大することです。明確な範囲のベースライン、取り込みログ、影響分析、名前付き承認権限、および変更が承認された後にのみスケジュールを更新することで、これを防止します。
スコープ クリープとは何ですか?
スコープ クリープとは、時間、予算、リソースの調整が承認されずに、作業開始後にプロジェクト要件が制御されずに拡大することです。 新しい要件が自動的にスコープ クリープになるわけではありません。チームが非公式に受け入れたり、誰が承認したか追跡できなかったり、下流コストを黙って吸収したりすると、スコープクリープになります。
実践的な防御は「決して変わらない」ことではありません。証拠、規制、リスク、顧客価値が変化した場合、プロジェクトも変更する必要があります。防御は、リクエスト→影響分析→決定→更新されたベースラインとスケジュールという、短くて目に見えるパスです。
スコープ クリープは通常のスコープ変更とどう違うのですか?
管理対象範囲の変更は明示的、評価、承認、資金提供、および記録されます。スコープ クリープは、その制御なしでプロジェクトに入ります。 金メッキはまた異なります。配信チームは、有益だと思われるため、要求されていない作業を追加します。機能クリープは、承認の有無にかかわらず、追加によって蓄積される製品の複雑さを表します。
| 期間 | それが何を意味するか | 代表的な開始剤 | 正式に承認されましたか? | 正常な応答 |
|---|---|---|---|---|
| スコープクリープ | トレードオフが一致しないまま、合意されたベースラインを超えて作業が拡大する | 関係者またはチームメンバー | いいえ、または承認があいまいです | 停止、記録、評価、決定 |
| 制御されたスコープの変更 | 承認された範囲が意図的に変更されている | スポンサー、顧客、規制当局、またはチーム | はい | 範囲、コスト、スケジュール、コミュニケーションを更新する |
| 金メッキ | チームはリクエストされていない追加機能を追加します | 配送チーム | 通常はありません | 削除するか、変更として送信します |
| フィーチャークリープ | 製品には機能と複雑さが蓄積されます | 製品、販売、顧客、またはエンジニアリング | 時々 | 成果、価値、ライフサイクルコストを再確認する |
| 発見 | 新しい事実により、提供すべき内容が洗練される | 研究チームまたは提供チーム | まだ | 発見が明確化なのか変更なのかを決定する |
米国エネルギー省のプロジェクト管理用語集では、スコープ ベースラインを、承認されたスコープ ステートメント、作業分解構造、および WBS ディクショナリとして定義しています。これは、変更管理を、承認されたベースラインに対する変更を特定、レビュー、承認、実装、テスト、および文書化するプロセスとして定義します。これら 2 つの定義は問題の核心を明らかにします。ベースラインがなければ、チームは何かが変化したことを証明できません。
スコープクリープの原因は何ですか?
スコープ クリープは通常、1 人の難しい利害関係者からではなく、弱い境界と弱い決定から発生します。 最も一般的な原因は次のとおりです。
- あいまいな成果物。 「レポート作成」は、経営幹部、アナリスト、エンジニアにとって意味が異なります。
- 受け入れ基準が欠落しています。 要求された結果がいつ完了するかは誰にもわかりません。
- 非公式の受け入れ リクエストは会議、チャット、電子メールで届きますが、ログには記録されません。
- 指名された承認者はいません。 人々は会議への熱意が承認と同等であると考えます。
- 隠れた依存関係 2 時間の目に見える変更により、設計、開発、テスト、トレーニング、および展開の作業が発生します。
- 日付固定の楽観主義 チームは、期限と人員配置が固定されたままであるかのように装いながら、範囲を追加します。
- 管理されていない発見。 有用な発見は、評価されるのではなく、自動的に含まれるものとして扱われます。
- 金メッキ。 チーム メンバーは、メンテナンス コストを考慮せずに、合意された結果を超えてソリューションを改善します。
これが、人々に「ノーと言え」と言うのは弱いアドバイスである理由です。信頼性の高いシステムにより、チームは次のように言えます。「はい、このコストも承認する場合は、この日付を変更するか、この他の項目を削除するか、このリスクを受け入れるかします。」
スコープクリープの初期警告兆候は何ですか?
最も早い警告は、誰かが承認された変更記録を指摘する前に、作業が議論または開始されることです。 次の 7 つの信号に注意してください。
- 新しいタスクがリクエスト ID なしでスプリントまたはスケジュールに表示されます。
- 成果物の説明は変更されますが、ベースライン文書は変更されません。
- 利害関係者は、配信チームが見積もる前に、リクエストを「小さい」と呼びます。
- チームメンバーは報告範囲が変わらないまま夜間作業を繰り返します。
- 受け入れレビューでは、決して書き留められなかった期待が明らかになります。
- マイルストーンは移動しますが、プロジェクトは依然として「計画どおり」に報告されます。
- バックログは、完了した作業または明示的に削除された作業よりも速く増加します。
スケジュールは、リクエストに時間を占有させ、先行者と後続者に接続することを強制するため、優れた検出器です。それ自体が承認制度ではありません。より詳細なスケジュール ロジックについては、次を参照してください。 依存関係ネットワークが下流への影響を明らかにする方法 そして 4 つのガント依存関係タイプ。
作業を開始する前にスコープクリープを防ぐにはどうすればよいでしょうか?
実行前にプロジェクトの境界をテストできるようにすることで、スコープ クリープを防ぎます。 誰も読まない大きなドキュメントよりも、人々が使用する短いベースラインの方が優れています。
少なくとも次のことを記録します。
- 結果と指定された成果物。
- 明示的な除外と仮定。
- 各成果物の受け入れ基準。
- チームが推定できるレベルの作業分解構造。
- 承認された予算と主要なマイルストーンの日付。
- 誰がどのクラスの変更を承認できるか。
- 変更リクエストが記録される場所と、変更リクエストが決定を受け取るまでの時間。
次に、合意された作業をスケジュールに関連付けます。各成果物には、所有者、期間、先行ロジック、および承認マイルストーンが必要です。ツールがスケジュール ベースラインをサポートしている場合は、スケジュール ベースラインを保存します。そうでない場合は、日付付きのエクスポートまたは名前付きの計画バージョンを保存します。バージョンは視覚的なベースライン オーバーレイよりも便利ではありませんが、それでもトレーサビリティを実現します。
官僚主義を生み出さずに範囲の拡大を阻止する変更管理プロセスは何ですか?
1 つのフォーム、1 人の意思決定者、およびリスクベースの承認しきい値を使用します。 小規模なチームでは、文言の変更ごとに企業委員会は必要ありませんが、一貫した記録は必要です。
| フィールド | 入力例 | なぜそれが重要なのか |
|---|---|---|
| リクエスト | 起動前にSSOを追加してください | 提案を具体化する |
| 業務上の理由 | 契約済みの企業顧客が必要 | 価値と好みを区別する |
| 影響を受ける成果物 | 認証、管理者設定、サポートドキュメント | 本当の境界線を明らかにする |
| スケジュールへの影響 | +8営業日。リリースは8月21日→9月2日に変更 | 時間を見える化する |
| コスト/リソースへの影響 | 40時間のアイデンティティスペシャリスト | 見えない残業を防ぐ |
| リスクへの影響 | アカウントのリスクを軽減します。起動が複雑になる | 両面を表示 |
| オプション | 日付を追加および移動します。分析を削除します。 SSOを延期する | 承認者に選択肢を与える |
| 意思決定の所有者/日付 | スポンサー、8 月 10 日 | 権威とトレーサビリティを確立する |
軽量フローは次のとおりです。
- 配信を約束せずにリクエストをキャプチャします。
- 結果と合格基準を明確にする。
- 直接的な作業と影響を受ける依存関係を見積もります。
- クリティカル パス、予算、リソース、リスクへの影響を示します。
- 単に承認/拒否するだけではなく、トレードオフを提案します。
- 指定された承認者の決定を取得します。
- スコープのベースライン、スケジュール、予算、バックログ、および関係者のメッセージをまとめて更新します。
APM では、変更管理を、ベースライン計画の範囲または別の部分を変更する問題に使用されるプロセスとして説明します。 DOE は同様に、変更管理ログを、変更、ステータス、およびアクションをリストした文書として定義します。重要な動作はレコードを同期することです。スケジュールを変更せずに電子メールの変更を承認すると、真実の第 2 バージョンが作成されます。
ガント チャートは、「小規模な」リクエストの実際のコストをどのように明らかにするのでしょうか?
ロジックにリンクされたガント チャートは、新しい作業がスケジュールに追加されたときにどの下流の日付が移動するかを示します。 顧客プロファイルに 1 つのフィールドを追加するリクエストを考えてみましょう。
| 影響を受ける作品 | 追加の労力 | 依存関係の結果 |
|---|---|---|
| 製品の説明 | 0.5日 | ブロックデザイン |
| UX と検証ルール | 1日 | フロントエンドと API コントラクトをブロックします |
| API/データベース変更 | 1.5日 | ブロック統合テスト |
| フロントエンドの変更 | 1日 | 回帰テストをブロックします |
| テスト、ドキュメント、リリース | 1.5日 | リリースマイルストーンを移動します |
| 合計 | 5.5日 | 最初に説明した「クイックフィールド」ではありません |
これらのアクティビティにフロートがある場合、最終期限は変更されない可能性があります。彼らがその上に座ると、 クリティカルパス、チームが他の場所で順序、容量、範囲を変更しない限り、終了日は移動します。このチャートは、感情的な交渉を明確なスケジュール決定に変えます。
GanttFather は、ラグのある FS、SS、FF、および SF の依存関係をモデル化し、現在のクリティカル パスを表示できます。現在、GanttFather は専用のスケジュール ベースライン オーバーレイを提供していないため、正式なベースライン比較が必要な場合は、承認されたエクスポートまたは名前付きバージョンを保存してください。を参照してください。 プロジェクトベースラインガイド ライブ予測と承認済みの参照計画の違いについて。
スコープクリープがすでに発生した後、どのように回復しますか?
新しい作品の受け入れを一時的に停止し、現在の範囲を再構築し、スポンサーレベルのトレードオフを強制します。 古いベースラインを黙って置き換えることによって差異を隠さないでください。
- 進行中のすべての作業と、承認された範囲に含まれていない完了した作業の一覧表を作成します。
- 必須の変更をオプションの機能強化や金メッキから分離します。
- 残りの作業を実行する担当者と再見積もりします。
- 依存関係ロジックを再構築し、信頼できる予測を計算します。
- オプションを提示します。日付を変更する、適格なキャパシティーを追加する、範囲を削除する、明示的に同意した場合にのみ品質/リスク管理を削減する、またはプロジェクトを停止します。
- 復旧計画を承認し、学んだ教訓の元のベースラインを保持します。
主要な変更が承認された後は、再ベースラインが正当になる可能性があります。当初の計画が乖離した証拠を消してはなりません。 DOE の用語集では、差異を承認された範囲、コスト、またはスケジュールのベースラインからの逸脱として説明し、差異は排除するのではなく追跡および報告する必要があると述べています。
GanttFather でスコープ変更のスケジュールへの影響を可視化するにはどうすればよいですか?
承認されたスケジュールを Excel エクスポートで保存し、誰かが日付を約束する前に、提案されたアクティビティ、期間、依存関係リンクを作業計画に追加します。GanttFather は、ラグのある FS、SS、FF、SF の関係をモデル化し、クリティカル パスを再計算できるため、承認者はリクエストがフロートを消費するか、終了マイルストーンを移動するかを確認できます。視聴者とゲストは無制限にライブ結果を確認でき、2 つの編集者席で無料プロジェクトへの変更を管理します。
GanttFather は、変更権限ではなく、スケジュールの証拠を提供します。専用のベースライン オーバーレイや自動リソース平準化がないため、日付付きのエクスポートを保持し、決定内容をプロジェクトの変更ログに記録してください。架空のリクエストを使用してプロセスをテストするには、 無料の GanttFather プロジェクトを作成する 新しい作業を追加する前と後の終了日を比較します。
よくある質問
すべての新しい要件のスコープはクリープですか?
いいえ。合意された変更プロセスを通じて追加された要件は、制御された範囲の変更です。スコープクリープとは、承認されていない、または追跡されていない作業の拡大です。それぞれの変更に目に見える権限、影響力、資金提供、更新された記録がある場合、プロジェクトは多くの正当な変更を「忍び寄る」ことなく受け入れることができます。
スコープクリープを防ぐ責任は誰にありますか?
スポンサーは主要な範囲の決定を所有し、プロジェクト マネージャーは制御プロセスを所有し、製品またはビジネスの所有者は価値を明確にし、デリバリ チームは労力と依存関係を明らかにします。利害関係者が取り込みを回避できる場合、またはチームメンバーが承認されていない作業を開始した場合、誰一人としてスコープクリープを防ぐことはできません。
アジャイル チームにスコープ クリープが発生する可能性はありますか?
はい。柔軟なバックログは、修正リリース内で無制限に作業できることを意味するものではありません。アジャイル チームは、バックログの順序付け、スプリントまたはリリース目標の定義、キャパシティの可視化、既存のコミットメントとの新しい項目の交換によってスコープを制御します。記録されていない追加や目に見えない残業は、どのような配信方法においても範囲を超えます。
利害関係者がさらなる作業を要求する場合に使用する最適な文は何ですか?
使用: 「その変更を評価できます。コミットする前に、その変更が日付、コスト、依存関係、および現在の優先順位に与える影響を示します。」判決はその要請を拒否したものではない。これにより、配信への影響が理解される前に会話が承認されることを防ぎます。
ガント チャートはそれ自体でスコープ クリープを防止しますか?
いいえ。ガント チャートは時間と依存関係を可視化しますが、ビジネス権限を定義したり、承認を強制したりすることはできません。スケジュールをスコープ ベースライン、変更ログ、承認基準、および指名された意思決定所有者と組み合わせます。このチャートは影響を示す証拠を提供します。ガバナンスが決定を下す。
出典



