プロジェクト・マネジメント-プロジェクトの立ち上げ

プロジェクトの立ち上げ

プロジェクトの立ち上げプロセスの目的は、プロジェクトの確固とした基盤を確立することです。これにより、ビジネスは本格的な支出やリソースをコミットする前に、プロジェクト成果物を提供するために行う必要のある作業を理解できるようになります。

プロジェクトの立ち上げプロセスの達成目標は、以下についての共通の理解を得ることです。 * プロジェクトを実施する理由、期待されるベネフィットおよび関連するリスク(完全なビジネス・ケースで文書化される) * 実施されるスコープ、提供される成果物 * 成果物を提供する方法、時期、コスト * プロジェクトの意思決定に関与する人物 * 求められている品質を達成する手段 * ベースラインを確立してコントロールする方法 * リスクと課題を特定、評価、コントロールする方法 * 進捗をモニタリングおよびコントロールする方法 * 情報を必要とする人、情報の書式、必要な時期 * プロジェクトでビジネスの方針、手法、ガイダンスを適用する方法

プロジェクトの立ち上げでは、プロジェクトの成功を達成させるための基盤が整います。特に、プロジェクトが達成しようとしていること、プロジェクトが必要な理由、成果の達成方法、責任について、関係者全員が明確なアイデアを持ち、プロジェクトに真にコミットメントする必要があります。 プロジェクトの立ち上げプロセスにより、プロジェクト委員会は、プロジェクトの指揮プロセスを経て、プロジェクトが十分ビジネス目標に整合しており、その継続を正当化できるかどうかを判断します。 プロジェクトの立ち上げプロセス中に、プロジェクト・マネージャーは、プロジェクト委員会が特定したコントロール・レベルに必要な一連のマネジメント成果物を作成します。プロジェクト・マネージャーは、マネジメント成果物をどのようにレビューおよび承認するかについて、プロジェクト委員会と合意している必要があります。 プロジェクトの立ち上げプロセスのすべての活動は、ユーザーとサプライヤーが商業的関係である場合、さらに検討が必要となります。この理由は、リスク、報酬、プロジェクトの引き受け理由が、(顧客である)ユーザーとサプライヤーとで異なるためです。

活動

インプット	活動	アウトプット
プロジェクト立ち上げの認可 (このプロセスをトリガー) プロジェクト要約書 (レビュー) プロジェクト・ログ (確認) プロジェクト成果物記述書 (レビュー) ステージ計画書 (立ち上げ) (レビュー)	テーラリング要件への合意	マネジメント・アプローチ (作成) プロジェクト計画書 (作成)
プロジェクト立ち上げの認可 (このプロセスをトリガー) プロジェクト要約書 (レビュー) プロジェクト・ログ (確認) プロジェクト成果物記述書 (レビュー) ステージ計画書 (立ち上げ) (レビュー)	マネジメント・アプローチへの合意	マネジメント・アプローチ (作成) プロジェクト計画書 (作成)
プロジェクト立ち上げの認可 (このプロセスをトリガー) プロジェクト要約書 (レビュー) プロジェクト・ログ (確認) プロジェクト成果物記述書 (レビュー) ステージ計画書 (立ち上げ) (レビュー)	プロジェクト・コントロールの確立	マネジメント・アプローチ (作成) プロジェクト計画書 (作成)
プロジェクト立ち上げの認可 (このプロセスをトリガー) プロジェクト要約書 (レビュー) プロジェクト・ログ (確認) プロジェクト成果物記述書 (レビュー) ステージ計画書 (立ち上げ) (レビュー)	プロジェクト計画書の準備	マネジメント・アプローチ (作成) プロジェクト計画書 (作成)
ビジネス・ケース概要	完全なビジネス・ケースの準備	ビジネス・ケース (作成)
ビジネス・ケース プロジェクト要約書 プロジェクト成果物記述書 プロジェクト計画書 マネジメント・アプローチ プロジェクト立ち上げ文書	プロジェクト立ち上げ文書のとりまとめ	プロジェクト立ち上げ文書 (作成) プロジェクト・ログ (更新) ステージ終了が近づく(ステージ境界のマネジメント・プロセスをトリガー)
プロジェクト立ち上げ文書	プロジェクト認可の要求	プロジェクト認可の要求 (プロジェクトの指揮プロセスをトリガー)

