プロジェクト・マネジメント-進捗

進捗

進捗プラクティスの目的は、計画に対する実際の達成度をモニタリングし、継続的な実行可能性を予測し、許容度を超える偏差をコントロールする。

基本定義

• 進捗(Progress)
  • 計画された達成目標に対し、実際の達成度合いを測定すること。
• 予測(Forecast)
  • 履歴データや過去のパターンを分析・研究することで導き出される、将来の見通し。
• 例外(Exception)
  • PMとプロジェクト委員会(または、プロジェクト委員会と組織の経営層/ビジネス・レイヤー)の間で合意された 許容度(トレランス) を超える偏差が生じると予測される状況を指す。

ガイダンス

• 効果的な進捗マネジメントには、以下の活動が含まれる。
  • マネジメント・レベルと**許容度(トレランス)**の定義
  • 2 種類のコントロール(イベント型・時間型)の適用
  • 進捗と教訓のレビューおよび報告
  • 残り作業時間の予測とエスカレーション
  • データの活用

1. マネジメント・レベルと許容度

プロジェクトは3つの階層で管理され、各レベルで設定された許容度の範囲内で実行責任を持つ。

• 1.1. 各レベルの役割とエスカレーション
  • ビジネス・レイヤー(プロジェクト外): 全体的な要件とプロジェクト・レベルの許容度を設定する。
  • プロジェクト委員会(指揮): プロジェクト・レベルのコントロールを担う。PMにステージ許容度を割り当て、継続の是非を判断する。許容度超えの予測時は、ビジネス・レイヤーへ報告する。
  • PM(マネジメント): 日々のステージ運営を担う。ステージ許容度を超える予測時は、例外報告書を用いてプロジェクト委員会へエスカレーションする。
  • チーム・マネージャー(提供): ワーク・パッケージ(WP)のコントロールを担う。WP 許容度を超える予測時は、課題を提起してPMへ報告する。
• 1.2. 許容度マトリクス(定義場所のサマリー)

  許容度の領域	プロジェクトレベル	ステージレベル	WPレベル	成果物レベル
  ベネフィット 範囲の観点からのターゲット・ベネフィットの定義	ビジネス・ケース	ステージ計画書	-	-
  時間 ターゲット完了日までの時間の延長または短縮	プロジェクト計画書	ステージ計画書	WP 記述書	-
  コスト 計画予算の増減	プロジェクト計画書	ステージ計画書	WP 記述書	-
  品質 範囲の観点からの品質ターゲットの定義	プロジェクト成果物記述書	-	-	成果物記述書
  スコープ プロジェクト・ソリューションのスコープの許容されるバリエーション	プロジェクト計画書	ステージ計画書	WP 記述書	-
  持続可能性 持続可能性のために合意された測定基準の制限	ビジネス・ケース	ステージ計画書	WP 記述書	成果物記述書
  リスク 脅威の集計値の制限	ビジネス・ケース	ステージ計画書	WP 記述書	-

• 1.3. 適用とコンテキスト
  • 組織方針: 進捗コントロールは、ビジネス・レイヤー(組織上層部)の意思決定サイクルに整合させる。
  • 商業環境: 外部サプライヤーとの契約義務を尊重しつつ、良好な協力関係を促進するよう調整する。サプライヤー側は入札から保証期間までをライフサイクルとして捉える点に留意する。
  • デリバリー手法による違い
    • ウォーターフォール: 成果物の完成時期とコストに焦点を当て、次ステージへの移行基盤を確認する。
    • アジャイル: 時間よりも要件の達成度や頻繁なデリバリーを重視する。報告はプッシュ型ではなく、バーンダウンチャート等のプル型システムをベースにする。
  • 持続可能性:
    • 法律や規制へのコンプライアンスを支援するため、必要なデータを収集・報告する。
    • 持続可能性の報告は独立した活動ではなく、通常の進捗報告の循環サイクルに統合して実施する。
  • 規模と複雑性:
    • 単純なプロジェクト: 成果物の結合、データ分析の簡素化、デジタルアクセスによる効率化を図る。
    • 複雑なプロジェクト: 多数の利害関係者の要件を満たすため、正式かつ構造化された報告アプローチを採用する。

2. コントロールの種類

プロジェクトの有効期間全体を通じて、イベントに基づくコントロールと時間に基づくコントロールの2 種類を提供することで、効果的なプロジェクト・コントロールを実現する。

