プロジェクト・マネジメント-ステージのコントロール

ステージのコントロール

ステージのコントロール・プロセスの目的は、作業のアサイン、その作業のモニタリング、課題への対処、プロジェクト委員会への進捗報告、ステージをプロジェクト委員会が設定した許容度内に収めるための是正処置を実施する

ステージのコントロール・プロセスの達成目標は、以下のことを確実に行う。 * ステージの成果物のデリバリー手法に注意を向けること。ステージの開始時に合意された成果物とデリバリーから逸脱する動きがある場合、コントロールされない変更を回避するためにモニタリングします。 * リスクと課題がコントロールされていること。 * ビジネス・ケースがレビューされていること。 * ステージで合意された成果物が合意された期待品質を満たし、受け入れられること。 * プロジェクト・マネジメント・チームは、確立された許容度内でのデリバリーに努めること。 エスカレーションを最小限に抑えることができるように、可能であれば許容度を使用してチーム・マネージャーに自由を与えます。同様にプロジェクト・マネージャーは、不必要なエスカレーションを回避して自由に行動と学習ができるよう、自身の許容度についてプロジェクト委員会と話し合います。したがって、プロジェクト・マネージャーはコントローラーではなくファシリテーターとして機能します。

ステージのコントロール・プロセスは、プロジェクト・マネージャーによるステージの日常的なマネジメントを説明します。このプロセスは、プロジェクトの各ステージで使用されます。最終ステージを例外として、各マネジメント・ステージの終了が近づくと、ステージ境界のマネジメント・プロセスの活動が実施されます。 通常、ステージのコントロール・プロセスは、プロジェクト委員会がプロジェクトを認可した後に最初に使用されます。しかし、大規模なプロジェクトや複雑なプロジェクトでは、立ち上げステージで使用する場合もあります。 ワーク・パッケージ記述書は、実行する作業を定義、アサイン、コントロールしたり、チーム・マネージャーの許容度を設定したりするために使用されます。プロジェクト・マネージャーがチーム・マネージャーの役割を果たしている場合でも、個々のチーム・メンバーの作業を定義してコントロールするために、やはりワーク・パッケージ記述書を使用する必要があります。(この場合、ステージのコントロール・プロセスでチーム・マネージャーについて書かれている部分は、作業にアサインされた個々のチーム・メンバーについての記述と見なす必要があります。)

実施中の作業を日々コントロールすることは、プロジェクトの最終的な成功を実現するために重要です。作業のコントロールは、ステージ全体を通して、以下のサイクルから成り立っています。 * 作業を認可する * 作業に関する進捗情報をモニタリングする(完了したワーク・パッケージの受け入れを含む) * 状況をレビューし(成果物の品質を含む)、新しいワーク・パッケージをトリガーする * 合意された頻度でプロジェクト委員会にハイライトを報告する * 課題とリスクを観察、評価し、対応する * 許容度内に収めるために必要な是正処置を実施する 最終ステージの終わりが近づくと、プロジェクトのクローズ・プロセスがトリガーされます。

活動