テーラリング要件への合意

プロジェクト・マネージャーは、プロジェクトの遂行方法に影響を与える内部要因や外部要因を認識するために、テーラリングしなければならない場合があります。ビジネスには、プロジェクトに適用する準備ができている、テーラリングされたバージョンに基づく標準のプロジェクト・マネジメント・フレームワークがすでに存在する場合があります。ビジネスの標準的なプロジェクト・マネジメント・フレームワークにどのように適用と調整の両方またはいずれかを行うかを文書化し、合意する必要があります。

プロジェクト・マネージャーに推奨される処置 * テーラリング・アプローチの概要(定義されている場合) を理解するために、プロジェクト要約書をレビューする。 * 過去の類似のプロジェクト、ビジネス、外部組織からテーラリングを適用する方法についての教訓を集める。 * 関連するプロジェクト・コントロールを含むプロジェクト立ち上げ文書の一部として、テーラリング要件を定義する。 * プロジェクト保証と協議して、提案されたテーラリングがプロジェクト委員会またはビジネスのニーズに応えていることを確認する。 * テーラリングについて、プロジェクト委員会に承認を求める(ただしプロジェクト委員会は、プロジェクト立ち上げ文書の一部として後でレビューすることを望む場合もあります)。

マネジメント・アプローチへの合意

プロジェクトのアプローチを確立する活動は複数を並行して実行することができます。ただし、コミュニケーション・マネジメント・アプローチは、その他のアプローチで必要なコミュニケーションを含むため最後に完了させることをお勧めします。 プロジェクトが準拠しなくてはならないビジネス戦略、標準、プラクティス、プロジェクト成果物記述書で把握されているユーザーの期待品質と持続可能性に基づいてマネジメント・アプローチは策定されます。アプローチが定義されると、プロジェクト・コントロールを確立し、プロジェクト計画書の作成が可能になります。異なるマネジメント・アプローチは次のとおりです。 * 変更マネジメント・アプローチ * コミュニケーション・マネジメント・アプローチ * 持続可能性マネジメント・アプローチ * ベネフィット・マネジメント・アプローチ * 商業マネジメント・アプローチ * 品質マネジメント・アプローチ * リスク・マネジメント・アプローチ * 課題マネジメント・アプローチ * デジタルおよびデータ・マネジメント・アプローチ

プロジェクト・マネージャーに推奨される処置 * テーラリング方法と、それがマネジメント・アプローチに与える影響をレビューする。 * プロジェクト要約書をレビューし、マネジメント・アプローチに関するビジネス戦略、標準、プラクティスをプロジェクト中に適用する必要があるかどうかを理解する(すべての契約上の要件も含みます)。 * 過去の類似のプロジェクト、ビジネス、外部組織から、マネジメント・アプローチに関連する教訓を集める(これらの中にはプロジェクト・ログにすでに盛り込まれているものもある)。 * プロジェクト・ログをレビューして、マネジメント・アプローチに関連する課題やリスクがあるかどうかを確認する。 * 新たなリスクや課題が特定された(または既存のリスクに変化が生じた)場合は、プロジェクト・ログを更新する。 * プロジェクト保証と協議して、提案されたマネジメント・アプローチがプロジェクト委員会またはビジネスのニーズに応えていることを確認する。 * マネジメント・アプローチについて、プロジェクト委員会に承認を求める(ただしプロジェクト委員会は、プロジェクト立ち上げ文書の一部として後でレビューすることを望む場合もある)。

プロジェクト・コントロールの確立

プロジェクト委員会が要求する立ち上げ以降のコントロール・レベルについて合意する必要があります。また、そのコントロールのメカニズムを確立することも必要です。チーム・マネージャーが実施する作業に関して、プロジェクト・マネージャーが要求するコントロール・レベルについても同じことが言えます。プロジェクト・コントロールにより、プロジェクトを規模、リスク、複雑性、重要性に応じて効果的、効率的な方法で管理することができます。