• 2.1. コントロールの定義
  • イベントに基づくコントロール: 特定のイベント(事象)が発生したタイミングで実施される。
  • 時間に基づくコントロール: 事前に定義された間隔(週次、月次など)で定期的に実施される。
• 2.2. 運用上の特徴

  活動内容	コントロールのタイプ	備考
  モニタリング	時間に基づく活動	定期的な状況確認として実施する
  コントロール(意思決定)	イベントに基づく活動	必要なタイミングで意思決定を行う
  報告	時間とイベントの両方	定期報告に加え、特定の事象発生時にも行う

• 2.3. 効率性の向上
  • イベントに基づくコントロールを適切に活用することで、プロジェクト・マネジメント・チームは最も必要なときにのみ会議や意思決定を行うことができる。これにより、不必要または過剰な会議を削減し、業務の効率性を高めることが可能となる。

3. 進捗と教訓をレビューする

• 3.1. 進捗のレビューと更新
  • 定期的なレビュー: PMは、チェックポイント報告書を用いて進捗を確認し、プロジェクト・ログを管理する。
  • 計画への反映: 実際の実績に基づき、ステージ計画書を更新する。進捗コントロールは、計画に定義された詳細レベルでのみ実施可能である。
  • 傾向分析: データを分析して傾向を把握し、ステージ全体の健全性を評価する。
• 3.2. ログと登録簿による管理

  ツール名	特徴と役割
  デイリー・ログ	小規模なアクションや、非公式な課題・メモ・観察事項を記録する。些細な記録の積み重ねから、新たなリスクや課題を発見することに役立つ
  課題登録簿	プロジェクトに重大なインパクトを与える「正式な課題を記録し、オープンな場でモニタリング・レビュー
  成果物登録簿	成果物のステータス(待機・進行中・完成)を管理する。データの正確性を担保するため、物理的な成果物の状態と照合する

• 3.3. 教訓の管理 当該プロジェクトや将来のプロジェクトの将来を支援し、経験からの学習を積極的に促進する(情報は成功事例(プラス)と失敗事例(マイナス)の両方が含まれる)。
  • 3.3.1. 教訓の把握と記録 プロジェクト終了時だけでなく、以下の機会を通じて期間中継続的に記録する。
    • プロジェクト期間中の会議やレトロスペクティブ
    • マネジメント成果物(チェックポイント/ハイライト報告書など)
    • 課題発生時や利害関係者との面談
    • 電子共有ワークスペースの活用
  • 3.3.2. 教訓分析の5つの問い 以下の順序で分析を行うことで、経験を知識化する。
    1. 期待: 何が起こると期待していたか。
    2. 事実: 実際に何が起こったか。
    3. 成功: 何がうまくいったか、その理由は何か。
    4. 失敗: 何がうまくいかなかったか、その理由は何か。
    5. 改善: 次回は別の方法で行うべきか、または繰り返すべきか。
  • 3.3.3. システムとデータの役割
    • 効率化: 文書マネジメントシステムやチーム協働システムを活用し、教訓の共有と報告を行う。
    • デジタル化: 報告書やログを統合システムから生成し、必要に応じて詳細データへアクセスできるドリルダウン能力を備えた形で提示する。

4. 進捗と教訓を報告する

• 4.1. 報告頻度の考え方 報告の頻度は、必要なコントロール・レベルに応じて適切に設定する。これはプロジェクトの状況により変動し得る。
  • 頻度を下げる例: チームの経験が豊富で、信頼性が高い場合。
  • 頻度を上げる例: チームの経験が浅く、十分な確信が得られるまでのモニタリングが必要な場合。
• 4.2. 主要な報告書一覧

  報告書	送信元/宛先	種類	主な目的
  チェックポイント報告書	TM -> PM	時間ベース	チーム計画の進捗とステータス更新を報告する
  ハイライト報告書	PM -> プロジェクト委員会	時間ベース	プロジェクトおよびステージの進捗とステータス更新を報告する
  教訓報告書	状況による	イベント/時間	特定の教訓、ステージ、またはプロジェクト全体の詳細な教訓レビューを提供する
  課題報告書	状況による	イベントベース	変更要求、仕様外項目、ビジネス機会、問題などを正式にレビュー・対応可能にする
  例外報告書	PM -> プロジェクト委員会	イベントベース	許容度を超える/予測事態を報告し、委員会の指示を仰ぐ
  ステージ終了報告書	PM -> プロジェクト委員会	イベントベース	ステージの実績を報告し、次ステージへの承認を要求する
  プロジェクト終了報告書	PM -> プロジェクト委員会	イベントベース	全体のパフォーマンスと後続勧告を報告し、クローズの承認を要求する

