プロジェクト・マネジメント-プロセス

プロセス

プロセスの目的は、特定の達成目標を達成するために、インプットとアウトプットを定義した一連の活動(アクション)を構造化し、プロジェクトを正しく指揮・管理・提供する。

• 1. 構成

  7つのプロセスが定義されている。それぞれのプロセスには、適切な指揮・管理・提供を行うために必要な活動が含まれている。

  • 1.1. プロジェクトの始動(Starting up a Project): 実行可能性の確認。
  • 1.2. プロジェクトの指揮(Directing a Project): プロジェクト委員会による意思決定。
  • 1.3. プロジェクトの立ち上げ(Initiating a Project): 詳細計画とベースライン策定。
  • 1.4. ステージのコントロール(Controlling a Stage): PMによる日々の管理。
  • 1.5. 成果物デリバリーのマネジメント(Managing Product Delivery): チームによる制作。
  • 1.6. ステージ境界のマネジメント(Managing a Stage Boundary): 次のステージへの準備。
  • 1.7. プロジェクトのクローズ(Closing a Project): 正式な終了手続き。
• 2. ステージ構成

  プロジェクトの規模に関わらず、時間軸においては少なくとも以下の2つのステージが必ず存在する。

  • 立ち上げステージ(Initiation Stage)
  • 最終ステージ(Final Stage) ※プロジェクトの規模や必要性に応じて、これら2つのステージの間に複数の中間ステージを設けることもできる。

ライフサイクル

プロジェクト開始前

プロジェクトが正式に動き出す前には、アイデアやニーズを具体化し、その妥当性を検証する「準備段階」が必要である。

• 1. プロジェクトのトリガー(プロジェクト権限委任) プロジェクトが始まるきっかけをプロジェクト権限委任と呼ぶ。
     • 提供元: ビジネス(プロジェクトを委託する組織)から提供される。
     • 形態: 口頭による指示から、詳細に定義された正式な文書まで、その形式は多岐にわたる。
• 2. プロジェクトの始動(Starting up a Project)プロセス プロジェクトを正式に開始する前に、そのプロジェクトに価値があり、かつ実行可能であるかを評価・確認する。
     • 主な活動:
       • プロジェクト・マネージャー(PM)およびプロジェクト委員会の任命。
       • プロジェクト要約書の作成。
       • 最初のステージ(立ち上げステージ)のためのステージ計画書の作成。
• 3. プロジェクトの指揮プロセス プロジェクトを実際に開始するかどうかの決定は、プロジェクト委員会このプロセスを通じて行う。
     • レビューと意思決定:
       • プロジェクト委員会は、提出されたプロジェクト要約書とステージ計画書を精査する。
       • プロジェクトの開始を承認するかどうか、および必要な人員やリソースの割り当てについて最終決定を下す。

立ち上げステージ

プロジェクトの始動が承認された後、詳細な計画を策定し、管理体制を構築するステージである。

• 1. プロジェクトの立ち上げ(Initiating a Project)プロセス プロジェクトを成功させるために、以下の重要な要素を確立し、基盤を固める。
     • 詳細計画の立案: スケジュールやリソースの明確化。
     • ガバナンスの構築: プロジェクト・マネジメント・アプローチとコントロールの定義。
     • ビジネス・ケースの精査: 投資対効果や正当性を裏付ける堅固なビジネス・ケースの開発。
     • ベネフィット・マネジメント: 成果がもたらす利益をどのようにレビューするかを決定。
• 2. 次のステージの準備 立ち上げステージの後半で、ステージ境界のマネジメントプロセスを使用して、次のステージに関する詳細な計画を作成する。
• 3. ステージの終了と認可 立ち上げステージは、プロジェクト委員会による最終レビューをもって終了する。
     • PID(プロジェクト立ち上げ文書)の作成: ステージの最後には、すべての情報をまとめたPIDを作成する。
     • 意思決定: プロジェクト委員会は、プロジェクトの指揮プロセスを用い、プロジェクト全体および次ステージを認可するかどうかを決定する。
     • PID(プロジェクト立ち上げ文書)の承認: 承認されたPIDは、その後のプロジェクトの進捗を評価するためのベースラインとして保存される。 ※PIDはプロジェクト期間中に変更される可能性が高いため、初期状態を記録しておくことが重要である。

