プロジェクト・マネジメント-プロジェクトの指揮

プロジェクトの指揮

プロジェクトの指揮プロセスの目的は、プロジェクト委員会が主要な決定を行い、全体的なコントロールを行う一方、プロジェクトの日々のマネジメントをプロジェクト・マネージャーに委任し、プロジェクトの成功に対する説明責任を果たせるようにする。 プロジェクトの指揮プロセスの達成目標は、次の点を確認する。 * プロジェクトの立ち上げが認可されていること。 * プロジェクト成果物の提供が認可されていること。 * プロジェクトのライフサイクルを通して、マネジメントの指揮とコントロールが適切に行われていること。 * プロジェクトが継続して実行可能であること。 * ビジネス・レイヤーにプロジェクトとの関連性があること。 * プロジェクトのクローズが認可されていること。 * プロジェクト終了後のベネフィットを実現するための計画書がマネジメントされ、レビューされていること。

プロジェクトの指揮のプロセスはプロジェクトの始動プロセスが完了すると始まり、プロジェクトの立ち上げ要求によってトリガーされます。

プロジェクトの指揮プロセスでは、プロジェクト委員会の活動が対象であり、プロジェクト・マネージャーの日々の活動は対象となりません。プロジェクト委員会は例外によるマネジメントを行います。少数者による決定によって、報告書を通してモニタリングし、コントロールします。(プロジェクト・マネージャーは例外的な状況をプロジェクト委員会に通知するため、プロジェクト委員会以外の進捗会議は必要ありません。権限のレベルと意思決定プロセスを明確に定義し、プロジェクト・マネージャーとチーム・マネージャーに権限を与えることも重要です。) (プロジェクト期間中は、プロジェクト委員会とビジネス・レイヤーとの間で情報を相互にやり取りする必要があります。プロジェクト委員会は、プロジェクトが常にビジネス・レイヤーの戦略に整合していることを確かなものにする必要があります。) プロジェクト委員会の主要な役割は、ビジネス・レイヤーに関与し、コミュニケーション・チャネルとして機能することです。(プロジェクト委員会がコミュニケーション・チャネルとして機能するための要件とその方法については、コミュニケーション・マネジメント・アプローチで文書化する必要があります。) プロジェクト委員会はプロジェクト・マネージャーに対して、統一性のある指揮とガイダンスを提供します。(プロジェクト委員会が統一された意見を提供できない場合、プロジェクト・マネージャーは矛盾する要件と優先順位に基づいて行動する可能性があるため、プロジェクトに障害が発生するリスクが大幅に高まります。そのような場合は、プロジェクト・エグゼクティブが決定を下します。) プロジェクトの指揮プロセスは、プロジェクト委員会が現場でのプロジェクト・マネジメント活動による過度な負担を負うことなく、ビジネス正当性の継続の確保という責任を全うするためのメカニズムを提供します。(また、プロジェクト委員会がプロジェクト・マネージャーに細かく指示することを回避するメカニズムも提供します。) プロジェクト委員会の機能の 1 つは、プロジェクト・マネージャーに対して非公式に助言とガイダンスを提供すると同時に、公式な指揮をすることです。(これは双方向であり、プロジェクト委員会はプロジェクト外の問題についてプロジェクト・マネージャーに報告し、プロジェクト・マネージャーはプロジェクトの過程で必要に応じて助言を求めます。)

活動

インプット	活動	アウトプット
プロジェクト立ち上げの要求(このプロセスをトリガー) ビジネス・ケース概要(レビュー) プロジェクト要約書(レビュー) プロジェクト成果物記述書(レビュー) ステージ計画書(立ち上げ用)(レビュー)	立ち上げの認可	ビジネス・ケース概要(承認済み) プロジェクト要約書(承認済み) プロジェクト成果物記述書(承認済み) ステージ計画書(立ち上げ用)(承認済み) 立ち上げ通知 プロジェクト立ち上げの認可(プロジェクトの立ち上げプロセスをトリガー)
プロジェクト認可の要求(このプロセスをトリガー) プロジェクト立ち上げ文書(レビュー) ビジネス・ケース(レビュー)	プロジェクトの認可	プロジェクト立ち上げ文書(承認済み) ビジネス・ケース(承認済み) プロジェクト認可の通知
次のステージの要求(このプロセスをトリガー) 例外計画書の承認の要求(プロセスをトリガー) ステージ終了報告書(レビュー) ステージ計画書(次のステージ用)(レビュー) プロジェクト計画書(確認) ビジネス・ケース(確認)	ステージまたは例外計画書の認可	ステージ終了報告書(承認済み) ステージ計画書(次のステージ用)(承認済み) プロジェクト計画書(必要に応じて更新)(承認済み) ビジネス・ケース(必要に応じて更新)(承認済み) 認可されたステージまたは例外(ステージのコントロール・プロセスをトリガー) プロジェクト立ち上げ文書(必要に応じて更新)(承認済み)
助言の要求(このプロセスをトリガー) 例外の提起(このプロセスをトリガー) 教訓報告書(レビュー) ハイライト報告書(レビュー) 課題報告書(レビュー) 例外報告書(レビュー) ビジネス・ケース(確認)	継続的な指揮	例外計画書の要求(ステージ境界のマネジメント・プロセスをトリガー) プロジェクト委員会の助言と決定(ステージのコントロール・プロセスをトリガー) 早期クローズの通知(ステージのクローズ・プロセスをトリガー)
プロジェクトのクローズの要求(このプロセスをトリガー) プロジェクト終了報告書(レビュー) ビジネス・ケース(確認)	プロジェクトのクローズの認可	プロジェクトのクローズの通知