• 4.3. 報告の形式とデジタル化
  • 構成と整合性: 特定の形式は定義されていないが、品質・リスク・課題マネジメントのアプローチと整合させる必要がある。プログラムの一部である場合は、そのモニタリング要件にも整合させる。
  • 電子ダッシュボード: 統合システムのデータを集約したダッシュボード形式が推奨される。各レベルの利害関係者が、役割に応じた情報にアクセスできる。
  • セルフサービス: 成果物のステータス(スナップショット)は、手動の文書ではなく、システム内の成果物登録簿に記録し、関係者が自ら確認できる環境を構築する。
• 4.4. 教訓報告に含めるべき内容
  • 成果物の開発: プロダクト作成に直接関わる情報。
  • マネジメント側面: プロジェクト・マネジメントのプラクティス、プロセス、手順、ツールなどの有効性(貢献した点や問題点)。

5. 予測する

• 5.1. 例外管理と予測の重要性 例外によるマネジメントの原則において、予測は極めて重要な要素である。
  • 迅速な対応: 実際に偏差が発生するまで待つのではなく、予測した段階で早期に対応することが、プロジェクトの成功を確保するために不可欠である。
• 5.2. 予測の対象と情報源
  • 多角的な視点: 時間やコストだけでなく、7つのパフォーマンス最終目標(ベネフィット、品質、スコープ、持続可能性、リスクを含む)すべてを考慮する。
  • 実績の活用: 現在のプロジェクトのパフォーマンスに加え、組織内外の過去のプロジェクト実績を考慮する。
• 5.3. データ分析とシステムの活用
  • 意思決定の支援: 収集したデータを分析・照合することで、将来のリスクや成果を予測し、ビジネス上の正当性が継続しているかを判断する。
  • 統合システムのメリット: データが統合システムで管理されていれば、What-ifシナリオのシミュレーションが可能になり、PMの予測作業の負担が軽減される。
  • 外部データの活用: デジタルおよびデータ・マネジメント・アプローチに基づき、データ・トラストなどの外部参照データを利用することで、より高度な予測データ解析(予測分析)が可能になる。

6. エスカレーションする

進捗レビューに基づき、各レベルの計画が合意された許容度(トレランス)内に収まるかを判断する。許容度を超える、または超えると予測される状況は例外とみなされ、上位のマネジメント層へ報告(エスカレーション)が必要となる。

• 6.1. ワーク・パッケージ・レベルの例外
  • 状況把握: PMは、チェックポイント報告書を通じてチーム・マネージャー(TM)から進捗通知を受ける。
  • 対応フロー: TMが許容度超過を予測した場合、**課題(Issue)**を提起してPMに通知する。
  • 是正: PMが状況を確認し、必要な是正処置についてTMに助言・指示を行う。
• 6.2. ステージ・レベルの例外
  • 報告: ステージ許容度の超過が予測される場合、PMは分析結果をまとめた課題報告書を作成し、その後プロジェクト委員会へ例外報告書を提出する。
  • 委員会の判断: プロジェクト委員会は報告を受け、以下のいずれかの対応を選択する。
    • 例外計画書の作成指示(現行計画に代わる新たな計画)。
    • 原因の除去、または許容度の再設定(調整)。
    • 検討のための時間確保。
  • 承認: 例外計画書が要求された場合、プロジェクト委員会がその内容をレビューし、承認または拒否を決定する。
• 6.3. プロジェクト・レベルの例外
  • 権限の移行: プロジェクト全体の許容度を超える予測が生じた場合、プロジェクト委員会はプロジェクトを指揮する権限を失う。
  • エスカレーション先: 最終的な決定権は、さらに上位のビジネス・レイヤー(プログラム管理層など)に委ねられる。
  • 計画策定: プロジェクト委員会は、ビジネス・レイヤーの判断を仰ぐために、PMに対してプロジェクトレベルの例外計画書を作成させる。

7. 進捗マネジメントにデータとシステムを使用する

データと技術を効果的に活用することで、進捗トラッキングと意思決定の精度が向上し、プロジェクトをより正確に管理することが可能になる。

• 7.1. プロジェクト・データの形態:
  • プロジェクト文書、コミュニケーション記録、プロジェクト・ログ、レコードなど。
  • 組織内部のデータだけでなく、外部データも含まれる。
  • デジタル形式と非デジタル形式の両方が対象となる。
