プロジェクト・マネジメント-進捗 | 项目管理

進捗

進捗プラクティスの目的は、次のとおりです。 * 実際の達成度をモニタリングし、計画と比較するメカニズムを確立する * プロジェクト目標と継続的な実行可能性の予測を提供する * 例外の原因となる偏差をコントロールするプロジェクト・マネジメントの主要コンポーネントはプロジェクトの進捗コントロールであり、承認されたビジネス・ケースに対し、そのプロジェクトが引き続き実行可能であることを確保します。進捗コントロールでは、ベネフィット、時間、コスト、品質、スコープ、持続可能性、リスクのパフォーマンス最終目標に対し、実際の進捗状況を測定します。進捗はワーク・パッケージ、ステージ、プロジェクト・レベルでモニタリングできます。定義: * 进捗: 計画された達成目標の達成の測定。 * 予測: 履歴データと過去のパターンの研究することで出される予測。 * 例外: プロジェクト・マネージャーとプロジェクト委員会(あるいは、プロジェクト委員会とビジネス・レイヤー)が合意した許容度を超える偏差が生じることが予測される状況。

ガイダンス

効果的な進捗マネジメントには次のものが含まれます。 * 進捗コントロールのマネジメント・レベルと許容度を定義する
* 2種類のコントロール(イベントまたは時間に基づくコントロール)を適用する * 進捗と教訓をレビューする * 進捗と教訓を報告する * 残り作業時間を予測する * エスカレーションする * データを使用する

1. 進捗コントロールのマネジメント・レベルと許容度

plain ¹ 品質許容度はステージまたはワーク・パッケージ・レベルでまとめて定義せず、計画書のスコープ内の成果物記述書ごとに定義します。
² 計画書のスコープは提供される一連の成果物によって定義されます。スコープ許容度(使用する場合)は計画書の成果物ブレークダウン・ストラクチャーへの注意書き、または参照の形式で記述する必要があります。ステージまたはワーク・パッケージ・レベルのスコープ許容度は、アジャイルなどの反復的かつ段階的な開発手法を適用する場合に特に役立ちます。
³ プロジェクト委員会がステージを認可するとき、またはプロジェクト・マネージャーが特に外部のサプライヤーにワーク・パッケージを認可するときには、より詳細なステージ・レベルのリスク許容度を設定することもできます。
⁴ プロジェクト委員会がステージを認可するとき、またはプロジェクト・マネージャーが特に外部のサプライヤーにワーク・パッケージを認可するときには、より詳細なステージ・レベルの持続可能性の許容度を設定することもできます。

2. コントロールの種類

効果的なプロジェクト・コントロールは、実際の進捗を正確、タイムリー、かつ定期的に測定し、プロジェクトまたはステージのその時点での状況を計画された進捗と比較し、必要な是正処置を講じることによって提供されます。プロジェクトの有効期間全体を通じて、イベントに基づくコントロールと時間に基づくコントロールの2 種類の進捗コントロールを提供します。

定義 イベントに基づくコントロール: 特定のイベントが発生したときに行われるコントロール。 時間に基づくコントロール: 事前に定義された間隔で定期的に実行されるマネジメント・コントロール。

モニタリングは時間に基づく活動で、コントロール(意思決定)はイベントに基づく活動です。報告は時間とイベントの両方に基づきます。イベントに基づくコントロールを使用すると、プロジェクト・マネジメント・チームは最も必要なときに会議を行い、不必要にまたは頻繁に会うことがなくなるため、効率性が向上します。

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

