プロジェクトの立ち上げ
プロジェクトの立ち上げプロセスの目的は、プロジェクトの確固とした基盤を確立する。ビジネス側が本格的な支出やリソースの投入(コミットメント)を決定する前に、成果物提供のために必要な作業、コスト、リスクを十分に理解できる。
達成目標
関係者全員が以下の事項について共通の理解を持つことを目指す。
- 正当性と価値: 実施理由、期待されるベネフィット、および関連するリスク(ビジネス・ケース)。
- スコープと成果物: 実施される作業範囲と、提供される具体的な成果物。
- 計画: 成果物を提供する方法、スケジュール、およびコスト(プロジェクト計画書)。
- 体制と責任: 意思決定に関与する人物とその責任。
- 品質: 求められる品質を定義し、達成する手段。
- コントロール: ベースラインの確立方法、進捗のモニタリング、リスクや課題の管理手法。
- コミュニケーション: 情報を必要とする人、書式、およびタイミング。
- 整合性: 組織のビジネス方針、手法、ガイダンスをプロジェクトに適用する方法。
位置付け
実施のポイント
- プロセスの重要性と役割
プロジェクトの成功を左右する合意とコミットメントを形成するフェーズである。
- 真のコミットメント: プロジェクトの目的、必要性、達成方法、責任について、関係者全員が明確なイメージを持ち、プロジェクトに対して真にコミットする。
- 意思決定の支援: このプロセスで作成された情報を基に、プロジェクト委員会はプロジェクトの指揮プロセスを通じて、プロジェクトの継続がビジネス目標に整合しているかを判断する。
- マネジメント成果物の作成: PMは、委員会が求めるコントロール・レベルに応じた一連のマネジメント成果物を作成する。これらの成果物を誰がどのようにレビューし承認するかについて、あらかじめ合意しておく必要がある。
- 商業的環境での考慮事項
ユーザー(顧客)とサプライヤーが商業的関係にある場合、本プロセスの活動には慎重な検討が求められる。
- リスクと報酬の相違: 顧客側とサプライヤー側では、プロジェクトを引き受ける理由や、許容できるリスク、期待する報酬が異なる。
- 利害の調整: 双方の立場を考慮し、双方が納得できる形で基盤を構築する必要がある。
活動
| インプット | 活動 | アウトプット |
|---|---|---|
| プロジェクト立ち上げの認可 (このプロセスをトリガー) プロジェクト要約書 (レビュー) プロジェクト・ログ (確認) プロジェクト成果物記述書 (レビュー) ステージ計画書 (立ち上げ) (レビュー) | テーラリング要件への合意 | マネジメント・アプローチ (作成) プロジェクト計画書 (作成) |
| プロジェクト立ち上げの認可 (このプロセスをトリガー) プロジェクト要約書 (レビュー) プロジェクト・ログ (確認) プロジェクト成果物記述書 (レビュー) ステージ計画書 (立ち上げ) (レビュー) | マネジメント・アプローチへの合意 | マネジメント・アプローチ (作成) プロジェクト計画書 (作成) |
| プロジェクト立ち上げの認可 (このプロセスをトリガー) プロジェクト要約書 (レビュー) プロジェクト・ログ (確認) プロジェクト成果物記述書 (レビュー) ステージ計画書 (立ち上げ) (レビュー) | プロジェクト・コントロールの確立 | マネジメント・アプローチ (作成) プロジェクト計画書 (作成) |
| プロジェクト立ち上げの認可 (このプロセスをトリガー) プロジェクト要約書 (レビュー) プロジェクト・ログ (確認) プロジェクト成果物記述書 (レビュー) ステージ計画書 (立ち上げ) (レビュー) | プロジェクト計画書の準備 | マネジメント・アプローチ (作成) プロジェクト計画書 (作成) |
| ビジネス・ケース概要 | 完全なビジネス・ケースの準備 | ビジネス・ケース (作成) |
| ビジネス・ケース プロジェクト要約書 プロジェクト成果物記述書 プロジェクト計画書 マネジメント・アプローチ プロジェクト立ち上げ文書 | プロジェクト立ち上げ文書のとりまとめ | プロジェクト立ち上げ文書 (作成) プロジェクト・ログ (更新) ステージ終了が近づく(ステージ境界のマネジメント・プロセスをトリガー) |
| プロジェクト立ち上げ文書 | プロジェクト認可の要求 | プロジェクト認可の要求 (プロジェクトの指揮プロセスをトリガー) |
テーラリング要件への合意
すべてのプロジェクトに標準の手法をそのまま適用できるわけではない。プロジェクトの規模、複雑さ、リスク、重要度に応じて、管理の仕組みを最適化(テーラリング)する必要がある
- テーラリングの必要性
PMは、プロジェクトの遂行に影響を与える内部要因(組織文化、標準プロセスなど)や外部要因(法規制、市場環境など) を認識し、手法を最適化しなければならない。
- 組織標準の活用: ビジネス(組織)にすでに標準的なフレームワークが存在する場合は、それをベースにどのように適用し、どこを調整するかを明確にする。
- 合意の重要性: 調整した内容は文書化し、関係者間で合意を得る必要がある。 *管理のやりすぎや不足を防ぐ。
- PMに推奨される処置
PMは、以下のステップを通じてテーラリングの妥当性を確保する。
- 既存方針の確認
- プロジェクト要約書をレビューし、すでに定義されているテーラリング・アプローチの概要を把握する。
- 教訓の収集
- 過去の類似プロジェクトや外部組織の事例から、効果的なテーラリング方法についての教訓を収集する。
- 要件の定義
- 関連するプロジェクト・コントロールを含め、**プロジェクト立ち上げ文書(PID)**の一部としてテーラリング要件を定義する。
- 妥当性の確認
- プロジェクト保証と協議し、提案したテーラリング内容がプロジェクト委員会や組織のニーズに合致しているかを確認する。
- 承認の取得
- テーラリング内容について委員会の承認を得る。 ※委員会がPID 全体の一部として後でまとめてレビューすることを希望する場合もある。
- 既存方針の確認
マネジメント・アプローチへの合意
マネジメント・アプローチは、プロジェクトをどのように管理・運営していくかのルールブックである。これらを定義することで、一貫性のあるコントロールが可能になり、詳細なプロジェクト計画の策定が進められるようになる。
- 策定のポイント
- 策定の順序: 各マネジメント・アプローチの策定活動は、複数を並行して進めることができるが、コミュニケーション・マネジメント・アプローチは他すべてのアプローチの伝達要件を網羅する必要があるため、最後に完了させることが推奨される。
- 策定の根拠: ビジネス戦略、組織の標準、成果物記述書にあるユーザーの期待品質、および持続可能性などの要件に基づいて策定される。
- 定義すべき9つのマネジメント・アプローチ
プロジェクトの特性に応じて、以下の領域における管理方針を定義する。
- 変更マネジメント・アプローチ
- コミュニケーション・マネジメント・アプローチ
- 持続可能性マネジメント・アプローチ
- ベネフィット・マネジメント・アプローチ
- 商業マネジメント・アプローチ
- 品質マネジメント・アプローチ
- リスク・マネジメント・アプローチ
- 課題マネジメント・アプローチ
- デジタルおよびデータ・マネジメント・アプローチ
- PMに推奨される処置
PMは、実効性のあるアプローチを策定するために以下の実務を行う。
- 影響の評価
- 決定済みのテーラリングが、各アプローチに与える影響をレビューする。
- 要件の把握
- プロジェクト要約書を確認し、適用すべきビジネス戦略やプラクティス、契約上の義務を特定する。
- 知見の活用
- 過去の類似事例から教訓を収集し、アプローチに反映させる。
- リスクと課題の確認
- プロジェクト・ログを精査し、アプローチ策定に関わるリスク(例: 特定の管理手法が複雑すぎるリスクなど)があるか確認し、必要に応じてログを更新する。
- 妥当性の検証と承認
- プロジェクト保証と協議し、提案内容が委員会やビジネスのニーズを満たしているか確認する。
- プロジェクト委員会に承認を求める。 ※多くの場合、最終的なプロジェクト立ち上げ文書(PID) の一部として一括で承認される。
- 影響の評価
プロジェクト・コントロールの確立
プロジェクト・コントロールの確立は、プロジェクトを規模、リスク、複雑性、重要度に応じて効果的かつ効率的に管理するためのメカニズムを構築する。
- 重要性
- 合意の形成: プロジェクト委員会とPM 間、およびPMとチーム・マネージャー間での管理レベル(コントロール・レベル)について合意する。
- 効率的な管理: 適切なコントロールを確立することで、各マネジメント層が過度な負担を負わずに意思決定に関与できる環境を作る。
- 構成要素
効果的なコントロールを実現するために、以下の要素を具体的に定義し確立する。
- コミュニケーション: 各レイヤー間における報告の頻度と形式。
- ステージの設定: 適切な意思決定ポイントとしてのステージ数と境界。
- 課題管理: 課題を確実に把握し、分析するためのメカニズム。
- 許容度(トレランス)の設定: 委任された権限の範囲(時間、コスト、品質、スコープ、ベネフィット、リスク)。
- モニタリング: 委任された権限が守られているかを監視する方法。
- エスカレーション: 許容度を超える事態(例外)が発生した際の報告ルート。
- PMと支援チームに推奨される処置
役割に応じて以下の処置を取る。
- 手法と環境の評価
- デリバリー手法の確認: ウォーターフォール、アジャイル、ハイブリッドなどの手法が、コントロールに与える影響を評価する。
- テーラリングの反映: プロジェクト立ち上げ文書(PID)で定義された調整内容が、コントロールに与える影響を確認する。
- 知見とリスクの活用
- 教訓の反映: 過去のプロジェクトから、どの程度のコントロールが有効であったかの知見を集める。
- リスクと課題のレビュー: ログを精査し、リスクの蓄積が管理の厳格さにどう影響するかを判断する(リスクが高いほど、コントロールを強める必要がある)。
- 体制と手順の構築
- ステージ境界の確定: 適切なタイミングでコントロールを行うためのステージ区切りを決定し、文書化する。
- 意思決定手順の確立: 各レベルに最適な意思決定権限を割り当て、具体的な手順(品質システム等のテーラリング)を策定する。
- 役割の更新: 必要に応じてチーム組織を再編成し、役割記述書に決定権限と責任を反映させる。
- エスカレーション・パスの確認: チーム -> PM -> 委員会 -> ビジネスという報告ルートを確定させる。
- 最終確認と承認
- 整合性の確認: プロジェクト保証と協議し、提案したコントロールがプロジェクトの性質やビジネスのニーズと一致しているかを確認する。
- 承認依頼: 策定したコントロールについてプロジェクト委員会に承認を求める ※多くの場合、最終的なプロジェクト立ち上げ文書(PID) の一部として一括で承認される。
- 手法と環境の評価
プロジェクト計画書の準備
プロジェクト計画書の準備は、本格的な支出やリソース投入を決定する前に、プロジェクトの期間、コスト、リソース、人員の要件を明確に定義し、ベネフィット実現の基盤となり、プロジェクト委員会が全体をコントロールするための基準を提供する。
- 計画立案の基本姿勢
- 共創: 計画はPMが単独で作るものではない。ユーザーやサプライヤーと緊密に連携し、ワークショップなどを通じて成果物や依存関係の特定を促進する。
- 運用への配慮: 成果物の完成だけでなく、引き渡した後の保守体制やサービス合意(SLA)についても、必要に応じて計画に含める。
- PMに推奨される処置
- 前提条件と手法の確認:
- デリバリー手法(アジャイル、ウォーターフォール、ハイブリッド)、テーラリング要件をレビューし、計画立案に与える影響を評価する。
- 過去の教訓や現在のプロジェクト・ログを精査し、計画上のリスクを特定・評価する。
- 成果物の定義と構造化:
- 成果物ブレークダウン・ストラクチャー (PBS)、成果物記述書、成果物流れ図を作成し、何を作るのかを構造的に定義する。
- 立ち上げ中の理解の変化に基づき、必要に応じてプロジェクト成果物記述書を更新する。
- 見積もりとリソースの確保:
- 見積もり手法を選択し、ツールやコントロール手法を特定する。
- 必要な人員・リソースを特定し、関係者の可用性やコミットメントを確保する。
- 管理活動の組み込み:
- 品質管理やプロジェクト・コントロールのための活動、リソース、時期を計画に反映する。
- 各成果物の情報を成果物登録簿に記録する。
- プレゼンテーションと承認:
- 対象者(プロジェクト委員会など)に合わせて、最も理解しやすい書式(成果物チェックリスト等)で提示する。
- プロジェクト保証と協議し、ビジネスニーズを満たしているか確認した上で、委員会の承認を得る。
- 前提条件と手法の確認:
完全なビジネス・ケースの準備
プロジェクトの始動段階で作成されたビジネス・ケース概要を、最新のプロジェクト計画書(見積もり時間・コスト)およびプロジェクト・ログ(集約されたリスク)に基づいて詳細化する
- PMに推奨される処置
- 情報の収集と詳細化
- 要件の確認: プロジェクト要約書をレビューし、求めるビジネス・ケースの書式や内容を把握する。
- 教訓の反映: 過去の類似プロジェクトや外部事例から、効果的なビジネス・ケース開発に関連する教訓を収集する。
- 詳細版の構築: プロジェクト計画書の見積もりとプロジェクト・ログのリスクを集約し、詳細なビジネス・ケースを作成する。
- 管理と妥当性の確認
- ログの更新: ビジネス・ケース策定中に特定された新たなリスクや課題、または既存情報の変化をプロジェクト・ログに反映させる。
- プロジェクト保証との協議: 提案内容がプロジェクト委員会やビジネス層のニーズに合致しているか、客観的な評価(プロジェクト保証)を受ける。
- 承認の取得
- 委員会の承認: 完成したビジネス・ケースについて、プロジェクト委員会に承認を求める。 ※多くの場合、最終的な**プロジェクト立ち上げ文書(PID)**の一部として一括で承認される。
- 情報の収集と詳細化
プロジェクト立ち上げ文書のとりまとめ
PIDは、プロジェクトの何を、なぜ、誰が、どのように、いつ、いくらでに関する全情報を集約。
*プロジェクトの憲章とも呼べる。
- 役割
- 合意の形成: 主要な利害関係者がプロジェクトの内容に合意したことを確認する。
- ガイダンスの提供: プロジェクト関係者がいつでも参照できる公式な情報源として機能させる。
- 認可の根拠: プロジェクト実行の認可を得るための最終的な判断材料となる。
- 性質
- 情報の集約: 立ち上げ中に作成された多くのマネジメント成果物を参照または包含する。必ずしも単一の文書である必要はなく、ツール上のデータや複数のドキュメントの集合体でもよい。
- ベースライン化: 認可を受けたPIDのバージョンはベースラインとして保存し、変更コントロールの対象とする。これは、プロジェクト終了時に当初の予測と実績を比較するための基準となる。
- プロジェクト・マネージャーに推奨される処置
- プロジェクト要約書の情報を最新の状態に修正して取り込む。
- 要素の包含: 以下の主要な情報をPIDに含める、あるいは参照させる。
- プロジェクト・マネジメント・チームの組織構造と役割記述書
- 完全なビジネス・ケース
- 各マネジメント・アプローチ(品質、リスク、コミュニケーションなど)
- プロジェクト計画書
- テーラリングの要約: プロジェクトの性質に合わせてどのように手法を調整(テーラリング)したかを要約する。
- 互換性のチェック、相互の互換性を確認する。
- プロジェクト保証との協議: PIDの内容がプロジェクト委員会や組織のニーズを満たしているかを確認する。
- 次のステージへの準備: PIDのとりまとめによりステージ境界のマネジメントプロセスをトリガーし、次期ステージの実行に向けた準備を開始する。
プロジェクト認可の要求
プロジェクトの立ち上げプロセスを締めくくり、プロジェクトの実行フェーズ(デリバリーステージ)へ進むための最終的な承認を得る。
- PMに推奨される処置
- 成果物の共有と提示
- 最終ドキュメントの提出: ビジネス・ケースの最終バージョン、プロジェクト立ち上げ文書(PID)、およびプロジェクト計画書をプロジェクト委員会へ提示する。
- 権限とリソースの要求
- 実行権限の正式要求: プロジェクト成果物を提供し、計画を実行に移すための公式な権限を要求する。
- リソースの確保: プロジェクトの成果物を提供(デリバリー)するために必要な人員やリソースを確保・使用する権限を、プロジェクト委員会に対して正式に要求する。
- 成果物の共有と提示
適用
このプロセスを実務に適用する際は、形式的な文書作成に陥ることなく、プロジェクトの確固とした基盤(ファウンデーション)を築くための柔軟な運用が求められる。
一般的な考慮事項
プロセスの規模や詳細度は、プロジェクトの複雑性やリスクに応じて適切にテーラリングされるべきである。
- 活動の柔軟な運用: 立ち上げプロセスの各活動は、プロジェクトの都合や状況に応じて、結合・分割、あるいは同時並行で実行できる。
- テーラリングの段階的詳細化: 立ち上げ開始時点では不明な要因も多いため、最初から過度な詳細を求める必要はない。シンプルに開始し、状況が明らかになるにつれて、内容を具体化することが推奨される。
- 不確実性への対処(調査ステージ): アウトプットを即座に完全定義できないほど複雑なプロジェクトでは、ライフサイクル内に調査用のステージを設ける。この場合、立ち上げプロセスは第 1ステージ開始時の管理・コントロール環境を確立するために使用される。
役割のテーラリング
実務の委任は可能だが、プロジェクトの実行方法に関する最終的な責任の所在を明確にしておく必要がある。
- PMの実行責任: マネジメント成果物の作成に関する実行責任はPMにある。PMはタスクに応じて適切な人員に作業を割り当てることができる。
- 支援組織の活用: プロジェクト支援やプログラム・オフィス(PMO)などの既存組織は、補助的な成果物の作成においてPMに支援を提供できる。
- 責任の維持: 誰が実務を補助したとしても、プロジェクトの実行方法についてプロジェクト・エグゼクティブに対して負う実行責任は、PM 一元化されていなければならない。
責任
| 活動 | ビジネス・レイヤー | プロジェクト・エグゼクティブ | シニア・ユーザー | シニア・サプライヤー | プロジェクト・マネージャー | チーム・マネージャー | プロジェクト保証 | プロジェクト支援 |
|---|---|---|---|---|---|---|---|---|
| テーラリング要件への合意 | 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 = 情報先
プロセスへのプラクティスの適用
| プラクティス | プロジェクトの立ち上げプロセスへの適用 |
|---|---|
| ビジネス・ケース | 概要を完全なビジネス・ケースへと発展させる。ベネフィットおよび持続可能性マネジメント・アプローチを策定し、投資の正当性を強固にする |
| 組織化 | 権限委任の詳細を反映してチーム組織を更新し、残りのメンバーを任命・オンボーディングする。コミュニケーション・変更・商業マネジメント・アプローチを作成し、WBSを用いて作業編成や外部調達を判断する |
| 計画 | 成果物ベースの計画手法(PBS、成果物流れ図)を用いてプロジェクト計画書を作成し、必要なステージ構成を定義する |
| 品質 | 成果物記述書、品質マネジメント・アプローチ、成果物登録簿、品質登録簿を作成。必要に応じてプロジェクト成果物記述書を更新する |
| リスク | リスク・マネジメント・アプローチとリスク登録簿を作成。特定されたリスクを評価・記録し、必要に応じてリスク予算を設定する |
| 課題 | 課題マネジメント・アプローチと課題登録簿を作成。特定された課題を評価・記録し、必要に応じて変更予算を設定する |
| 進捗 | デジタルおよびデータ・マネジメント・アプローチを作成。全アプローチのコントロールを確立して進捗管理の基盤とし、当ステージの報告にはハイライト報告書を使用する |
気に入ったならばコメントを残してくださいね~