プロジェクトマネージメントにおけるスコープクリープとは何でしょうか？

スコープがプロジェクトに必要な作業を定義することは私たち全員が認識しています。スコープの管理はプロジェクトマネージャ―の職務であり、特にプロジェクトが開始してスコープクリープが顕在化してからはプロジェクトマネージャ―の役割が重要になります。ここで質問です。プロジェクトマネージメントにおけるスコープクリープとは何でしょうか？

スコープクリープとは何でしょうか？

スコープクリープ（「要件クリープ」や「機能クリープ）としても知られる）は、プロジェクトのライフサイクルにおいてプロジェクトの要件が増加することを意味します。例えばプロジェクト開始時は1つであった成果物が5つに増えたり、製品の特徴が3つから10に増えたり、またプロジェクトの途中で顧客が求めるニーズが変わり、プロジェクトの要件が変更することなどが挙げられます。スコープクリープは通常、主要ステークホルダーの要件変更、または社内の不十分なコミュニケーションや意見の対立などが原因となります。本投稿では問題が大事に至る前に解決する方法を紹介しながら、スコープクリープがプロジェクトに忍び寄る方法、およびその解決に取り組みます。スコープクリープがプロジェクトの遅滞や妨害、予算超過につながることもありますが、スコープクリープは必ずしも悪いことではありません。プロジェクトの実行において変更は避けられないものであることを忘れないでください。顧客のニーズは時間と共に変化し、顧客のニーズに応えるプロジェクトを実行するにはスコープを変更する必要が出てきます。スコープクリープは現実のものであり、すぐれたプロジェクトマネージャ―はそれを予想し、それに対応する準備をしておかなければなりません。

プロジェクトスコープの管理方法

スコープを変更する際の管理が不十分であればスコープクリープにつながり、管理されていればきちんと文書化されたプロジェクト要件の変更となります。スコープクリープの管理はスコープでそれらの変更を管理するか、または管理プロセスを変更します。これには以下が含まれます。

プロジェクトの状況とベースラインのスコープを監視する
分散分析を行い、実際に測定した作業パフォーマンスとベースラインのスコープを比較する：「現在のプロジェクトは本来のプランからどのように変化していますか？」
変更があった場合は、その原因と変更の度合いを特定する
変更リクエストを評価する。例：是正措置または予防措置のどちらが必要か？
すべての変更リクエストと推奨対策（是正措置または予防措置）を管理するか、または統合変更管理プロセスを実行する

承認された変更リクエストがプロジェクト全体のスコープやコストのベースラインに影響する場合は、スコープステートメント、作業分解構成図（WBS）および/またはコストベースラインを更新し、ステークホルダーに送ります。まとめると、すべての変更を適切に処理し、文書化し、伝達することが求められます。

Scope creep (sometimes known as “requirement creep” or even “feature creep”) refers to how a project’s requirements tend to increase over a project lifecycle, e.g., what once started as a single deliverable becomes five; or a product that began with three essential features, now must have ten; or midway through a project, the customer's needs change, prompting a reassessment of the project requirements. Scope creep is typically caused by key project stakeholders changing requirements or sometimes by internal miscommunication and disagreements. This post tackles several ways it creeps up on projects, along with tips on how to nip it in the bud. While it might result in project delays, roadblocks, or going over budget, scope creep is not always a bad thing. Remember that change is inevitable — customer needs evolve over time and delivering a project that answers their needs often means altering the scope. Scope creep is, therefore, a reality that every good project manager expects and plans for.

How to manage project scope

Changes to scope can be either uncontrolled, resulting in scope creep, or controlled, resulting in documented changes to the project requirements. Managing scope creep boils down to controlling those changes in scope via a change control process. This involves:

Monitoring the project's status and baseline scope
Comparing actual work performance measurements with the baseline scope using variance analysis, i.e., "How different is the current project from the original plan?"
Determining the cause and degree of the changes found
Deciding on change requests, i.e., whether corrective or preventive action is needed
Managing all change requests and recommended actions (whether corrective or preventive actions) via the Perform Integrated Change Control process

If approved change requests affect the project's overall scope and cost baseline, then the scope statement, Work Breakdown Structure (WBS), and/or cost baseline is updated and sent out to stakeholders. In short, all changes are processed, documented, and communicated properly.

Examples of scope creep

To avoid scope creep, it’s important to consider some concrete project scope creep examples.

Consider a company that is launching a new type of phone case next month. The company has meticulously planned the product launch from start to finish. However, over the course of development, the CEO and exec team decide they want to add a ring light, battery pack, and other elements to the case. This requires the project team to spend considerable additional time on this product, which, in turn, affects the product’s final launch date and the attendant revenue.

In a particularly famous real-world example of scope creep, we look to Denver International Airport (DIA) and its experience with attempting to create a fully automated baggage handling system, which was plagued by scope creep that involved over 2,000 design changes. These design changes were, in part, a result of not including relevant parties in the planning stages and ignoring fundamental project concerns. The scope creep during the DIA baggage automation project meant the project finished 16 months late and more than 250% over budget.

But while DIA’s attempt at automating baggage ultimately failed, there are key lessons to be learned from one of the most well-known project creep examples.

From this example, future project managers will hopefully be reminded of the importance of communicating with all stakeholders from the initial phases, heeding expert warnings about potential obstacles that could impact timeline and budget, and breaking projects into smaller chunks using achievable project milestones.

プロジェクトマネージメントにおけるスコープクリープとは何でしょうか？