PMP：試験 - 監視・制御のバックアップ(No.20) - .NET 開発基盤部会 Wiki

[ トップ ] [ 新規 | 一覧 | 単語検索 | 最終更新 | ヘルプ ]

「.NET 開発基盤部会 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。

戻る
- 試験
- 監視・制御

目次 †

概要 †

監視・制御プロセス群の試験対策

詳細 †

監視・制御の流れ †

実行とI/Oを相互にする。

統合変更管理 †

統合変更管理から見た、変更要求のI/O

Input（変更要求）

「監視・制御プロセス群」直

「プロジェクト作業の監視・コントロール」経由

計画プロセス群
「スケジュール・コスト予測」をベースにした変更要求

実行プロセス群
「作業パフォーマンス・データ」をベースにした変更要求
（ただし、各コントロールで「作業パフォーマンス情報」に変換され、
それが、「作業パフォーマンス報告書」に変換されて利用される。）

Output（承認済み変更要求）

実行プロセス群
- プロジェクト作業の指揮・マネジメント

監視・制御プロセス群
- 品質管理(QC)
- 調達のコントロール

各プロセス †

実行プロセス（統合）

Input
- 承認済み変更要求

Output
- 成果物
- 作業パフォーマンス・データ
- 変更要求
- 各種計画書・文書更新版

各監視・制御プロセス

Input
- 成果物（品質のみ）
- 作業パフォーマンス・データ
- 承認済み変更要求

Output
- 作業パフォーマンス情報
- 変更要求
- 各種計画書・文書更新版

※ 監視・制御で重要なのは、作業パフォーマンス・データでなく作業パフォーマンス情報。
※ 作業パフォーマンス報告書にはスケジュール・コスト予測を含める。
※ 変更については、全て計画書に反映され、変更の履歴は、全て変更ログに反映される。

区分 †

プロジェクト目標
- 範囲
  - スコープの妥当性確認
  - スコープのコントロール
- 時間 : スケジュールのコントロール
- 原価 : コストのコントロール

重要
- 調達 : 調達のコントロール
- コミュニケーション : コミュニケーションの監視
- ステークホルダー : ステークホルダー・エンゲージメントの監視

その他
- 品質 : 品質管理(QC)
- 資源 : 資源のコントロール
- リスク : リスクの監視

基礎知識 †

統合系 †

統合変更管理

以下が更新される
- 承認済み変更要求
- プロジェクト・マネジメント計画書更新版
- プロジェクト文書更新版
- 変更ログ

以下は終結で更新される
- 組織のプロセス資産

範囲系 †

契約の範囲内であれば、変更管理。
契約の範囲外であれば、営業云々的な話になる。
受入れ前のスコープ変更は変更要求として扱う。
受入れ後のスコープ変更はクレームとしても処理しない。

※ スコープの決定は顧客（スポンサー）とPMで行う（プロジェクト・メンバを除く）。

調達系 †

クレーム処理（紛争、ADR）
- 紛争 : 交渉により解決する。解決できない場合、クレームは、紛争になる。
- ADR : 紛争は、法廷（裁判外紛争解決手続（ADR））に従って処理。

コミュニケーション系 †

ステークホルダー系 †

その他 †

選択肢の絞り込み †

変更要求の前に実施すること。 †

この問題はパターンが多い。

例えば、顧客から追加作業を依頼された場合、
- 変更要求を出す前にQCDのPBMに対する影響を評価。
- 実際に変更要求を出す前にスコープ記述書を確認する。
- 変更管理プロセスに準拠し変更要求を（CCBに）提出する。

例えば、コスト超過で、スコープ変更が必要になった場合、
- リスクのコンティンジェンシーを除いて再見積もりをする。
- それでも超過するようならスコープ縮小を検討する。
- それらの検討の後に、何らかの変更要求を出す。

※ 変更要求を出す前にやることがある。
　既定のパスを経由しないような要求の場合は、
　要求を「変更要求」として出すように依頼する。

変更要求の後に実施すること。 †

承認済み変更要求を受けて、

計画書、文書の更新（PMB変更など

教訓登録簿へ教訓を登録
（PMB変更など、教訓の登録が必要な変更を行った場合）

変更管理におけるPMの役割 †

変更要求がPBMに与える影響の評価する。

統合変更管理プロセスに上記の評価結果を伝える。

↓ ↓ ↓

（統合変更管理プロセス）

↓ ↓ ↓

承認済み変更要求を、実行プロセス群で実行する。

上記の変更結果をステークホルダーに伝える。

※ それ以外は、PM単独の権限で行うものではないタメ。

受け入れ前に実施すること。 †

品質管理(QC)

↓ ↓ ↓（検証済み成果物

スコープの妥当性確認

※ 検証と言えば前者。？？と言えば後者。

受け入れ基準が曖昧だった場合 †

検収に問題が発生するため、以下に直接的に影響する。
- 支払い金額の決定
- 品質尺度の設定
- プロジェクトの完了

プロジェクトの成功・失敗には間接的に影響する。

似たような言葉 †

XXXシステム †

プロジェクト・マネジメント情報システム（PMIS）
- データの収集/配布
- フィードバック・プロセスの促進
- スケジュール設定/変更
- コスト設定/変更
- 資源設定/変更
- 作業認可システム

コンフィギュレーション・マネジメント・システム
情報システム化されたコンフィギュレーション・マネジメント

コンフィギュレーション・マネジメント
情報システムではなく、文書化された手順の集合体。
- 構成管理・形態管理システム（プロダクト領域）
- 変更管理システム（マネジメント領域）

XXX委員会 †

CCBは中小規模では必須ではない。
変更要求→レビュー/評価/承認/保留/却下の
変更管理（コントロール）を適切にやるコトが重要。

#	略号	英語	日本語
1	CCB	change control board	変更管理委員会
2	ERB	engineering review board	エンジニアリング・レビュー委員会
3	TRB	technical review board	テクニカル・レビュー委員会
4	TAB	technical assessment board	テクニカル・アセスメント委員会

XXX差異 †

スケジュール差異 -> スケジュールに影響を与えることもある。
コスト差異 -> スケジュールに影響を与えることもある。
スコープへの影響 -> 意思決定基準なので基本的には死守で、やむを得ず修正される。

作業パフォーマンスXXX †

作業パフォーマンス・データが実行プロセス群で生成され、

監視・制御プロセス群で以下のように変換される。
- 作業パフォーマンス・データ ---> 作業パフォーマンス情報
- 作業パフォーマンス情報 ---> 作業パフォーマンス報告書

監視・制御で主要な情報は、作業パフォーマンス情報

作業パフォーマンス報告書は、
- 実行プロセス群に戻され活用される。
- 一部は、統合変更管理プロセスを経由してから。
- 監視・制御プロセス群での活用はリスクの監視でのみ。

スケジュール・コスト予測 †

EVMの結果、

作業パフォーマンス情報と差異分析結果 †

作業パフォーマンス情報
是正処置が必要か否か？

差異分析結果
予測との差異を分析した結果、
どのような是正処置が必要か？

コミュニケーション or 人間関係スキル †

ステークホルダー・エンゲージメントの監視時のTT

コミュニケーション・スキル
- フィードバック
- プレゼンテーション

人間関係とチームに関するスキル
- 積極的傾聴
- 文化的な相違点と要求事項
- リーダーシップ
- ネットワーキング
- 政治的な認識

コチラが参考になる。

その他 †

アジャイル関連 †

アジャイル関連は、監視・制御が多い筈。

レトロスペクティブ・レビュー：プロセスの修正・改善
ベロシティー：速度（生産性）、成果物の進捗 / イテレーション