インプット	活動	アウトプット
ステージの認可 (このプロセスをトリガー) 例外計画書の認可 (このプロセスをトリガー) プロジェクト立ち上げ文書 (レビュー) チーム計画書 (レビュー) ステージ計画書 (レビュー)	ワーク・パッケージの認可	プロジェクト・ログ (更新) ワーク・パッケージ記述書 (作成、修正、承認) ワーク・パッケージの認可 (成果物デリバリーのマネジメント・プロセスをトリガー)
新しい課題またはリスク (このプロセスをトリガー) ワーク・パッケージ記述書 (レビュー) チーム計画書 (レビュー) チェックポイント報告書 (レビュー)	ワーク・パッケージのステータスの評価	プロジェクト・ログ (更新) ステージ計画書 (更新) 課題報告書 (必要に応じて作成) 助言の要求 (プロジェクトの指揮プロセスをトリガー)
新しい課題またはリスク (このプロセスをトリガー) ワーク・パッケージ記述書 (レビュー) チーム計画書 (レビュー) チェックポイント報告書 (レビュー)	課題とリスクの把握	プロジェクト・ログ (更新) ステージ計画書 (更新) 課題報告書 (必要に応じて作成) 助言の要求 (プロジェクトの指揮プロセスをトリガー)
新しい課題またはリスク (このプロセスをトリガー) ワーク・パッケージ記述書 (レビュー) チーム計画書 (レビュー) チェックポイント報告書 (レビュー)	是正処置の実施	プロジェクト・ログ (更新) ステージ計画書 (更新) 課題報告書 (必要に応じて作成) 助言の要求 (プロジェクトの指揮プロセスをトリガー)
完了したワーク・パッケージの通知 (このプロセスをトリガー) ワーク・パッケージ記述書 (レビュー)	完了したワーク・パッケージの受け取り	プロジェクト・ログ (更新)
プロジェクト委員会の助言 (このプロセスをトリガー) ハイライト報告書 (前期) (レビュー) ステージ計画書 (レビュー) チェックポイント報告書 (レビュー) プロジェクト・ログ (レビュー)	ステージのステータスの評価	プロジェクト・ログ (更新) ハイライト報告書 (期間ごとに作成) ステージ終了が近づく (ステージ境界のマネジメント・プロセスをトリガー) プロジェクト終了が近づく (プロジェクトの指揮プロセスをトリガー)
プロジェクト委員会の助言 (このプロセスをトリガー) ハイライト報告書 (前期) (レビュー) ステージ計画書 (レビュー) チェックポイント報告書 (レビュー) プロジェクト・ログ (レビュー)	ハイライトの報告	プロジェクト・ログ (更新) ハイライト報告書 (期間ごとに作成) ステージ終了が近づく (ステージ境界のマネジメント・プロセスをトリガー) プロジェクト終了が近づく (プロジェクトの指揮プロセスをトリガー)
ステージ計画書 (レビュー) プロジェクト計画書 (レビュー)	課題とリスクのエスカレーション	例外報告書 (作成) 例外の提起 (プロジェクトの指揮プロセスをトリガー)

ワーク・パッケージの認可

(プロジェクト作業を実施するために人々が必要とする自律性の度合いについては、作業の開始時期と作業完了時期を調整する必要性とのバランスを取る必要があります。)プロジェクト作業は、プロジェクト・マネージャーの同意を得て開始、継続する必要があります。そうしない場合、人々が自分の好きなときに活動を開始するので作業環境が混乱します。プロジェクト作業の調整された時期を確保するための手段は、ワーク・パッケージの認可、実行、デリバリーです。 ワーク・パッケージには 1 つまたは複数の成果物を作成するための作業が含まれます。1 つの成果物の作成に複数のワーク・パッケージが必要な場合、成果物をさらにサブ成果物に分け、成果物記述書も分割します。

プロジェクト・マネージャーがワーク・パッケージの認可を行う際のトリガーとなるものには、以下の処置が挙げられます。 * ステージの認可: プロジェクト委員会はステージ計画書を実行する権限を付与する。 * 例外計画書の承認: プロジェクト委員会は例外計画書を実行する権限を付与する。 * 必要とされる新規のワーク・パッケージ: アウトプットはステージのステータスの評価から取得します。 * 是正処置課題またはリスクに対応する形で行う。 この活動は新しいワーク・パッケージの認可や既存パッケージの修正の認可に使用されます。

プロジェクト・マネージャーに推奨される処置 * プロジェクト立ち上げ文書とステージ計画書を調査して、必要なワーク・パッケージを判断する。 * 認可する(または修正する)ワーク・パッケージを定義する。 * チーム・マネージャーとの仕事上の関係を構築する。 * ワーク・パッケージ記述書をチーム・マネージャーと共創してレビューし、受け入れを確認したら、チーム・マネージャーに作業開始を認可する。反復的かつ段階的なデリバリー手法を使用するプロジェクトの場合、ワーク・パッケージ記述書の共創は、チーム・マネージャー、開発チーム、プロダクト・オーナーとの共同作業である可能性があります。 * チーム・マネージャーの作成したチーム計画書をレビューし(プロジェクト・マネージャーがその内容を見ることが不適切であるような商業的環境の場合は、そこから引用されたマイルストーンを使用する)、認可されたワーク・パッケージの時期を反映するようにステージ計画書を更新する。 * プロジェクト・ログを更新して、認可されたワーク・パッケージの内容を反映する。 * 計画された品質マネジメント活動のプロジェクト・ログを更新する。 * 特定および選択された品質レビュー担当者が受け入れ可能かどうか、プロジェクト保証と協議する。 * 必要な場合は、マネジメント・アプローチに従ってプロジェクト・ログを更新する。

ワーク・パッケージのステータスの評価

この活動はワーク・パッケージのステータスを定期的に評価する手段を提供します。通常、この活動の頻度と手続きはワーク・パッケージ記述書に定義されている報告頻度と整合しており、現在のステージのステージ計画書に基づき実施されます。

