ログイン
サインイン

PMP 第 5 章プロジェクトのスコープ管理

アメリカの有名ビジネススクールのPMPコアコース。プロジェクト管理人材は中国で最も不足している人材の 1 つである。これが近年、オフィス人材市場で継続的に広まっているメッセージである。過去 2 年間、プロジェクト管理は我が国の外国専門家局によって中国に導入されることに成功し、米国プロジェクト管理スキャナー協会は中国で PMP 資格認定試験を実施しました。ビジネス管理エリートになることに興味のあるグループは、幸運なことに、American Project Management Council が発行する PMP 証明書を取得できるでしょう。本書の特徴は、理論的でありながら実践性・操作性が高く、プロジェクトマネジメントの研修に非常に適していることです。

2023-02-22 15:35:14 に編集されました

WSUJfrxa

最近の作品その他の作品を表示>>

PMP 第 5 章プロジェクトのスコープ管理

WSUJfrxa

最近の作品その他の作品を表示>>

おすすめ
アウトライン

年間トレーニングプログラム
- 28
PlotWizard
販売前顧客サービスプロセストレーニング (自己使用)
- 19
PlotWizard
スポーツトレーニング
- 15
PlotWizard
トレーニングスペシャリストの職務責任と資格
- 14
PlotWizard
ビッグマーケティング部
- 8
WSUJfrxa
トレーニングニーズの分析
- 43
- 1
WSUJfrxa
家族教育トレーニングノートマインドマップ
- 21
WSUJfrxa
安全管理研修マインドマップ
- 20
MM
社内の従業員トレーニングフレームワーク
- 5
LoganBennett_045
コンサルタント業界の仕様
- 10
PlotWizard

プロジェクトの範囲管理

核となるアイデア

範囲の定義 (必要なすべての作業を実行)

製品の範囲

製品、サービス、または結果の特徴と機能

プロジェクトの範囲を決定する

変更自体が必ずしもプロジェクトのスコープの変更を引き起こすとは限りません

プロジェクトの範囲は含まれません

測定基準: 製品要件文書

プロジェクト範囲

指定された特徴や機能を備えた製品、サービス、または結果を提供するために完了する必要がある作業

提供する製品範囲

自分自身の変化が必ずしも製品範囲の変化につながるとは限らない

広義には、製品範囲も含まれる場合があります。

対策: プロジェクト管理計画

ライフサイクルスコープ管理の比較

予測ライフサイクル

プロジェクトの成果物はプロジェクトの開始時に定義され、スコープの変更は段階的に管理されます

安定した需要と成熟した技術

これらのプロセスは、プロジェクトの開始時にすべての要件に基づいて実行され、リアルタイムの全体的な変更管理プロセスを通じて必要に応じて更新されます。

範囲の確認: 各成果物の作成時または段階的なレビューポイントで

管理範囲：継続中

最終スコープベースライン: プロジェクトスコープステートメント WBS WBS ディクショナリ

適応性のある/機敏なライフサイクル

成果物は複数回の反復を通じて開発され、各反復の開始時に詳細な範囲が定義および承認されます。

多くの変化への対応と関係者の継続的な関与

各反復の開始時に、これらのプロセスを実行するために製品バックログの中で最も優先度の高い項目を選択します。

確認および制御範囲: 各反復では 2 つのプロセスが繰り返されます。

最終範囲ベースライン: 製品要件やユーザーストーリーを含む未完成の項目

開発トレンドと新たな実践方法

需要活動を定義、管理、制御することで競争上の優位性を向上させる

ビジネス分析アクティビティは、プロジェクトの開始とプロジェクトマネージャーの任命前に開始できます。

ビジネス分析の専門家とのコラボレーションに重点を置く

要件管理プロセスはニーズの評価から始まり、要件の完了で終わります。

プロジェクトマネージャーとビジネスアナリストの関係はパートナーシップです。

ビジネスアナリスト要件管理関連の活動を担当

