Wondershare EdrawMind
マインドマップギャラリー 情報システム プロジェクト マネージャー チュートリアル (第 4 版) 第 9 章_プロジェクト スコープ管理
- 4
情報システム プロジェクト マネージャー チュートリアル (第 4 版) 第 9 章_プロジェクト スコープ管理
このファイルは、情報システムプロジェクトマネジメントチュートリアル（第4版）の「第9章_プロジェクトスコープ管理」のマインドマップを自作したものです。スコープ管理の計画、要件の収集、スコープの定義、WBS の作成、スコープの確認、スコープの制御などが含まれます。過去問の要点に沿って重要度をマークし、すべての内容を詳細に統合しているため、半分の労力で最後の復習と学習の開始をより効果的に行うことができます。私は 10 時間以上かけて、すべての章を読んで要約し、すべて最新版を作成しました。
2023-12-13 09:39:36 に編集されました
- おすすめ
- アウトライン
プロジェクトの範囲管理
管理の基本
プロジェクト スコープ管理には、プロジェクトを正常に完了するために必要なすべての作業をプロジェクトが確実に実行し、実行するだけであることを保証することが含まれます。
プロジェクト スコープ管理は主に、プロジェクトに含めるべき作業とプロジェクトに含めるべきではない作業を定義および制御することです。
スコープの意味
製品の範囲
製品、サービス、成果物の特性や機能を指します。
完成度は製品要件に照らして評価されます
「要件」とは、特定の契約またはその他の必須仕様に従って、製品、サービス、または結果が備えていなければならない条件または機能を指します。
プロジェクト範囲
指定された機能を備えた製品、サービス、または結果を提供するために実行する必要がある作業
完了はプロジェクト管理計画 (範囲ベースライン) に照らして評価されます。
1. 製品のスコープが変更された場合、プロジェクトのスコープは必ずしも変更されない可能性があります。 例: 壁をペイントする場合、製品はペイントされた壁であり、プロジェクトは壁をペイントしています。ペイントの色の変更は、プロジェクト内の特定の作業には影響しません。 2. プロジェクトのスコープが変更された場合、製品のスコープは必ずしも変更されない可能性があります。 たとえば、ソフトウェアを製品として開発する場合、プロジェクトはソフトウェアを提供するために必要な作業です。ソフトウェアにテストのラウンドが追加された場合、プロジェクトの範囲は変更されますが、製品の範囲は変更されません。
新しい管理慣行
ビジネスアナリスト (BA)
プロジェクトにビジネス アナリストがいない場合は、プロジェクト マネージャーとコア開発者が要件管理関連のアクティビティを担当することができます。
需要管理に関連する活動を担当します
プロジェクトマネージャー
要件管理関連の活動がプロジェクト管理計画に確実に含まれるようにする責任があります。
ビジネス アナリストとプロジェクト マネージャーの間にはパートナーシップが必要です
管理プロセス
調整に関する考慮事項には以下が含まれます:
知識と要件の管理、検証と制御、開発方法、要件の安定性、ガバナンス
アジャイルで適応的な手法
アジャイルまたは適応型プロジェクト
大量の変更に対処するように設計され、プロジェクトへの継続的な関係者の関与を必要とする、アジャイルまたは適応型のライフサイクルを採用します。
アダプティブ プロジェクトの全体的な範囲は、実装すべき一連の要件と実行すべき作業 (製品バックログ) に分割され、成果物は複数の反復にわたって開発され、各反復の開始時に詳細な仕様が定義および承認される必要があります。
各反復は機能します
プロジェクト チームは 3 つのプロセスを繰り返します
要件の収集、範囲の定義、WBS の作成
スポンサーと顧客担当者は 2 つのプロセスを繰り返します
範囲確認、制御範囲
予測（ウォーターフォール）プロジェクト
承認されたプロジェクト スコープ ステートメント、作業分解構造 (WBS)、および対応する WBS ディクショナリがプロジェクト スコープ ベースラインを構成します。
ベースラインの変更は、正式な変更管理プロセスを通じてのみ行うことができます
計画範囲管理
プロセスの概要
意味
プロジェクトスコープと製品スコープをどのように定義、確認、管理するかを記録するためにスコープ管理計画を作成するプロセスです。
主効果
プロジェクト全体でスコープを管理する方法についてのガイダンスと指示を提供する
このプロセスは 1 回だけ、またはプロジェクト内の事前定義された時点でのみ実行されます。
スコープ管理計画
意味
プロジェクトの範囲をどのように定義、開発、監視、制御、検証するかを説明するプロジェクトまたはプログラム管理計画のコンポーネント。
配合および精製時に分析が必要
1. プロジェクト憲章の情報
2. プロジェクト管理計画で承認されたサブプラン
3. 組織プロセス資産の履歴情報
4. 関連する事業環境要因
入力
1. プロジェクト計画書
プロジェクトの目的、プロジェクトの概要、前提条件、制約、およびプロジェクトが達成したい高レベルの要件を文書化します。
2. プロジェクト管理計画
1. 品質管理計画
組織の品質ポリシー、方法、基準がプロジェクトにどのように実装されるかは、プロジェクトと製品範囲の管理方法に影響します。
2. プロジェクトのライフサイクルの説明
3. 開発手法
3. キャリアに影響を与える要因
組織文化、インフラ、人事管理制度、市場環境等
4. 組織プロセス資産
政策と手順、過去の情報と教訓の知識ベースなど。
ツールとテクニック
専門家の判断
データ分析
代替分析手法
要件の評価、収集、プロジェクトと製品の範囲の詳細化、製品の作成、範囲の検証、および範囲の制御のためのさまざまな方法
ミーティング
出力
1. スコープ管理計画
意味
プロジェクトの範囲をどのように定義、開発、監視、制御、検証するかを説明するプロジェクト管理計画のコンポーネントです。
プロジェクトのニーズに応じて、範囲管理計画は公式または非公式、非常に詳細な計画または高レベルの計画になります。
指導（フォロー）業務
1. プロジェクトスコープステートメントの作成 (スコープの定義)
2. 詳細なプロジェクトスコープステートメントに基づいてWBSを作成する（WBSの作成）
3. 完了したプロジェクト成果物の正式な受領（範囲の確認）
4. スコープベースライン（コントロールスコープ）を承認および維持する方法を決定する
2. 需要管理計画
意味
要件をどのように分析、文書化、管理するかを説明するプロジェクト管理計画の不可欠な部分です。
メインコンテンツ
1. さまざまな要件アクティビティを計画、追跡、レポートする方法
2. 構成管理アクティビティ (変更の開始方法、変更の影響の分析方法、トレーサビリティ、追跡およびレポートの実行方法、変更の承認権限など)
3. 要件の優先順位付けプロセス
4. 測定すべき指標とそれを使用する理由
需要は定量化可能 (測定可能) である必要があります。たとえば、ページの応答速度は 2 秒を超えません。
5. どの要件属性が追跡マトリックスに含まれるかを反映します
要件を収集する
プロセスの概要
意味
目標を達成するために利害関係者のニーズと要望を特定、文書化、管理するプロセスです
主効果
製品範囲とプロジェクト範囲を定義するための基礎を築く
必要
意味
特定の契約またはその他の必須仕様に基づいて、製品、サービス、または結果が持たなければならない条件または機能
含む
スポンサー、顧客、その他の利害関係者のニーズと期待を定量化および文書化
対処する
これらの要件を十分に詳細にマイニング、分析、文書化し、プロジェクトの実行開始後に測定される範囲のベースラインに含めます。
フォローアップ効果
作業分解構造 (WBS) の基礎として機能し、コスト、スケジュール、品質、調達計画の基礎として機能します。
入力
1. プロジェクト管理文書
これは、要件を収集するプロセスに影響を与えるビジネス ケースによって生成される文書で、ビジネス ニーズを満たすために満たすべき必要な基準、期待される基準、およびオプションの基準が説明されています。
2. プロジェクト計画書
高レベルの要件
詳細な要件を策定するために使用されます（ステップバイステップの詳細化）
3. プロジェクト管理計画
1. スコープ管理計画
2. 需要管理計画
3. ステークホルダーエンゲージメント計画
要件活動へのステークホルダーの関与を評価および適応するために、計画からステークホルダーのコミュニケーションのニーズと関与レベルを理解します。
4. プロジェクトファイル （工程出力による分類）
1. プロジェクト憲章の作成
仮説ログ
製品、プロジェクト、環境、利害関係者、および要件に影響を与えるその他の要因に関する仮定が特定される
2. プロジェクトの知識の管理
教訓登録
特にアジャイルまたはアダプティブな製品開発手法を使用するプロジェクトに、効果的な要件収集テクニックを提供します。
3. 利害関係者の特定
利害関係者登録簿
どの利害関係者が要件情報を提供できるかを理解し、プロジェクトに対する利害関係者のニーズと期待を記録するために使用されます。
5. プロトコル
6. キャリアに影響を与える要因
組織文化、インフラ、人事管理体制、市場環境等
7. 組織プロセス資産
ポリシーと手順、過去のプロジェクトなどの情報を含む歴史的情報と教訓の知識ベース。
ツールとテクニック
1. 専門家の判断
実現可能性の調査と評価。同様の以前のプロジェクトからの要件の分析。
2. データ収集
ブレーンストーミング、インタビュー、フォーカス グループ、アンケート、ベンチマーク
3. データ分析
ファイル分析
既存のドキュメントを分析し、要件に関連する情報を特定して要件を取得します。
4. データパフォーマンス
親和図（グループ化と分類）、マインドマップ（統合）
5. 意思決定
投票 (製品要件の生成、分類、およびランク付けのため)、権威主義的な意思決定、多基準の意思決定分析
6. 対人スキルとチームスキル
1. 名目上のグループ手法
最初にブレインストーミングを行ってから、投票してランク付けします
2. 観察して話す
隠れたニーズを掘り起こす可能性がある
3. ガイド
主要な関係者を集めて要件を定義するためにトピックワークショップと組み合わせて使用されます。
7. システム相互作用図
ビジネス システム (プロセス、機器、コンピューター システムなど) と、それらが人々や他のシステム (アクター) とどのように対話するかを視覚化する製品範囲の視覚的な描写
8. プロトタイプメソッド
意味
実際に製品を製造する前に、目的の製品のプロトタイプを構築し、要件に関する早期フィードバックを求めることを指します。
含む
ミニチュア、コンピュータ生成の 2 次元および 3 次元モデル、モックアップまたはシミュレーション
道具
アシュア
試作技術
絵コンテ
一連の画像や図を通してシーケンスやナビゲーション パスをデモンストレーションする
出力
要件文書
効果
さまざまな単一要件がプロジェクト関連のビジネス要件 (高レベルの要件) をどのように満たすかを説明する
基準
明確で (測定可能でテスト可能)、追跡可能で、完全で、調整され、主要な関係者によって認識されている要件
要件のカテゴリ
1. ビジネスニーズ
ビジネス上の問題を解決したい、ビジネスチャンスを掴みたいなど、組織全体の高度なニーズとそのプロジェクトに取り組む理由
2. ステークホルダーのニーズ
ステークホルダーのニーズ
3. ソリューションの要件
システム要件。ビジネス ニーズやステークホルダーのニーズを満たすために、製品、サービス、または結果が備えていなければならない機能、機能、特性。
さらに分かれる
機能要件
製品に必要な機能について説明する
例: 製品が実行するアクション、プロセス、データ、およびインタラクション
非機能要件
これは機能要件を補足するものであり、製品の通常の動作に必要な環境条件または品質要件です。
例: 信頼性、機密性、パフォーマンス、セキュリティ、サービス レベル、サポート性、保持または削除など。
4. 移行と準備のニーズ
データ変換やトレーニング要件など。「現在の状態」から「将来の状態」に移行するために必要な一時的な機能を記述します。
5. プロジェクトの要件
マイルストーンの日付、契約上の義務、制約など、プロジェクトが満たす必要があるアクション、プロセス、またはその他の条件。
6. 品質要件
プロジェクトの成果物の正常な完了、またはテスト、認証、検証などの他のプロジェクト要件の達成を確認するために使用される条件または基準。
要件追跡マトリックス
意味
製品要件をそのソースからその要件を満たす成果物に結び付けるフォーム
効果
各要件をビジネス目標またはプロジェクト目標にリンクすると、各要件にビジネス価値があることが保証されます。
プロジェクトのライフサイクル全体にわたって要件を追跡する方法を提供し、要件文書内の承認された各要件がプロジェクトの終了時に確実に実装および提供されるように支援します。
製品範囲の変更を管理するためのフレームワークも提供します
要件を追跡する
1. ビジネスのニーズ、機会、目標および目的
2. プロジェクトの目的
3. プロジェクトの範囲と WBS 成果物
4. 製品デザイン
5. 製品開発
6. テスト戦略とテストシナリオ
中級事例分析テストの穴埋め問題に合格
7. 大まかな要件から詳細な要件まで
レコードの一般的なプロパティ
一意の識別子、要件のテキスト説明、要件を含める理由、所有者、ソース、優先度、バージョン、現在のステータス、およびステータスの日付
範囲を定義する
プロセスの概要
意味
プロジェクトと製品の詳細な説明を作成するプロセスです
主効果
製品、サービス、または結果の境界と許容基準を説明する
プロジェクト全体で何度も繰り返す必要がある
範囲の定義プロセスでは、要件文書 (要件の収集プロセスの出力) から最終的なプロジェクト要件を選択し、プロジェクトとその製品、サービス、または結果の詳細な説明を作成する必要があります。
既存のリスク（リスク登録）、仮定と制約（仮定ログ）の完全性を分析し、必要な追加または更新を行う必要があります。
プロジェクト範囲の詳細な記述
プロジェクトの成功に不可欠な
詳細なプロジェクト スコープ ステートメントは、プロジェクトの開始時に文書化された主要な成果物、前提条件、制約に基づいて準備する必要があります。
プロジェクト計画のプロセスでは、プロジェクト情報の理解が徐々に深まるにつれて、プロジェクトの範囲をより詳細かつ具体的に定義および説明する必要があります。
入力
1. プロジェクト計画書
プロジェクト、製品の特性、承認要件の概要が記載されています。
2. プロジェクト管理計画 - 範囲管理計画
プロジェクトのスコープを定義、確認、制御する方法を文書化
3. プロジェクトファイル （工程出力による分類）
1. プロジェクト憲章の作成
仮説ログ
製品、プロジェクト、環境、利害関係者、およびプロジェクトと製品範囲への影響に関する特定された前提条件と制約事項
2. 要件を収集する
要件文書
範囲に含めるべき要件が特定される
3. リスクを特定する
リスクレジスター
リスクを回避または軽減するためのプロジェクトおよび製品の範囲の縮小または変更など、プロジェクトの範囲に影響を与える可能性のある対応戦略が含まれます。
4. キャリアに影響を与える要因
組織文化、インフラ、人事管理体制、市場環境等
5. 組織プロセス資産
プロジェクト スコープ ステートメントを作成するために使用されるポリシー、手順、およびテンプレート。以前のプロジェクトから得られた教訓など。
ツールとテクニック
1. 専門家の判断
同様のプロジェクトの知識や経験を持つ個人またはグループからアドバイスを求める必要があります。
2. データ分析
代替案の分析
プロジェクト憲章に記載されているニーズと目標を達成するためのさまざまなアプローチを評価する
3. 意思決定
多基準の意思決定分析
意思決定マトリックスの助けを借りてシステム分析手法を使用し、要件、スケジュール、予算、リソースなどの基準を確立し、プロジェクトと製品の範囲を絞り込む手法
4. 対人スキルとチームスキル
ガイド
5. 製品分析
効果
製品やサービスを定義するために使用されます。これには、提供される製品の目的、特性、その他の側面を説明するために、製品やサービスに関する質問と回答が含まれます。
高レベルの製品またはサービスの説明を意味のある成果物に変換する
ステップ
高レベルの要件を取得する
最終的な製品設計に必要な詳細レベルまで洗練します。
テクノロジーには以下が含まれます
製品分解、需要分析、システム分析、システムエンジニアリング、価値分析、価値工学など
出力
プロジェクトスコープステートメント
意味
プロジェクトの範囲、主要な成果物、前提条件、制約の説明
効果
プロジェクトおよび製品の範囲を含む範囲全体を文書化し、プロジェクトの成果物の詳細を示し、プロジェクトの範囲に関するプロジェクト関係者間の合意を表します。
コンテンツ
1. 製品範囲の説明
プロジェクト憲章および要件文書に記載されている製品、サービス、または成果の特性を徐々に改善します。
2. 成果物
プロセス、フェーズ、またはプロジェクトを完了するために作成する必要がある独自の検証可能な製品、結果、またはサービス機能には、プロジェクト管理レポートやドキュメントなどのさまざまな補助結果も含まれます。成果物の説明は簡潔な場合もあれば、詳細な場合もあります
3. 合否基準
成果物が受け入れられる前に満たさなければならない一連の条件
一対一の対応
4. プロジェクトの除外
当事者 A のために情報管理システムを構築するがサーバーを提供しないなど、意見の相違や誤解が生じやすい領域は避けてください。これはプロジェクトの除外項目にマークする必要があります。
プロジェクトから除外されるものを特定します。何がプロジェクトの範囲外であるかを明確に示し、関係者の期待を管理し、範囲のクリープを軽減します。
5. 仮定
6. 制約
プロジェクト憲章との関連性と相違点
プロジェクト計画書
高度な情報が含まれています
スコープステートメント
プロジェクトの過程で徐々に詳しく説明する必要があるスコープのコンポーネントの詳細な説明
内容的には重複する部分もありますが、詳細度は全く異なります
実行する作業と実行しない作業の詳細レベルによって、プロジェクト管理チームがプロジェクトの範囲全体をどれだけ効果的に制御できるかが決まります。
プロジェクトファイル (更新済み)
1. 要件文書
2. 要件追跡マトリックス
要件プロセスの出力を収集する
3. 仮説ログ
4. 利害関係者登録簿
WBSの作成
プロセスの概要
意味
プロジェクトの成果物とプロジェクトの作業を、より小さく管理しやすいコンポーネントに分割するプロセスです
主効果
提供される内容の構造を提供する
WBS （作業分解図）
意味
これは、プロジェクトの目標を達成し、必要な成果物を作成するためにプロジェクト チームが実行する必要があるすべての作業範囲を階層的に分類したものです。
「仕事」の意味
アクティビティ自体ではなく、アクティビティの結果である作業成果物または成果物を指します。
ワークパッケージ
WBS の最下位レベルのコンポーネントは作業パッケージと呼ばれ、計画された作業が含まれます。
作業パッケージは関連するアクティビティを分類して、作業の手配、見積もり、監督、制御を容易にします。
最小の成果物です
WBS は、プロジェクトの全体的な範囲を整理および定義し、承認された現在のプロジェクト範囲ステートメントで指定された作業を表します。
入力
プロジェクト管理計画 - 範囲管理計画
プロジェクトのスコープステートメントに基づいて WBS を作成する方法を定義します。
プロジェクトファイル （工程出力による分類）
1. 要件を収集する
要件文書
さまざまな単一要件がプロジェクトのビジネス ニーズをどのように満たすかについての詳細な説明
2. 範囲を定義する
プロジェクトスコープステートメント
実行する必要がある作業とプロジェクトに含まれない作業について説明します。
キャリアに影響を与える要因
プロジェクトが属する業界の WBS 標準。これらの標準は WBS 作成の外部参考資料として使用できます。
組織プロセス資産
以前のプロジェクトから学んだプロジェクト ファイルを作成するためのポリシー、手順、テンプレートなど。
ツールとテクニック
専門家の判断
同様のプロジェクトの知識や経験を持つ個人またはグループからの意見を求める
壊す
概要
意味
プロジェクトの範囲とプロジェクトの成果物を、より小さく管理しやすいコンポーネントに段階的に分割する手法です。
ワークパッケージ
意味
WBS コストと期間を見積もって管理できる最低レベルの作業
詳細レベル
プロジェクトの規模と複雑さによって異なります
分解の程度
プロジェクトの効率的な管理を達成するために必要な制御の程度に応じて
WBSの作り方
1. トップダウンのアプローチ
下位レベルのコンポーネントをマージするために使用できます
2. 組織固有のガイダンスを使用する
3. WBSテンプレートを使用する
分解活動
1. 成果物と関連作業の特定と分析 (成果物と分解する必要がある作業の特定)
2. WBSをどのように構成・整理するかを決定する（内訳構造を決定する）
ツリー構造（組織図）：小規模プロジェクトに適しています テーブル構造 (アウトライン スタイル): 大規模プロジェクトに適しています
3. トップダウンおよびレイヤーごとの分解 (トップダウンのステップバイステップ分解)
4. 識別コードを開発して WBS コンポーネントに割り当てます (WBS コンポーネントの識別)
5. 成果物が適切な程度に分解されていることを確認（分解のレベルが適切かどうかを確認）
WBSの構造
構造タイプ
1. 分解の第 2 レベルとしてのプロジェクト ライフ サイクルのフェーズ 製品とプロジェクトの成果物は 3 番目のレベルに配置されます
2. 分解の第 2 レベルとしての主な成果物
3. プロジェクト チーム以外の組織 (外部委託された作業など) によって開発されたさまざまな下位レベルのコンポーネントを組み込みます。その後、アウトソーシング作業の一環として、売主は対応する契約書 WBS を作成する必要があります。
外部委託した作業も WBS に含める必要があります
WBS の上位レベルのコンポーネントを分解するとは、各成果物やコンポーネントを最も基本的なコンポーネント (検証可能な製品、サービス、結果) に分解することを意味します。
アジャイルまたは適応型アプローチを使用する場合、WBS は、概要、組織図、または階層を示すその他の形式をとることができます。
さまざまな成果物をさまざまなレベルに分解できます
メリットとデメリットの詳細な内訳
アドバンテージ
作業がより詳細に分割されるほど、作業の計画、管理、および制御がより強力になります。
欠点がある
過度の分解は、管理努力の非効率的な消費、リソースの非効率的な使用、作業の実行効率の低下をもたらし、また、WBS のすべてのレベルでのデータ集約にも困難をもたらします。
予防
1. WBS は成果物指向でなければなりません
プロジェクトの目標は製品またはサービスを提供することであり、WBS の各作業は成果物を提供することです。
2. WBS はプロジェクトの範囲内に収まる必要があります
WBS には、プロジェクトの成果物を完了するために必要なアクティビティのみを含める必要があります。
WBS では、すべての下位レベルの要素の合計が上位レベルの要素の合計を 100% 表す必要があります (100% 原則)
3. WBS の基礎となる層は、計画と管理をサポートする必要があります。
WBS はプロジェクト管理計画とプロジェクト範囲の間の架け橋です
WBS の最下層は、プロジェクト管理計画をサポートするだけでなく、管理者がプロジェクトの進捗状況と予算を監視および制御できるようにする必要があります。
4. 誰かが、ただ 1 人だけが WBS の要素に対して責任を負わなければなりません (独立責任の原則)
責任者は 1 人ですが、複数人が参加することもできます。WBS と責任者は、作業責任マトリックスを使用して記述できます。
5. WBSは4～6階層で管理する必要がある
WBS の各レベルは、前のレベルの要素を 4 ～ 7 つの新しい要素に分割します。同じレベルの要素のサイズは同様である必要があります。
相互従属を避けるために、作業ユニットは上位ユニットにのみ従属できます。
6. WBS には、プロジェクト管理作業 (管理はプロジェクトの特定の作業の一部であるため) と下請け作業を含める必要があります。
7. WBS の作成には、プロジェクトの (主要な) 関係者全員の参加が必要です
8. WBS は静的ではありません
WBS が完成した後も WBS を修正する必要がある場合があり、正式な変更管理プロセスを通じて変更を行う必要があります。
9. 8/80原則
補充する
作業パッケージの期間は 8 ～ 80 時間の間で制御されます
出力
スコープベースライン
意味
承認されたスコープステートメント、WBS、および対応する WBS ディクショナリであり、正式な変更管理プロセスを通じてのみ変更でき、比較の基礎として使用されます。
プロジェクトスコープステートメント
プロジェクトの範囲、主要な成果物、前提条件、制約の説明が含まれます。
WBS
これは、プロジェクト チームがプロジェクトの目標を達成し、必要な成果物を作成するために実行する必要がある作業の全範囲を階層的に分類したものです。
コントロールアカウント
範囲、予算、スケジュールが統合され、達成額と比較してパフォーマンスが測定される管理制御点
含む
ワークパッケージ
WBS の最下位レベルは、一意の識別番号を持つ作業パッケージです。
識別番号
コスト、スケジュール、リソース情報をレイヤーごとに集約するための階層構造、つまりアカウントコーディングを提供します。
コントロール アカウントには 2 つ以上のワーク パッケージが含まれており、各ワーク パッケージは 1 つのコントロール アカウントにのみ関連付けられます。
企画パッケージ
制御アカウントより下位、ワークパッケージより上位の作業分解構造コンポーネントです。作業内容はわかっていますが、詳細な進捗アクティビティは不明です。
制御アカウントには 1 つ以上の計画パッケージを含めることができます
WBS辞書
意味
WBS の各コンポーネントの成果物、アクティビティ、進捗情報を詳しく説明した文書 (WBS の補足)
効果
WBS ディクショナリは、ほとんどの情報が他のプロセスによって作成され、後の段階でディクショナリに追加される WBS をサポートします。
内容には以下が含まれます
アカウントコードの識別、作業の説明、前提条件と制約、責任組織、スケジュールマイルストーン、関連スケジュールアクティビティ、必要なリソース、コスト見積もり、品質要件、合格基準、技術リファレンス、契約情報など。
プロジェクトファイル (更新済み)
仮説ログ
要件文書
範囲の確認
プロセスの概要
プロジェクト全体で使用する必要があります
意味
完了したプロジェクト成果物を正式に承認するプロセスです
主効果
受け入れプロセスを客観的にする
各成果物を検証することで、最終製品、サービス、または結果が受け入れられる可能性が高まります。
プロジェクト全体を通じて必要に応じて定期的に実行する必要があります
参加者
主要な利害関係者、特に顧客またはスポンサーによる (品質管理) コントロール品質プロセスから出力された検証済み成果物のレビュー。これらの成果物が満足に完了し、正式に受け入れられたことを確認します。
範囲確認の根拠
プロジェクト スコープ マネジメントの知識領域の対応するプロセスから得られる出力 (要件文書やスコープ ベースラインなど)
他の知識領域の実行プロセスから取得されたジョブパフォーマンスデータ
範囲を確認する手順
考えられるランキング
1. スコープ検証が必要な場合を決定する
2. スコープの検証に必要な入力を特定する
3. 正式に受け入れられた範囲設定の基準と要素を決定する
4. スコーピング会議の組織的な手順を決定する
5. 組織範囲確認会議
管理品質プロセスとの比較
範囲確認プロセスは成果物の受け入れに焦点を当てますが、品質管理プロセスは成果物の正確さと品質要件を満たしているかどうかに焦点を当てます。
通常、プロジェクトチームはスコープを確認する前に、まず品質管理作業を行う必要があります（最初に品質管理を行い、次にスコープを確認します）。たとえば、ソフトウェアプロジェクトのスコープを確認する前に、システムテストなどの作業を実行する必要があります。完了確認作業のスムーズさを確保します。
通常、品質の制御プロセスはスコープの検証プロセスに先行しますが、同時に実行することもできます。
確認すべき問題
ケース分析に合格しました
1. 成果物が確実で確認可能かどうか
2. 各成果物に明確なマイルストーンがあるかどうか、またそのマイルストーンに顧客からの書面による承認などの明確で識別可能なイベントがあるかどうか。
3. 明確な品質基準はありますか？
成果物の納品には、明確な基準があるだけでなく、要求どおりに完了しているかどうか、成果物とその基準の間に明確な関連性があるかどうかに関する基準も必要です。
4. レビューと約束は明確に表現されていますか?
スポンサーは、プロジェクトの境界、プロジェクトによって完成する製品またはサービス、およびプロジェクト関連の成果物について正式に合意する必要があります。
プロジェクト チームは成果物が何であるかを明確に理解する必要があります
5. プロジェクトの範囲は、製品またはサービスのために完了する必要があるすべてのアクティビティをカバーしていますか? 漏れや間違いはありますか?
6. プロジェクト範囲のリスクが高すぎますか?
リスクが発生した場合に経営陣がプロジェクトへの影響を軽減できるかどうか
利害関係者の焦点の違い
1. 管理は主にプロジェクトの範囲に焦点を当てます
プロジェクトの進行状況、資金、リソースに対する範囲の影響を指し、これらの要因が組織の許容範囲を超えているかどうか、またインプットとアウトプットが妥当であるかどうかを指します。
2. 顧客は主に製品範囲に焦点を当てています
プロジェクトの成果物が製品またはサービスを完成させるのに十分であるかどうかを懸念している
3. プロジェクトマネージャーは主にプロジェクトの制約に焦点を当てます
プロジェクトの成果物が十分であり完了する必要があるかどうか、時間、資金、リソースが十分であるかどうか、主な潜在的なリスクと準備された解決策が適切であるかどうかに注意します。
4. プロジェクト チームのメンバーは、主に、自分たちが関与し、責任を負うプロジェクト範囲の要素に焦点を当てます。
スコープ内の時間を定義して作業時間が十分かどうか、プロジェクトのスコープ内に複数のタスクがあるかどうか、およびこれらのタスク間に競合がないかどうかを確認します。
入力
プロジェクト管理計画
1. スコープ管理計画
完成した成果物がどのように正式に受け入れられるかを定義します
2. 需要管理計画
プロジェクト要件を特定する方法について説明します
3. スコープベースライン
スコープのベースラインと実際の結果を比較して、変更、是正措置、または予防措置が必要かどうかを判断します。
プロジェクトファイル （工程出力による分類）
1. 要件を収集する
要件文書
要件と実際の結果を比較して、変更、是正措置、または予防措置が必要かどうかを判断します。
要件追跡マトリックス
要件の確認方法など、要件に関する情報が記載されています。
2. 経営品質
品質レポート
コンテンツには、チームによって管理されている、またはエスカレーションが必要なすべての品質保証問題の概要、改善のための提案、および品質管理中に発見された状況が含まれる場合があります。
3. プロジェクトの知識の管理
教訓登録
プロジェクトの初期段階で学んだ教訓を後の段階に適用して、成果物の受け入れの効率と有効性を向上させることができます。
仕事のパフォーマンスデータ
要件への適合度、不一致の数、不一致の重大度、または一定期間内に実施された確認の回数を含む
検証された成果物
完成し、品質管理プロセスによって正しいことが確認された成果物を指します。
ツールとテクニック
検査（レビュー、製品レビュー、検査）
測定、レビュー、検証などの活動を実施して、作業と成果物が要件と製品の受け入れ基準を満たしているかどうかを判断します。
意思決定
出力
受領のための成果物
受入基準を満たす成果物については、正式な文書が作成され、顧客またはスポンサーによって正式に署名および承認される必要があります。
変更要求
完了したが正式な承認に合格していない成果物と失敗の理由を文書化する必要があります。これらの成果物に対する変更リクエストを提出し、対応する欠陥修正作業を実行する必要がある場合があります。
仕事のパフォーマンス情報
どの成果物が受け入れられ、どの成果物が失敗したか、そしてその理由など、プロジェクトの進捗情報を含めます。この情報を記録し、関係者に渡します
プロジェクトファイル (更新済み)
1. 要件文書
実際の合格結果を記録し、要件文書を更新する
2. 要件追跡マトリックス
使用された受け入れ方法とその結果を含む、受け入れ結果に基づいて要件追跡マトリックスを更新します。
3. 教訓登録
制御範囲
プロセスの概要
意味
これは、プロジェクトと製品のスコープのステータスを監視し、スコープのベースラインへの変更を管理するプロセスです。
主効果
プロジェクト全体を通じてスコープのベースラインを維持する
プロジェクト全体を通じて実行する必要がある
制御範囲のプロセスは、他のプロジェクト管理知識領域の制御プロセスと調整する必要があります。
変更の管理
プロジェクトの範囲を制御することで、すべての変更要求、推奨される是正措置、または予防措置が、全体的な変更管理プロセスの実装を通じて確実に対処されるようになります。
スコープクリープ
製品またはプロジェクトの範囲が制御されずに拡大する (時間、コスト、リソースの対応する調整が行われない)
入力
プロジェクト管理計画
1. スコープ管理計画
プロジェクトと製品範囲を管理する方法を文書化
2. 需要管理計画
プロジェクト要件の管理方法を文書化
3. 変更管理計画
プロジェクトの変更を管理するための定義されたプロセス
4. 構成管理計画
どの構成アイテムが構成アイテムであるか、どの構成アイテムが正式な変更管理を必要とするか、およびこれらの構成アイテムの変更管理プロセスを定義します。
5. スコープベースライン
スコープのベースラインと実際の結果を比較して、変更、是正措置、または予防措置が必要かどうかを判断します。
6. パフォーマンス測定ベンチマーク
達成額分析を使用すると、パフォーマンス測定のベースラインが実際の結果と比較され、変更、是正措置、または予防措置が必要かどうかが判断されます。
プロジェクトファイル （工程出力による分類）
1. プロジェクトの知識の管理
教訓登録
2. 要件を収集する
要件文書
合意されたプロジェクトまたは製品の範囲からの逸脱を特定するために使用されます
要件追跡マトリックス
プロジェクト目標に対する変更や範囲ベースラインからの逸脱の影響を調査するのに役立ち、管理された要件のステータスも提供します。
仕事のパフォーマンスデータ
受信した変更リクエストの数、受け入れられた変更リクエストの数、または検証、検証、および完了した成果物の数が含まれます。
組織プロセス資産
範囲管理に関連する既存の公式および非公式のポリシー、手順、ガイドライン、利用可能な監視および報告方法およびテンプレートなど。
ツールとテクニック
データ分析
偏差分析
ベースラインと実際の結果 (業務パフォーマンス データ) を比較して、逸脱が臨界値の範囲内にあるかどうか、または修正措置または予防措置が必要かどうかを判断します。
トレンド分析
プロジェクトのパフォーマンスを長期的にレビューして、パフォーマンスが向上しているか低下しているかを判断します。
スコープのベースラインからの逸脱の原因と範囲を特定し、是正措置または予防措置を講じる必要があるかどうかを決定することは、プロジェクト スコープ管理の重要なタスクです。
出力
仕事のパフォーマンス情報
プロジェクトおよび製品スコープの実装に関する相互関連およびコンテキスト情報 (スコープ ベースラインに対する)
含む
受け取った変更の分類、特定されたスコープの逸脱と原因、スケジュールとコストに対する逸脱の影響、および将来のスコープのパフォーマンスの予測が含まれます。
変更要求
プロジェクト管理計画 (更新)
1. スコープ管理計画
2. スコープベースライン
スコープ、スコープステートメント、WBS、または WBS ディクショナリへの変更が承認されたら、スコープ ベースラインへの対応する変更が必要になります。
3. 進行状況のベースライン
スコープ、リソース、またはスケジュールの見積もりへの変更が承認された後は、スケジュール ベースラインへの対応する変更が必要になります
4. 原価ベース
範囲、リソース、またはコスト見積もりの変更が承認された後、コストのベースラインにも対応する変更を加える必要があります。
5. パフォーマンス測定ベンチマーク
範囲、スケジュールパフォーマンス、またはコスト見積もりの変更が承認された後、パフォーマンス測定のベースラインにも対応する変更が必要です
偏差が大きすぎる場合は、ベンチマークを再確立する必要があります。
プロジェクトファイル (更新済み)
1. 要件文書
要件を追加または変更する
2. 要件追跡マトリックス
要件ドキュメントの変更
3. 教訓登録
エクササイズ
正解は C です。管理範囲のプロセスでは、それぞれの管理プロセス自体が重なり合い、相互作用するため、範囲が変更されると、スケジュール、コスト、品質が変化するため、これらのプロセスを統合する必要があります。
オプション B. プロジェクトの実行組織の変更により、プロジェクトの範囲が変更される可能性があります。組織内の人物が退職したが、その人だけがプロジェクト内の特定の職務に就く資格がある場合、その職務は、次の理由が決まるまで一時的に保留する必要があります。従業員の代わりに新しい人が見つかりました。