進行中の各ワーク・パッケージについてプロジェクト・マネージャーに推奨される処置 * チーム・マネージャーと非公式な話をして関係を維持し(第 3 章を参照)、ワーク・パッケージで発生する可能性のある課題やリスクを理解する。 * 実行中のワーク・パッケージのチェックポイント報告書から進捗情報を収集し、レビューする。 * 必要に応じてプロジェクト・ログを更新する。 * 現在のステージのステージ計画書を更新し、これまでの実績、予測、調整を反映させる。

完了したワーク・パッケージの受け取り

作業が個人またはチームに割り当てられている場合、作業が完了し、承認されたことを確認する必要があります。

プロジェクト・マネージャーに推奨される処置 * チーム・マネージャーがワーク・パッケージ記述書で定義された作業を完了していること、またはアジャイル・アプローチが使用されている場合は、タイムボックスについて合意済みのフィーチャーが提供されていることを確認する。 * 成果物に関連する品質登録簿を確認して、必要な品質レビューが完了しているかどうかを判断する。 * ワーク・パッケージにある各成果物が、成果物記述書に記載された品質と持続可能性の責任の定義に従って、必要な承認を得ていることを確認する。 * 承認済み成果物の成果物登録簿のレコードが更新されていることを確認する。 * ステージ計画書を更新し、ワーク・パッケージを完了していることを示す。

ステージのステータスの評価

ステージをタイムリーに確認しなければ、ステージのコントロールが不能になるおそれがあります。計画立案を進めることと、イベントへ対応することのバランスを保つことが必要です。 情報に基づいた決定を下し、論理的なコントロールを実行するためには、実際に発生したことを、発生が予想されていたこと、および次に発生する可能性のあること(課題とリスクを含む)と比較する必要があります。 (このため、進捗の全体像を提供する一定の情報の流れと、その情報を供給する堅固なモニタリング・システムを備えることが不可欠です。) この活動の達成目標は、実施された作業の進捗状況、およびリソースのステータスに関する正確で最新の状況を保持することです。この活動は、ステージ計画書で定義されている頻度で実施されますが、プロジェクト委員会の助言によってトリガーされたり、新たな課題やリスクの分析の一部となったりする場合があります。

プロジェクト・マネージャーに推奨される処置 * ステージの進捗をレビューし、処置が必要かどうかを判断する。 * 必要に応じてプロジェクト・ログを修正する。 * 総合評価により予測に変更がある場合、ステージ計画書を更新する。 * 成果物のフェーズごとの移転の一環として、成果物のオーナーシップがユーザーに移行されているかどうかを確認する(プロジェクト・ライフサイクル中に移管が複数回発生する場合もある)。 * 教訓のレビューを今実施するか、後でステージ・ステータスのレビューを実施する時期まで待つか、ステージの終わりに近づいたときに実施するかを検討する。 * 現在のステージの終わりが近づいている(ステージ計画書、プロジェクト・ログの内容、マイルストーンなどによって示唆される)場合、次のステージを準備する。 * 最後のステージの終わりに近づいている場合は、プロジェクトのクローズ準備を行う

課題とリスクの把握

ほとんどの場合、プロジェクト・マネジメントの過程で課題が発生してリスクが特定されます。課題とリスクは構造化されていない方法で発生しており、一貫性のある信頼性の高い方法で把握しなければなりません。ビジネス、プロジェクト、またはその他の利害関係者のメンバーから、課題やリスクが提起されることもあります。さらに、プロジェクト・マネジメント・チーム内の心理的安全性を確保することは非常に重要です。関連する課題とリスクは、迅速かつ適切に対処する必要があります。 どのような処置を講じるかを決定する前に、プロジェクト・ログに各課題またはリスクを登録し、次にそのインパクトを評価します。

プロジェクト・マネージャーに推奨される処置 * リスクが発生した場合は、リスク・マネジメント・アプローチに従ってリスクを記録、管理する * 課題が発生した場合は、課題マネジメント・アプローチに従って課題を記録、管理する * 是正処置の実施が必要な場合、プロジェクト委員会に助言を要求するか、課題やリスクをエスカレーションする。その後全体像を検討できるよう、まずステージのステータスをレビューする

是正処置の実施

是正処置の実施の達成目標は、計画からの偏差を解決する処置を(ステージとプロジェクト許容度の限度内で)選択、実施することです。是正処置は、ステージ・ステータスの評価中にトリガーされ、一般にはプロジェクト委員会から受け取った助言とガイダンスや、チーム・マネージャーから提起された課題への対応が含まれます。

