スコープクリープとは何ですか?どうすれば回避できますか?

公開: 2022-08-23

プロジェクトでスコープ クリープを回避する方法を説明する前に、プロジェクト スコープとスコープ クリープとは何かを理解する必要があります。

プロジェクトの範囲とは?

簡単に言えば、プロジェクト スコープは、プロジェクトを完了するために必要なすべての作業を指します。 作業分解図 (WBS) を使用すると、プロジェクトの個々のタスク、アクティビティ、および成果物をすべて識別することができます。 次に、スコープ ステートメントが必要になります。これは、プロジェクトのスコープを定義するプロジェクト計画ドキュメントです。

プロジェクト管理におけるスコープ クリープとは

スコープ クリープは、変更要求などの制御手順なしでプロジェクト スコープに変更が加えられた場合に発生します。 これらの変更は、プロジェクトのスケジュール、予算、コスト、リソースの割り当てにも影響を与え、マイルストーンや目標の達成を危うくする可能性があります。 スコープ クリープは、最も一般的なプロジェクト管理リスクの 1 つです。

通常、スコープ クリープは、プロジェクトの実行が開始された後に、プロジェクト クライアントまたは他の利害関係者によって新しいプロジェクト要件が追加されたときに発生します。 多くの場合、これらの変更は適切にレビューされていません。 したがって、プロジェクト チームは、元のスコープと同じリソースで同じ時間内に、より多くのタスク、成果物、およびマイルストーンを完了することが期待されます。

一方、承認され、検討された多くの変更を伴うプロジェクトになってしまう可能性があります。終了したと思うたびに、新しい製品機能などの新しいプロジェクト要件が受信ボックスに届き、それを行う必要があるためです。さらに変更を加えます。

プロジェクトのスコープを制御し、スコープのクリープを防ぐには、スコープ、変更、およびリスク管理計画が必要です。

スコープ管理計画

範囲管理計画は、プロジェクトの範囲をどのように確立して管理するかを説明するプロジェクト計画の構成要素です。 このドキュメントには、作業分解構造、スコープ ステートメント、およびスコープがプロジェクトのベースラインとして利害関係者によって承認されるプロセスが含まれています。

スコープ マネジメント計画は、プロジェクト マネージャがプロジェクト スコープのベースラインと、その変更がプロジェクト マネジメント計画全体に与える影響を利害関係者が理解していることを確認するのに役立ちます。

変更管理計画

当然のことながら、プロジェクトには常に変更が発生しますが、これらの変更を制御できるように変更管理計画を策定することが重要です。 プロジェクト計画で定義されたとおりにプロジェクトが進行することはほとんどありません。 ほとんどの場合、プロジェクト マネージャーは、スケジュール、予算、および範囲を調整する必要があります。 ただし、変更管理プロセスをある程度制御できなければ、プロジェクト マネージャーが作業を把握し、プロジェクトを効果的に管理する可能性はほとんどありません。

リスク管理計画

利害関係者、クライアント、またはチーム メンバーがスコープおよび変更管理手順に従わなかったためにスコープ クリープが発生した場合は、リスク管理計画を参照する必要があります。 プロジェクトのリスク管理計画は、リスク管理のための戦略、役割、責任、および資金を確立する文書です。 簡単に言えば、スコープ クリープなどのリスクを防止および軽減するために必要なすべての情報を含む計画です。

スコープ クリープの例

プロジェクト マネージャーは 3 か月間にわたって、新しいソフトウェアの提供を任されていました。 計画フェーズに入ってから数週間後、プロジェクトのスポンサーは製品に新しい機能を追加しました。 プロジェクト マネージャーが新しい要件をプロジェクト スコープに含めた後、スポンサーは、プロジェクト クライアントの要求に応じてさらに変更を加えました。

もちろん、プロジェクト マネージャーは、変更要求が提出され、スコープに追加された余分な作業を実行するためにより多くのリソースが与えられれば、新しい製品機能は問題にならないだろうと答えました。 3 か月の締め切りが近づくと、スポンサーは動揺し、プロジェクトが予定より遅れており、クライアントは成果物を期待していると不満を漏らしました。 ベースラインのプロジェクト計画は野心的すぎて、追加の作業をスケジュールどおりに進めることができなかった、とプロジェクト マネージャーは説明しました。

次に何が起こったか推測できますか? うん。 プロジェクトマネージャーは、スポンサーから「遅すぎる」と非難され、プロジェクトから外されました。 これはスコープクリープの典型的な例です。 変更要求によって新しい製品機能が追加され、追加のタスクを実行するのに十分なリソースがあったにもかかわらず、時間の制約は変わらなかったため、プロジェクト マネージャーは計画されたプロジェクト スケジュールのベースライン内で機能を提供できませんでした。