効果的なプロジェクト・コントロールは、例外によるマネジメントの必須条件です。プロジェクト・コントロールには以下の内容が含まれます。 * プロジェクト・マネジメント・レイヤー間およびプロジェクト・マネジメント・レイヤー内のコミュニケーションの頻度と形式 * ステージの数 * 課題を把握、分析するメカニズム * 委任された権限の許容度の設定 * あるマネジメント・レベルから別のレベルに委任された権限のモニタリング方法 * 例外をエスカレーションするメカニズム これらのコントロールの多くがマネジメント・アプローチで定義済みですが、必ず確立されるわけではありません。この活動の主眼は、このようなコントロールを確立し、首尾一貫して意味のある活動にすることです。

プロジェクト・マネージャーとプロジェクト支援に推奨される措置 * デリバリー手法(直線的かつ連続的、反復的かつ段階的、ハイブリッド)を確認し、プロジェクト・コントロールへの影響を評価する。 * テーラリングし、プロジェクト立ち上げ文書に含める方法と、プロジェクト・コントロールへの影響を確認する。 * マネジメント・アプローチを確認して、確立する必要があるコントロールを特定する。 * 過去の類似のプロジェクト、ビジネス、外部組織からプロジェクト・コントロールに関連した教訓を集める。その中には、プロジェクト・ログに記録済みのものがある場合もある。 * プロジェクト・ログをレビューして、プロジェクト・コントロールと関連したリスクや課題があるかどうかを確認する(一連のリスクが積み重なると、コントロール活動の規模や厳格さにインパクトを与えることになる)。 * 適切なコントロール・レベルを提供するために必要なステージ境界を確認し、文書化する。 * プロジェクト内で必要とされるさまざまな意思決定レベルを、最適なプロジェクト・マネジメント・レベルに割り当てる。 * 適切であると考えられる意思決定手順を確立する。このために、既存の品質マネジメント・システム内あるいは他の標準手順内の手順をテーラリングする場合がある。 * 合意された意思決定権限と責任をプロジェクト・マネジメント・チーム組織構造と役割記述書に適宜構築する。これには、それまで割り当てたことのない役割の確定や、以前に割り当てたことのある役割の再割り当てが含まれる場合がある。また、必要に応じて、プロジェクト・マネジメント・チームの再編成を行って、必要な利害関係者をすべて含め、首尾一貫したチームを構築することが含まれる * プロジェクトの許容度とエスカレーション手順を確認する(チーム・マネージャーからプロジェクト・マネージャー、プロジェクト・マネージャーからプロジェクト委員会、プロジェクト委員会からビジネス)。 * プロジェクト計画書のプロジェクト・コントロールについて説明する。 * プロジェクト保証と協議して、提案したプロジェクト・コントロールが、プロジェクトの性質と整合するものであり、プロジェクト委員会またはビジネスのニーズに応えていることを確認する。 * 新たなリスクや課題が特定された(または既存のリスクに変化が生じた)場合は、プロジェクト・ログを更新する。 * プロジェクト・コントロールについて、プロジェクト委員会に承認を求める(プロジェクト委員会は、プロジェクト立ち上げ文書の一部として後でレビューする場合もある)。

プロジェクト計画書の準備

プロジェクトへの本格的な支出をコミットする前に、期間、リソース、人員の要件を確立する必要があります。この情報はプロジェクト計画書に記載され、ベネフィット・マネジメント・アプローチの策定と、プロジェクト委員会によるプロジェクト・コントロールを可能にするために必要です。 計画立案は、プロジェクト・マネージャーが単独で行う活動ではなく、プロジェクト計画書を共創するためにユーザーやサプライヤーと緊密に関係しながら実施されるべきものです。計画立案ワークショップを開催することは、必要とされるすべての成果物、その詳細、成果物間の依存関係を特定するのに役立つことがよくあります。