• 7.2. 過去実績から未来の予測へ 進捗レビューの役割は、単に過去の実績を振り返るだけではない。
  • データの蓄積: システムを介してデータを安全に保護・保存する。
  • 予測への活用: 蓄積された過去のパフォーマンス・データを分析し、将来のパフォーマンスを予測するための基盤として活用する。

技法

ステップ 1: ワーク・パッケージ・レベルの対応

1. 予測と検知: チーム・マネージャー(TM)が、ワーク・パッケージ(WP)内の成果物が許容度から外れると予測する。
2. 課題の提起: PMの注意を引くため、課題(Issue)を提起する。
3. 記録と分析: * 課題は課題登録簿に記録される。 * 詳細な分析が必要な場合は、課題報告書を作成する。
4. 解決の判断: * PMがステージ許容度内で解決できる場合、例外報告書は不要。 * 解決した課題は、次回のハイライト報告書でプロジェクト委員会へ事後報告し、必要に応じて教訓ログに記録する。

支援技法

進捗管理や意思決定を円滑にするために、以下の技法を活用する。

• ダッシュボード グラフや信号機(赤・黄・青)などの視覚的表現を用い、膨大な意思決定情報を統合して表示する技法。
• デイリー・スタンドアップ 毎日短時間で行う会議。以下の3つの質問を軸に、チーム内で進捗と障害を共有する。
  • 昨日何をしたか？
  • 今日何をするか？
  • 問題や課題はあるか？
• アーンド・バリュー・マネジメント(EVM) スコープ・スケジュール・コストを統合してベースラインと比較する技法。過去の客観的評価だけでなく、総コストや完了時期の予測にも活用できる。
• ピア・レビュー プロジェクト外部のPM 経験者に依頼し、客観的な視点からプロジェクトの評価を受ける技法。
• バーン・チャート(バーンダウン / バーンアップ) 作業の進捗を線グラフで可視化する技法。アジャイル開発で特によく使われる。

  種類	特徴	役割
  バーンダウン・チャート	残っている作業量を示す	見積もりの課題を早期に特定し、残り労力を理解する
  バーンアップ・チャート	完了した作業量を示す	作業の完了度合いを可視化し、チームのモチベーションを高める

• レトロスペクティブ(ふりかえり) 成果物そのものではなく、作業方法に焦点を当てたレビュー。
  • 成功のポイント: 独立したファシリテーターの配置、適切な参加者の選定、視覚的ツールの活用、アクション可能な少数の課題への集中。
• カンバン・ボード 仕掛中の作業(WIP)を制限し、作業の流れを可視化するシステム。
  • 機能: 状態(ステータス)ごとに列を分け、作業カードを左から右へ移動させる。
  • メリット: ボトルネックや障害を視覚的に即座に特定できる。

ステップ 2: 例外報告と意思決定の要請

1. 例外の特定: 発生した課題がステージ(またはプロジェクト)の許容度に影響を及ぼし、その範囲を超えると予測される場合、PMは例外報告書を作成する。この報告書には、以下の内容を盛り込む必要がある。 * 発生している状況の具体的な詳細 * 解決のための複数のオプション(選択肢) * PMとしての勧告(推奨案)
2. エスカレーション: 例外報告書は、意思決定を支援する関連データとともに、指揮レベルであるプロジェクト委員会(またはプロジェクト・エグゼクティブ)へ提出される。

ステップ 3: 意思決定と指示

• 例外報告を受けたプロジェクト委員会(またはプロジェクト・エグゼクティブ)は、以下のいずれかのアクションを選択し、プロジェクトの方向性を決定する。
  • 許容度の再割当て: 全体的なプロジェクト許容度の範囲内で、ステージ許容度を再配分し、特定のステージで発生した許容度の超過問題を解決する。
  • 優先順位の再設定: 成果物のスコープ解除またはスコープ再設定を行い、ステージを強制的に許容度内に戻す。
  • 検討時間の確保: オプションを慎重に検討するため、判断にさらなる時間が必要であることをPMに通知する。
  • 例外計画の要求: 提示された例外報告の内容を採用し、PMに対して例外計画書の作成を指示する。
  • 上位層へのエスカレーション: 例外によってプロジェクト・レベルの許容度を超えることが予測される場合は、ビジネス・レイヤー(上位組織)へ報告し、助言と指示を仰ぐ。
  • 上位層からの指揮の伝達: ビジネス・レイヤーから受けた指示に基づき、PMに対して具体的な指揮を執る。

ステップ 4: 計画の再編と承認準備

