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

目次

概要

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

詳細

監視・制御の流れ

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

  • 変更要求 → 承認済み変更要求
  • 作業パフォーマンス・データ → 情報 → 報告書

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

統合変更管理

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

  • Input(変更要求)
  • 「監視・制御プロセス群」直
  • 「プロジェクト作業の監視・コントロール」経由
  • Output(承認済み変更要求)

統合変更管理から見た、作業パフォーマンスのI/O

  • Input(作業パフォーマンス)
    各監視・制御プロセスから
    • 作業パフォーマンス情報(各知識エリアのプロセス)
    • 作業パフォーマンス報告書(統合のプロセス)
  • Output(作業パフォーマンス報告書)
    • 統合変更管理リスク(の監視・制御プロセス)、
    • チーム、コミュニケーション(の実行プロセス)

各プロセス

  • 実行プロセス(統合)
  • 各監視・制御プロセス

区分

  • プロジェクト目標
    • 範囲
      • スコープの妥当性確認
      • スコープのコントロール
    • 時間 : スケジュールのコントロール
    • 原価 : コストのコントロール
  • 重要
    • 調達 : 調達のコントロール
    • コミュニケーション : コミュニケーションの監視
    • ステークホルダー : ステークホルダー・エンゲージメントの監視
  • その他
    • 品質 : 品質管理(QC)
    • 資源 : 資源のコントロール
    • リスク : リスクの監視

基礎知識

統合系

  • 統合変更管理
  • ポイントは、
    • 権限ある者の承認・却下を、
    • 書面により管理する。
  • 以下が更新される
    • 承認済み変更要求
    • プロジェクト・マネジメント計画書更新版
    • プロジェクト文書更新版
    • 変更ログ
  • 以下は終結で更新される
    • 組織のプロセス資産

範囲系

  • 監視・制御の核
    意思決定基準のスコープ・ベースライン
  • 変更管理
    契約の範囲とスコープをどう切り分けているのか?という話はある。
  • 契約の範囲
    • 内であれば、変更管理。
    • 外であれば、営業云々的な話になる。

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

  • ユーザの受入・最終納品
    • 適合性の確認
      • 品質要求事項(品質管理(QC))
      • 受入基準(スコープの妥当性確認)
    • 正式な署名

品質系

  • 検査(プロダクト)

資源系

チーム・マネジメント

  • 人事(機能部門マネージャ)にメンバの評価を渡す。
  • 組織体の環境要因(EEF)更新版

調達系

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

コミュニケーション系

実行の監視・制御

ステークホルダー系

実行の監視・制御

その他

選択肢の絞り込み

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

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

  • 例えば、顧客から追加作業を依頼された場合、
    • 変更要求を出す前にPBM、QCDなどに対する影響を評価。
    • 実際に変更要求を出す前にスコープ記述書を確認する。
    • 変更管理プロセスに準拠し変更要求を(CCBに)提出する。
  • 例えば、コスト超過で、スコープ変更が必要になった場合、
    • リスクのコンティンジェンシーを除いて再見積もりをする。
    • それでも超過するようならスコープ縮小を検討する。
    • それらの検討の後に、何らかの変更要求を出す。

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

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

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

  • 計画書、文書の更新(PMB変更など
  • 教訓登録簿へ教訓を登録
    (PMB変更など、教訓の登録が必要な変更を行った場合)

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

  • 変更要求がPBMに与える影響の評価する。
  • 統合変更管理プロセスに上記の評価結果を伝える。

↓ ↓ ↓

  • (統合変更管理プロセス)

↓ ↓ ↓

  • 承認済み変更要求を、実行プロセス群で実行する。
  • 上記の変更結果をステークホルダーに伝える。

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

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

↓ ↓ ↓(検証済み成果物

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

スコープ面と品質面がありそう。

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

似たような言葉

XXXシステム

  • プロジェクト・マネジメント情報システム(PMIS)
    • データの収集/配布
    • フィードバック・プロセスの促進
    • スケジュール設定/変更
    • コスト設定/変更
    • 資源設定/変更
    • 作業認可システム
  • コンフィギュレーション・マネジメント・システム
    情報システム化されたコンフィギュレーション・マネジメント
  • コンフィギュレーション・マネジメント
    情報システムではなく、文書化された手順の集合体。
    • 構成管理・形態管理システム(プロダクト領域
    • 変更管理システム(マネジメント領域

XXX委員会

  • CCBは中小規模では必須ではない。
  • 変更要求→レビュー/評価/承認/保留/却下の
    変更管理(コントロール)を適切にやるコトが重要。
#略号英語日本語
1CCBchange control board変更管理委員会
2ERBengineering review boardエンジニアリング・レビュー委員会
3TRBtechnical review boardテクニカル・レビュー委員会
4TABtechnical assessment boardテクニカル・アセスメント委員会

XXX差異

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

差異分析と傾向分析

  • EVM(スケジュール・コスト)だけでなく、
  • スコープに対しても適用される。

作業パフォーマンスXXX

  • 作業パフォーマンス・データが実行プロセス群で生成され、
  • 監視・制御プロセス群で以下のように変換される。
    • 作業パフォーマンス・データ ---> 作業パフォーマンス情報
    • 作業パフォーマンス情報 ---> 作業パフォーマンス報告書
  • 監視・制御で主要な情報は、作業パフォーマンス情報
  • 作業パフォーマンス報告書は、
    • 「実行プロセス群」では「チーム / コミュニケーション・マネジメント」でのみ活用される。
    • 「監視・制御プロセス群」では「リスクの監視」でのみ活用される。
    • 一部は「統合変更管理」を経由して「承認済み変更要求」になる。

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

EVMの結果、

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

  • 作業パフォーマンス情報
    是正処置が必要か否か?
  • 差異分析結果
    予測との差異を分析した結果、
    どのような是正処置が必要か?

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

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

  • コミュニケーション・スキル
    • フィードバック
    • プレゼンテーション
  • 人間関係とチームに関するスキル
    • 積極的傾聴
    • 文化的な相違点と要求事項
    • リーダーシップ
    • ネットワーキング
    • 政治的な認識

その他

アーンド・バリュー(EV)

アジャイル関連

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

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

トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2019-03-10 (日) 20:27:51 (9d)