スコープ クリープを回避する方法

スコープ クリーパーがあなたのプロジェクトを台無しにしないようにしてください。 以下は、プロジェクトの範囲を管理するための 5 つの方法です。

1. プロジェクト要件を文書化する

スコープ クリープを回避するための最も重要なことは、プロジェクトの要件を文書化することです。 プロジェクト要件を明確に定義することで、プロジェクトの範囲を定義できます。 すべてのプロジェクト関係者およびユーザーと話し合い、彼らがプロジェクトに何を求めているかを正確に把握します。 それを書き留め。 競合を管理します。 ある利害関係者が新しいウェブサイトを青くしたい、クライアントが緑にしたい場合、仲裁して最終決定を下す人を見つけます。 すべての要件を満たすことはできない場合があるため、要件に優先順位を付けます。

利害関係者の発言をすべて記録するのは時間がかかる場合がありますが、記録が終わったら、すべての要件をドキュメントに記録します。 このドキュメントは要件管理計画と呼ばれ、追跡方法や要件を変更するプロセスなど、プロジェクト要件を管理するために必要なすべての情報が含まれている必要があります。 そのドキュメントをオンラインで共有して、誰もが簡単に見られるようにします。

2. 変更管理プロセスを設定する

要件ドキュメントは出発点にすぎません。 誰かが何かを変えたいと思ったとき、何が起こりますか?

何も変わらないと考えるのは非現実的です。 スコープ クリープを防ぐために必要なのは、プロジェクトの変更を管理し、制御することです。 そのためには、プロジェクト計画を変更する必要がある場合に従わなければならない変更管理プロセスの手順を定義する変更管理計画が必要です。 また、スコープ クリープなどのリスクを追跡できるように、プロジェクトの全体的なステータスを監視する頻度を確立するリスク管理計画を立てることも重要です。

変更管理プロセスは非常に簡単です。 基本的に、誰かが変更要求を介して変更を提案し、それがレビューされ、承認または却下され、承認された場合はプロジェクト計画に組み込まれます。 プロジェクト管理ソフトウェアに変更管理機能がある場合は、それを使用してください。

プロジェクトの変更管理プロセスを設定するということは、誰が変更をレビューして承認するかを考えるということです。 それらについては、プロジェクト スポンサーまたはチーム ミーティングで話し合うことができます。

プロセスがなければ、変化はただ…起こるだけです。

3. 明確なプロジェクト スケジュールを作成する

利害関係者の要件を使用して、プロジェクトの範囲を決定します。 次に、作業分解構造 (WBS) を使用して、詳細なタスク リストを作成できます。 プロジェクトのスケジュールは、プロジェクトが何を提供するかを知ることの結果です。 タスク、活動、マイルストーンの形で、すべての要件とそれらを達成する方法を示す必要があります。 これは一般的にガント チャートで作成されます。

プロジェクトのタスクのスケジュール
オンライン ガント チャートを使用してプロジェクトのスケジュールを作成する —詳細

プロジェクト スケジュールを要件管理計画書と相互参照して、忘れ物がないことを確認できます。

スケジュールの概要を説明したら、不測の事態に備えて計画を立ててください。 上記のように、変化は起こります。 プロジェクト スコープ クリープは、変更が変更管理計画で定義されたとおりに処理されなかった場合にのみ発生します。

4. 利害関係者とのプロジェクト スコープの確認

利害関係者の要件を適切に理解していることを確認することが重要です。 プロジェクトのスポンサーがプロジェクトの成果物について何を意味しているとあなたが考えているかは、彼または彼女が意図したものではないかもしれません。 多くの場合、人々は無意識のうちに矛盾した目的で話します。 クライアント、投資家、プロジェクト スポンサーなどの利害関係者に時間をかけて、要件ドキュメントを共有してください。 また、プロジェクトのスケジュールを表示して、表示されると予想されるすべての要素がタスク リストに表示されていることを確認することもできます。

製品の機能や納期などについて考えが変わったことに気付くかもしれません。 プロジェクトが開始されてから後で気付くのではなく、計画プロセスの早い段階でプロジェクト計画を調整して、スコープ クリープのリスクを軽減することが重要です。