• 指示を受けたPMは、以下の実務的な対応を行う。
  • 例外計画の策定:
    • ステージの停止: 現在進行中のステージを一旦停止し、仕切り直し(ステージ境界の導入)を行う。
    • 例外計画書の作成: 許容度の超過を解消し、プロジェクトを軌道に戻すため、承認された方針に基づき、現在のステージ計画に代わる新たな例外計画書を作成する。
  • 関連文書の調整: プロジェクト立ち上げ文書(PID)など、影響を受ける他のマネジメント成果物との整合性を図り、調整を行う。
  • 実績報告の作成: ステージが相当程度進捗しており、その実績データが意思決定に役立つと判断される場合は、例外計画書に加えてステージ終了報告書を作成する。

ステップ 5: 例外計画書の評価と決定

• プロジェクト委員会(またはプロジェクト・エグゼクティブ)は、提出された例外計画書を評価し、最終的なアクションを決定する。主なオプションは以下の通りである。
  • 却下と修正要求: 例外計画書の内容が不適切であると判断し、PMに対して内容の修正を指示する。
  • 却下と継続指示: 例外計画書を承認せず、現在のステージ計画のまま続行するよう指示する。
    • この際、計画の微調整が必要になる場合がある。
  • 承認: 例外計画書を正式に承認する。承認後、計画書をPMへ返送し、新しいベースラインとして今後の活動(ステージの再開・実行)を開始させる。

ステップ 6: 例外計画の実施と再開

• 承認された例外計画を実行に移し、プロジェクトを正常な軌道に戻す最終ステップである。
  1. 新計画の発効: 承認された例外計画書は、PMに返送された時点で、新たなステージ計画書として効力を持つ。
  2. 作業の再認可: PMは、例外の原因となった課題への対応を考慮した上で、チームに対して次のワーク・パッケージ・セットの実行を認可し、作業を再開させる。
  3. スケジュールの整合: 可能であれば、新しいステージの終了時期を、当初予定されていた旧ステージの終了時期と一致させるよう検討する。
  • メリット: プロジェクト委員会によるステージ終了評価のスケジュールを変更する必要がなくなり、元のプロジェクト計画との整合性を引き続き確保できる。
  4. 可視化の活用: 成果物流れ図を使用して進捗をマッピングすることで、成果物間の依存関係や順序をプロジェクト委員会に分かりやすく提示できる。

マネジメント成果物

アウトプット

マネジメント成果物: デジタルおよびデータ・マネジメント・アプローチ(プロジェクト立ち上げ文書のー部)

• 目的:
  1. プロジェクト・マネジメント(プロジェクト・コントロールなど)とプロジェクト作業(設計や建設のためのデジタル・ツインの使用など)を支援するために、デジタル技術をどのように使用するか？
  2. データと情報がプロジェクト・エコシステム全体と、プロジェクト・ライフサイクル全体およびその後にわたり、どのように作成、使用、管理されるか？
• コンテンツ概要
  • スコープ: 管理するデータを記述します。
  • デジタル技術要件: プロジェクト・マネジメント活動の自動化と促進、および専門的なプロジェクト作業を支援するために必要な専門的な技術を考慮した場合にプロジェクトで必要となるデジタル技術の分析(場合によっては、ビジネスとサプライヤーによってすでに確立されているシステムの使用が含まれる場合がある。また、別のシステムや追加のシステムが必要になる場合もある)。
  • データ・マネジメント要件: 次の点を考慮した場合にプロジェクトが生成または必要とするデータの分析。
    • どのようなデータまたは情報が必要か、または作成されるか？
    • データはどこから取得されるか？
    • データはどこに保持されるか？
    • データはどのように安全に保たれるか？
    • どのレベルのプライバシーが必要か？
    • データまたは情報はどのように分析、キュレーション、提示されるか？
    • 誰がアクセス権または権限を持つか。完全性はどのように確保されるか？
    • データ品質はどのように保証されるか？
    • プロジェクト完了後、データはどうなるか？
  • デジタルおよびデータ・マネジメント手順: プロジェクトで使用されるデジタルおよびデータ・マネジメント手順の記述(デジタルおよびデータ・マネジメント要件の分析をベースとする)
  • 責任: デジタルおよびデータ・マネジメント・アプローチに関連する役割の実行責任者
  • 正式なデジタルおよびデータ・マネジメント活動の時期: 例えば、システムの実装、データ監査の時期、調達活動を支援するためのデータ・ルームの提供など
  • サポート・ツールまたはシステム: デジタルおよびデータ・マネジメントに使用されるツールまたはシステムについて記述する。例えば、プロジェクト予測における人工知能(AI)の使用。
  • 標準: プロジェクトに必要なデジタルおよびデータ・マネジメント標準について記述する
  • 参照: 関連する文書または成果物