プロジェクトマネージャーは、これらの活動がプロジェクト管理計画に組み込まれ、価値を創出しながら時間どおりに予算内で完了するようにする責任があります。

アジャイルまたは適応コンテキスト要素で考慮すべき要素

プロジェクトの初期段階で範囲の定義と交渉に費やす時間を意図的に短縮し、継続的な探索と範囲の明確化のためのプロセスの作成に費やす時間を増やします。

意図的にプロトタイプを構築およびレビューし、複数のリリースを作成して要件を明確にします。未完成の項目に要件を追加する

切断時に考慮すべき要素

プロセスには以下が含まれます

計画範囲管理（計画プロセスグループ）

プロジェクト範囲と製品範囲がどのように定義、検証、制御されるかを文書化する範囲管理計画を作成するプロセス。

主な役割: プロジェクト全体の範囲を管理する方法についてのガイダンスと指示を提供する

出力

スコープ管理計画

プロジェクトの範囲がどのように定義、開発、監視、制御、検証されるかを説明します。

気をつけて

スコープ管理計画にスコープがありません (スコープはスコープベースライン内にあります)

範囲管理計画には、公式または非公式、非常に詳細な計画または高レベルの計画があります。

要件管理計画（ビジネス分析計画）

プロジェクトと製品の要件がどのように分析、文書化、管理されるかを説明します。

気をつけて

要件管理計画に要件がありません (要件は要件文書にあります)

コンテンツには、構成管理アクティビティ、要件の優先順位付けプロセス、測定指標などが含まれます。

要件の収集 (計画プロセスグループ)

目標を達成するために、関係者のニーズと要望を特定、文書化、管理するプロセス。

このプロセスの内容: 製品の範囲とプロジェクトの範囲を定義するための基礎を築きます。

必要

定義: 特定の契約またはその他の必須仕様に従って、製品、サービス、または結果には条件または機能がなければなりません。

要件には、スポンサー、顧客、その他の関係者の定量化および文書化されたニーズと期待が含まれます。

入力

プロジェクトファイル

利害関係者登録

どの関係者が要件に関する情報を提供できるかを理解し、プロジェクトに対する関係者のニーズと期待を記録するために使用されます。

ビジネス文書

要件収集プロセスに影響を与えるビジネス文書は、ビジネスニーズを満たすために満たすべき必要な基準、期待される基準、およびオプションの基準を説明するビジネスケースです。

プロトコル

要件収集プロセスに影響を与えるビジネス文書は、ビジネスニーズを満たすために満たすべき必要な標準、期待される標準、およびオプションの標準を説明するビジネスケースです。

ツールとテクニック

データ収集

ブレーンストーミング

豊かな創造性、アイデア、自由な言論

インタビュー

直接チャット、事前設定された質問と即興の質問、1対1、多対多、機密情報へのアクセス

フォーカスグループ

同じ職務、同じ分野、同様の背景、主題専門家 (SME)、モデレータが双方向のディスカッションを主導

アンケート

対象読者は多様で、迅速に完了する必要があり、地理的に分散しており、統計分析に適しています。

ベンチマーク

ベンチマークは、ベストプラクティスを特定し、改善のための提案を策定するために、社内または社外、同じ業界または異なる業界で行うことができます。

データ分析

ファイル分析

既存のファイルを分析する

意思決定

投票する

全会一致で同意した

誰もが同意します、Delphi (専門家、匿名性、複数ラウンド、収束、偏見の排除)

大多数が同意する

50%を超える場合、意思決定グループの人数は通常奇数に設定されます。

相対多数が同意する

相対多数。通常、候補者が 3 人以上いる場合に使用されます。

独裁的な意思決定

一人で決断を下す

多基準の意思決定分析

意思決定マトリックス、複数の基準、評価とランキング

重み * スコアを計算して合計スコアを比較します

データパフォーマンス

親和性図

グループ化、分類

マインドマッピング