ステージのコントロール・プロセスのー環として、プロジェクト・マネージャーはチェックポイント報告書を使って定期的に作業の進捗をレビューし、プロジェクト・ログを管理します。プロジェクト・マネージャーはこの情報を基に、実際に達成した進捗に応じてステージ計画書を更新します。チェックポイント報告書の形式と報告頻度は、個々のワーク・パッケージのニーズによって異なります。進捗は計画の詳細レベルでのみコントロールできます。また、プロジェクトのデータを分析して傾向を把握し、ステージの全体的な健全性を把握する必要もあります。アクションはさまざまなところから提起されるため、小規模なアクションについてはデイリー・ログに記録し、完了時に印を付ける程度で十分です。デイリー・ログは、他のマネジメント成果物によって記録されない非公式の課題、メモ、観察などを記録するために使用することもできます。正式な課題と非公式の課題の違いは、正式な課題がオープン・フォーラムとして課題登録簿に記録される点です。課題登録簿に記録されると、プロジェクトまたはステージへの重大なインパクトがあるとしてモニタリングおよびレビューされます。非公式な課題とは、重大なインパクトを及ぼさないか、オープン・アクセスが不適切な場合に適合する方法で処理する必要がある課題です。(デイリー・ログは、個々の観察を記録するうえで便利な方法です。それのみでは一見すると重要でないと思えるものが、並べることによってプロジェクト・マネージャーが新たな課題やリスクに気付くことがあります。) 成果物登録簿には、完成している成果物、現在進行中の成果物、開発を待機中の成果物のステ一タスに関するデータも提供されます。この登録簿のデータは、プロジェクト進捗の保証を提供するために、成果物の物理的ステータスと比較される場合があります。プロジェクト・マネジメント・チームが経験から学ぶ。(したがって、プロジェクト・チームは、プロジェクトの存続期間を通じて関連する教訓を積極的に探し、記録し、組み込み、残りの作業に適用し、将来のプロジェクトのために共有します。多くの場合、教訓の特定は進捗レビューの際に行われます。プロジェクト・ログには教訓ログが含まれ、教訓ログは教訓の把握に使用され、進捗のレビュー時にアクセスされます。)

定義: 教訓: 教訓は、当該プロジェクトまたは他のプロジェクトの将来を支援し、経験からの学習を積極的に促進するための情報。経験は、成功したテストや成果のようにプラスのものもあれば、事故や障害のようにマイナスのものもある。プロジェクト中に教訓を記録することは、組織、プロジェクト・チーム、その他の既存および将来のプロジェクトに役立ちます。教訓は、プロジェクトのポジティブな経験とネガティブな経験の両方を反映した文書化された情報であり、教訓は次のようなことから把握できます。 * プロジェクト終了後のレビュー中 * プロジェクト期間全体における会議中(教訓を共有するためにプロジェクト終了後のレビューまで待つ必要はない) * チェックポイント報告書やハイライト報告書などのマネジメント成果物経由 * レトロスペクティブの実施 * 課題が発生したとき * 利害関係者の 1 対 1 の会議中 * データと情報が共有される電子ワークスペースを使用しながら教訓の分析では、次の順序で 5 つの質問への答えを見つけます。 * 何が起こると期待していたか。 * 実際に何が起こったか。 * 何がうまくいったか、その理由は何か。 * 何がうまくいかなかったか、その理由は何か。 * 何を別の方法で行う必要があるか、何を繰り返す必要があるか。文書マネジメント・システムまたはチーム協働システムは、教訓からの知識を共有および報告するのに便利なツールです。システムとデータは、進捗のレビュ一において主要な役割を果たします。(前述の報告書、登録簿、またはログは、データが統合され、アクセス可能なシステムから生成される場合があります。これは、デジタルおよびデータ・マネジメント・アプローチに準拠しており、より詳細にアクセスするためのドリルダウン能力を備えた電子的な方法で提示されます。)

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

5. 予測する