デイリー・ログ(プロジェクト・ログのー部)

• 目的:
  • 他のマネジメント成果物の対象とならない非公式の課題、必要な処置、または重要なイベントを記録することです。デイリー・ログは、PMのプロジェクト日記としての役割を果たすことができます。また、他の登録簿が設定されていないときに、プロジェクトの始動プロセス中に課題やリスクのリポジトリとしても使用できます。
  • PMのデイリー・ログとは別に、ワーク・パッケージ用に1つ作成したいとチーム・マネージャーが考える場合、複数のデイリー・ログが作成されます。PMまたはチーム・マネージャーが何らかのイベントについて記録するのが適切であると考えた場合、エントリを作成します。通常、項目は考察や会話、観察をべースとします。
• コンテンツ概要
  • ログの項目: 非公式の課題、処置、イベント、または日記の記述
  • 日付: ログに記録された日付、評価日、または処置日

教訓ログ(プロジェクト・ログのー部)

• 目的: 現在または今後のプロジェクトに適用される教訓を記録するリポジトリを提供することです。他のプロジェクトで把握された教訓は、プロジェクトのアプローチおよび計画書へのインプットとして、教訓ログに記録します。プロジェクト実施中に把握された教訓は、新しい経験(良し悪しはあっても)として現在のプロジェクトに適用したり、他のプロジェクトに移転したりできます。
• コンテンツ概要
  • 教訓の識別子: 教訓の一意の参照コード
  • 教訓の記述書: 教訓の概要と関連する詳細。例えば、効果(プラス／マイナスの財務的インパクト)、既知の原因／トリガー、早期警告指標の有無、以前にリスク(脅威または機会)として特定されたことがあるか、勧告
  • 教訓の種類: チームの教訓、プロジェクトの教訓、ビジネス・レイヤーの教訓など
  • 教訓のオーナー: 教訓から学んだことの実行責任者(チーム、プロジェクト、またはビジネスからのものである可能性がある)
  • 格付け: 優先度と重大度の評価
  • ステータス: 教訓の現在のステータス(記録済み、レビュー済み、プロジェクト別の学習処置済み、ビジネス別の学習処置済みなど)
  • 教訓に関連する日付: 発生日、最終レビュー日、処置の期日、解決日など
  • レコード: 課題とその場所に関連付けられている文書のリスト

チェックポイント報告書

• 目的: ワーク・パッケージに定義された頻度で、ワーク・パッケージのステータスをPMに報告する
• コンテンツ概要
  • エグゼクティブ要約: チーム・マネージャーの報告書
  • 期間: チェックポイント報告書の対象となる報告期間
  • フォローアップ: 過去の報告書の未解決項目(完了した処置項目や未解決事項など)
  • 今回の報告期間: 今回の報告期間中にチームが開発する成果物、今回の報告期間中にチームが完成させた成果物、今回の報告期間中に実施した品質マネジメント活動、特定された教訓
  • 次の報告期間: 次の報告期間中にチームが開発する成果物、次の報告期間中にチームが完成させる予定の成果物、次の報告期間中に計画されている品質マネジメント活動
  • ワーク・パッケージの許容度のステータス: ワーク・パッケージの実行が許容度に対してどのように実施されているか(コスト/時間/スコープの実績と予測など)
  • 課題とリスク: ワーク・パッケージに関連した課題とリスクの更新

ハイライト報告書

• 目的: プロジェクト委員会(およびその他の利害関係者)に対し、定義された間隔でステージのステータスに関する要約を提供する
• コンテンツ概要
  • エグゼクティブ要約: PMの報告書
  • 期間: ハイライト報告書の対象となる報告期間
  • フォローアップ: 過去の報告書の未解決項目(完了した処置項目や未解決事項など)
  • 今回の報告期間: 今回の報告期間中に保留中の認可、実行中、完了済みものを含むワーク・パッケージの実際の進捗状況(ワーク・パッケージを外部サプライヤーが実施している場合、この情報に注文書と請求書データが添付される場合がある)。今回の報告期間中に完成した成果物、期間中に計画されていたが、開始または完成していない成果物(早期警告指標または時間許容度の違反可能性を提供する)、期間中に実行された是正処置など
  • 次の報告期間: 次の期間中に認可予定、実行中、完成予定のものを含むワーク・パッケージの進捗状況の予測(ワーク・パッケージを外部サプライヤーが実施している場合、この情報に注文書と請求書データが添付される場合がある)。次の期間に完成予定の成果物、次の期間に完成予定の是正処置など
  • ステージおよびプロジェクト許容度のステータス: プロジェクトとステージの実行が許容度に対してどのように実施されているか(コスト/時間の実績と予測など)
  • 主要課題とリスク: 実際または潜在的な課題とリスクの概要(その期間に提起、処置、保留された変更要求または仕様外項目のリストなど)
  • 教訓(該当する場合): うまくいったこととうまくいかなかったことのレビュー、およびビジネスが検討するべき勧告。教訓ログまたは教訓報告書がある場合はそこから取得する。