統合し、共通点と相違点を反映し、新しいアイデアを刺激し、脳の地図を作成します

人間関係とチームスキル

名目上のグループ

ブレーンストーミング、投票、優先順位付け、5 段階評価、ラウンドの集計を容易にします。

観察（ワークシャドーイング）して話す

「仕事の追従」、明確に説明することが難しいまたは嫌がる、隠れたニーズを掘り起こす

ガイド

コンセプト

テーマワークショップ、部門を超えたさまざまな部門と組み合わせて使用し、利害関係者の相違を調整します

シーン

共同アプリケーションのデザインまたは開発（JAD）

ソフトウェア開発業界、ビジネス主題の専門家、開発チームが集中

品質機能搭載 QFD

製造業、顧客ニーズ（顧客の声）収集開始、分類・整理

ユーザーストーリー

要件ワークショップ、役割、目標、動機

必要な機能の短いテキストの説明

システム相互作用図

トポロジーマップ、製品範囲の視覚化

プロトタイプメソッド

漸進的な精緻化の概念をサポートします。例: ストーリーボード作成。手戻りのリスクを軽減できます。

ステップ (繰り返しサイクル): 1. モデルの作成、2. ユーザーエクスペリエンス、3. フィードバックの収集、4. プロトタイプの修正 (変更プロセスが必要な場合があります)

出力

要件文書 (単一要件)

さまざまな単一要件がプロジェクト関連のビジネスニーズをどのように満たすかを説明する

ベンチマークとして使用できるのは、明確で (測定可能でテスト可能)、追跡可能で、完全で、調整されており、主要な利害関係者によって認識されることを望んでいる要件のみです。

要件のカテゴリー

ビジネスニーズ

上級管理職と組織全体のニーズ

ステークホルダーのニーズ

利害関係者または利害関係者グループのニーズ

ソリューションの要件

分類

機能要件

製品に必要な機能について説明する

非機能要件

機能要件の補足は、製品の通常の動作に必要な環境条件または品質要件です。

ビジネスニーズや利害関係者のニーズを満たすために、製品、サービス、成果物が持つ必要のある機能、特性。

移行と準備のニーズ

データ変換やトレーニングのニーズなど、「現在の状態」から「将来の状態」に移行するために必要な暫定的な機能について説明します。

プロジェクトの要件

マイルストーンの日付、契約上の義務、制約など、満たすべきアクション、プロセス、またはその他の条件。

品質要件

プロジェクトの成果物の正常な完了、またはテスト、認証、検証などの他のプロジェクト要件の達成を確認する条件または基準。

要件追跡マトリックス

他からの製品需要を、その需要を満たす成果物に結びつける形です。

各要件をビジネス目標またはプロジェクト目標にリンクすると、各要件にビジネス価値があることが保証されます。

プロジェクトのライフサイクル全体にわたって要件を追跡する方法を提供します（順方向追跡、逆方向追跡）。

要件文書内のすべての承認された要件がプロジェクトの終了時に確実に提供されるようにするのに役立ちます。

要件を収集するときに生成される要件ドキュメントと要件追跡マトリックスは、プロジェクトの真の範囲を表しません。

何がプロジェクトの範囲に含まれ、何が除外されるのかをさらに明確にする必要があります。 (スコープを定義)

範囲の定義 (計画プロセスグループ)

詳細なプロジェクトと製品の説明を作成するプロセス

主な機能: 製品、サービス、または結果の境界と許容基準を説明する

要件文書から最終的なプロジェクト要件を選択し、プロジェクトとその製品、サービス、または結果の詳細な説明を指定します。

詳細なプロジェクトスコープステートメントは、プロジェクトの開始時に文書化された主要な成果物、前提条件、制約に基づいて準備する必要があります。

既存のリスク、仮定、制約の完全性を分析し、必要な追加や更新を行うことも必要です。

スコープ定義プロセスを複数回繰り返す必要があります (複数回の繰り返しを含む)

入力

プロジェクト憲章 (高レベルの要件)