プロジェクト・マネージャーに推奨される処置 * デリバリー手法(直線的かつ連続的、反復的かつ段階的、ハイブリッド)を確認し、計画立案への影響を評価する。 * プロジェクト要約書をレビューして、スコープと計画立案要件を理解する。 * プロジェクトに合わせてテーラリングし、プロジェクト立ち上げ文書に含める方法と、計画立案への影響を確認する。 * 過去の類似のプロジェクト、ビジネス、外部組織から、計画立案に関連する教訓を集める(これらの中にはプロジェクト・ログにすでに盛り込まれているものもある)。 * プロジェクト・ログをレビューして、計画立案と関連したリスクや課題があるかどうかを確認する。 * プロジェクトで使用する計画立案ツールとコントロール・ツールを特定し、それらの使用方法をプロジェクト計画書で文書化する。 * プロジェクトの計画の見積もり手法を選択する。 * マネジメント・アプローチをレビューして、実施する作業のリソース、標準、方法、コストを理解する。 * プロジェクト成果物とその主なコンポーネントの成果物ブレークダウン・ストラクチャー、これらの成果物記述書、成果物流れ図を作成し、これらをすべてプロジェクト計画書に含める。 * プロジェクト成果物を運用へと移行する際の取り決めを特定する(プロジェクト成果物を運用することで、保守が必要となる可能性がある場合、支援グループとユーザー間で、適切なサービス合意を作成する。その場合、プロジェクト計画書に成果物としての契約を含める必要がある)。 * プロジェクト成果物記述書を更新する必要があるかどうかを検討する(例えば、プロジェクトの立ち上げを実施中に、受け入れ基準の理解が変更されたり、詳細化されたりした場合)。 * 計画により提供される各成果物について、プロジェクト・ログの成果物登録簿のレコードを作成または更新する。 * 必要な人員とリソースを特定および確認する。 * 人員の可用性、役割の受け入れ、役割実行へのコミットメントを確認する。 * プロジェクト・コントロールの活動、リソース、人員、時期を特定し、それらを計画書に記載する。 * プロジェクト計画書の対象者と計画書の使用法を考慮して、プロジェクト計画書の書式とプレゼンテーションについて文書化して決定する(例えば、プロジェクト委員会に計画を提示するのに成果物チェックリストを使用するだけで十分な場合もある)。 * プロジェクト保証と協議して、提案されたプロジェクト計画書がプロジェクト委員会またはビジネスのニーズに応えていることを確認する。 * 新たなリスクや課題が特定された(または既存のリスクに変化が生じた)場合は、プロジェクト・ログを更新する。 * プロジェクト計画書について、プロジェクト委員会に承認を求める(ただしプロジェクト委員会は、プロジェクト立ち上げ文書の一部として後でレビューすることを望む場合もある)。

完全なビジネス・ケースの準備

プロジェクトの始動で作成されたビジネス・ケース概要は、プロジェクト計画書で定められた見積もり時間とコスト、および更新されたプロジェクト・ログの集約されたリスクを反映して更新する必要があります。 完全なビジネス・ケースの準備は、プロジェクト・マネージャーが単独で実行する活動ではなく、ビジネス・ケースを共創するためにプロジェクト・エグゼクティブと緊密に関係しながら実施されるべきものです。完全なビジネス・ケースはプロジェクト委員会によるプロジェクトの認可に使用され、プロジェクトが引き続き実行可能であることを継続的に確認するための根拠となります

プロジェクト・マネージャーに推奨される処置 * プロジェクト要約書をレビューし、ビジネス・ケースの書式や内容に関するビジネス要件があるかどうかを確認する。 * 過去の類似のプロジェクト、ビジネス、外部組織から、ビジネス・ケース開発に関連する教訓を集める(これらの中にはプロジェクト・ログにすでに盛り込まれているものもある)。 * 詳細情報を追加した詳細なビジネス・ケースを作成する。 * 新たなリスクや課題が特定された(または既存のリスクに変化が生じた)場合は、プロジェクト・ログを更新する。 * プロジェクト保証と協議して、提案されたビジネス・ケースがプロジェクト委員会またはビジネスのニーズに応えていることを確認する。 * ビジネス・ケースについて、プロジェクト委員会に承認を求める(ただしプロジェクト委員会は、プロジェクト立ち上げ文書の一部として後でレビューすることを望む場合もある)。

