プロジェクト開始文書

プロジェクトドキュメント( PID ) は、プロジェクト管理における最も重要な成果物の 1 つであり、ビジネス プロジェクトの基盤を提供します。

プロジェクト開始ドキュメントには、 PRINCE2で管理されたプロジェクト環境でのプロジェクトの開始(SU) プロセスとプロジェクトの開始 (IP) プロセスを通じて取得された情報がまとめられています。PRINCE2 の 2009 年の「ドキュメント」から「ドキュメンテーション」への名称変更は、システム内のすべての情報ではなく、プロジェクトの作成中に収集されたドキュメントのコレクションを示しています。^{[誰によると? ]}

プロジェクト開始ドキュメントは、顧客とプロジェクト チームの両方にとって、プロジェクト全体にわたる参照ポイントとなります。

プロジェクト開始文書には、多くの場合、次の内容が含まれます。

• プロジェクトの目標
• 範囲
• プロジェクト組織
• ビジネスケース
• 制約
• ステークホルダー
• リスク
• プロジェクト管理
• 報告フレームワーク
• PID サインオフ
• まとめ

プロジェクト開始ドキュメントの代わりにプロジェクト憲章を作成することもできます。この 2 つのドキュメント タイプは非常に似ています。ただし、プロジェクト憲章は詳細度が低いため、コンテンツ作成者があまりいない場合に適しています。

プロジェクト開始文書は、プロジェクト管理におけるアプローチ計画を表すPRINCE2 ^[1]用語です。これは、ビジネスケース、業務委託条件、コミュニケーション計画、リスク登録簿、プロジェクト許容範囲、プロジェクト計画、および部門品質計画または共通プロジェクトアプローチの一部としての特定のプロジェクト管理または検査を含む一連の他の文書から構成されます。プロジェクト開始文書は、プロジェクト概要と呼ばれる基本的なプロジェクト開始文書の詳細版を表します。

プロジェクト開始文書は、プロジェクトを健全な基盤で開始および実行するために必要なすべての重要な情報をまとめた論理的な文書を形成するために文書をまとめたものです。これはすべての利害関係者に伝えられ、ビジネス スポンサーによって承認および承認される必要があります。つまり、これはプロジェクトの「誰が、なぜ、何を」の部分です。これはプロジェクトのすべての主要な側面を定義し、プロジェクトの管理と全体的な成功の評価の基礎を形成します。プロジェクト開始文書は、開始活動中に生成された情報と分析データを使用して、ビジネス ケース (存在する場合) に基づいて作成されます。^[2]

PRINCE2 ^[3]などの正式なプロジェクト方法論の共通部分であるこの文書は、プロジェクト (IP) プロセスの開始における主要なマイルストーンです。プロジェクト開始の承認を得るために プロジェクト委員会に提出される文書です。

プロジェクト開始ドキュメントは、顧客とプロジェクト チームの両方にとって、プロジェクト全体にわたる参照ポイントとなります。

プロジェクト開始文書の目的は、プロジェクトを正しく定義し、計画するために必要な重要な情報を収集して記録することです。プロジェクト開始文書は、プロジェクトの権限を拡張し、プロジェクトの目的と達成計画、およびこれらの目的を達成することの重要性の理由を述べる必要があります。また、プロジェクト開発に最初から最後まで参加している人々のリストと、その役割と責任も含まれています。プロジェクト開始文書には、プロジェクト開始文書がプロジェクト委員会によって承認された日付も含まれています。プロジェクト開始文書は、プロジェクトの段階では定期的に更新されません。必要な改訂や更新は、次のステップの詳細なマイルストーンを組み込むために、各段階の最後に行われます。プロジェクト開始文書は、プロジェクトのために下された決定の基礎であり、後の段階で、理由、担当者、時期について言及せずに文書に質問したり変更したりしても役に立ちません。^[4]

プロジェクト スコープ ステートメントは、プロジェクト開始文書の最も重要なセクションの 1 つです。プロジェクト スコープ ステートメントは、プロジェクト スコープ ステートメント、提案されたソリューション、プロジェクトの範囲内の 3 つの部分に分かれています。これは、プロジェクトが利害関係者と顧客に提供するものを詳細に説明するプロジェクト開始文書の一部です。提案されたソリューションでは、プロジェクトが環境と社会にどのような革新、変更、側面をもたらすか、また、どのような変更と更新を引き起こすかを説明します。プロジェクト スコープ ステートメントには、プロジェクトのライフサイクルで問題や疑問が急増するのを防ぐのに役立つため、できるだけ多くの詳細を含める必要があります (範囲内のカテゴリで成功するには要件が必要です)。範囲内のフェーズでは、プロジェクト マネージャーが財務面とプロジェクトの費用を決定するのに役立ちます。 ^[5]