これらのディスカッションを使用して、変更管理プロセスについてスポンサーや利害関係者と話すこともできます。 プロジェクト計画の変更をどのように管理するか、および続行するためにどのような承認が必要かを説明してください。 これは、彼らが望むものはほとんど何でも手に入れることができるということを彼らに思い出させるのに役立つ瞬間です。

利害関係者が「忙しすぎて」この段階でスケジュールの詳細を知りたくない場合は、あなたがどの段階にいるのかをそっと思い出させてください。コミュニケーションが不十分なために、要件収集プロセスが実際に終了したことを主要な利害関係者に知らされていないことがあります。

5. プロジェクト チーム メンバーを参加させる

プロジェクトの利害関係者が満足している場合は、プロジェクト チームのメンバーも満足していることを忘れないでください。 彼らは、変更管理プロセスと、それが彼らに与える影響について知る必要があります。 彼らは、変更の主体ではなく、プロジェクトのスコープの保護者、保護者である必要があります。

プロジェクト チーム メンバーは、助けになりたいと思って、正式な変更管理プロセスを適用せずに何かを変更することに同意する場合があります。 プロジェクト計画に影響を与え、スコープクリープを引き起こす可能性があるため、変更が承認されない限り、変更に「はい」とは言えないことを説明します。 利害関係者を支援したい場合は、変更管理プロセスを説明し、変更の文書化を支援することを申し出るのが最善の方法です。

スコープ クリープは、特にプロジェクト マネージャー、チーム、および利害関係者が、変更がリソース、予算、およびスケジュールに与える影響を理解していない場合に、プロジェクトで深刻な問題となります。 幸いなことに、最初のプロジェクト スコープが明確であり、プロジェクトのライフサイクル中にプロジェクト計画の変更を慎重に管理していれば、大きな問題になる必要はありません。

スコープ クリープを回避し、プロジェクトの絶え間なく変化する要件を管理するには、新しい変更を追加してリアルタイムで確認するための変更管理機能を提供する、タスクに対応したオンライン プロジェクト管理ソフトウェアが必要です。 ProjectManager.com を使用すると、プロジェクト マネージャーはこれらの変更に優先順位を付けてチーム メンバーに作業を割り当てることができ、変更が承認されると、誰かがすぐに作業に取りかかることができます。

プロジェクト管理におけるスコープ クリープ、PMP で説明

プロジェクト マネージャーは、プロジェクトのスコープ クリープを常に監視していますが、問題は解決していません。 このビデオでは、プロジェクトが頓挫する前にこのリスクを軽減する 7 つの方法を紹介します。

レビュー中: プロジェクト管理の範囲クリープ

PMP の Jennifer Bridges が、プロジェクトでスコープ クリープを回避する方法に関する短いチュートリアルを提供しています。 彼女は、プロジェクトを計画どおりに管理し、変更を管理するために適用できる計画手法を提供します。 彼女は、スコープ クリープを防止して対処する 7 つの方法を概説しています。

  • スコープを定義する
  • 変更をログに記録する
  • ベースラインの再設定
  • 追加の資金やリソースをリクエストする
  • 兆候に注意してください
  • 優先順位を設定する
  • トラップを避ける

スコープ クリープの原因がリソースにある場合があることに注意することが重要です (この記事は、チームがいつ制御不能になったかを判断するのに役立ちます)。 あなたのプロジェクトでスコープ クリープを引き起こしている問題を起こしているのは誰ですか? 彼らは、チームメンバーから利害関係者にまで及ぶ可能性があります。 上記で概説したものと同じ計画手法を使用して、それらを管理できます。

プロのヒント: 自分自身にも注意してください。 プロジェクト マネージャーとして、機能や要件を追加して範囲を拡大しないようにする必要があります。 プロジェクトへの影響について自由に話し合い、共有できる共同チームを編成することが、プロジェクトをサポートする最善の方法です。

このビデオでは、これらすべてのポイントについて詳しく説明しています。 これは、プロジェクトを成功裏に完了するための重要な障害に対処するための優れた入門書です。

ProjectManager.com がスコープ クリープを抑制する方法

スコープ クリープの管理は、プロジェクトの管理に少し似ています。 たくさんのピースをコントロールして、パズルのように組み合わせていく必要があります。 ProjectManager.com は、受賞歴のあるプロジェクト管理ソフトウェアであり、プロジェクトとチームを編成して予定どおりに進めることができます。

関係者から変更が提案されたら、それを把握する必要があります。 当社のソフトウェアには無制限のファイル ストレージがあるため、詳細な記録を 1 か所に保存できます。 要件を取得したら、それらを共有する必要があります。これは、当社のソフトウェアをクリックするだけです。