プロジェクト、製品の特性、承認要件の概要が記載されています。

プロジェクトファイル

要件文書

範囲に含めるべき要件が特定される

ツールとテクニック

データ分析

代替案の分析

意思決定

多基準の意思決定分析

対人スキルとチームスキル

ガイド

ワークショップやパネルディスカッションでファシリテーションスキルを活用して、異なる期待や異なる専門的背景を持つ主要な関係者を調整し、プロジェクトの成果物やプロジェクトと製品の境界について部門を超えた合意を形成します。

製品分析

高レベルの製品説明を具体的な成果物に変換します。製品分析手法には、製品分解、システム分析、需要分析、システムエンジニアリング、バリューエンジニアリング、価値分析などが含まれます。

出力

スコープステートメント (成果物/受け入れ基準)

これは、プロジェクトの範囲、主要な成果物、前提条件、および制約についての説明です。プロジェクトと製品の範囲を含む範囲全体が文書化されます。

プロジェクトの成果物を詳細に説明し、プロジェクトの範囲に関するプロジェクト関係者の合意を表します。

利害関係者の期待を管理しやすくするために、プロジェクトスコープステートメントでは、どの作業がプロジェクトのスコープ外であるかを明確に示します。

以下のものが含まれます

製品範囲の説明

プロジェクト憲章および要件文書に記載されている製品、サービス、または成果の特性を段階的に改良します。

成果物

生産する必要があるユニークで検証可能な製品、結果、またはサービス機能。プロジェクト管理レポートや文書などの付随的な結果も含まれます。

合否基準

成果物が受け入れられる前に満たさなければならない一連の条件

除外事項

何がプロジェクトの範囲外であるかを明確に示すことは、関係者の期待を管理し、範囲のクリープを減らすのに役立ちます。

WBS（計画プロセスグループ）（作業分解構造）の作成

プロジェクトの成果物とプロジェクトの作業を、より小さく、より管理しやすいコンポーネントに分割するプロセス

このプロセスの内容: 提供される内容の構造を提供します。

WBS は、プロジェクトの全体的な範囲を整理して定義します (プロジェクトの範囲の記述は範囲のみを定義し、組織の範囲ではありません)。

WBS の最下位レベルのコンポーネントは作業パッケージと呼ばれ、計画された作業が含まれます。

作業分解構造という用語では、作業とは、活動そのものではなく、活動の結果である作業成果物または成果物を指します。

ツールとテクニック

壊す

プロジェクトの範囲とプロジェクトの成果物を、より小さく管理しやすいコンポーネントに段階的に分割する手法

ワークパッケージ

WBS の最下位コンポーネント。コストと期間を見積もって管理できます。

WBS を作成するということは、プロジェクトの作業全体を作業パッケージに分割することを意味します

5段階の分解

1. 成果物と関連作業の特定と分析

2. WBSの構成と配置方法を決定する

3. 上から下まで層ごとに精製および分解されます。

4. 識別コードを開発して WBS コンポーネントに割り当てる

5. 成果物の分解度が適切か検証

WBS構造の形式

プロジェクトのライフサイクルの各段階を分解の第 2 レベルとして考え、製品とプロジェクトの成果物が第 3 レベルであると考えてください。

主要な成果物を分解の第 2 レベルとして扱う

プロジェクトチーム以外の組織 (外部委託作業など) によって開発されたさまざまな下位レベルのコンポーネントを組み込む

WBS作成時の4つの注意点

アジャイル手法を使用する場合、長いストーリーをユーザーストーリーに分割できる

さまざまな成果物をさまざまなレベルに分解できます

分解が詳細であればあるほど良いというわけではありません。分解が詳細すぎると、管理労力が無駄に消費され、リソースが非効率的に使用され、作業の実行効率が低下します。また、WBS のすべてのレベルでデータの集計が困難になります。

将来完成する成果物やコンポーネントは、現時点では分解（計画パッケージ）できず、ローリング計画が必要になる可能性があります。

