プロジェクト・マネジメント-プロジェクトの始動

プロジェクトの始動

プロジェクトの始動プロセスの目的は、「このプロジェクトは実行可能で、利益をもたらすものか」という問いに答えることによって、プロジェクトの立ち上げのための必須条件が確立されていることを確認する。 プロジェクトを開始する決定は明確に行われる必要があります。プロジェクトの始動プロセスで行う活動はこの決定の前に行われるためです。プロジェクトを委託する合理的な判断を下すために必要な基本情報を明確に定義し、主要な役割と責任を割り当て、詳細な計画立案のための基盤を整備するまでは、いかなる作業も開始すべきではありません。 プロジェクトの始動プロセスの目的は、十分に吟味されていないアイデアの立ち上げを防ぎ、実行可能なプロジェクトを承認に向けて進行することにあります。(そのため、プロジェクトの始動プロセスは、詳細かつ綿密なプロジェクトの立ち上げプロセスに比ベると簡略的なプロセスです。)主な狙いは、プロジェクトを立ち上げる価値が本当にあるのかどうかを判断するために、最低限の活動を行うことにあります。

プロジェクトの始動プロセスの達成目標は、次の点を確認する。 * プロジェクトを立ち上げるビジネス正当性があること(ビジネス・ケース概要で文書化)。 * プロジェクトを開始するために必要な権限がすべて存在すること(例: 人のアサインやリソースの確保)。 * プロジェクト・スコープを定義、確認するために十分な情報が(プロジェクト要約書の形式で)用意されていること。 * 代替のアプローチが評価され、選択されたプロジェクト・アプローチが合意されていること。 * 立ち上げステージに必要な作業を行う者、プロジェクト中にプロジェクト・マネジメントの重要な役割を担う者のいずれかが任命されていること。 * 立ち上げステージ(ステージ計画書で文書化)に必要な作業計画が策定されていること。 * プロジェクト・スコープ、期間、受け入れ基準、制約条件について、曖昧な前提に基づきプロジェクトを立ち上げ、時間を無駄にしないこと。

プロジェクトはさまざまな方法でトリガ一できるため、正式に開始される前に利用できる情報にはさまざまなバリエーションがあります。プロジェクトのトリガーをプロジェクト権限委任と呼んでいます。これは、プロジェクトを委託しているビジネスの責任権限者によって提供されます。責任権限者が生まれる可能性のある領域もさまざまです。(例えば、プロジェクト・エグゼクティブ・グループ、機能単位または運用単位、プログラム、ポートフォリオ、顧客などです。) 責任権限者はビジネス・レイヤーのプロジェクトの外部にあると見なされます。「プロジェクト権限委任」という用語は、実行可能性調査やサプライヤー環境での提案依頼書の受領など、プロジェクトのトリガーに使用されるあらゆる情報に適用されます。プロジェクト権限委任には、プロジェクトの委任事項に加え、少なくともプロジェクト委員会のプロジェクト・エグゼクティブ候補者を特定するために十分な情報が提供される必要があります。プロジェクト権限委任の情報は詳細化され、プロジェクト要約書としてまとめられます。 プロジェクト委員会には、プロジェクト立ち上げの決定を下すための十分な情報が提供される必要があります。これを目的としてプロジェクト要約書が作成されます。 プロジェクトの始動プロセスにかかる労力は、プロジェクトによって大きく異なる場合があります。プロジェクトがプログラムのー環として実施される場合、プログラム・マネジメント・チームがプロジェクト要約書を提供し、プロジェクト委員会のー部または全メンバーを任命します。(これにより、このプロセスで求められる作業の大半が省かれます。このようなケースでは、プロジェクト・マネージャーはプログラムが提供するものを確認し、必要に応じて修正を提案します。) ビジネス・ケース概要の準備と、プロジェクト要約書をまとめる活動は、並行して反復的に行います。プロジェクト・マネージャーやプロジェクト委員会などの利害関係者間で、定期的かつ頻繁なやり取りを行う必要があります。プロジェクトの始動プロセスに多くの時間を確保し、要件事項を明確に把握することにより、プロジェクトの立ち上げとデリバリーでの課題、例外、計画見直しが避けられ、大幅な時間の節約につながります。