プロジェクト・マネージャーに推奨される処置 * 偏差に関する関連情報を収集する。 * 偏差に対して可能な解決策を特定し、最も適切なオプションを選択する。 * ワーク・パッケージを認可することによって是正処置をトリガーする。 * 影響を受ける成果物の成果物登録簿のレコード(変更が必要かどうか、または新しい成果物が必要かどうかなど)を更新する。 * 課題報告書を更新し、必要に応じて是正処置のステータスを示す。 * 是正処置による変更を反映するようにプロジェクト・ログを更新する。 * 現在のステージのステージ計画書を更新する。

課題とリスクのエスカレーション

ステージでは、プロジェクト委員会で合意された許容度を超えないようにする必要があります。プロジェクト・マネージャーは、プロジェクト委員会が設定した許容度内でステージ(またはプロジェクト)が完了すると予測される場合に限って、是正処置の実施または現状の維持ができます。プロジェクト・マネージャーがコントロールできる範囲内での是正処置によっては、ステージが合意された許容度を超えることを防げない場合に、この活動は適用されます。これは、プロジェクト委員会が設定した許容度内で解決できない、すべての種類の課題やリスク(またはそれらが集約されたもの)に適用されます。 例外報告書の作成向け情報の収集に時間を要する場合が予想される場合、できる限り早期にプロジェクト委員会に警告することを推奨します。したがってプロジェクト・マネージャーは、プロジェクト委員会が準備できるように、予測される例外状況をプロジェクト委員会に速やかに通知した後に例外報告書で情報の裏付けを行うという 2 ステップの手順で活動を実行するとよいでしょう。 プロジェクト・マネージャーはエスカレーションに対応するプロジェクト委員会の決定事項を実行します。課題とリスクをエスカレーションすることはグッド・プラクティスであり、障害と見なすべきではありません。課題を早期にエスカレーションするほど、是正処置の実施のための時間が得られることになります。

プロジェクト・マネージャーに推奨される処置 * ステージ計画書を調査し、偏差の範囲および未完成の成果物を定義して、偏差を放置した場合に何が起こるかを判断する。 * プロジェクト・マネジメント・チーム内の心理的安全性を理解して、処置が必要かどうかを判断する。 * 最新ベースラインのプロジェクト立ち上げ文書を使用して、プロジェクトのステータスと偏差の全体的な影響に関してプロジェクト計画書を調査する。 * 復旧のためのオプションを判断し、ビジネス・ケースを参照して評価する。 * 現在のステージのステージ計画書を参照して、復旧のためのオプションのインパクトを評価する(インパクトの評価には、スキルや経験のある個人やグループの可用性を考慮します)。 * 状況、オプション、プロジェクト委員会への行動方針の推奨事項を例外報告書に記載する。その後、プロジェクト委員会は適切な行動方針を決定する(プロジェクト・マネージャーの勧告を支援または拒否する場合があります)。

ハイライトの報告

プロジェクト・マネージャーは、ステージとプロジェクトのステータスについての要約情報をプロジェクト委員会に提供し、コミュニケーション・マネジメント・アプローチに文書化されている頻度で、プロジェクト委員会による定義に従って利害関係者にその他の情報を配布する必要があります

プロジェクト・マネージャーに推奨される処置 * 現在の報告期間のチェックポイント報告書、プロジェクト・ログ、成果物ステータス報告書からの情報とステージ計画書の重要な修正をまとめる。情報はステージ・ステータスのレビューから得られます。 * 報告期間中に実施された是正処置(プロジェクト・ログに記載または記録されている)のリストを組み立てる。これにより、プロジェクト・マネージャーが合意された許容度内で行動していることがプロジェクト委員会に保証されます(情報は是正処置を実施することで得られます。)。 * 過去の報告期間のハイライト報告書をレビューする。 * 現在の報告期間のハイライト報告書を作成する。 * ハイライト報告書を配布する。アジャイルなどの反復的かつ段階的なデリバリー手法を使用するプロジェクトの場合、ハイライト報告書は「プル」システムに基づいている場合があります。プロジェクト委員会はこのシステムでプロジェクト・マネージャーと開発チームによって維持されている進捗チャートを確認します。

適用

一般的な考慮事項