プロジェクトの背景は、プロジェクトがなぜ、どのように作成されたかを示します。プロジェクトのフェーズ 1 では、必要なオンライン機能と、影響を受ける必要なビジネス システムの変更が提供され、フェーズ 2 では、デジタル著作権管理とリアルタイム広告挿入が提供されます。プロジェクト参加で中心的な役割を果たした人物は、プロジェクト開始文書のこのセクションで言及する必要があります。これは、チームの最もアクティブな候補者の参加を強調することで、特定のプロジェクトを他のプロジェクトよりも優先させる合理的な方法です。これは、会社内の重要な人物がそれを見たいからです。その結果、リソースと機器が利用可能になり、プロジェクトを確実に実行できるようになります。^[6]

プロジェクト開始文書には、前提条件、依存関係、制約が詳細に記述されています。これらの詳細は、プロジェクト管理要件とビジネス要件仕様が文書化される前に想定されています。プロジェクト開始文書のプロジェクト制約は、リソースや競合相手（他のプロジェクトなど）が利用できないなどの外部の影響を特定します。^[7]

組織化段階を完了するには、チームは組織図を完成させる必要があります。プロジェクトは、開発、インタラクティブ、テスト、ネットワーク、インフラストラクチャ、ビジネスシステム、セキュリティ、マーケティングなど、複数の部門の経験豊富な代表者で構成される部門横断的なチームによって達成される場合があります。さまざまな分野の関与は、初期プロジェクトの進行に応じて変化します。^[8]主要な調査結果と進展は、SMG（上級管理グループ）に通知されます。^[9]

プロジェクト開始文書を作成するプロセス全体を通して、プロジェクトマネージャーは、サードパーティのプロジェクトマネージャー、リードアーキテクト、チームリーダーとの会議に出席し、プロジェクト管理レポート、毎週のプロジェクトチーム会議、2週間ごとのサプライヤー会議、毎週のプログラム委員会会議について話し合うことを認識しています。^[10]

プロジェクト品質計画は通常、IT 品質保証 (ITQA) によって作成され、プロジェクトの一部として提供される側面 (ベースライン プロジェクト計画、ビジネス要件(BRS)、ユース ケース、高レベル設計(HLD)、ソフトウェア要件仕様(SRS)、テスト スクリプト、テスト レポート、開発後レビュー(PDR)、プロジェクト品質計画の段階的評価) を特定します。ITQA は、最終段階評価(ESA) をいつ実施するかも決定します。これらは基本的に、プロジェクトの期間中にチェックポイントとなり、品質の高い製品が提供されるようにします。ESA は、ベースライン プロジェクト計画が最新かつスケジュールどおりであることを確認する会議、プロジェクト管理レポート、プロジェクト ワークストリーム チェックポイント レポート、チーム会議の議事録、アクションとアジェンダ、プロジェクトのリスクと問題のログ、品質計画のヒントを意味します。^[11]

プロジェクト開始文書の初期計画書を書くことは、提案された日付と詳細段階を適切に再検討することを意味します。多くの場合、ビジネス関係者はプロジェクトを不可能な日付に納品するよう要求するため、その事実を強調する必要があります。その場合、ほとんどの関係者は柔軟に対応し、開始日を再検討するか、範囲を縮小しようとしています。開始日の再設定または範囲の縮小には、開始日を延期するという決定を下す関係者の正当な理由が必要です。関係者とそのような関係を築き始めるのが早ければ早いほど、後で範囲に関するより差し迫った懸念が生じたときに、より簡単に対処できます。^[12]

プロジェクト全体の管理という観点から、完了する必要のあるセクションがいくつかあり、プロジェクト管理、プロジェクト ステージ、例外プロセスなどがあります。これらには、各会計期間に作成された予算実績と予測、企業プログラム マネージャーにエスカレーションされる例外、品質計画からの製品レビュー、プロジェクト許容範囲、リスク軽減計画、プロジェクト リスクの特定とその軽減計画、問題ログ、既存の変更管理プロセス、企業プログラム ボード向けの週次ハイライト レポート、週次サプライヤー ミーティング、週次プロジェクト チーム ミーティングなどが含まれます。