立ち上げの認可

プロジェクトの立ち上げには時間とコストがかかるため、立ち上げの活動を計画、モニタリング、コントロールすることが必要です。プロジェクト委員会による立ち上げの認可という活動によって、このような投資に価値があることを確認します。 (プロジェクト・マネージャーからプロジェクトの立ち上げ要求を受け取ると(プロジェクトの始動プロセスの後)、プロジェクト委員会はプロジェクトを立ち上げステージに進めるかどうかを決定する必要があります。)これは公式なプロジェクト委員会の会議で決定することも、公式な会議を開かずに決定することもできます。ただし、すべてのメンバーが決定に合意していることに加え、プロジェクト・マネージャーがプロジェクト・エグゼクティブから文書で立ち上げ指示を受け取ることが条件です。プロジェクト委員会は、処置のレビューと評価(実行可能性を確認するための立ち上げステージ計画書のレビューなど)を行うプロジェクト保証を個人またはグループに委任することもできます。プロジェクト保証活動が委任されている場合、プロジェクト委員会は引き続き説明責任を負います。

プロジェクト委員会に推奨される処置 * プロジェクト・アプローチがビジネスの方針に整合していることを確認する。 * プロジェクト要約書とプロジェクト成果物記述書をレビューし、承認する。 * ビジネス・ケース概要が、ビジネス戦略に整合した実行可能なプロジェクトを示していることを確認する。 * 立ち上げステージのステージ計画書をレビューし、承認する。立ち上げステージに対する許容度を設定する。 * すべての利害関係者とインパクトを受けるサイトに対し、プロジェクトが立ち上げステージにあることを通知し、立ち上げステージに必要とされるロジスティックに関する支援(通信設備、備品、プロジェクト支援など)を要求する。 * プロジェクト・マネージャーが立ち上げステージに進めることを認可する。

プロジェクトの認可

この活動はプロジェクト・マネージャーからのプロジェクト実行の認可要求によって開始します。(ステージ計画書または例外計画書の認可と並行して行う場合があります。)

プロジェクトの認可の達成目標は、これ以降プロジェクトを進めてよいかどうかを決定する。プロジェクト委員会は、以下のことを確認する必要があります。 * 堅固なビジネス・ケースが存在し、実行可能なプロジェクトを示していること。 * プロジェクト計画書とベネフィット・マネジメント・アプローチは、プロジェクトがビジネス・ケースを提供できることを示していること。 * マネジメント・アプローチとコントロールが、プロジェクト計画書のデリバリーを支援していること。

プロジェクト委員会がプロジェクトを認可しなかった場合、プロジェクトを早期にクローズする必要があります。 プロジェクト委員会は、すべての利害関係者がカバーされていることを確認するためにコミュニケーション・マネジメント・アプローチを検査するなど、レビューおよび評価措置の一部を実施するように個人またはグループに指示することにより、プロジェクト保証を委任できます。プロジェクト保証活動が委任されている場合、プロジェクト委員会は引き続き説明責任を負います。