ワーク・パッケージ記述書は、ビジネスとサプライヤーの関係によって詳細が異なる場合があります。プロジェクト計画書、ステージ計画書、プロジェクト立ち上げ文書のいずれかからの抜粋を含めるか、単に要素への相互参照を行うことがグッド・プラクティスです。これにより、重複するコンテンツを減らすことができます。 ステージのコントロール・プロセス中のプロジェクト・マネージャー、プロジェクト支援、チーム・マネージャー間の関係は、協調的である必要があります。プロジェクト・マネージャーは、チーム・マネージャーやプロジェクト支援にタスクを委任したりアサインしたりするのではなく、オーナーシップを改善させ、チーム・マネージャーとプロジェクト支援がプロジェクトに貢献し、最終的にはビジネス目標を提供できるようにするプロセスを促進します

役割のテーラリング

プロジェクト・マネージャーは、このプロセスにおけるあらゆる新しいマネジメント成果物の作成の実行責任を負いますが、責任を維持したうえでタスクを他の人に委任できます。(プロジェクト・マネージャーはワーク・パッケージ記述書の作成に実行責任を負うとされています。ただし実際には、プロジェクト・マネージャーが、ワーク・パッケージ記述書でスペシャリスト成果物または手法に関する記述を定義するために必要なスキルを持っていない場合があります。したがって、プロジェクト・マネージャーはコンテンツを作成するためにチーム・マネージャーまたは他の専門家に頼り、プロジェクト・マネージャーの役割は、ステージ計画書のニーズを満たすためにそれらが十分に定義、レビュー、保証されていることを確認することです。)

責任

活動	ビジネス・レイヤー	プロジェクト・エグゼクティブ	シニア・ユーザー	シニア・サプライヤー	プロジェクト・マネージャー	チーム・マネージャー	プロジェクト保証	プロジェクト支援
ワーク・パッケージの認可		A			R	C	C	C
ワーク・パッケージのステータスの評価		A			R	C	C	C
完了したワーク・パッケージの受け取り					A	R	C	I
ステージのステータスの評価		A	C	C	R	C	C	C
課題とリスクの把握		A			R¹	R²	C	C
是正処置の実施		A	C	C	A¹/R³	R⁴		I
課題とリスクのエスカレーション		A	C	C	R	I		I
ハイライトの報告		A	C	C	R	C	C	C

R = 実行責任、A = 説明責任、C = 協議先、I = 情報先

• R¹: ステージ・レベルで課題とリスクを把握する実行責任がある
• R²: チーム・レベルで課題とリスクを把握する実行責任がある
• A¹: チーム・マネージャーが実施した是正処置に説明責任がある
• R³: 自分のは正処置に実行責任がある
• R⁴: チーム・レベルでのは正処置に実行責任がある

プロセスへのプラクティスの適用

プラクティス	ステージのコントロール・プロセスへの適用
ビジネス・ケース	ビジネス・ケースは定期的に確認され、実行可能であることを確認します。それ以外の場合はプロジェクト委員会に通知する必要があります。ベネフィット・マネジメント・アプローチと持続可能性マネジメント・アプローチが適用され、それらの要件がステージのワーク・パッケージ記述書に含まれます
組織化	コミュニケーション・マネジメント、変更マネジメント・アプローチ、商業マネジメント・アプローチが適用され、それらの要件がステージのワーク・パッケージ記述書に含まれます。 プロジェクト・チームのウェルビーイングと状況がモニタリングされます
計画	ステージのワーク・パッケージ記述書が作成または更新されます。 ステージ計画書とプロジェクト計画書が更新されます
品質	成果物登録簿は、ステージの成果物のステータスで更新されます。 品質マネジメント・アプローチが適用され、その要件がステージのワーク・パッケージ記述書に含まれます。 ステージの成果物記述書が作成または更新されます。 品質登録簿は、計画済みの品質活動または実際の品質活動で更新されます
リスク	リスク・マネジメント・アプローチが適用され、その要件がステージのワーク・パッケージ記述書に含まれます。 リスク登録簿が新しいリスクの詳細で更新され、リスク対応策が実行または完了されます
課題	課題マネジメント・アプローチが適用され、その要件がステージのワーク・パッケージ記述書に含まれます。 課題登録簿は、新しい課題の詳細と、必要な処置または完了した処置で更新されます。 課題報告書は、エスカレーション、詳細な分析、処置が必要な課題に対して作成されます
進捗	デジタルおよびデータ・マネジメント・アプローチが適用され、その要件がステージのワーク・パッケージ記述書に含まれます。 デイリー・ログと教訓ログが新しいエントリで更新されます。 ハイライト報告書は、プロジェクト・コントロールに必要な頻度で作成、発行されます。 例外報告書は、合意された許容度内で解決できない課題について作成とエスカレーションが行われます