活動

インプット	活動	アウトプット
プロジェクト権限委任(このプロセスのトリガー) 前回の教訓報告書(レビュー)	プロジェクト・エグゼクティブとプロジェクト・マネージャーの任命	デイリー・ログ(作成)
プロジェクト権限委任(このプロセスのトリガー) 前回の教訓報告書(レビュー)	前回の教訓の評価	教訓ログ(作成)
プロジェクト権限委任(このプロセスのトリガー) 前回の教訓報告書(レビュー)	ビジネス・ケース概要の準備	プロジェクト成果物記述書(作成) ビジネス・ケース概要(作成)
プロジェクト権限委任(このプロセスのトリガー) 前回の教訓報告書(レビュー)	プロジェクト・マネジメント・チームの任命	プロジェクト要約書(作成)
プロジェクト権限委任(このプロセスのトリガー) 前回の教訓報告書(レビュー)	プロジェクト・アプローチの選択	プロジェクト要約書(作成)
プロジェクト権限委任(このプロセスのトリガー) 前回の教訓報告書(レビュー)	プロジェクト要約書のとりまとめ	プロジェクト要約書(作成)
プロジェクト権限委任(このプロセスのトリガー) 前回の教訓報告書(レビュー)	立ち上げステージの計画	ステージ計画書(立ち上げステージ用に作成)
プロジェクト権限委任(このプロセスのトリガー) 前回の教訓報告書(レビュー)	プロジェクトの立ち上げ要求	プロジェクト立ち上げの要求(プロジェクトの指揮プロセスをトリガー)

プロジェクト・エグゼクティブとプロジェクト・マネージャーの任命

プロジェクトで物事を進めるには、ビジネスの各利害関係者の関心を代表する、適切な権限を持った意思決定者(プロジェクト・エグゼクティブ)が必要です。プロジェクト・エグゼクティブの任命は、プロジェクトの正当性を確保するうえで必須条件です。 プロジェクト・マネージャーを任命することによって、プロジエクト・エグゼクティブに代わってプロジェクト・マネージャーが日々プロジェクトをマネジメントできるようになります。(プロジェクト・エグゼクティブがプロジェクト・マネージャーを任命する際は、ビジネスと協議し、合意を得る必要がある場合があります。) 推奨される処置 - ビジネスはプロジェクト権限委任をレビューし、理解を確認し、曖昧さを明確にする。 - ビジネスはプロジェクト・エグゼクティブを特定、選択、任命する。 - プロジェクト・エグゼクティブはプロジェクト・マネージャーを特定、選択、任命する。 - プロジェクト・マネージャーはプロジェクト情報のリポジトリとしてデイリー・ログを作成する。

前回の教訓の評価

(数多くの教訓が、ビジネスや外部組織の他のプロジェクトにより明らかになっている場合があります。)教訓には、プロセスの弱点または強み、使用された手順、技法、ツール、使用されたタイミング、使用方法、使用者などが含まれます。過去のプロジェクトからの教訓は、プロジェクト・マネジメント・チーム編成、ビジネス・ケース概要、プロジェクト要約書の内容、立ち上げステージのステージ計画書で活用できます。 関連する教訓を把握する手段として、ワークショップの開催が役立つ場合があります。ワークショップの参加者には、このプロジェクトの関係者や、過去の類似するプロジェクトの関係者を含めることもできます。ビジネスにこのプロジェクトと同種のプロジェクト経験がない場合は、関連する経験のある組織外の人員を含めることも有効です。 プロジェクト・マネージャーに推奨される処置 - 過去の類似するビジネス組織および外部組織のプロジェクトの関連する教訓をレビューし、今回のプロジェクトに適用できる教訓を特定する(例えば、監査とプロジェクト・レビューの結果などが当てはまる)。 - 類似したプロジェクトの経験を持つ個人やチームと協議する。 - 必要に応じて教訓ログを作成し、特定した教訓や関連する措置を記録する。