例外によるマネジメントの原則の基本的なコンポーネントは予測です。(例外とは、合意されている許容度レベルを超える偏差が発生すると予測される状況です。その偏差が発生するまで待つ必要はなく、待つことで良い結果は生まれません。)したがって、プロジェクト内の予測は、プロジェクト・リスクへの対応を特定し、プロジェクトの成果を予測し、プロジェクト全体の成功を確保するために不可欠です。 (これまでのプロジェクトや組織内外の他のプロジェクトのパフォーマンスを考慮することが重要です。トラッキングする主な測定基準としてよく挙げられるのは時間とコストですが、パフォーマンス最終目標すべてを考慮しなければなりません。) 次に、収集されたデータをふるいにかけ、照合、分析して、プロジェクト・マネージャーに過去のパフォーマンスに関する十分な情報を提供し、将来のリスクと成果を予測し、プロジェクトがビジネス正当性の継続を保持しているかどうかを判断します。繰り返しになりますが、データは統合システムに保持され、「what if」シナリオ予測も可能になり、プロジェクト・マネージャーの予測作業を軽減できる場合があります。デジタルおよびデータ・マネジメント・アプローチでは、プロジェクトで使用されるシステムとデータが記述され、予測を支援します。(これには、予測デ一夕解析を使用できるようにするために、参照クラスとしてのデータ・トラストからのデータなど、プロジェクトまたはビジネスの外部からデータを使用することも含まれる場合があります。)

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

進捗レビューのアウトプットに基づき、ワーク・パッケージ、ステージ計画書、プロジェクト計画書が合意された許容度の範囲内に留まるか、または超えるかを判断します。(合意された許容度を超える、または超えると予測される場合は例外です。)

6.1. ワーク・パッケージ・レベルの例外ワーク・パッケージの許容度についてチーム・マネージャーと合意したプロジェクト・マネージャーは、定期的なチェックポイント報告書で常に進捗に関する最新情報を通知されます。ワーク・パッケージが許容度を超えると予測された場合、チーム・マネージャーはプロジェクト・マネージャーの関心を引くために課題を提起して、プロジェクト・マネージャーに通知します。プロジェクト・マネージャーは必要な是正処置について助言します。
6.2. ステージ・レベルの例外ステージで許容度を超えると予測された場合、プロジェクト・マネージャーは偏差背景にあるデータを把握、分析した課題報告書を作成し、その後プロジェクト委員会に例外報告書を提供します。この報告書の情報をベースとして、プロジェクト委員会はプロジェクト・マネージャーに対して、許容度を超えると予測される計画に代わる例外計画書を作成するよう求める場合があります。また、プロジェクト委員会は原因を取り除いたり、許容度の受け入れと調整を行ったり、勧告を検討するためにさらなる時間を求めたりする場合があります。例外計画書が要求された場合、プロジェクト委員会は例外計画書をレビューし、承認または拒否します。
6.3. プロジェクト・レベルの例外プロジェクト許容度を超えると予測された場合、プロジェクト委員会はプロジェクトを指揮する権限を失い、ビジネス・レイヤーに決定を委ねる必要があります。プロジェクト委員会は、プロジェクト・マネージャーにプロジェクトの例外計画書の作成を要求する場合があります。

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

データと技術は、進捗のトラッキングと意思決定を支援することで、プロジェクトをより正確に管理するのに役立ちます。(プロジェクト・データは、プロジェクト文書、通信、プロジェクト・ログ、レコードの形式になります。これには、内部データと外部データの両方と、デジタル形式と非デジタル形式が含まれます。) 進捗レビューは、過去を振り返るだけではありません。システムを介してデータを保護して保存した後、過去のパフォーマンスは今後のパフォーマンスを予測するために使用されます。

技法

1. ステップ 1

ワーク・パッケージ・データから、チーム・マネージャーはワーク・パッケージ内の1つ以上の成果物がその許容度の1つから外れると予測します。この時点で、プロジェクト・マネージャーの注意を引くために課題が提起されます。課題は課題登録簿に取り込まれます。一部の課題については、取り込まれた詳細のみで課題を分析し、対応できる場合があります。その他の課題では、より詳細な情報が必要な場合や、より正式な方法での提起と対応が必要な場合があります。このような場合、課題は課題報告書により詳細に記録されます。プロジェクト・マネージャーがステージの許容度内で課題を解決できる場合、例外報告書を作成する必要はありません。ただし、この課題は次のハイライトでプロジェクト委員会に報告され、教訓ログにメモが作成される場合があります。

