PRINCE2のメソッド

ビジネスケース

このテーマでは、ビジネスケースがプロジェクトを通してどのように開発・維持されるか、各段階の終了時にどのように更新・見直し・承認されるかが類型化されています。プロジェクト委員会が、プロジェクトが投資に見合う価値があるかという点に基づいて決定を行います。

組織

このテーマでは、プロジェクトマネジメントチームの全メンバーのアカウンタビリティと責任の構造が類型化されています。PMIのプロジェクトマネジメント知識体系(PMBOK® ガイド)に慣れている方は、PRINCE2がプロジェクトマネジメントチームの役割についてより広い定義をしていることに驚かれるかもしれません。しかしながら、PRINCE2において推奨されるプロジェクトマネジメントチームの構造は非常に柔軟で、小規模なプロジェクト及び大規模なプロジェクトのどちらのニーズにも同様に適用することができます。

品質

品質は、全てのプロジェクトにおいて大変重要な要素です。PRINCE2では、要求される品質基準の定義に関する責任の所在、そして、あらゆるプロジェクトに必要な品質管理の計画をしやすくするシンプルなプロセスが類型化されています。また、文書の品質を見直す際に使用が特に推奨される、品質レビューテクニックも類型化されています。

リスク

PRINCE2では、ポジティブ及びネガティブな不確実性によってリスクが定義されています。このテーマでは、把握、評価、リスク対応策の計画及び実行、そしてリスクの状態に関する報告の手順が表されます。リスクは、計画の進捗を通して取り組むものであり、プロジェクト委員会がプロジェクト継続の可否決定する際には、段階修終了アセスメントへの主なインプットとなります。

計画

PRINCE2では、様々なレベルのプロジェクトマネジメントチームのニーズに対応するための様々なレベルの計画が定義されています。上位の計画、例えばプロジェクト委員会に向けた計画は長期的であまり具体的ではありません。下位の計画、例えばチームマネージャによって利用されるチーム計画は、短期的でより詳細です。PRINCE2は、計画の範囲を特定し成果物の品質基準を定義するために、成果物ベースのプランニングテクニックの利用を推奨しています。

変更

どのようなプロジェクトも、変更に依存しています。PRINCE2プロジェクトもその例外ではありません。しかしながら、PRINCE2は課題及び変更コントロール手順によって類型化される、変更をマネジメントするためのメカニズムを有しています。課題と変更を把握して影響分析・決定を行い、対応策を実行・追跡・報告するためのシンプルなプロセスがまとめらています。

進捗

先に述べた許容度は、いかにして上位管理者から下位管理者へ、例えばプロジェクト委員会からプロジェクトマネージャへ、権限を委譲するのかを類型化しています。許容度を越える段階のパフォーマンス及びプロジェクトは追跡・報告されなければなりません。これは、チームマネージャとプロジェクトマネージャの間、及びプロジェクトマネージャとプロジェクト委員会の間で定期的に起こることです。

しかしながら、報告書は、各マネジメントレベルのパフォーマンス管理を可能にするPRINCE2による管理の一つにすぎません。プロジェクト継続の可否を決定が行われるため、プロジェクト委員会による段階終了アセスメントが主要な管理です。このように、プロジェクト委員会はプロジェクトマネージャが支出及び作業の承認を行うために主要な決定を行います。

プロジェクトの指示

PRINCE2プロジェクトで行われる最初のプロセスではありませんが、投資価値のあるプロジェクトか、資金調達に関わるべきか、プロジェクトを継続するべきか、終了するべきか、変更とリスクにどう対応するべきか、ターゲットは何か、等プロジェクトにおける最も重要な決定の全てがこのプロセスで行われるため、様々な意味において最も重要なプロセスです。これらの決定は、PRINCE2プロジェクトにおける最上位の権限者であるプロジェクト委員会によって行われるものです。

プロジェクト委員会は三要素から構成されています。資金調達の責任者でありプロジェクトの最終的なアカウンタビリティを負うエグゼクティブ、ベネフィットの実現と特定に責任を負うシニアユーザ、成果物の納品に責任を負うシニアサプライヤです。プロジェクト委員会は、プロジェクトに関する全ての主要な決定を集合的に行います。

プロジェクトの立ち上げ

最初のプロセスであり、プロジェクト開始前に行われます。なぜプロジェクトが必要なのか、主なステークホルダーは誰か、教訓は何か、最終的な(プロジェクト)成果物及び成果物の納品方法などについての、高いレベルでの理解を高めることを目的としています。これらの項目は全て、高いレベルのプロジェクトの概要を構成するプロジェクト要約書に文書化されます。ここで、第一ステージでの計画も作成されます。どちらの文書(マネジメント成果物)も、プロジェクトの第一段階に取り組む前にプロジェクト委員会によってレビューされ承認されます（承認されないこともあります）。

