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

プロジェクトスコープ プロジェクトスコープステートメントの開発は時間のかかる活動であり、組織外の専門家を含む複数の利害関係者の参加が必要な場合があります。, プロジェクトマネージャーは、プロジェクトスコープステートメントを定義する際に、次の二つのことを含めることを避けます。

承認されていないスコープ：プロジェクトマネージャーは、人々がスコープを要求したが、プロ

必要ないスコープ：プロジェクトマネージャーは、スコープが簡単に誤解される可能性のある領域を明確にする必要があります。 スコープベースラインは、project scope文とWBSおよびWBS辞書の組み合わせです。 スコープベースラインは、プロジェクト管理計画の一部です。,

プロジェクトスコープステートメントには、次のものが含まれます。

• 製品スコープ

• プロジェクトスコープ

• 成果物

• 製品の受け入れ基準

• 範囲外のアクティビティ

• 制約と仮定

ワークブレークダウン構造(Wbs)の作成

すべてのプロジェクト(大小)にはWbsが必要です。 これは、プロジェクト管理に必須の要素です。 WBSは、管理可能な成果物に分割されたプロジェクトの完全な範囲を示しています。 WBSが利用できない場合、プロジェクトには予定された時間よりも時間がかかります。, プロジェクト管理者も見逃る重要な活動のWBS. このようなWBSのプロジェクトで負の影響を受けた。 最プロジェクト管理者のリストアップ活動として実用的な. これは、いくつかの成果物を見落とす可能性があります。 さらに、リストは面倒で、プロジェクトマネージャーが大きなプロジェクトを小さな適切な部分に明確に分解することはできません。 人々はリストを見ることによってプロジェクトの理解を得ない。 リストは一人の個人によって作成されます。 リストを見ると、誰がリストを作成したのかわかりません。, これらは活動のリストを作成することの主要な欠点のいくつかである。 一方、WBSには大きな利点があります。 WBSを使用すると、実用的なものは見逃されません。 プロジェクトマネージャーで簡単に破ることにより、作業の仕事パッケージのWBSを示してどのようにパッケージを掘削する。 Wbsは、利害関係者とチームからのインプットによって作成されます。 これは自動的に購入の追求で助け、こうして性能の改善を導く。 WBSの作成は、チームが彼らの心の中でプロジェクトを歩くので、プロジェクト計画を改善することができますプロセスです。,

したがって、プロジェクトの実行ははるかに簡単でリスクが少なくなります。 人々の関与が増え、すべてがプロジェクトがより達成可能であると感じています。 WBSにはプロジェクトの完全な階層が表示されるため、ある成果物と別の成果物がどのように関連しているかを簡単に確認できます。 これはwbsのサンプルです。 このWBSは発展途上国の使用のためのきれいで、支持できる完全な照明装置の開発にある。 最も一般的には、プロジェクトのタイトルはWBSの上部にあります。, 最初のレベルは、通常、プロジェクトのライフサイクルと同じです（例えば、ここで説明するプロジェクトWBSのために、エネルギーを統合するための方法、頑丈で堅牢なケーシングを開発し、長寿命、大容量ストレージシステムを開発し、軽いシステムを開発し、安価な製品を開発し、基本的なコンポーネントを再発明しない）。 それ以降のレベルは小さい部分にプロジェクトを破る。 などを分解して生じるプロジェクトマネージャーのレベルを適切に管理します。 WBSは企業の組織構造ではないことに注意することが重要ですが、それは一つのように見えます。, この機能が異なることができる下のような圧倒的なプロジェクト作までの計画、組織の管理と制御が可能となります。 WBSの創設はトップダウンの取り組みです。 それは、成果物とそれらを生成するために必要な作業を、ワークパッケージと呼ばれる小さな断片に分解することを含む。,

プロジェクト全体は、WBSのすべてのレベルを見ることによって理解することができます

WBSにはプロジェクト以外の成果物が含まれていません

成果物は、次のときに作業パッケージと見なされます。