2. ステップ 2

課題がステージ(またはプロジェクト)の許容度に影響を与え、超過が予測される場合は、プロジェクト・マネージャーによって例外報告書が作成され、解決オプションと勧告を含む状況の詳細が示されます。例外報告書は、意思決定を支援するためのその他の関連データとともに、指揮レベルのプロジェクト委員会またはプロジェクト・エグゼクティブに送信されます。

3. ステップ 3

プロジェクト委員会またはプロジェクト・エグゼクティブが取ることができるアクションには、次のようなオプションがいくつかあります。 * 全体のプロジェクト許容度を再度割り当てて、ステージ許容度の超過を解決する * ステージを許容度内に戻すために要件の優先度付けを再設定する(成果物のスコープ解除またはスコープ再設定) * プロジェクト・マネージャーに、オプションを検討するためにより多くの時間が必要であることを通知する * 例外報告書を実施し、プロジェクト・マネージャーに例外計画書を要求する * 例外によってプロジェクトがプロジェクト・レベルの許容度の 1 つ以上を超える場合は、助言と指揮のためにビジネス・レイヤーにエスカレーションして例外報告書を実施する * ビジネス・レイヤーはプロジェクト委員会に指揮を提供し、プロジェクト委員会はそれに応じてプロジェクト・マネージャーを指揮する

4. ステップ 4

プロジェクト・マネージャーは現在のステージを停止し、ステージ境界を導入して例外計画書を作成し、プロジェクト立ち上げ文書内のその他の関連情報を調整します。ステ一ジ終了報告書が決定に役立つデー夕になるまでステージが進行している場合は、ステージ終了報告書を作成することもできます。

5. ステップ 5

プロジェクト委員会またはプロジェクト・エグゼクティブは例外計画書を評価しますが、これには次のようなオプションがいくつかあります。 * 例外計画書を却下し、プロジェクト・マネージャーに修正を要求する * 例外計画書を却下し、プロジェクト・マネージャーにステージを続行するように指揮する * これには、現在のステージの微調整が必要になる場合がある * 例外計画書を承認し、今後のアクションのためにプロジェクト・マネージャーに返送する

6. ステップ 6

例外計画書は、プロジェクト・マネージャーが新しいステージ計画書として実施する指揮とともに受け取ります。実際には、例外計画書が新しいステージ計画書になります。プロジェクト・マネージャーは、例外をトリガーした課題を考慮して、提供レベルの次のワーク・パッケージ・セットの再開を認可します。望ましい場合、または実行可能性がある場合、新しいステージの終了を古いステージの終了に整合させることを検討します。これにより、プロジェクト委員会またはプロジェクト・エグゼクティブによるステージ終了評価のスケジュールを変更する必要がなくなり、プロジェクトのその時点で決定に必要な元の要件との整合性を引き続き確保できます。成果物流れ図を使用して進捗をマッピングすると同時に、プロジェクト委員会に成果物の依存関係と順序付けを知らせることもできます。

支援技法

ダッシュボード

ダッシュボードは、グラフや信号機などの表形式とグラフィック表現を使用して、膨大な量の意思決定支援情報を統合レベルで表現する技法です。

デイリー・スタンドアップ

デイリー・スタンドアップは、簡単に行われる毎日の会議です。進捗がレビューされ、すべてのチーム・メンバーが次の3つのガイドとなる質問を使用して、次のステップを宣言します。 * 昨日から何をしたか？ * 今日は何をする予定か？ * 何か問題や課題が発生したか？デイリー・スタンドアップの利点の一部は、チームの全員が他のメンバーが何をしているのかを常に認識できることにあります。これにより、組織化され、権限を与えられたチーム内で、一人のチーム・メンバーから別のチーム・メンバーにタイムリーな支援や提案を提供する機会が生まれます。

アーンド・バリュー・マネジメント

