特定の製品、サービス、または成果の特性と機能、および製品範囲が完了しているかどうかは、製品要求仕様によって測定されます。

スコープ ステートメントは、指定された機能を備えた製品とサービスを提供するために完了する必要がある作業とプロセスを定義します。

プロジェクトの範囲が完了したかどうかは、プロジェクト管理計画、プロジェクトの範囲のステートメント、WBS、および WBS ディクショナリによって測定されます。プロジェクトの範囲は、プロジェクトの明確な目標、またはプロジェクトの投資家または顧客の特定のニーズに基づいています。

プロジェクト スコープの確認は、プロジェクトの関係者によるプロジェクト スコープの正式な承認であり、プロジェクトのライフ サイクル全体にわたって実行されます。

プロジェクト スコープは、需要の変化を効果的に管理する唯一の方法です。明確なプロジェクト スコープがあれば、そのスコープ内のビジネス プロセスのみを分析して、顧客のニーズが変化したときに、そのスコープを効果的に管理できます。

プロジェクトの範囲と機能要件は顧客によって提供されるものではありません。顧客は、プロジェクト チームのメンバーが顧客の分析を理解した後に、どのような目標を達成するかを知っているだけです。

プロジェクトに何が含まれるか、何が含まれないかを定義および制御するプロセスを指します。このプロセスは、プロジェクト チームとプロジェクトの関係者がプロジェクトの製品とそれらの製品の製造に使用されるプロセスについて共通の理解を確保するために使用されます。

需要開発を通じてプロジェクト要件を取得し、それに基づいてプロジェクトの範囲を決定し、プロジェクト範囲管理を実行します。需要管理は、需要管理の定義、需要管理プロセス、需要管理計画の策定、管理を含むプロジェクト要件のライフサイクル全体を管理します。プロジェクトの要件については、要件の緊急性と重要性に応じて段階的に満たすことができ、この期間の要件管理の基礎となります。要件の変更により、プロジェクトの範囲が変更されます。

基本的な内容

5つの工程

さまざまな単一の要件がプロジェクトに関連するビジネス要件をどのように満たすかを説明します。明確で、追跡可能で、相互に調整され、主要な関係者によって認識されている要件のみをベースラインとして使用できます。

含む

プロジェクトのライフサイクル全体を通じて、要件がどのように分析、文書化、管理されるかについて説明します。ライフサイクルの各段階における部門間の関係は、要件の管理方法に大きな影響を与えます。

含む

インタビュー、フォーカスグループ、ガイド付きワークショップ、グループイノベーションテクニック、グループ意思決定テクニック、アンケート、観察、プロトタイピング

Delphi テクニック: 選ばれた専門家のグループがアンケートに答え、要件収集の各ラウンドの結果についてフィードバックを与えます。匿名性を維持するために、専門家の回答はモデレータにのみ提供され、専門家が全員平等である場合、複数の制御されたフィードバックにより、個人が結果に過度の影響を与えることを回避できます。

ブレーンストーミング: プロジェクト要件および製品要件について複数のアイデアを生成および収集するために使用される手法

コンセプト/マインドマップ：ブレインストーミングで得たアイデアを簡単な図で結び、アイデア間の共通点や相違点を反映し、新しいアイデアを導きます。

企業環境要因、組織プロセス資産、プロジェクト憲章、プロジェクト範囲の予備的記述、プロジェクト管理計画

専門家の判断、作業分解テンプレート、変更管理フォーム、組織プロセスの標準

スコープ管理計画

組織プロセス資産 (テンプレート)、プロジェクト憲章、予備的なプロジェクト スコープ ステートメント、プロジェクト スコープ管理計画、承認された変更リクエスト (プロジェクトの実行フェーズ中に発生)

製品分析（製品分解、システム分析、要件分析、システムエンジニアリング、バリューエンジニアリング分析など、製品を成果物とするプロジェクトに有効なツール）、代替識別（異なる実行方法を提案する手法）、専門家判断手法、プロジェクトステークホルダー分析

プロジェクト範囲 詳細説明

変更要求

プロジェクト管理計画

プロジェクトを分解すると、関係者が一目でプロジェクトを理解できるようになります。

プロジェクト構造の体系性と完全性を確保する（やるべき作業の省略や金ぴかさの防止）

万全のプロジェクト保証体制を確立

責任の分割と実施を促進するために、すべての当事者の作業インターフェースを明確にする

スケジュールの計画と管理のツールとして

プロジェクトコミュニケーション管理を確立するための基盤を提供する

これは、プロジェクト計画と管理措置の策定の基礎と基礎です。

階層ツリー構造

表形式

階層構造は、プロジェクトの目標を達成するために必要なプロジェクト作業を、管理しやすい小さな断片に分解したもので、プロジェクトのスコープ全体内のすべての作業を整理して定義します。これには、明確で検証可能な成果物が含まれます。論理的に分割することは、スケジュールの調整、コストの見積もり、監視の基礎となるものであり、WEB の各層をエンコードする必要があります。

組織プロセス資産、プロジェクト範囲ステートメント、プロジェクト範囲管理計画、承認された変更要求 (実行フェーズ中に WBS を更新する必要がある場合があります)

作業分解構造テンプレート

壊す

WBSコーディング設計

プロジェクト スコープ ステートメント (更新)、作業分解構造、WBS ディクショナリ、スコープ ベースライン (ベースラインは WBS の承認後に形成されます)、プロジェクト管理計画、変更要求 (変更スコープ ステートメントは全体的な変更管理を通過します)

プロジェクトスコープステートメント

WBS辞書

プロジェクト範囲管理計画

成果物

スコープ確認を達成するためにチェックします

成果物は受け入れられました

変更要求

推奨される是正措置

スコープ変更を引き起こす要因と要求された変更は、プロジェクト全体の変更管理に従って処理され、スコープ変更が実際に WBS で定義されたプロジェクト スコープの変更として発生したときに管理されます。

変更理由

集中

スコープステートメント

作業分解構造、WBS辞書、プロジェクトスコープ管理計画書

パフォーマンスレポート

承認された変更リクエスト

仕事のパフォーマンス情報

変更管理システム

偏差分析

再計画

構成管理システム

プロジェクトスコープステートメント、WBSおよびWBS辞書、スコープベースライン、変更要求、承認された是正措置、組織プロセス資産、プロジェクト管理計画

段階的な実施 - 大規模プロジェクトは範囲が広く、サイクルが長く、複雑なビジネスになります。コア事業は第 1 フェーズで実現され、第 2 フェーズで包括的に推進されます。

ユーザー マネージャー、ビジネス マネージャー、主要ユーザーを含むプロジェクトの組織構造を確立します。プロジェクトの範囲を完全に理解し、矛盾を回避します。

適切なニーズの分析と調査 - プロジェクトの範囲を決定し、ユーザーのニーズ仕様を作成するための基礎となります。

スコープ管理計画を作成する - プロジェクトのスコープ、各段階の成果物、使用する実装方法、および機能の説明を決定するためのスコープ ステートメントを作成します。

スコープ定義 – トップダウンアプローチを使用して WBS を分割する

定期的なプロジェクト会議制度 - プロジェクトの範囲と結果を確認する

プロジェクトの週次および月次レポート システム - システムの進捗状況の分析と概要

プロジェクト監理制度 - 監理会社参加