教訓報告書

• 目的:
  • 教訓を共有し、その教訓を是正処置のトリガ一にして、組織が適切な作業の進行を確保することです。教訓報告書はプロジェクトのいかなる時点においても作成でき、終了時まで遅延させる必要はありません。この報告書は、ステージ終了報告書またはプロジェクト終了報告書の一部として含めるのが一般的です。特定の組織(ユーザー、サプライヤー、ビジネスなど)を対象にした教訓報告書を作成することが適切(および必要)な場合もあります。
• コンテンツ概要
  • エグゼクティブ要約: 教訓の要約
  • ワーク・パッケージ、ステージ、またはプロジェクトの教訓の記述書: うまくいったこととうまくいかなかったことのレビュー、および現在または今後のプロジェクトへの勧告
  • 特定の教訓の記述書: 影響(プラス／マイナスの財務的インパクトなど)、既知または証明された原因やトリガー、早期警告指標の有無、以前にリスク(脅威または機会)として特定されたことがあるか、現在または今後のプロジェクトへの勧告。

例外報告書

• 目的: ステージ計画書またはプロジェクト計画書が設定された許容度を超えると予測される場合にプロジェクト委員会に通知し、続行する方法のオプションと勧告を提供する
• コンテンツ概要
  • 識別子: 例外の一意の識別子
  • 日付: 発行日
  • 記述書: 報告される例外の概要
  • 例外の理由: 現行の計画からの偏差の理由の説明
  • 例外の結果: 偏差に対処しない場合に、プロジェクトとビジネスが受ける影響
  • オプション: 偏差に対処するために使用できるオプションと、各オプションを採用した場合のビジネス・ケース、リスク、許容度に対する効果
  • 勧告: 使用できるオプションのうち、推奨されるオプションと、その理由
  • 教訓: 現在または今後のプロジェクトで、例外から学べること

ステージ終了報告書

• 目的: 現在までの進捗状況の要約、全体的なプロジェクトの状況、プロジェクトで次に何をすべきかを決定するようプロジェクト委員会に依頼するのに十分な情報を伝える
• コンテンツ概要
  • エグゼクティブ要約: PMの報告書
  • パフォーマンス・レビュー: ビジネス・ケース、プロジェクト目標、ステージ目標、チーム・パフォーマンス、品質活動、成果物のステータス、成果物のフェーズの移管(適用可能な場合)、教訓のレビュー
  • 継続対応勧告の概要: ステージ内で成果物をフェーズごとに移管した後にビジネスが実行する処置
  • 主要課題とリスク: 実際または潜在的な課題とリスクの概要(その期間に提起、処置、保留された変更要求または仕様外項目のリストなど)
  • 予測: 次のステージとプロジェクトに対するターゲットおよびその許容度

プロジェクト終了報告書

• 目的: プロジェクトの認可に使用されたプロジェクト立ち上げ文書のバージョンを基準として、プロジェクトがどのように実施されたかをレビューする
• コンテンツ概要
  • エグゼクティブ要約: PMの報告書
  • パフォーマンス・レビュー: ビジネス・ケース、プロジェクト目標、チーム・パフォーマンスのレビュー
  • 成果物のレビュー: 成果物、仕様外項目、プロジェクト成果物の移管、教訓のレビュー
  • 継続対応勧告の要約: ビジネスまたはサプライヤーが実行するプロジェクト終了後の処置

主要な役割

役割	責任
ビジネス・レイヤー	ビジネス・レイヤーの責任
プロジェクト・エグゼクティブ	プロジェクト・エグゼクティブの責任
シニア・ユーザー	シニア・ユーザーの責任
シニア・サプライヤー	シニア・サプライヤーの責任
PM	プロジェクト・マネージャーの責任
チーム・マネージャー	チーム・マネージャーの責任
プロジェクト保証	プロジェクト保証の責任
プロジェクト支援	プロジェクト支援の責任