• それは（現実的かつ自信を持って）推定することができます

それはすぐに完了することができます

• 中断することなく完了することができます（詳細は必要ありません）

• アウトソーシングまたは契約

wbsレベルは後の段階で番号が付けられます。, ワークパッケージは、WBSの完了後に割り当てられた識別番号を使用してWBSで区別されます。 これは、WBSに番号付けシステムを使用する例です。 試験では、”コントロールアカウント”という用語が表示されます。 一部のプロジェクトでは、原価は作業パッケージレベルで管理されません。 代わりに、それらは制御アカウントと呼ばれるWBSの上位レベルで管理されます。 計画プロセスが進むにつれて、チームはWBSからの作業パッケージを作業パッケージを生成するために必要なアクティビティに分解します。, このWBSのアクティビティ-リストへのさらなる内訳は、アクティビティの定義の時間管理プロセスの一部として行われます。 チームは、project scopeステートメント、WBS、およびWBSディクショナリを使用して、成果物を作成するために必要なアクティビティを定義します。 すべてのプロジェクトの基礎は”WBS”です。 WBSの作成後、計画で発生するすべてのものはWBSに関連しています。 WBSディクショナリ各作業パッケージに対して、WBSディクショナリは、実行される作業の説明を提供します。, WBS辞書の利点には、スコープのクリープを回避し、成果物の明確な説明を提供することが含まれます。 Create WBSプロセスの出力はWBS辞書です。

WBS辞書は複数の用途を持つことができます：作業パッケージがいつ開始されるかを知らせるため、作業承認システムのスケジュールマイルストーン、受け入れ基準、および作業パッケージに関するその他の情報がWBS辞書に含まれています。 どのような作業が行われるかの制御機構として使用することができます。, ステークホルダーは、WBS辞書スコープベースラインを持つ作業パッケージに関わる努力について理解を深めていますプロジェクト管理計画の特定の部分の最終承認バージョンは、ベースラインと呼ばれます。 スコープ管理では、ベースラインはWBS、WBS辞書、およびスコープステートメントです。 これらのすべては、作業を開始する前に経営陣と利害関係者によって承認される必要があります。 これらのベースラインの助けを比較するとプロジェクトの進捗状況のベースラインはできます。 スコープベースラインから逸脱する場合は、変更要求が必要です。, この変更要求は、統合された変更制御の実行を経て、承認された場合、scopeステートメント、WBSおよびWBS辞書に追加されます。 関連する他のコンポーネントまたは文書も更新する必要があります。 要件とスコープベースラインを満たすことは、プロジェクトの成功の尺度です。,l>

品質管理プロセスの実行からの入力

検証済み成果物スコープステートメント、

WBSおよびWBS辞書

要件トレーサビリティマトリックス

要件ドキュメント

検証スコープの出力は次のとおりです。

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

• 変更要求

• プロジェクト文書の更新

コントロールスコープスコープパフォーマンス(プロジェクトおよび/または製品の)の測定とスコープベースライン変更の管理は、コントロールスコーププロセスの主要な成果物です。, プロジェクトマネージャーのニーズを制御範囲くことを確保する範囲が含まれておりますので、どのプランです。 のプロジェクトのニーズを適切に管理用の制御範囲です。 コントロールスコーププロセスに必要な二つのコンポーネントは、プロジェクト管理計画からのスコープベースライ 要求書および要件トレーサビリティ-マトリックスできましたものであり、これら全ての制御範囲です。 プロジェクトマネージャーを識別する場合があり逸脱に対するベースライン 偏差が存在する場合は、是正措置または予防措置が推奨されます。, 変更要求は、変更が必要な場合に発生します。 プロジェクトマネージャーニーズの特定と実行の統合を変更管理プロセス、その後更新の必要があります。 制御範囲プロセスは順向のアプローチを信じる。 プロジェクトマネージャーのジョブを制御するプロジェクトのベースラインとしてのプロジェクト管理プランです。 変更管理プロセ

---