後続ステージ

立ち上げステージ以降、プロジェクトは一つまたは複数の実行ステージ(後続ステージ)を経て進行する。

＊このステージでは、日々の管理、成果物の作成、ステージの切り替えが中心となる。

• 1. ステージのコントロール(Controlling a Stage)プロセス プロジェクト委員会は、ステージごとの日々の管理をPMに委任する。
     • PMの責務: 承認された計画に沿って進捗しているか、予測が「許容度(トレランス)」の範囲内に収まっているかを常に確認する。
     • 委員会への報告: PMはハイライト報告書を定期的に提出し、プロジェクト委員会に進捗状況を通知する。
• 2. 成果物デリバリーのマネジメント(Managing Product Delivery)プロセス PMとチーム・マネージャー(またはチーム・メンバー)間のやり取りを管理するプロセスである。
     • 作業の割当: PMは実行すべき作業をWPとしてアサインする。
     • チームからの報告: チーム側は、チェックポイント報告書を通じて作業の進捗状況をPMに報告する。
• 3. ステージ境界のマネジメント(Managing a Stage Boundary)プロセス 各ステージの終盤に行われる、ステージの締めと次への準備のためのプロセスである。
     • 実績報告と許可依頼: PMは現在のステージの実施状況を報告し、プロジェクト委員会に対して次のステージへ進むための許可を依頼する。
     • 計画と更新: 次のステージの詳細計画を作成すると同時に、最新の状況に基づいてビジネス・ケースを更新する。
     • 委員会の意思決定: プロジェクト委員会は、プロジェクトがビジネス戦略と整合しており、実行可能性(妥当性)があるかを評価し、次ステージの開始を認可するか決定する。

最終ステージ

プロジェクトは一時的な組織体であるため、最終ステージの終盤で正式に終了させる手続きが必要となる。

• 1. プロジェクトのクローズ(Closing a Project)プロセス
  • 1.1. 成果物の移転とオーナーシップの確定 プロジェクト期間中、個別の成果物は随時運用側へ移転・移行されている場合がある。クローズに際しては、以下の点を確認する。
    • 受領者の準備: 成果物の受領者がそれらを所有し、継続して使用できる状態にあること。
    • ビジネス側の責任: ビジネス(委託組織)がプロジェクト成果物の全体的なオーナーシップを完全に引き継げる状態にあること。
  • 1.2. プロジェクトの評価とリソースの解放 プロジェクトを正式に終了させるために、以下の事務的・管理的作業を行う。
    • パフォーマンス評価: プロジェクトの最終的な実績を、当初の計画書と比較して評価する。
    • リソースのリリース: プロジェクトにアサインされていた人員やリソースを解放する。
    • 文書の保管: 後の参照や監査に備え、プロジェクト関連文書を適切にアーカイブ(保管)する。
  • 1.3. プロジェクト終了後の活動 プロジェクトが終了した後にしか評価できない事項についても、この段階で整理を行う。
    • ベネフィット・レビュー計画の確認: プロジェクト成果物の使用開始後に現れるベネフィットを、いつ、誰が、どのように評価するかを定めた計画を確認、または必要に応じて修正する。

プロジェクト終了後

プロジェクトが正式にクローズした後も、価値の実現を確認するための活動は継続される。

• 1. ベネフィットの実現 一部のベネフィットはプロジェクト期間中に実現することもあるが、大半はプロジェクト完了後の運用フェーズで実現される。
• 2. プロジェクト終了後のレビュー 計画に基づき、プロジェクト終 了後に1回以上のレビューが実施される。これは期待された成果が実際に出ているかを確認するために不可欠である。
• 3. ベネフィット・マネジメント・アプローチの役割 ベネフィットを確実に把握するため、以下の事項を「ベネフィット・マネジメント・アプローチ」に文書化しておく必要がある。
     • 時期と方法: ベネフィット・レビューをいつ、どのように実施するか。
     • 責任の所在: 誰がレビューに対して実行責任と説明責任を負うか。

プロセス記述の構成要素

項目	内容
目的	プロセスを実行する理由
達成目標	プロセスで達成すべき固有の目標
位置づけ	他のプロセスとの関係、成果物のIN/OUT
活動	推奨される処置の一連の流れ
責任	RACI 図による役割分担の定義