変更が発生した場合、スコープ クリープが発生しないようにするには、コントロールを追加するのが最善の方法です。 これを行うために、ワークフローを視覚化するかんばんボードがあります。 列は完全にカスタマイズ可能なので、doing、testing、done というタイトルの列を作成できます。 これで、各リクエストを追跡して、より大きなプロジェクトに悪影響を与えていないことを確認できます。

ProjectManager.com のかんばんビューのスクリーンショット。複数のプロジェクト スコープ タスク (カードとして表される) が列 (完了の段階を表す) に沿って移動していることを示しています。

変更が完了列に反映されたら、プロジェクト スケジュールを作成して、その変更をプロジェクト タイムラインに実装します。 プロジェクト計画で行うのと同じように、オンライン ガント チャートの 1 つに基づいて作業をスケジュールしたいと考えています。 この時点で、タスクを設定し、依存関係をリンクし、作業を行うチーム メンバーを割り当てることができます。

ProjectManager.com のガント チャート インターフェイスのスクリーンショット。階層化されたタイムラインでソフトウェア プロジェクト スコープのさまざまな段階を示しています。 「無料トライアルを開始するには、ここをクリックしてください」というテキストがスクリーンショットの上に重ねて表示されます。

そのプロジェクト計画を実行する前に、利害関係者はそれを見て承認する必要があります。 幸いなことに、ガント チャートを関係者と簡単に共有して、賛成してもらうことができます。 次に、計画をチームと共有し、タスクに優先順位を付けて、リソースがキャパシティに一致するようにすることができます。 ProjectManager.com でスコープ クリープを寄せ付けません。

見てくれてありがとう。

転写

こんにちは、ProjectManager.com のディレクター、Jennifer Whitt です。 ProjectManager.com ファンの皆様、ようこそ。 今日のホワイトボード セッションは気に入っていただけると思います。スコープ クリープの防止にご参加いただきありがとうございます。

プロジェクトでスコープクリープを引き起こすのは誰ですか?

無意識のうちに「スコープ クリープの防止」を書いたので、私は時々自分自身をクラックします。以前にスコープ クリープを経験したことはありますが、スコープ クリープを認識したほうがよいでしょう。 ご存じのように、私たちのプロジェクトや利害関係者のリソース、あるいはスコープ クリープの原因となる問題を注入する人々である顧客かもしれません。

ですから、スコープ クリープを管理するためのテクニックを導入するだけでなく、スコープ クリープも重要であると感じています。 彼らはどんな見た目ですか?
ええと、スコープが忍び寄ると思うことがあります。私たちのプロジェクトにスコープを挿入する人々は恐ろしい顔をしています。 多分彼らは意地悪です。 しかし、私たちが学んだことは、彼らはあなたが最も好きな人である可能性が高いということです.

彼らはあなたにドーナツを持ってきて、あなたを昼食に連れて行く人々です. 彼らはあなたの親友です。 あなたは彼らのためにすべてをしたいです。 そのため、彼らは常にちょっとしたおまけを求めているのです。 それが今日お話しすることです。 これを管理するために導入できるいくつかのテクニックを次に示します。

スコープ クリープを回避するための 7 つのヒント

以上が、軌道に乗る方法について私が学んだ 7 つのヒントです。 まず、スコープを定義します。 私は自分が取り組んでいるプロジェクトの数にいつも驚かされますが、彼らはその範囲を本当に特定していません. または、彼らはそれが何であるかについてある程度知っているかもしれませんが、プロジェクトの開始後ではなく、プロジェクトの開始前にスコープを知り、定義することが重要です. あなたもそれを見たことがあるので、あなたが笑っていることがわかります。

1. プロジェクトの範囲を事前に定義する

そのため、事前に定義し、変更管理委員会、利害関係者、クライアント、およびベースラインと合意することが重要です。 プロジェクトを開始する前に、スコープが何であるかをベースラインにすることが重要です。

2. 文書範囲の変更

次に、変更をログに記録します。 繰り返しますが、ここにもう 1 つあります。 プロジェクトまたはスコープへの変更が文書化されていないところに完全にショックを受けました。 そのため、変更を文書化し、変更を評価し、どの変更がプロジェクトにどのように影響するかを評価し、承認することをお勧めします。

あなたがそれで何をしようとしているのかを知ってください。 保留にしますか? 私たちはそれを承認し、その変更を実施しますか? それをどうするつもりですか? あなたのプロジェクトの変更管理委員会がその呼び出しを行うことが重要であり、あなた、プロジェクトマネージャー、またはそうでない場合は、最終的にプロジェクトバッグを保持したままになります。