完成した成果物と実際のコストと時間を、スケジュールとコストの見積もりと比較することにより、スコープ、スケジュール、コスト・パフォーマンスを組み合わせて統合されたプロジェクトのベースラインを作成する技法です。過去のパフォーマンスの客観的な評価を提供するだけでなく、過去のパフォーマンスをベースにしてプロジェクトの総コストと期間を予測するために使用できます。

ピア・レビュー

ピア・レビューでは、プロジェクト・マネジメントの経験を持つ、プロジェクト・マネジメント・チーム以外の人物にプロジェクトの評価を依頼します。

バーン・チャート

完了した作業とまだ完了していない作業を1つ以上の線で示し、進捗を表す(タイムボックス期間中など)技法です。チャートは定期的に(通常は毎日)更新します。(これは、アジャイル・アプローチを使用する場合に最も一般的な技法の1つです。) バーン・チャートには、バーンダウン・チャートとバーンアップ・チャー2の２つの形式があります。バーンダウン・チャートは最もよく知られているチャートで、作業がどれほど残っているかを示します。一方、バーンアップ・チャートは作業の完了度合いを示します。バーンダウン・チャートは、見積もりの課題を早期に特定し、残っている作業量と労力を理解するのに役立ちます。バーン・チャートは、プロジェクトの成果に向けた進捗を示すことで、チームのモチベーションを高めるのに役立ちます。

レトロスペクティブ

レトロスペクティブは、作成されたものを見るのではなく、作業方法を具体的に検討する進捗レビューの一種です。レトロスペクティブの効果を最大に高めるには、計画、構造化、積極的な進行を行わなければなりません。極めて非公式なものになることもありますが、構造化されていない会議として実行されると効果がなくなり、より良い働き方に貢献しなくなる可能性があります。効果的なレトロスペクティブを実行することは、ワークショップを成功させることと似ており、次の点を考慮します。 * 適切な人を招待する(通常はチームのみ、場合によってはプロジェクト支援) * 独立したファシリテーターを持つ * 結果として行動に移せそうにない多数の課題ではなく、対処可能な少数の課題に焦点を当てる * さまざまな創造的なアプローチでレトロスペクティブを興味深い有用なものにする * 自分のアイデアを表現するのに役立つ視覚的なフィードバック・ツール

カンバン・ボード

カンバン・システムは現在行っている作業項目の数を制限する視覚的なマネジメント・システムです。カンバン・ボ = ドは、システム内の作業を視覚的に表示するためにカンバンで使用されるツールです。通常、作業項目のさまざまなステータスが完了するときに左から右に移動する一連の列(および場合によっては行)で構成されます。力ンバン・ボードはダッシュボードのように機能し、チームは障害とスムーズに流れていない領域を確認できます。

プラクティスの適用とコンテキスト

組織的な状況

すべてのプロジェクトの出発点は、プロジェクトにおいて意思決定または権限を必要とするビジネス・レイヤーのガバナンスの取り決めの時期を特定することです。通常、プロジェクトの進捗コントロールは、ビジネス・レイヤーの時期に整合させて設計することをお勧めします。通常、プロジェクトがプログラムまたはポートフォリオのー部である場合、プログラムまたはポートフォリオではプロジェクトの進捗コントロールを義務付けています。一般的に、これには共通のコントロール、手順、許容度、時期を定義することが含まれます。

商業的な状況

関係者間の契約は、プロジェクトやワーク・パッケージを管理するときのプロジェクト・マネージャーやチーム・マネージャ一の自由度を制約します。このため、契約が協力関係を阻害するのではなく、良好な関係を反映して促進し、テーラリングする場合には、各関係者の契約義務の尊重を確保することがグッド・プラクティスです。サプライヤーの観点から、プロジェクト・ライフサイクルは、ソリューションの認定、設計とコスト計算や入札、交渉などの契約前の活動を考慮して定義します。また、保証期間や保守期間など、プロジェクト終了時の活動も考慮される場合があります。