プロジェクト立ち上げ文書のとりまとめ

プロジェクトの「何を、なぜ、誰が、どのように、どこで、いつ、どのぐらい」に関係するすべての情報については、以下の点に注意する必要があります。 * 収集した情報については主要な利害関係者が合意する。 * プロジェクトの関係者にとってのガイダンスや情報として利用できる。 この情報はプロジェクト立ち上げ文書に集約されます。プロジェクト立ち上げ文書は立ち上げ中に作成または更新される多くのマネジメント成果物を集約したもので、プロジェクト続行の認可を得るのに使用されます。(プロジェクト立ち上げ文書は必ずしも単一の文書ではなく、文書やその他の形式の情報(業務工程表やプロジェクト・マネジメント・ツールのコンテンツなど)を集めたものです。) プロジェクトの立ち上げプロセス中に作成され、プロジェクト実施の認可を得るために使用されたプロジェクト立ち上げ文書のバージョンは、ベースライン化して変更コントロールの対象とする必要がありますこれは、承認の基となった当初の予測とプロジェクトの実際のパフォーマンスを比較するために、後で使用されます。

プロジェクト・マネージャーに推奨される処置 * プロジェクト要約書から情報を抽出し、必要に応じて修正する。 * 以下の情報を含めるか、参照する。 * プロジェクトのマネジメント・チーム組織構造および役割記述書 * ビジネス・ケース * マネジメント・アプローチ * プロジェクト計画書 * プロジェクト・コントロールを含めるか参照し、プロジェクトでどのようにテーラリングしたかを要約する。 * プロジェクト立ち上げ文書をとりまとめる。 * さまざまな要素にある情報の照合確認を実施し、情報に互換性のあるようにする。 * プロジェクト保証と協議して、まとめられたプロジェクト立ち上げ文書がプロジェクト委員会またはビジネスのニーズに応えていることを確認する。 * 次のステージに備える(このステージによってステージ境界のマネジメント・プロセスがトリガーされる)。

プロジェクト認可の要求

プロジェクトの立ち上げプロセス、つまり立ち上げステージを終了するために、プロジェクト・マネージャーはプロジェクト委員会に連絡してプロジェクト認可を要求します。正式な正当性は、ビジネス・ケースとプロジェクト立ち上げ文書に記載されています。

プロジェクト・マネージャーに推奨される処置 * ビジネス・ケースの最終バージョン、プロジェクト立ち上げ文書、プロジェクト計画書をプロジェクト委員会と共有する。 * 必要な人員とリソースを確保するために、プロジェクトを提供する権限をプロジェクト委員会に正式に要求する。

適用

一般的な考慮事項

このプロセスの活動はプロジェクトの都合に応じて結合、分割、または同時に実行できます。

(このプロセスで作成されるマネジメント成果物の数は膨大になる場合があり、さらに、必ずしも必要ではない詳細レベルになることもあります。このプロセスはプロジェクトの基盤であり、この時点でプロジェクトに応じたテーラリングが主に決定されます。) テーラリングはプロジェクトの事情に合わせるために必要ですが、立ち上げの開始時点では、関連する要因が明らかではない場合もあります。プロジェクトのこのような初期ステージでは、十分な情報がない場合もあります。テーラリングのニーズは、立ち上げ作業が進むにつれて明らかになります。(そのため、仮説的な主要プロジェクトに適したマネジメント環境を作成するよりも、シンプルに開始し、必要に応じて詳細化することをお勧めします。) (一部のプロジェクトは複雑すぎて、このプロセスが終了するまでに、合意済みのプロジェクトのアウトプット(ひいてはプロジェクトの最終成果物)を完全に定義できません。このような場合は一般的に、プロジェクト・ライフサイクルに、選択肢を検討して解決策を選択するための調査ステージが複数含まれています。その場合、プロジェクトの立ち上げプロセスは、マネジメントおよびコントロール環境を確立するために第 1 ステージの開始時のみに使用されます。)

役割のテーラリング

