【47プロセス】プロジェクトの監視・コントロール

【47プロセス】プロジェクトの監視・コントロール

【47プロセス】プロジェクトの監視・コントロール


 

【プロセス「プロジェクトの監視・コントロール」概要】

計画内容と実施した作業を比較し、必要あれば変更要求を出す。また、報告書を作成するプロセス

 

【INPUT】
・プロジェクトマネジメント計画書
・スケジュール予測
・コスト予測
・妥当性確認済み変更
・作業パフォーマンス情報
・組織体の環境要因
・組織のプロセス資産


【ツールと技法】
・専門家の判断
・分析技法
・プロジェクトマネジメント情報システム
・会議


【OUTPUT】
・変更要求
・作業パフォーマンス報告書
・プロジェクトマネジメント計画書更新版
・プロジェクト文書更新版

 

 

プロジェクトの監視・コントロールの流れ

要するに、当初の計画と実績値とを評価し、差異を発見し、必要ならば対策を施すプロセスです。

計画値と実績値を評価するので、【INPUT】には 計画値である「プロジェクトマネジメント計画書」(の中の「ベースライン」)と、実績値として「作業パフォーマンスデータ」を含みます。

計画値と実績値を元に、【ツールと技法】専門家の判断(つまり相談)とか、【ツールと技法】プロジェクトマネジメント情報システム(つまりExcelとか)を使って、【ツールと技法】会議(つまりミーティング)を行い、【ツールと技法】分析技法を用いて、値を分析します。

結果として、このプロセスから【OUTPUT】変更要求が出てきたり、分析した結果の報告書【OUTPUT】作業パフォーマンス報告書が出てきます。

あと、このプロセスで作られる作業パフォーマンス報告書に記載するために、【INPUT】にスケジュール予測、コスト予測が含まれています。この差異のままプロジェクトが進むとどうなるかを併せて報告書に記載するためです。

 

 

分析技法

計画値と実績値を比較・評価するために用いられるのが、この「分析技法」です。
PMBOKガイド92ページには、11の分析技法が挙げられています。

PMP試験では、「~の状況で、どの分析技法を採用すべきか?」という4択が出題される場合があります。
つまり問題文の中に、ヒントが隠されているというわけです。

 

計画値と実績値の差異から、差異の原因を調べるなら
→差異分析


過去の傾向から将来を予測するなら
→傾向分析


金額に換算して、スケジュールの進捗、コストの差異を調査するなら
→アーンドバリューマネジメント分析


根本的な原因を追究する必要があるなら
→根本原因分析


ツリーの上位にトラブルを位置づけ、ツリー構造で原因を調べるなら
→故障の木解析(FTA)


2つの変数をグラフにし、その変化を定量的に分析するなら
→回帰分析


故障が発生した時、上位システムが受ける影響をランク付けするなら
→故障モード影響解析(FMEA)

 

問題文から、どの分析技法を選択するかだけ読み取れればOKなので、いっこいっこ詳しくは説明しません。

大事なものは、後から詳しくやりましょー。

 

photo credit: Heritage Hills Lone Tree real estate tracker via photopin (license)

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

次のHTML タグと属性が使えます: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>