デリバリー手法

反復的かつ段階的なデリバリー手法を使用するプロジェクトでは、通常、スプリントの終わりまでに要件のどれだけが満たされているかをトラッキングすることに焦点を当てる方が、成果物の完成にかかる時間に焦点を当てるよりも適切です。許容度はこれに従って設定されています。受け入れ/品質仕様を満たす成果物の頻繁なデリバリーが進捗情報の主なソースであり、今後の進捗を予測する基礎を提供します。報告書の形式は、カンバンやバーンダウンまたはバーンアップ・チャートなどのアジャイル技法を使用する反復的かつ段階的なプロジェクトでは異なる場合があります。チェックポイント報告書は、開発チームによって送信されるのではなく、維持されているチャートをプロジェクト・マネージャーがレビューする「プル」システムをベースとしている場合があります。直線的かつ連続的なデリバリー手法を使用するプロジェクトの場合、ステージの成果物がいつ完成し、どのくらいのコストがかかるかに焦点が当てられる場合があります。このようにして、プロジェクト委員会は現在のステージから次のステージに移行するための堅固な基盤があることを確信できます。

持続可能性

進捗マネジメントは、プロジェクトのクリティカルな成功要因であるプロジェクト実施文書に記録された持続可能性の側面に関するデータを収集します。これは、プロジェクトが持続可能性の許容度内にあり、ビジネス・レイヤーによって確立されたパラメーター内にあることを確認するためです。持続可能性の一部の領域は、法律、規制、またはビジネス・レイヤー方針の対象になります。したがって、コンプライアンスを支援する証拠が必要になります。進捗マネジメントでは、この証拠を支援するのに必要なデータを特定して報告できる必要があります。プロジェクト・エグゼクティブは、持続可能性規制へのコンプライアンスが必要な場合、プロジェクトの監査を要求できます。助言は、ビジネスまたはプログラムの品質保証機能に求める必要があります。持続可能性の報告は、合意された報告要件とは別にするのではなく、プロジェクト・マネージャー、チーム・マネージャー、プロジェクト支援によるプロジェクト・データの循環分析に統合します。計画の活動では、プロジェクト内の他の許容度と同様に、持続可能性分析を満たすために必要なデータを考慮する必要があります。これは、持続可能性に関する証拠報告が進捗マネジメントの結果であり、追加の活動やりソースを必要とするものではないためです。

規模

進捗マネジメントは、プロジェクトの規模、リスク、複雑性、重要性のニーズを反映するように適用またはテーラリングする必要があります。リスクと複雑性が最小限である単純なプロジェクトにおいて、進捗プラクティスは、報告と予測の目的のための簡素化されたデ一タ分析に役立つ場合があります。 * すべてのマネジメント成果物を使用する必要があるか？ * 結合できるマネジメント成果物はあるか？ * データをより効果的かつ効率的な方法で提供できるか？ * デジタルおよびデータ・マネジメント・アプローチに従って、データへのアクセスを利害関係者に提供できるか？プロジェクトがより複雑になり、より多くのリスクが生じるにつれて、プロジェクト・ビジネスには、さまざまな報告要件を持つより多くの利害関係者が含まれるようになる可能性があります。このような状況下では、より正式な評価と報告のアプローチを用いて、構造化された報告書またはデータとシステムの使用のいずれかを通じて、利害関係者の要件を満たす必要があります。プロジェクト・エグゼクティブまたはプロジェクト委員会は、報告の頻度について合意し、プロジェクト・マネージャーにプロジェクト立ち上げ文書に要件を記録させる必要があります。

マネジメント成果物

アウトプット

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

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

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

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

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

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

チェックポイント報告書

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

ハイライト報告書

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

教訓報告書

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

例外報告書

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

ステージ終了報告書

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

プロジェクト終了報告書

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

主要な役割

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

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

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

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

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

シニアユーザーの責任

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

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

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

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

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

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

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

プロジェクト保証の責任

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

プロジェクト支援の責任

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