マインドマップギャラリー PMP-05 プロジェクトのスコープ管理
第 5 章 プロジェクトのスコープ管理、 PMPプロジェクトマネジメント、PMBOK第6版知識構造組織、 (PMBOK 第6版) 勉強や試験対策に必須の49のプロセステスト、 PMPの10の知識領域、5つのプロセスグループのインプットとアウトプット、 PMP 試験 - ナレッジ ポイントのレビュー (PMBOK 第 6 版)。
2019-08-26 09:16:00 に編集されました05 件 スコープ管理
5.1 計画範囲管理
目的: プロジェクトの範囲を定義、検証、制御する方法を文書化する
入力
プロジェクト憲章、プロジェクト管理計画: 品質管理計画
ツールとテクニック
専門家の判断
データ分析
代替案の分析
要件の分析と収集、スコープ管理の実行に使用されます 複数の選択肢と選択
ミーティング
範囲管理計画と要件管理計画を作成するための会議を開催します。
出力
スコープ管理計画
スコープステートメント、WBS、WBS辞書の書き方
誰がスコープベースラインを承認し、成果物はどのように承認されるのでしょうか?
需要管理計画
要件の収集にどのような方法が使用されるか、要件のランク付けにどのような基準が使用されるか、要件の実装を追跡する方法
5.2 要件を収集する
目的:関係者のニーズを収集し、具体的なプロジェクトのニーズに変換して記録する
要件は測定可能でなければなりません
入力
プロジェクト憲章、要件管理計画、範囲管理計画、利害関係者関与計画
利害関係者名簿、仮定記録、ビジネス文書、契約書/契約書
ツールとテクニック
専門家の判断
対人スキルとチームスキル
名目上のグループ手法
シーケンスのブレインストーミング
観察して話す
作業をフォローし、待機して観察したり、観察に参加したりできます
ガイド
部門や分野を超えた関係者が代表者を派遣してニーズを議論し、 いくつかの国境を越えた要件を特定し、矛盾する要件を調整するため
データ収集 要件を収集する
ブレーンストーミング
複数の人々が対面してブレインストーミングを行い、できるだけ多くのアイデアを出します
インタビュー
何が必要かを直接本人に尋ねる
フォーカスグループ
同じような背景を持つ 6 ~ 10 人を会議に参加するよう呼びかけ、主催者をターゲットにさせます 質問について話し合い、グループ全体の意見を得る
アンケート
多くの回答者から要件を迅速に収集
ベンチマーク
内部または外部のローカル コントラスト
データ分析
ファイル分析
現地調査
個人調査方法、集団調査方法、接触比較方法
システム相互作用図
製品範囲を視覚的に表現したもの
業務システムの入出力を表示します。
プロトタイプメソッド
プロトタイピング、ユーザー エクスペリエンス、フィードバックの収集、プロトタイプの修正。
データパフォーマンス
親和性図
ブレーンストーミングの大量の要件を分類します。
親和図により、潜在的な欠陥の原因を分類し、最も懸念される領域を示すことができます
マインドマッピング
ブレーンストーミングのアイデアを画像に統合して、共通点と相違点を反映し、新しいアイデアを刺激します。
意思決定
投票する
計画に対する集団的な評価決定を行います。
多基準の意思決定分析
意思決定マトリックスを使用して優先順位を付ける
デルフィ技法
匿名投票、専門家は 1 つだけの投票を行う必要があります
アンケートによる複数回のフィードバック
コンセンサスに達することは、個人的な偏見を軽減するのに役立ちます。
出力
要件文書
内容:シリアル番号、要件説明、分類、仕分け、合格基準、合格方法、関係者
要件追跡マトリックス
具体的なニーズと上位目標の対応、および具体的なニーズについて説明する プロジェクト設計と成果物の詳細レベルでの対応
内容: WBS での要件、ランキング、ソース、高レベルの目標、結果の説明
要件の分類
ビジネスニーズ
ビジネスチャンスを掴むなど最高レベルです。解決策: なぜ特定のプロジェクトをやりたいのですか?
ステークホルダーのニーズ
これは中間レベルであり、「利害関係者はプロジェクトの成果物で何をしたいのか?」に対処します。
ソリューションの要件
これはプロジェクト製品に必要な機能と機能の最低レベルです。 解決策: プロジェクト チームはどのプロジェクト製品を開発する必要がありますか?
移行と準備の要件
データ移行など
5.3 範囲を定義する
目的: プロジェクトの境界を定義する
ツールとテクニック
専門家の判断
データ分析
代替案の分析
入力
プロジェクト憲章、スコープ管理計画、要件文書、仮説ログ
出力
プロジェクトスコープステートメント
洗練された製品ラインナップ
詳細な合格基準
成果物
プロジェクト管理レポートやドキュメントなど、プロジェクトを完了するために作成する必要がある成果物
プロジェクトの除外
プロジェクトはユーザーの期待を下げて満足度を高めるために何もしてはなりません
利害関係者の期待を管理し、範囲のクリープを軽減するのに役立ちます
プロジェクト文書の更新 前提ログ 要件文書 要件追跡マトリックス 関係者登録簿
このプロジェクトで実装する必要がある要件を明確にし、これらの要件に基づいてプロジェクト スコープ ステートメントを作成し、プロジェクト スコープの境界を明確にします。
5.4 WBSの作成
仕事を小さなタスクと作業パッケージに分割し、 そして、これに基づいてスコープベンチマークを作成します。 スコープクリープの特定に役立ちます
作業分解構造はプロジェクトの全体的な範囲を決定するために使用され、プロジェクトのすべての作業がそれに含まれている必要があります。
作業分解構造の 100% ルールの要件: 作業分解構造には作業の 100% のみを含める必要があり、含めることができます。
やりすぎてもいけませんし、少なすぎてもいけません
作業分解構造の準備には、すべての主要な関係者の参加とプロジェクト チームのメンバーの参加が必要です。
レイヤーごとに分解する目的は、時間とコストの見積もりの精度を向上させることです。 プロジェクトの企画・実施・管理をより効果的に行うため
入力
プロジェクト管理計画: スコープ管理計画
プロジェクト文書: プロジェクト範囲記述書、要件文書、ビジネス環境要因、組織プロセス資産
出力
スコープベースライン
承認された範囲宣言 WBS および WBS ディクショナリ
プロジェクトスコープステートメント
WBS
ワークパッケージ
WBS の最下位レベル。作業パッケージはプロジェクトの最小の成果物であり、さらにスケジュールされたアクティビティに分割されます。
企画パッケージ
制御アカウントの下、作業パッケージの上。計画パッケージは、実行する前に作業パッケージに分割する必要があります
WBS辞書
ワークパッケージの各種詳細
道具
分解、ローリングプランニング
5.5 範囲の確認
目的: 完了したプロジェクト成果物を正式に受領するプロセス
各成果物を検証して改善する 最終製品の結果が受け入れられる可能性
入力
プロジェクト管理計画: 要件管理計画、範囲管理計画、範囲ベースライン
プロジェクト文書: 要件文書、要件追跡マトリックス、品質レポート
作業パフォーマンスデータ、検証された成果物
出力
受領のための成果物
クライアントまたはスポンサーによって正式に署名および承認されている
仕事のパフォーマンス情報
プロジェクトの進捗情報が含まれます
変更要求
完了したが正式な承認に合格していない成果物と失敗の理由を文書化する必要があります。
ツールとテクニック
チェック(チェックリスト)
意思決定
投票する
5.6 制御範囲
目的: プロジェクトと製品のスコープのステータスを監視し、スコープのベースライン変更のプロセスを管理します。
スコープクリープと金メッキプロジェクトは失敗する
入力
プロジェクト管理計画: スコープ管理計画、要件管理計画、スコープ ベースライン、パフォーマンス測定ベースライン
プロジェクト文書: 要件文書、要件追跡マトリックス、作業実績データ
出力
仕事のパフォーマンス情報
受け取った変更の分類、特定された範囲の逸脱とその原因、スケジュールとコストに対する逸脱の影響、 将来のスコープのパフォーマンスの予測。
変更要求
プロジェクトのパフォーマンスを分析した後、スコープのベースラインとスケジュールのベースラインに対して変更リクエストを行うことができます。
ツールとテクニック
データ分析
偏差分析
プロジェクト範囲のパフォーマンスが範囲ベースラインから逸脱する程度と理由を判断する
トレンド分析
将来のプロジェクト範囲のパフォーマンスを予測する