マネジメント成果物の作成はプロジェクト・マネージャーに実行責任があるものとして示します。プロジェクト支援が一部の補助的な成果物を担当する場合がありますが、いずれの場合もプロジェクト・マネージャーが、プロジェクトの実行方法についてプロジェクト・エグゼクティブに対し実行責任を負います。したがって、プロジェクト・マネージャーはタスクに適した人にさまざまな役割をアサインできます。多くの場合、より概要でのプログラム・オフィスや同様のセットアップが支援を提供できます。

責任

活動	ビジネス・レイヤー	プロジェクト・エグゼクティブ	シニア・ユーザー	シニア・サプライヤー	プロジェクト・マネージャー	チーム・マネージャー	プロジェクト保証	プロジェクト支援
テーラリング要件への合意		A	C	C	R	C	C	I
マネジメント・アプローチへの合意		A	C	C	R	C	C	I
プロジェクト・コントロールの確立		A	C	C	R	C	C	I
プロジェクト計画書の準備		A	C	C	R	C	C	C
完全なビジネス・ケースの準備		A	C	C	R	C	C	I
プロジェクト立ち上げ文書のとりまとめ		C	C	C	A	C	C	R
プロジェクト認可の要求	I	A	C	C	R	I	C	I

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

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

プラクティス	プロジェクトの立ち上げプロセスへの適用
ビジネス・ケース	プロジェクト要約書のビジネス・ケース概要は、プロジェクトと提案されたオプションに対するより深い理解に基づいて、プロジェクト委員会による承認の準備ができている完全なビジネス・ケースへとさらに発展させます。ベネフィット・マネジメント・アプローチと持続可能性マネジメント・アプローチはビジネス・ケースを支援し、コントロールを確立するためのインプットを提供するために作成されます
組織化	プロジェクト・マネジメント・チーム組織は、あるレイヤーから次のレイヤーに委任された権限のレベルの詳細で更新され、残りのプロジェクト・マネジメント・チームの任命とオンボーディングが行われます。ワーク・ブレークダウン・ストラクチャーは、プロジェクト計画書に基づいて考慮され、チームへの作業編成に関する情報を提供し、どの要素が外部から供給されるかを判断します。コミュニケーション・マネジメント・アプローチ、変更マネジメント・アプローチ、商業マネジメント・アプローチが作成され、プロジェクト・コントロールを確立するためのインプットを提供します
計画	プロジェクト成果物記述書は、プロジェクト計画書の作成に使用される成果物ブレークダウン・ストラクチャーと成果物流れ図を作成するために使用されます。プロジェクト計画書は、プロジェクトに必要なステージを定義します
品質	成果物登録簿が作成されます。成果物記述書が作成され、必要に応じてプロジェクト成果物記述書が更新されます。成果物記述書の品質仕様は、コントロールを確立するためのインプットを提供する品質マネジメント・アプローチの作成に役立ちます。品質登録簿が作成されます
リスク	リスク・マネジメント・アプローチは、プロジェクト・コントロールを確立するためのインプットを提供するために作成されます。リスク登録簿はカテゴリーに基づいて作成され、格付けシステムはリスク・マネジメント・アプローチで定義されます。ビジネス・ケース、プロジェクト計画書などで特定されたリスクは、リスク登録簿に記録され、評価されます。リスク予算が考慮され、必要に応じて作成されます
課題	課題マネジメント・アプローチは、変更コントロールと課題マネジメントのプロジェクト・コントロールを確立するインプットを提供するために作成されます。課題登録簿はカテゴリーに基づいて作成され、格付けシステムは課題マネジメント・アプローチで定義されます。ビジネス・ケース、プロジェクト計画書などで特定された課題は、課題登録簿に記録され、評価されます。変更予算が考慮され、必要に応じて作成されます
進捗	デジタルおよびデータ・マネジメント・アプローチは、プロジェクト・コントロールを確立するためのインプットを提供するために作成されます。 すべてのマネジメント・アプローチのプロジェクト・コントロールが確立され、進捗マネジメントの基盤が提供されます。 ハイライト報告書は、立ち上げステージの進捗を示すために使用されます