プロジェクト委員会がこのプロセスの最終段階で問うべき重要な質問は、「このプロジェクトに価値があるのか、プロジェクトは理に適っているのか？」ということです。プロジェクトが理に適い、価値のあるものであるならば、プロジェクトの第一段階をスタートする権限がプロジェクトマネージャに与えられます。

プロジェクトの開始

このプロセスでは、第一段階でプロジェクトマネージャによって行われる作業がカバーされます。ここでは、より詳細な計画と準備が行われ、プロジェクト開始文書(Project Initiation Document, PID) が作成されます。

PIDは、プロジェクトの費用とタイムスケールを詳細化し管理段階を特定するプロジェクト計画書、プロジェクトの費用対効果、マネジメント戦略、リスク、品質、構成マネジメント及びコミュニケーションを表す詳細なビジネスケースなどの、いくつかの文書を集めたものです。

PIDはベネフィット測定のための計画書、次の段階へ向けた段階計画書と共にプロジェクト委員会へ提示されます。プロジェクト委員会がプロジェクトに価値があると決定し、必要な管理及び戦略が全て整い、プロジェクト計画が現実的で実現可能なものである場合、PIDと段階計画書がプロジェクト委員会に承認され、次の段階へ進めるためプロジェクトマネージャに権限が委譲されます。

段階のコントロール

ここまでは、プロジェクトの計画及び管理に使用される文書(マネジメント成果物とし呼ばれる)が作成されます。ここでは、「専門的な」製品、例えばベネフィット実現に向け顧客が使用する成果物の受け渡し、などの納品を始める時です。この段階計画書では、成果物を設計、開発、試験するための作業(ワークパッケージ)を特定します。

このような専門的な作業はチームによって行われ、チームマネージャに作業を委任するのはプロジェクトマネージャの責任です。チームマネージャは報告書によってプロジェクトマネージャに進捗を報告します。プロジェクトマネージャはあらゆる課題及びリスクを管理下に置き、自らの権限を越えるものについては上位管理者の処理事項とされます。これら全てがこの段階で起こり、全ての通常マネジメントがカバーされています。プロジェクトマネージャは、定期的に段階の進捗をプロジェクト委員会に報告します。

段階がプロジェクト委員会によって割り当てられた許容度の範囲内にある場合、プロジェクトマネージャは許容度踰越の恐れを上位管理者に報告する必要はありません。しかしながら、許容度踰越が予測される場合、十分な情報に基づいて決定を下すことができるよう、プロジェクト委員会への報告のために例外報告書が作成されます。

成果物納品の管理

このプロセスはチームマネージャによって行われ、全ての専門的作業がサプライヤチームによって行われます。ここでは、ソフトウェアプロジェクトを例にとると、SCRUMやエクストリーム・プログラミングなどの専門的なソフトウェア開発手法が用いられます。プロセスのどこかの時点でチームが成果物をユーザに納品すると、品質管理が行われ、顧客によって承認されます。

段階境界のマネジメント

段階が終了する直前に、プロジェクトマネージャは次の段階計画を準備し、ビジネスケースとプロジェクト計画を更新し、リスク状況に関する見直しを行わなければなりません。現在のステータスをまとめた報告書が、プロジェクト委員会のために準備されます。プロジェクト委員会は報告書を踏まえ、プロジェクト継続の可否について決定を下すことができます。次の段階へ進む、との決定が下された場合、「段階のコントロール」プロセスの引き金となります。この一連の流れは、続く各段階で繰り返されます。

プロジェクトの終了

最終段階の終了時、あるいはプロジェクト委員会が時期を早めてプロジェクト終了を決定した場合、プロジェクトを終了しなければなりません。このプロセスは、プロジェクト活動及びそれに続く運営と、通常業務との間の明確な区切りをつけるために設計されました。ここでは、必要な受け入れ基準を満たしていることを条件として、特定の成果物が運用チーム及びサポートチームに受け渡されます。

やり残した事項を全て完成させ、担当部署へ引き渡します。納品物、コスト、タイムスケール、課題の影響、変更及びリスクを含むプロジェクトの達成事項の概要が、報告書としてプロジェクト委員会に提示されます。報告書には、プロジェクトからの教訓、後続プロジェクトチームへの受け渡しの準備が整っているか、が要約されています。成果物がユーザによって受け取られ、プロジェクトでこれ以上取り組むべき事項がないと満たされている場合、プロジェクト委員会はプロジェクトの終了を許可することができます。