プロジェクト委員会に推奨される処置 * プロジェクト立ち上げ文書をレビューし承認する * プロジェクトの許容度を確認する * 過去の同様のプロジェクトからの教訓をレビューし、これに対処していることを確認する * リスクのレビューが行われており、脅威と機会に対するリスク対応策が適切で、計画済みであることを確認する * プロジェクトに必要な人員とリソースを入手またはコミットする(このリソースはステージごとにプロジェクト・マネージャーに提供される) * プロジェクトが認可されたことをビジネスおよびその他の利害関係者に通知する * プロジェクト・マネージャーによるプロジェクトの実行を認可する。または、プロジェクトを進めないと決定した場合はプロジェクトの早期クローズをプロジェクト・マネージャーに指示する

継続的な指揮

プロジェクト委員会のメンバーは、プロジェクト期間中いつでも、非公式なガイダンスを与えたり、助言要求に対応したりする必要があります。プロジェクト・マネージャーとプロジェクト委員会の間で行う協議は、立ち上げステージ中とステージ境界に近づいている場合に、特に頻繁に必要となる可能性があります。 継続的な指揮は、プロジェクト委員会全体として、または個々のプロジェクト委員会のメンバーが行う場合があります。継続的な指揮はさまざまな場面でトリガーされます。 * プロジェクトに関する一般的な助言(プロジェクトに関連するビジネスの持続可能性目標と ESG 報告要件の説明など) * 要求への対応(選択肢を明確にする必要がある場合や、対立が生じている状況を解決しなければならない場合など) * 報告書への対応(ハイライト報告書、例外報告書、課題報告書など) * 外部からの影響への対応(ビジネスの優先度の変更など) * プロジェクト委員会メンバーの個別の懸念事項 * プロジェクト委員会の構成員の変更への対応(ビジネスの承認も必要となる場合がある)

ステージ中に例外が発生した場合、プロジェクト委員会はプロジェクト・マネージャーに、例外計画書を作成してプロジェクト委員会の承認を受けることを求める場合があります。プロジェクト委員会による承認のためにエスカレーションする必要があるのは、ステージ計画書の例外のみです。プロジェクト計画書からの偏差には、ビジネスの承認が必要です。(ワーク・パッケージのレベルの例外は、ステージのコントロール・プロセスを使用して、プロジェクト・マネージャーが対応します。)承認された例外計画書は、例外となった計画書と置き換わり、新しいベースライン計画書となります。 また、ビジネスがプロジェクトの外部で生じたイベントに対応してプロジェクト権限委任を見直したり、プロジェクト委員会にプロジェクトのクローズを指示したりする場合もあります。ビジネスがプロジェクト権限委任の変更を決定した場合、プロジェクト委員会には主に 2 つの選択肢があります。 * 変更要求として取り扱い、プロジェクト・マネージャーに対し、ステージまたはプロジェクトを計画し直すよう求める。 * 停止し、早期のクローズをトリガーし、変更されたプロジェクト権限委任を満たすために新しいプロジェクトを開始する。この場合は、変更要求として取り扱う場合に比べて、追加コストがかかる場合がある。

プロジェクト委員会は、インパクトが適切に評価されたことを確認するために変更要求を検査するなど、レビューおよび評価措置の一部を実施するように個人またはグループに指示することにより、プロジェクト保証を委任できます。(プロジェクト保証活動が委任されている場合、プロジェクト委員会は引き続き説明責任を負います。)決定を下す際には、すべての利害関係者(コミュニケーション・マネジメント・アプローチで特定)へのインパクトを考慮することが重要です。

プロジェクト委員会に推奨される措置 * 助言やガイダンスの非公式の要求に応じて、(必要に応じて)助言を求め、プロジェクト・マネージャーを支援する。 * エスカレーションされた課題に応じて、(必要に応じて)助言を求め、決定を下す。課題が仕様外項目の場合、対応として、プロジェクト・マネジメント・チームまたはサプライヤーが関連する成果物を完成させる必要があることを意味する拒否を行うか、不完全な成果物が受け入れられることを意味する条件付き承認を行う。 * 例外報告書に応じて、(必要に応じて)助言を求め、決定を下す。 * ハイライト報告書の受領に応じて、必要に応じてレビューを行い措置を講じる。 * ビジネスからの助言や決定に応じて、プロジェクト・マネージャーに変更を通知する。

ステージまたは例外計画書の認可

ステージは、プロジェクト委員会が決定したときのみに開始することが重要です。プロジェクト委員会は現在のステージのパフォーマンスをレビューし、次のステージのステージ計画書を認可して、ステージを承認します。ステージ計画書の承認は、すべてのステージの前に行われます。 プロジェクト委員会は、ステージ計画書を検査して実行可能であることを確認するなど、レビューおよび評価措置の一部を実施するように個人またはグループに指示することにより、プロジェクト保証を委任します。プロジェクト保証活動が委任されている場合、プロジェクト委員会は引き続き説明責任を負います。