3. プロジェクト スケジュールまたはプロジェクト計画のベースラインを再設定する

3 つ目は、ベースラインの再設定です。これらの変更が承認されるか、プロジェクトに組み込まれたら、スケジュールまたはプロジェクト計画のベースラインを作成することが重要です。 それは実行できる簡単なことの 1 つなので、あなたが見ている統計はわかりません。 Gartner を含むいくつかの組織や他の多くの組織が、失敗したプロジェクトの数を常に調べていることを私は知っています。

したがって、ソースを検討してください。 あるソースによると、プロジェクトの 75% は失敗します。 まあ、そのほとんどは、人々が変化を制御できないこの領域にあります. これらの変更が利害関係者と変更管理委員会によって合意され、そのグループによって承認された後、ベースラインを再設定するだけで、プロジェクトが失敗することはありません。 失敗したプロジェクトの 75% にいるか、成功したプロジェクトの 25% にいるかの違いです。

数字だけを見ると、同じ部屋に 10 人のプロジェクト マネージャーがいる場合は 7.5 になります。端数を切り上げると、8 人が失敗したプロジェクトを管理しており、2 人が成功したプロジェクトを管理しています。 わずかな違いは、スコープの変更を管理しているかどうか、および計画のベースラインを再設定しているかどうかと同じくらい小さいものです。

4.追加の資金またはリソースをリクエストする

4 番目に、追加の資金またはリソースを要求します。 これで、変更が承認されました。 ベースラインを再設定しました。 しかし、一部の人々にとっては、戻って追加のリソース、つまりそれらの変更を実現するために必要な資金を要求するのが難しい場合があります. これに同意するが、これらの変更を行うために必要な人員、資金、リソースを要求しない場合は、ここでも統計に戻ります。

5. プロジェクト チームと連絡を取り、進捗状況を追跡する

5番、標識に注意してください。 したがって、プロジェクト マネージャーとして、常にチーム、チームの行動を監視する必要があります。 物事が静かになりすぎたとき、つまり人々が働いていても、チームからの信号やフィードバックが得られない場合に兆候があるように感じます. または、プロジェクト チームやチーム メンバーに「調子はどうですか?」と尋ねると、常に問題はありません。 そしてすべてが順調です。 ええと、それらは、何かが正しくない可能性があるという兆候だと私たちは感じています.

ですから、戻ってチーム メンバーやプロジェクトをチェックし、実際に完了しているものを見て、「本当に順調に進んでいるか」を確認して評価することは常に良いことです。 彼らはスコープ クリープからクッキー、ブラウニー、ドーナツを取り、それらの変更を実装し、静かにそれらを実行していますか? プロジェクトの最後に、スコープが忍び寄り、それについて知らなかったことに気付くのはあなただけです。

6. 優先順位を設定する

6 番目、優先順位を設定します。 繰り返しますが、これは前のステップに戻り、変更管理委員会が変更を評価して優先順位を付けます。 これは通常、複数のグループが存在する場合に発生します。場合によってはプロジェクトで、さまざまなビジネス ユニットのさまざまな利害関係者がいて、変更をもたらすこともあります。その後、口論になります。 どの変更を承認する必要があるかは、変更管理委員会に決定してもらいます。 変更管理委員会にそれをさせてください。

7.スコープクリープトラップを回避する

7番、トラップを避けてください。 私たちは、彼らが「あなたがそこにいる間に…」または「あなたがそれをしている間に、これもできますか?」と言う小さなフレーズがスコープクリープからそれらすべてを見てきました。 または、「あなたがしなければならないのは…」ということです。 または、私が最も愛しているのは、「ねえ、それほど時間はかからないよ」です。

さて、何に基づいて? 誰の評価に基づいて? 今までにやったことがない人に基づいていますか? 変化や評価に基づいていませんか? したがって、これらは失敗したプロジェクトの 75% またはそれ以上の数に陥ってしまう小さな落とし穴です。

ですから、私が顧客であるとき、私は実際にはスコープ クリープであることを認めなければなりません。欲しいです。 したがって、これらのヒントのいくつかは、自分のプロジェクトからだけでなく、自分がスコープ クリープである他のプロジェクトの顧客である自分自身から学んだものです。

したがって、スコープ クリープを管理するためのヒント、ツール、またはテクニックが必要な場合、またはさらに良いことに、スコープ クリープを特定する場合は、ProjectManager.com にアクセスしてください。