4つの主要な原則

100％原則

明確な責任者がいる

80時間ルール

あまり細かく分けすぎないでください

WBSの作り方

トップダウン

ボトムアップ

出力

スコープベースライン

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

プロジェクト範囲

主な成果物

合否基準

プロジェクトの除外

WBS

ワークパッケージ

企画パッケージ

コントロールアカウント

範囲、予算、実際のコスト、スケジュールを統合し、達成額と比較してパフォーマンスを測定する管理コントロールポイント (組織の財務手順にリンクできる)

各制御アカウントには 1 つ以上の作業パッケージ (または計画パッケージ) を含めることができますが、作業パッケージは 1 つの制御アカウントにのみ属することができます。

パフォーマンステストベンチマーク PMB: スコープベンチマーク、スケジュールベンチマーク、コストベンチマークで構成されます。

WBS辞書

WBS の各コンポーネントの成果物、アクティビティ、進捗情報を詳しく説明した文書

検証範囲（監視プロセスグループ）

完了したプロジェクト成果物をクライアントまたはスポンサーが正式に受け入れるプロセス

このプロセスの内容: 各成果物を受け入れることで、最終的な製品、サービス、または結果が受け入れられる可能性が高まります。

入力

検証された成果物

完成し、品質管理プロセスによって正しいことが確認された成果物

ツールとテクニック

検査（レビュー、製品レビュー、検査）

測定、レビュー、検証などの活動を実施して、作業と成果物が要件と製品の受け入れ基準を満たしているかどうかを判断します。

出力

受領のための成果物

受け入れ基準を満たす成果物は、クライアントまたはスポンサーによって正式に承認される必要があります。

関係者によるプロジェクト成果物の正式な受諾を証明する正式な文書をクライアントまたはスポンサーから入手する必要があります。

変更要求

受け入れが失敗した場合の処理手順は次のとおりです。 1. 理由を記録 (理解) します。 2. 変更プロセスに従って欠陥を修正します。

制御範囲（監視プロセスグループ）

プロジェクトと製品のスコープのステータスを監視し、スコープのベースライン変更のプロセスを管理します

効果

プロジェクト全体を通じてスコープのベースラインを維持する

すべての変更要求、修正措置、予防措置が、全体的な変更管理プロセスの実装を通じて処理されることを確認します。

ツールとテクニック

偏差分析

ベースラインと実際の結果を比較して、偏差が臨界値の範囲内かどうか、または修正措置または予防措置が必要かどうかを判断するために使用されます。

トレンド分析

プロジェクトのパフォーマンスの時間の経過に伴う変化を調べて、パフォーマンスが向上しているか低下しているかを判断するように設計されています。

スコープのベースラインからの逸脱の原因と範囲を特定し、是正措置または予防措置を講じる必要があるかどうかを決定することは、プロジェクトスコープ管理の重要なタスクです。

スコープクリープ

時間、コスト、リソースを適切に調整できず、製品やプロジェクトの範囲が制御されずに拡大する

金メッキ

チーム内からのスコープクリープ

プロジェクト担当者は、顧客に喜んでもらうために、実際の問題を解決せず、応用価値のないプロジェクト活動を行います。

スコープクリープ

チーム外部の理由によるスコープクリープ

これは、顧客が継続的に小さな、目に見えない範囲の変更を提案することを指します。これを管理しないと、その積み重ねにより、プロジェクトが確立された範囲のベースラインから大幅に逸脱し、プロジェクトの制御不能や失敗につながります。

スコープクリープが発生した場合は、不正な変更を中止し、変更プロセスを見直す必要があります。変更プロセスが承認されない場合は、不正な変更を取り消す必要があります。

PMP 第 5 章 プロジェクトのスコープ管理

PMP 第 5 章 プロジェクトのスコープ管理

PMP 第 5 章プロジェクトのスコープ管理

PMP 第 5 章プロジェクトのスコープ管理