プロジェクト委員会に推奨される措置 * ステージ終了報告書をレビューし、承認する。 * プロジェクト・マネージャーが承認を求めているステージ計画書または例外計画書をレビューする。 * 計画を承認するか、却下された計画を修正するようにプロジェクト・マネージャーに依頼するか、プロジェクトの早期クローズを開始するようにプロジェクト・マネージャーに指示する。 * プロジェクトのステータスをビジネスに伝達し、プロジェクト進捗について他の利害関係者に最新情報を通知する(コミュニケーション・マネジメント・アプローチに基づく)。

プロジェクトのクローズの認可

プロジェクトのクローズをコントロールすることは、開始のコントロールと同様に重要です。元のバージョンと最新バージョンのプロジェクト立ち上げ文書とプロジェクト計画書の達成目標を評価するポイントを設け、次の点を把握する。 * 達成目標が達成されたかどうか * プロジェクトが初期計画からどの程度逸脱したか * プロジェクトにはこれ以上貢献できることがないか

このアプローチを取らないと、ビジネスへの移管が完了せず、コントロールされた方法でプロジェクトをクローズできず、本来のベネフィットが重視されなくなるリスクがあります。また、チームが新しい作業のために完全にリリースされないリスクがあります。 プロジェクトのクローズ認可は、プロジェクト委員会の解散前に行う最後の活動となります。また、ビジネスによる承認が必要となる場合があります。プロジェクト委員会は、処置のレビューと評価(プロジェクト終了報告書の正確性を確認するためのレビューなど)を行うプロジェクト保証を要求することもできます。

プロジェクト委員会に推奨される措置 * 元のバージョンと最新バージョンのプロジェクト立ち上げ文書をレビューして、プロジェクト当初のベースライン、現在のアプローチとコントロールを把握する。 * プロジェクト終了報告書をレビューし、承認する。 * 更新されたベネフィット・マネジメント・アプローチで定義されたプロジェクト終了後のベネフィット・レビューで、運用使用時のプロジェクト成果物のパフォーマンスが対象となっていることを確認し、副作用(有益または有害なもの)の有無を特定できるようにする。 * 更新されたベネフィット・マネジメント・アプローチをレビューし、承認を得る。まだ確認できていない予想ベネフィットも言及されていることを確認する(ベネフィット・マネジメント・アプローチには、プロジェクト・ライフサイクル外のリソースを含むため、このアプローチの責任をビジネスに移転する必要がある)。 * 更新されたビジネス・ケースをプロジェクトの正当性の確保に使用したビジネス・ケース概要とベネフィット、コスト、リスクの実績値と予測値を比較して、確認する(プロジェクトがクローズした後でなければ実現しないベネフィットがあるため、すべてのベネフィットは確認できない場合がある)。 * コミュニケーション・マネジメント・アプローチに従って、プロジェクトのクローズ通知をレビューし、通知を送る。プロジェクト委員会は、プロジェクト用の支援インフラストラクチャーとリソースの提供者に対して、その撤去が可能になったことを伝える。プロジェクトに請求されるコストを計算するため、終了日を明記する。 * 残りのすべてのプロジェクト・チーム・メンバーのオフボーディングが正しい方法で処理されていることを確認する。

適用

このプロセスのすベての活動はプロジェクト・エグゼクティブが実行責任を負いますが、実際の作業は他の担当者に任せられます。(ただし、プロジェクト・マネージャーは、プロジェクト・エグゼクティブの責任の範囲内にある事項について決定を下したり、承認したり、指揮したりすることはできないことに留意する必要があります。プロジェクト・エグゼクティブとプロジェクト・マネージャーの役割は分離する必要があります。)

責任

活动	ビジネス・レイヤー	プロジェクト・エグゼクティブ	シニア・ユーザー	シニア・サプライヤー	プロジェクト・マネージャー	チーム・マネージャー	プロジェクト保証	プロジェクト支援
立ち上げの認可	I	A/R
プロジェクトの認可	I	A/R	C	C	I	I	C	I
継続的な指揮	C	A/R¹	R²	R³	C/I	I	C	I
ステージまたは例外計画書の認可	I	A/R	C	C	I	I	C	I
プロジェクトのクローズの認可	I	A/R	C	C	I	I	C	I

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

• R¹: ビジネス関連
• R²: ユーザー関連
• R³: サプライヤー関連

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