ビジネス・ケース概要の準備

この時点で利用できる情報量を考えると、ビジネス・ケース概要は概観に過ぎません。(ビジネス・ケース概要は、プロジェクトの立ち上げプロセスにおいて、より詳細にビジネス・ケースを作成する際の合意形成基盤となります。) 推奨される処置 - プロジェクト・エグゼクティブは、プロジェクト権限委任に従い、プロジェクトに関する現在の情報に基づいてビジネス・ケース概要を作成する。ビジネス・ケース概要の作成は、この時点でシニア・ユーザーが任命されている場合、シニア・ユーザーと協議の下で行う。シニア・ユーザーは、プロジェクトがビジネス目標にどのように貢献するかを理解する必要がある。 - プロジェクト・マネージャーはシニア・ユーザー、シニア・サプライヤー、プロジェクト・エグゼクティブと協議のうえ、プロジェクトの成果物を定義し、プロジェクト成果物記述書を作成する - デイリー・ログに記録されたリスクをレビューし、プロジェクトの実行可能性を左右する主要リスクをビジネス・ケース概要にまとめる。

プロジェクト・マネジメント・チームの任命

プロジェクトで迅速に決定を下すには、ふさわしい権限、責任、知識を持つ人員の配置が不可欠です。プロジェクト・マネジメント・チームには、ビジネス、ユーザー、サプライヤーの利益を含め、全関係者の利益を反映させる必要があります。上記の権限、責任、知識に加えて、関係者が協力してパフォーマンスの高いチームを結成できることが重要です。 プロジェクトを安定して進行させるためには、誰が何の説明責任を誰に対して負うのか、誰が何の実行責任を負うのか、また報告およびコミュニケーション系統について、プロジェクト・マネジメントに関わる全員が理解し、合意することが不可欠です。 推奨される処置 - プロジェクト・マネージャーは教訓ログを確認して、プロジェクト・マネジメント・チーム組織を設計し、役割記述書を準備する。 - プロジェクト・エグゼクティブは、シニア・ユーザーおよびプロジェクト・マネージャーと協議の下、プロジェクト・マネジメント・チームを特定、選択、任命する。 - プロジェクト・マネージャーは、立ち上げステージのチームの作業プラクティスとコミュニケーションに合意し、リスクが特定された場合はそのリスクをプロジェクト・ログに追加する。

プロジェクト・アプローチの選択

プロジェクトの計画立案を開始する前に、プロジェクト作業にアプローチする方法について疑問点を挙げる。 * ソリューション開発を社内で行うか、第三者に委託するか(デリバリー・モデルとも呼ばれる) * 既存の成果物を修正するか、ゼロから構築するか * 商業的オフザシェルフの成果物(既製品または COTS 成果物とも呼ばれる)を基盤とするか、特注とするか * どのデリバリー手法を使用するか、例えば、プロジェクト成果物はアジャイルな作業方法を使用して段階的に提供することができるのか、それとも直線的で連続的な方法で提供する必要があるのか * プロジェクト・アプローチは、持続可能性に関する期待や要件をどのように支援するか 業務の実施方法は、ユーザーまたはサプライヤーの標準、プラクティス、ガイドラインに左右されます(例えば、特定のデリバリー手法を採用する場合もあります)。これらの基準はプロジェクトの立ち上げプロセスで策定されるマネジメント・アプローチに影響を与えるため、プロジェクト・アプローチの一環としてプロジェクト要約書に盛り込む必要があります。こうした側面を捉えることは、ユーザーとサプライヤーがプロジェクト・アプローチを確実に理解し、何らかの形でプロジェクトを脅かすことを防ぐうえでも役立ちます。 プロジェクト・マネージャーに推奨される処置 * デリバリー・ソリューション案を評価し、プロジェクト成果物のデリバリーとビジネス・ケース概要の実現において最適なプロジェクト・アプローチを判断する。 * 現時点で判明している場合、方法をテーラリングする要件を定義する。 * 新たな課題またはリスクがあれば、プロジェクト・ログに記録する。

