Wondershare EdrawMind
マインドマップギャラリー プロジェクトの範囲管理
- 9
プロジェクトの範囲管理
プロジェクトにどの作業が含まれ、何が含まれないかを決定し、それによってプロジェクトのスコープを定義します。プロジェクトのライフサイクル全体を通じて、プロジェクトのスコープはさまざまな理由で変更される可能性があります。プロジェクトのスコープ管理は、プロジェクトのスコープの変更も管理する必要があります。プロジェクトスコープの変更は変更とも呼ばれます。
2020-05-29 21:46:16 に編集されました
- おすすめ
- アウトライン
プロジェクトの範囲管理
プロジェクトにどの作業が含まれ、何が含まれないかを決定し、それによってプロジェクトのスコープを定義します。プロジェクトのライフサイクル全体を通じて、プロジェクトのスコープはさまざまな理由で変更される可能性があります。プロジェクトのスコープ管理は、プロジェクトのスコープの変更も管理する必要があります。プロジェクトスコープの変更は変更とも呼ばれます。
製品の範囲: 製品、サービス、または結果の特徴と機能を表します。製品の範囲は、製品要件が満たされているかどうかによって測定されます。
プロジェクトの範囲: 指定された機能を備えた製品、サービス、または成果物を完成させるために完了する必要がある作業。プロジェクトスコープが完了したかどうかは、プロジェクト管理計画、プロジェクトスコープステートメント、WBS、WBS辞書によって測定されます。製品範囲は、製品要件に基づいて測定されます。
管理プロセス
1. 範囲管理計画を作成する
スコープの定義、検証、制御方法、および作業分解構造の作成および定義方法を指定します。
ツールとテクニック
1. 専門家の判断
2. テンプレート、フォーム、標準
作業分解構造テンプレート、変更管理フォーム、範囲変更管理フォームが含まれています
入力：
1. プロジェクト憲章
2. プロジェクト範囲記述書（暫定版）
プロジェクト スコープ ステートメントは、プロジェクトを「成果物」レベルで完了するために実行する必要がある対応する作業を明確にします。
プロジェクト スコープ ステートメント (暫定版) では、プロジェクトとその関連製品およびサービスの特性と境界、およびスコープの管理と承認の方法を明確にします。
プロジェクトスコープ管理計画では、プロジェクトスコープ記述書（暫定版）をプロジェクトスコープ記述書（詳細版）に分解する方法を明確に定義する必要があります。
3. 組織プロセス資産
4. 環境要因と組織要因
5. プロジェクト管理計画。
プロジェクト管理計画の策定は段階的な改善プロセスであり、プロジェクトの初期段階の概要計画から、計画段階の終わりには詳細なプロジェクト管理計画に段階的に進化します。このプロセスでは、範囲管理、スケジュール計画、および計画が吸収されます。予算やその他のサブプラン。
出力：
1. 予備的なプロジェクトスコープステートメントに基づいて詳細スコープステートメントを作成する方法。
2. 詳細なプロジェクト スコープ ステートメントから WBS 方法論を作成します。
3. 完成した成果物の形式化と承認に関する詳細な手順
4. 管理要件の変更をプロジェクト範囲の詳細な記述に組み込む方法。要件の変更は、多くの場合、変更管理プロセス全体をトリガーします。
特定のプロジェクトの実際の状況に応じて、プロジェクト範囲管理計画は公式または非公式、詳細または大まかなものになります。プロジェクト管理計画に含めたり、プロジェクト管理計画のサブ計画にすることもできます。プロジェクト管理計画は、他の知識領域からのサブ計画の集合です。
2. 範囲の定義
プロジェクトと製品について詳しく説明します。これらの説明は詳細なプロジェクト管理手順に記載されており、将来のプロジェクト決定の基礎として機能します。
ツールとテクニック
1. 製品分析
2. 複数の代替案を特定します。たとえば、ブレインストーミングや水平思考を使用します。
3. 専門家の判断
入力：
1. プロジェクト憲章と暫定的な範囲の表明
2. プロジェクト範囲管理計画
プロジェクト スコープ管理計画は、予備的なスコープ ステートメントから詳細なプロジェクト スコープ ステートメントを作成する方法を提供します。
3. 組織プロセス資産
4. 変更申請の承認
出力：
1. プロジェクトの目標。達成目標と拘束力のある目標を含む
2. 製品範囲の説明
3. プロジェクトの成果物
4. プロジェクトの境界
5. 製品の合格基準
成果物を受け入れるためのプロセスと原則が明確に定義されています。
6. プロジェクトの制約
7. プロジェクトの前提条件
8. プロジェクトドキュメントを更新しました
スコープ定義プロセスの変更はスコープ管理計画の変更につながり、これらの文書にはプロジェクト管理計画、サブ計画、プロジェクト関係者の要件文書、要件追跡マトリックスが含まれます。これらの更新は、全体的な変更管理を通じて処理されます。
プロジェクトを完了するために、既存のリスク、仮定、および制約が分析され、必要に応じて、新たに発見されたリスク、仮定、および制約が詳細な範囲記述に追加されます。
3. 作業分解構造を作成する
プロジェクトの成果物とプロジェクト作業を、より小さく管理しやすい単位に分割します。よく使用されるツール 作業分解構造 (WBS)
WBS表現
1. 組織図に似た階層ツリー構造。
2. リストフォーム。データの階層ディレクトリと同様に、直感的にインデントされた形式が最適です。
ツールとテクニック
1. 分解
分解とは、プロジェクトの成果物をより小さく管理しやすい単位に分割し、成果物を将来の明確に定義されたプロジェクト活動をサポートするのに十分な作業パッケージに導くプロセスです。 （業界では、1人で2週間で完了できる作業や、1人で80時間で完了できる作業を一般的にワークパッケージと呼んでいます）
プロセスアクティビティ:
1. プロジェクトの成果物とそれに関連する作業を特定して分析する
2. WBSの構築と整理
3. 高レベルの WBS 作業を低レベルの詳細な作業単位に分解する
4. WBS 作業単位にコードを割り当てる
5. ワークの分解度が必要かつ十分であることを確認する
分解方法：
1. ライフ サイクル ステージを分解の第 1 レベルとして使用し、プロジェクトの成果物を第 2 レベルで整理します。
2. プロジェクトの重要な成果物を分解の第 1 レベルとして使用します。
3. サブプロジェクトを第 1 階層に配置し、サブプロジェクトの WBS を分解します。
一般的な手順:
1. プロジェクトのフェーズと主な成果物の特定と確認
2. 分解し、各成分が十分に詳細に分解されているかを確認します。一般的に言えば、少なくとも妥当なコストと期間の見積もりができるまでは分解する必要があります。
3. 主な成果物の構成要素を確認します。パフォーマンスを評価できる具体的で検証可能な結果の観点から説明する必要があります。
4. 分解が正しいことを確認する
1. 最下位の要素はプロジェクトの分解に必要かつ十分ですか?
2. 各構成要素の定義は明確かつ完全ですか? 不完全な場合は、説明を変更または拡張する必要があります。
3. 各コンポーネントを適切にスケジュールし、予算を立てることができますか?部門、プロジェクト チーム、個人などの特定の組織単位が責任を受け入れ、満足のいく作業を実行できるかどうか。そうでない場合は、合理的な管理制御を確保するために必要な修正を行う必要があります。
原則として：
1. あらゆるレベルでプロジェクトの整合性を維持し、重要なコンポーネントの欠落を回避します。
2. ワークユニットの機能は、相互従属を避けるために上位レベルのユニットに従属します。
3. 同じレベルのワークユニットは同じプロパティを持つ必要があります。
4. 作業単位は、異なる責任者と異なる作業内容を分離できる必要があります。
5. 管理者はプロジェクトの管理と制御を促進する必要がある
6. 最下位レベルの作業は比較可能で、管理可能で、定量的に検査可能である必要があります。
7. 外部への作業を含むプロジェクト管理作業を含める必要がある
8. WBS の最下位の作業単位は作業パッケージです。
2. 作業分解構造テンプレート
3. WBSにおけるワークパッケージのフォーマット
Project2003 - 「プロジェクトの範囲を決定する」
4.ローリングウェーブプラン
短期作業計画はより詳細にする必要があり、長期作業計画はより一般的である必要があります。進歩的なディテール
入力：
1. プロジェクト範囲の詳細な記述
2. プロジェクト管理計画
3. 組織プロセス資産
出力：
1. WBSとWBS辞典
WBS 辞書は、WBS のサポート ファイルであり、WBS の各要素を説明するために使用されます。各要素はコンテンツを説明する必要があります。
1. 番号
2. 名前
3. 作品説明
4. 関連活動一覧
5. マイルストーンリスト
6. 主催組織
7. 開始時間と終了時間
8. リソース要件、コスト見積もり、耐荷重
9. 仕様
10. 契約情報
11. 作業品質に関する品質要求事項および技術参考資料
2. スコープのベンチマーク
承認された詳細なプロジェクト スコープ ステートメントと、それに関連する WBS および WBS ディクショナリが、プロジェクト スコープのベースラインとなります。スコープ ベースラインはプロジェクト管理計画の不可欠な部分です。
3. 更新されたプロジェクト管理計画
プロジェクト関係者の要件文書
プロジェクト管理計画
スコープのベースライン:
プロジェクト スコープ ステートメント、関連する WBS、および WBS ディクショナリは、プロジェクトのスコープ ベースラインとして機能し、ライフ サイクル全体を通じて、このスコープ ベースラインが監視、検証、確認されます。
一般的に、顧客などのプロジェクトの利害関係者はプロジェクトの成果物のレベルでスコープの変更を提案し、プロジェクトの成果物はプロジェクトのスコープステートメントに正式に詳細に記述されます。
プロジェクト管理チームは、変更管理プロセスに従い、変更管理委員会の承認を得て、プロジェクトのWBSを変更前後で比較し、変更が進捗状況、コスト、コストに与える影響を確認します。プロジェクトの品質への影響を具体的に評価し、対応する変更措置を講じることができます。
WBS の最小単位は作業パッケージであり、作業範囲の定義、プロジェクト組織の定義、プロジェクト製品の品質と仕様の設定、コストの見積もりと管理、時間の見積もりと進捗のスケジュール設定の基礎となります。
4. 範囲の確認
完了したプロジェクト成果物の正式な受諾を確認します。スコープ検証のプロセスにもなります。
ツールとテクニック
診る
作業や成果物が要件や製品の受け入れ基準を満たしているかどうかを判断するための、測定、テスト、検証などのタスクが含まれます。
入力：
1. プロジェクト管理計画
1. プロジェクトの範囲に関する記述
2.WBS
3.WBS辞書
2. 成果物
完了または部分的に完了し、品質管理プロセスによって正確性が検証されたプロジェクトの一部。
出力：
1. 許容可能なプロジェクトの成果物と作業
2. アプリケーションの変更
3. WBSとWBS辞書を更新しました
スコープ検証は品質管理とは異なります。スコープ検証は作業結果の受け入れに関するものですが、品質検証は作業結果が正しいかどうかに関するものです。
5. スコープ制御
プロジェクトと製品のスコープのステータスを監視し、スコープの変更を管理します。
要求されたすべての変更と推奨される修正措置が全体的な変更管理プロセスを通じて処理されていることを確認します。
1. 変更の理由
1. 国の産業政策の調整など、プロジェクトの外部環境の変化。
2. プロジェクト範囲の計画が完全かつ詳細ではなく、特定の誤りや脱落が存在します。
3. 新しい技術、新しい方法、新しいソリューションが市場に登場するか、設計者がそれらを提案します。
4. プロジェクトの実施組織そのものが変わる。
5. プロジェクト、プロジェクト製品、またはサービスに対する顧客の要件が変化する。
2. 変更管理の問題に焦点を当てる
1. スコープの変更が発生したかどうかを確認します。
2. 範囲を変更する要因に影響を与え、これらの変更が全会一致で認識されるようにします。
3. プロジェクトの変更が発生した場合、実際の変更を管理します。
ツールとテクニック
1. 偏差分析
実際に完了したプロジェクト範囲などのプロジェクトのパフォーマンスの尺度は、範囲のベースラインに対する変更の程度を評価するために使用されます。
プロジェクト範囲変更管理の重要な側面は、変更の理由と修正措置が必要かどうかを判断することです。
2. 計画を立て直す
3. 制御システムの変更と制御基板の変更
スコープ変更制御のアプローチは、スコープ変更に関連するプロセスを定義することです。必要な書類手続き、是正措置、追跡システム、承認された変更の承認レベルが含まれます。
変更管理システムは、構成管理システムなどの他のシステムと統合して、プロジェクトの範囲を制御します。
プロジェクトが契約の対象となる場合、変更管理システムは関連するすべての契約条件に準拠する必要があります。
変更管理委員会は、変更要求の承認または拒否を担当します。
変更管理システムと変更管理ボードは通常、範囲管理計画に記載されます。プロジェクト管理計画書がない場合は、プロジェクト管理計画書に変更管理システムおよび変更管理板を直接記載します。
4. 構成管理システム
範囲の変更は、プロジェクトの成果物とドキュメントに一連の体系的な変更をもたらします。これらすべてを管理するには、正式な構成管理システムが必要です。
入力：
1. プロジェクト管理計画
1. スコープのベンチマーク
2. 変更管理計画
プロジェクト管理のための定義された変更プロセス
3. 構成管理計画
構成アイテムおよび関連する構成アイテムへの変更を定義する正式な変更管理プロセス
2. 作業実績データ
3. 実績報告
4. 承認された変更リクエスト
出力：
1. 変更リクエスト
スコープ制御の結果により、確認された WBS を変更するための変更要求も生成されます。
変更はプロジェクトの全体的な変更管理プロセスに従って処理される必要があります
2. 仕事のパフォーマンス
3. 組織プロセス資産の更新
4. 更新されたプロジェクト管理計画
1. スコープベースラインの更新
2. 他のベンチマークの更新
プロジェクト管理計画とそのサブ計画に対する変更リクエストは、統合された変更管理を通じて処理されます。
プロジェクト管理に対するプロジェクトスコープの重要性を確認する
1. プロジェクト作業の具体的な範囲と内容を明確に理解して、コスト、時間、リソースの見積もりの精度を向上させるための基礎を築きます。
2. プロジェクト範囲の決定は、プロジェクトの具体的な作業タスクを決定することです。これは、責任を明確に分割し、タスクを割り当てるのに役立ち、作業とタスクをさらに配置するための基礎を築きます。プロジェクトの範囲の管理と制御はプロジェクト管理計画の一部であり、すべての計画の基礎となります。
プロジェクト マネージャーにとって、最も重要なことは、プロジェクト スコープを正しく明確に定義し、プロジェクト スコープの変更を管理することです。そうしないと、コストの超過やスケジュールの遅延が発生します。目標からの逸脱がプロジェクトの失敗につながる
プロジェクト範囲の完了は、プロジェクト管理計画に基づいて測定されます。製品範囲の完了は、製品要件に基づいて測定されます。必要な製品を満たせるように、プロジェクト スコープ管理プロセスを他の知識領域のプロセスと統合する必要があります。