プラクティス	プロジェクトの指揮プロセスへの適用
ビジネス・ケース	プロジェクト委員会は、ビジネス・ケースが望ましく、実行可能で、達成可能であり、提案されたオプションがビジネス戦略と整合していることを確認するために、ビジネス・ケースにインプットを提供します。 プロジェクト要約書内のビジネス・ケース概要は、プロジェクトを開始する価値があるかどうかを確認するためにレビューされ、価値がある場合は、プロジェクト委員会が承認を提供します。 完全なビジネス・ケースがレビューされ、プロジェクトと次のステージを認可する価値があるかどうかが確認されます。価値がある場合は、プロジェクト委員会が承認を提供します。プロジェクトのクローズの認可を求められた場合、プロジェクト委員会は完全なビジネス・ケースをレビューして、ビジネス・ケースに対するプロジェクトのパフォーマンスを確認します。 プロジェクト委員会はビジネス・ケースとビジネス戦略との整合性を図り、ベネフィット・マネジメント・アプローチと持続可能性マネジメント・アプローチの初期バージョンと更新バージョンを承認します。プロジェクト委員会は、プロジェクト・レベルのベネフィットと持続可能性の許容度をビジネスと合意し、それらにステージ・レベルの許容度を設定します
組織化	ユーザー、ビジネス、サプライヤーの3つの利害関係者の利益は、プロジェクトの性質と規模、およびプロジェクト・エコシステム全体の信頼性に対して適切なレベルの権限を持つシニア・リーダーによってプロジェクト委員会に代表されます。 プロジェクト委員会は、プロジェクト・マネジメント・チーム組織と役割記述書、商業マネジメント・アプローチ、コミュニケーション・マネジメント・アプローチ、変更マネジメント・アプローチの初期バージョンと更新バージョンを承認します。プロジェクト委員会は、提案されたデリバリー・モデルを確認します
計画	計画と提案されたデリバリー手法は、ビジネス・ケース、ビジネス戦略、主要なマイルストーンとクリティカルな決定の時期との整合性がレビューされます。 プロジェクト委員会は、プロジェクト・アプローチ、プロジェクト計画書、各ステージ計画書、例外計画書の初期バージョンと更新バージョンを承認します。プロジェクト委員会は資金、人、リソースを計画にコミットさせます
品質	プロジェクト委員会のシニア・ユーザーは、ユーザーの期待品質と受け入れ基準を定義します。プロジェクト委員会はプロジェクト保証に実行責任があり、ユーザー、ビジネス、サプライヤーの観点から適切な保証が計画および実施されるようにします。 プロジェクト委員会は、プロジェクト成果物記述書、成果物記述書、品質マネジメント・アプローチの初期バージョンと更新バージョンを承認します。 プロジェクト委員会は、プロジェクト・レベルの品質許容度をビジネスと合意し、成果物レベルの品質許容度を設定します。
リスク	プロジェクト委員会は、プロジェクト立ち上げを認可する前のプロジェクト要約書と、プロジェクトと各ステージを承認する前のビジネス・ケースで、高いレベルのリスクを検討します。 プロジェクト委員会は、プロジェクト・レベルのリスク許容度をビジネスと合意し、ステージ・レベルのリスク許容度を設定します。プロジェクト委員会は、プロジェクト・ライフサイクルを通じてリスクの全体的なレベルが受け入れ可能であることを確認します。 プロジェクト委員会は、リスク・マネジメント・アプローチの初期バージョンと更新バージョンを承認します
課題	プロジェクト委員会は、課題マネジメント・アプローチの初期バージョンと更新バージョンを承認します。プロジェクト委員会は課題報告書にタイムリーに対応し、プロジェクト・マネジャーに継続的な指揮を提供します。 プロジェクト委員会は変更許可委員を委任し、変更予算を設定するかどうか、またどのように行うかを確立します
進捗	プロジェクト委員会は、デジタルおよびデータ・マネジメント・アプローチの初期バージョンと更新バージョンを承認します。 プロジェクト委員会は、プロジェクト・レベルの時間、コスト、スコープ許容度をビジネスと合意し、それらにステージ・レベルの許容度を設定します。 プロジェクト委員会は、プロジェクト・マネジャーから提供されたハイライト報告書を合意された頻度でレビューおよび対応することにより、プロジェクトが計画どおりに進んでいることを確認します。 プロジェクト委員会は例外報告書にタイムリーに対応し、例外計画書が必要かどうかを検討します。 プロジェクト委員会はプロジェクト終了報告書を確認して承認し、プロジェクトがクローズすることをビジネスに通知します