プロジェクト要約書のとりまとめ

合意されたプロジェクト要約書によって、共通の理解に基づきプロジェクトの開始点を明確に定義できます。 プロジェクト・マネージャーに推奨される処置 * プロジェクトの現在のステータスを確認する。 * 例えば、プロジェクトの背景やこれまでに実施された準備作業など。 * 達成目標と望ましい成果を確認する。 * プロジェクト・スコープ、除外項目、プロジェクト許容度を確認する。 * 制約条件と前提条件を特定する。 * ユーザーを含む既知の関係者を特定する。 * プロジェクト・マネジメント・チーム組織と役割記述書をレビューして、プロジェクト・エコシステムに必要な追加の役割またはスキルを特定する。 * 必要に応じて役割記述書を追加で作成する。 * プロジェクトが維持する必要がある他のプロジェクトまたは活動との依存関係を特定する。 * 上記をプロジェクト要約書に文書化する。 * 新たな課題またはリスクがあれば、プロジェクト・ログに記録する。

立ち上げステージの計画

プロジェクトの立ち上げには時間とリソースが必要です。狙いがないまま、整理されていない状態でプロジェクトの立ち上げに至らないよう、作業を計画し、承認を得る必要があります。(プロジェクトがプログラムの一環として実施される場合、立ち上げステージの終了日はプログラムの計画で定義されている日付と照らし合わせて確認する必要があります。立ち上げステージのステージ計画書も、プログラムからの要件に関して、プログラム・マネジメント・チームへの注意を促すものになります。) 立ち上げステージは、プロジェクトの始動プロセスのー環と見なす必要があります。(例えば、プロジェクトによってはプロジェクトの立ち上げプロセスの中で、ステージのコントロールと成果物デリバリーのマネジメント・プロセスを適用する場合があります。) プロジェクト・マネージャーに推奨される処置 * プロジェクト・アプローチに基づいて、立ち上げステージの活動に適したマネジメント・コントロールを決定する。 * 立ち上げステージにおける時間とコストの制約条件を特定し、原則と技法に基づいて、このステージのステージ計画書を作成する。 * プロジェクト・ログに記録されたリスクをレビューし、立ち上げステージのステージ計画書に及ぼすインパクトを評価する。新たなリスクが特定された(または既存のリスクに変化が生じた)場合は、プロジェクト・ログを更新する。

プロジェクトの立ち上げ要求

プロジェクトの始動プロセスを終了するために、プロジェクト・マネージャーはプロジェクト委員会に連絡してプロジェクト立ち上げを要求します。ビジネス・ケース概要とプロジェクト要約書の正式な正当性がプロジェクト委員会に提示されます。 推奨される処置 * ビジネス・ケース概要、プロジェクト成果物、プロジェクト・アプローチ、プロジェクト・マネジメント・チームの任命、立ち上げステージの活動とコントロールについてプロジェクト委員会に説明する。 * 必要な人員とリソースを確保するために、プロジェクトを開始する権限をプロジェクト委員会に正式に要求する。

適用

一般的な考慮事項

このプロセスの活動は、状況に合わせて結合したり、分割したり、同時に実行したりできますが、プロジェクトの立ち上げ要求時に、プロジェクトの指揮プロセスとの関連の完全性を確保することに配慮します。 (プロジェクト・ライフサイクルのこの時点では、プロジェクトの作成によるアウトプットが必すしも明確ではない場合があります。そのような場合、少なくともどのビジネス上の問題を解決するか、またはどのような成果が求められるかを明確にしておきます。) 提案されたアプローチへの理解と賛同を高めるために、ビジネス・ケース概要、プロジェクト要約書、立ち上げステージ計画書を将来のユーザーや利害関係者と共創することの価値を考慮する。