ビジネス・レイヤーの責任

• プロジェクト許容度を設定し、プロジェクト権限委任に文書化する
• ビジネス・レイヤーの報告要件と標準(ハイライト報告書や安全衛生固有のコンテンツの定期的な時期など)を提供する
• プロジェクト・レベルの許容度を超えると予測される場合、例外報告書に関する決定を下す

プロジェクトエグゼクティブの責任

• ステージ許容度を設定する
• ビジネスの観点からのデジタルおよびデータ・マネジメント・アプローチを承認する(プロジェクトのクローズ時のレガシーデータの処理など)
• ビジネスの観点から、成果に向けての一貫性のある進捗を確保する
• ステージ・レベルの許容度を超えると予測される場合、例外報告書に関する決定を下す
• プロジェクト許容度を超過すると予測される場合、ビジネス・レイヤーに対し、プロジェクトに対する今後の処置を勧告する
• プロジェクトの持続可能性の報告に関するビジネスへの説明責任を維持する
• プロジェクトから学んだ教訓をビジネスと共有することの説明責任を維持する

シニアユーザーの責任

• ユーザーの観点から、デジタルおよびデータ・マネジメント・アプローチに合意する(運用および保守のニーズのための成果物データの移管など)
• ユーザーの観点から、持続可能性の報告要件を定義する
• ユーザーの観点から、成果に向けての一貫性のある進捗を確保する

シニアサプライヤーの責任

• サプライヤーの観点から、デジタルおよびデータ・マネジメント・アプローチに合意する。例えば、サプライヤーが使用または提供する専門的な技術や、ビジネスから提供されたりビジネスに移転されたりするデータに対する期待など
• サプライヤーの観点から、持続可能性の報告に対する実行責任を維持する
• サプライヤーの観点から、成果に向けての一貫性のある進捗を確保する

プロジェクトマネージャーの責任

• 利害関係者と協議し、デジタルおよびデータ・マネジメント・アプローチを策定し、維持する
• ワーク・パッケージ記述書で合意されたデータ・マネジメント手順をチーム・マネージャーが実施していることを確保する
• ワーク・パッケージを認可し、ワーク・パッケージの許容度を設定する
• プロジェクト・ログを確立し、維持する
• ステージ計画書に対する進捗をモニタリングする
• 教訓報告書、ハイライト報告書、例外報告書、ステージ終了報告書、プロジェクト終了報告書を作成する
• プロジェクトの観点から、持続可能性の報告に対する実行責任を維持する
• ステージ・レベルまたはプロジェクト・レベルの許容度を超えると予測された場合、プロジェクト委員会向けの例外報告書を作成する

チームマネージャーの責任

• ワーク・パッケージについてPMと合意する
• ワーク・パッケージ記述書で合意されたデータ・マネジメント手順を実施する
• チェックポイント報告書を作成する
• チームのために持続可能性の報告に対する実行責任を維持する
• ワーク・パッケージの許容度との偏差が予測される場合、PMに通知する
• 課題、リスク、教訓、完了した品質活動、完成した成果物をプロジェクト支援に通知する

プロジェクト保証の責任

• デジタルおよびデータ・マネジメント・アプローチについて、PMに助言する
• デジタルおよびデータ・マネジメント・アプローチがビジネスの方針に準拠していることをプロジェクト委員会に確認する
• 合意された許容度に対してステージとプロジェクト進捗を確認する
• プロジェクト進捗と外部イベントに対してビジネス・ケースを確認する
• 依頼された場合、プロジェクト委員会とPMを支援するために、ビジネス・ケースに対するインパクトの例外報告書をレビューする
• データ・マネジメントのプラクティスをレビューして、データが適切に管理されていることをプロジェクト委員会に保証し、データがプロジェクトのデジタルおよびデータ・マネジメント・アプローチに沿って実施されていることを確保する

プロジェクト支援の責任

• プロジェクト・マネジメント・チームがデジタルおよびデータ・マネジメント・アプローチを実施および適用するのを支援する
• デジタルおよびデータ・マネジメント・アプローチを支援するスペシャリスト・ツール(計画立案、コントロール、報告ツールなど)を管理する
• 報告書(チェックポイント報告書、例外報告書、教訓報告書、ステージ終了報告書、プロジェクト終了報告書)の編集、配布、保存を支援する
• PMを支援し、プロジェクト・ログを維持する