なぜほとんどのプロジェクトは始まる前に失敗するのか
プロジェクトの失敗は、後から振り返ってもほとんどの場合、突然起きたものではありません。根本原因は、ほぼ常に当初の計画、または計画が存在しなかったことに表れています。スコープ・ステートメントのない、日付だけが付いたタスクリスト。依存関係を把握する前に作られたタイムライン。RACIで責任を明確にしないままチーム全体に分散された責任。一度キックオフミーティングで話し合われただけで、記録されなかったリスク。これらは実行の失敗ではありません。計画の失敗であり、その負担を実行が引き受けることになるのです。
プロジェクトの失敗に関する調査では、一貫して同じ原因が特定されています。要件を際限なく拡大させる不明確なスコープ、全体の作業量を理解せずに作られた非現実的なスケジュール、曖昧な責任分担によって生じる抜け漏れや重複、予見可能だったにもかかわらず軽減されなかったリスクです。これらはいずれも実行の問題ではなく、計画の問題です - そして、開始時に適切なフレームワークを適用すれば、それぞれ防止できます。
Paul - KissMySkillsのプロジェクト管理agentは、1回のヒアリングセッションでこのフレームワークを適用します。出力されるのは、経験豊富なプロジェクトマネージャーが適用する方法論に基づいて構築された完全なプロジェクト計画です。明確な除外事項を含むスコープ・ステートメント、ワーク・ブレークダウン・ストラクチャー、クリティカルパス上のマイルストーン・タイムライン、RACIマトリクス、軽減策を含むリスク登録簿、ステークホルダー・コミュニケーション計画が含まれます。1つのタスクが始まる前に、プロジェクトの開始時点で作成されます。
Paulは、スコープ・ステートメント、ワーク・ブレークダウン・ストラクチャー、RACIマトリクス、クリティカルパスのタイムライン、リスク登録簿を作成します - 1回のセッションで完全なプロジェクト計画を作成できます。
Paulを見る →完全なプロジェクト計画に実際に含まれるもの
「プロジェクト計画」と呼ばれる文書の多くは、日付と最上部の名前が付いたタスクリストにすぎません。完全なプロジェクト計画には、タスクリスト方式では省略される6つの構成要素があります - それぞれが異なる失敗モードに対処します。
何がスコープに含まれ、そして同じくらい重要なことに、何が明確にスコープ外であるかを定義するスコープ・ステートメント。明確な除外事項がなければ、スコープは、個別には妥当でも全体としてはスケジュールを破綻させるステークホルダーの要望によって、利用可能な時間と予算をすべて埋めるまで拡大します。
プロジェクトの成果物をワークストリームに分解し、さらにタスクへと分解して、すべての作業に担当者と規模が割り当てられるまで細分化するワーク・ブレークダウン・ストラクチャー。WBSは、主要なマイルストーンの間に埋もれているため、常に過小見積もりされる作業を可視化するツールです - 統合テスト、承認プロセス、ドキュメント作成、トレーニング、移行作業などが含まれます。
マイルストーンタイムライン。クリティカルパス、つまり遅延するとプロジェクトの終了日も遅れるタスクの連続に基づいて作成します。多くのプロジェクトのタイムラインは、作業全体のどの経路が本当にクリティカルなのかを特定せず、希望する終了日から逆算して作成されています。クリティカルでないタスクが遅れれば問題になります。クリティカルパス上のタスクが遅れれば、プロジェクト全体が遅れます。
RACIマトリクス。重要な各成果物について、Responsible（実行責任者）、Accountable（説明責任者）、Consulted（協議先）、Informed（報告先）の役割を割り当てます。実行開始前に責任の所在を明確にするツールです。これにより、4週目になって、2人が互いに相手が担当だと思っていたため、誰も完了していない成果物があることに気づく事態を防げます。
リスク登録簿。特定されたリスクを記録し、その発生可能性と影響度を評価し、軽減策を割り当て、プロジェクト期間を通じて各リスクを監視する担当者を決めます。
ステークホルダーコミュニケーション計画。誰が、どのような更新情報を、どの頻度で受け取るのかを定めます。これにより、ステークホルダーがプロジェクトの状況を突然知らされることはなくなり、プロジェクトマネージャーが重要な会議に向けた準備済みの報告を用意できない事態も防げます。
タイムラインより先にスコープを定める：プロジェクト管理で最も守られていないルール
明確なスコープなしに作成されたタイムラインは、タイムラインではありません。それは、精度があるように見せかけた見積もりです。プロジェクトが期限に間に合わない最も一般的な理由は、チームの実行力不足ではありません。全体のスコープを把握する前、すべての依存関係を特定する前、あるいは初期要件に現れない作業を明らかにする質問を誰もしていない段階で、タイムラインを作成してしまうことです。
Paulは、タイムラインを作成する前に、成果物、依存関係、制約、明示的な対象外事項について確認します。最初に作成するのはスコープ記述書であり、単一のマイルストーン日も設定する前に、内容を確認して合意します。スコープクリープは、始まってから管理するよりも、未然に防ぐ方がはるかに容易です。また、スコープ記述書に明示された対象外事項があることで、新しい依頼が来たときに、プロジェクトマネージャーは「それはスコープ外です」と言う権限を持てます。対象外事項を文書化していなければ、「それは簡単そうなので、追加できますか」という会話のたびに交渉が必要になります。
RACI：責任の分散を防ぐツール
責任の分散は、プロジェクト管理における傍観者効果に相当します。成果物に複数の人が関わっているにもかかわらず、明確な担当者が決まっていないと、それぞれが誰か別の人が対応していると思い込みます。その結果、成果物は誰にとっても問題ではないまま、全員の問題になるまで放置されます。そして発見が遅れ、対応を急がされ、チームのせいにされるのです。
RACIマトリックスは、実行開始前に責任の所在を明確にすることで、これを防ぎます。Responsibleは作業を行う人です。Accountableは結果に対して責任を負う、指名された唯一の人です - 1人しか置けません。Consultedは意見を求める必要がある人々です。Informedは状況を知る必要がある人々です。Paulは、プロジェクト内のすべてのワークストリームにわたる重要な成果物ごとにRACIを作成し、役割を持つすべてのステークホルダーを網羅します。
RACIは、プロジェクトのキックオフミーティングで確認することを前提に設計されています - 非同期レビュー用の文書として送るのではなく、チームで話し合い、一人ひとりが自分の役割を確認し、説明責任を理解し、プロジェクト開始前に懸念を提起できるようにします。キックオフで見つかったRACIの矛盾は、解決に5分しかかかりません。プロジェクト途中で見つかった矛盾は、解決に数週間かかります。
リスクが顕在化する前に作成するリスク登録簿
リスク登録簿を作成する最適なタイミングは、チームの意識が将来を見据え、まだ選択肢が開かれているプロジェクト開始時です。開始時に特定されたリスクは緩和できます。リスクが実際に発生している段階で特定しても、管理することしかできません - 選択肢は狭まり、コストは高くなり、タイムラインへの影響は悪化します。
Paulは、特定したリスク、発生可能性と影響度の評価（High/Medium/Low）、各リスクに対する具体的な緩和策、そしてプロジェクトのライフサイクル全体を通じて各リスクを監視する担当者の氏名を含むリスク登録簿を作成します。特定されるリスクには、主要なリソースの確保や第三者の依存関係による遅延といった明白なものだけでなく、経験上、この種のプロジェクトで最も一般的だと考えられるカテゴリ固有のリスクも含まれます。
すでに問題を抱えているプロジェクト向け
Paulは新しいプロジェクトを計画するだけでなく、問題を抱えたプロジェクトの診断と立て直しも行います。予定より遅れている、予算を超過している、またはスコープが制御不能に拡大しているプロジェクトでは、intake questionsによって根本原因が明らかになります。それは、当初のスコープが不明確だったこと、非現実的なスケジュール、責任の所在が曖昧だったこと、または緩和策が用意されないまま顕在化したリスクです。リカバリープランは、残りのスケジュールを単に圧縮するのではなく、実際の原因に対処します - 根本的に欠陥のある計画にスケジュール短縮を適用しても、同じ失敗の別バージョンが生まれるだけだからです。
Paulでプロジェクト計画セッションを始める方法
PaulのスキルファイルをClaude Projectsに読み込ませます。activation promptを貼り付けます。Paulは、プロジェクトの目標、成果物、期限、チーム構成、既知の依存関係、制約についてintake questionsを行います。具体的に回答してください - 実際のプロジェクトについて提供する詳細が多いほど、計画の精度が高まります。セッション全体で、30分以内に完全なプロジェクト計画が作成されます。PaulはClaude、ChatGPT、またはsystem promptsを受け付けるあらゆるAIチャットで動作します。