役割のテーラリング

(このプロセスのできるだけ早い段階でプロジェクト・マネージャーを任命することがグッド・プラクティスですが、プロセスの後半までプロジェクト・マネージャーが任命されていない場合は、プロジェクト・エグゼクティブまたはプロジェクト・エグゼクティブによって任命された人が必要なマネジメント成果物を作成しても構いません。同様に、プロジェクト・エグゼクティブはビジネス・ケース概要を自ら作成する必要はなく、代わりに別の担当者に作成を依頼できます。各役割の義務に対する説明責任の一元化は維持されます。)

責任

活動	ビジネス・レイヤー	プロジェクト・エグゼクティブ	シニア・ユーザー	シニア・サプライヤー	プロジェクト・マネージャー	チーム・マネージャー	プロジェクト保証	プロジェクト支援
プロジェクト・エグゼクティブとプロジェクト・マネージャーの任命	A/R¹	R
前回の教訓の評価	C	A			R
ビジネス・ケース概要の準備	C	A/R	C³	C³	R
プロジェクト・マネジメント・チームの任命	A	R
プロジェクト・アプローチの選択		A	C	C	R	C²	C
プロジェクト要約書のとりまとめ		A	C	C	R		C	C
立ち上げステージの計画		A	C	C	R	I²	C	C
プロジェクトの立ち上げ要求		A	C	C	R	I²	C	I

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

• A/R¹: ビジネスは、プロジェクト・エグゼクティブとプロジェクト・マネージャーの任命に説明責任を負います。また、ビジネスはプロジェクト・エグゼクティブを任命する実行責任があります。
• C²/I²: プロジェクト・マネジメント・チームを設計および任命するときにチーム・マネージャーが特定された場合、チーム・マネージャーがそのステージに関与しているのであれば、プロジェクト・アプローチについて協議し、立ち上げステージのステージ計画書の重要な詳細を通知することがグッド・プラクティスです。
• C³: 任命された場合

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

プラクティス	プロジェクトの始動プロセスへの適用
ビジネス・ケース	ビジネス・ケースは、プロジェクト権限委任と学んだ教訓から得られた理解と、ビジネスおよび将来のユーザーとの協議に基づいて、アウトラインとして作成されるとともにプロジェクト要約書の一部を形成します
組織化	プロジェクト・エグゼクティブとプロジェクト・マネージャーはビジネスによって任命され、プロジェクトに必要なプロジェクト・マネジメント・チーム組織を判断し、プロジェクト立ち上げに必要な役割に人を任命します
計画	この早い段階で判明している主要なマイルストーンは、プロジェクト要約書に組み込まれます。 プロジェクト・エグゼクティブとプロジェクト・マネージャーは、このプロセスの後に使用されるプロジェクト・アプローチを開発し、デリバリー手法とプロジェクト計画書を決めます。ステージの数はこの時点で特定される場合があり、プロジェクト・アプローチで記録される場合もあります。 プロジェクト・マネージャーは、プロジェクトを正常に開始するために必要な成果物と作業、およびステージの期間とコストを詳述した立ち上げステージのステージ計画書を作成します
品質	ユーザーの期待品質と、この早い段階で判明している仕様や標準は、プロジェクト成果物記述書に組み込まれ、記録されます。ユーザーの期待品質は、このプロセスの後、プロジェクトの立ち上げ時や、個々の成果物記述書の開発を通じて各ステージを計画立案するときにさらに洗練されます
リスク	高いレベルのリスクが捕捉され、プロジェクト要約書に組み込まれます
課題	上位レベルの課題が補足され、プロジェクト要約書に組み込まれます
進捗	プロジェクトの既知の許容度が特定され、プロジェクト要約書に組み込まれますプロジェクトの既知の許容度はこのプロセスの後に洗練され、承認されます。 立ち上げステージの許容度が特定され、承認のためのステージ計画書に組み込まれます