ルール^{[明確化が必要]}によれば、コミットする内容が多ければ多いほど、より多くの成果物を提供する必要がある。プロジェクトの段階は、開始、要件、設計、開発、テスト、プロジェクトの開始、例外プロセス ステージで終了する。最後の段階は最も不安定で、プロジェクトを例外に移行させずに予算、時間、プロジェクト範囲をどれだけ増やすことができるかが問題となる。利害関係者がプロジェクトを例外に移行することを決定した場合、例外前に使用されていたプロジェクト/ステージ プランのバージョンに代わる詳細な例外プランを導入する必要がある。そして、このすべての追加書類に加えて、プロジェクト マネージャーはプロジェクトを前進させ、チームのモチベーションを維持する必要もある。プロジェクト開始文書が正式に承認されると、例外に移行する前に利用できる追加の予備手段があることを意味する。これは、成長中のビジネスで成功するために良いキャッシュ フローが鍵となるのと同じように、プロジェクトの成功に大きな違いをもたらす可能性がある。^[13]

ボームは、リスク管理段階を6つに分類しました。それは、特定、評価、優先順位付け、管理計画、解決、監視であり、これらはプロジェクト開始文書で実施されます。^[14]

プロジェクト開始文書の作成の最後の段階は承認です。これは、プロジェクト開始文書内の配布リストに記載されているすべての利害関係者と、リソースの運用や人事などのその他の利害関係者に、コメントを求める電子メールで配布することを意味します。次に、チームのリーダーがコメントを収集し、その後、利害関係者と利害関係者がプロジェクト開始文書についてさらに詳細に話し合う最終会議が続きます。これらの段階が完了した後にのみ、プロジェクト開始文書は承認され、資金提供のためにプログラム委員会に渡されるのに十分な基準になります。プロジェクトの複雑さと規模に応じて、段階は5回の非公式レビューと4回の公式レビューで完了します。リソース不足や資金不足などの問題が発生する可能性があります。プロジェクト開始文書を開始する前に、プロジェクトの優先順位を特定することが極めて重要です。これにより、プロジェクトが例外段階に陥ろうとしている場合に、多額の費用を回避するのに役立ちます。^[15]

プロジェクトの重要性を特定し、^{[説明が必要]}プロジェクト開始文書は、それがプロジェクト管理者とスポンサーの間の契約であることを確認します。プロジェクト開始文書の目的は、プロジェクトの前提を理解することです。プロジェクト開始文書の正しい形式は、背景、目的、利点の理解を表します。優れたプロジェクトマネージャーは、顧客に成果物や機能を提供することに関心があるだけでなく、より広いコンテキストと、この機能が最終的にもたらす利点に関心があります。プロジェクト開始文書は、フロー図と製品ブレークダウン構造を使用して、プロジェクトの範囲内で何が実行されるかを特定します。極めて重要な役割を果たすのは責任の特定であり、これにはプロジェクトマネージャー、チームリーダー、スポンサー、サプライヤー、ユーザー代表、利害関係者、運営委員会のメンバーの役割が含まれます。^[16]

プロジェクトを開始し、プロジェクト開始文書を作成する前に、検討する必要がある重要な側面がいくつかあります。たとえば、プロジェクトはどのように実施されるか、どのようなタイプのアプローチか、さまざまな手法 (ウォーターフォール、アジャイル手法など)、リスク、問題、変更を把握しながら利害関係者とどのようなコミュニケーションをとるかなどです。

プロジェクト開始文書の場合、プロジェクトの主なフェーズとアクティビティを強調する場所を含めるだけで十分です。

プロジェクト開始文書とプロジェクト全体の成功は、プロジェクトの視覚的な記憶を促進する方法として、グラフィックなどの視覚的な側面に基づいて構築されます。

リスクは、プロジェクト全体の中で問題として現れる前に特定する必要があります。この問題は、主要なプロジェクトのリスクのリストを作成し、どのような予防措置を講じる必要があるかを示すことで解決できます。

プロジェクトの財務面を考慮する必要があります。プロジェクト開始の文書化スキームには、予算上の制約事項を含める必要があり、チームが見積りの際に使用した前提と、見積りのレビュー頻度に関する詳細も記載する必要があります。重要な側面は、スペルや専門用語などの間違いの原因となる可能性があるため、孤立させないようにする必要があります。

プロジェクト開始文書を改善するために、主要なポイントを特定し強調したプレゼンテーションを作成することができます。^[16]

• ビジネスケース
• プリンス2
• プロジェクト管理
• プロジェクト計画