電球を発明したトーマス・エジソンの名言に、こんなものがあります。「私は失敗なんてしたことはない。うまくいかない方法を一万通り発見しただけだ。」エジソンは電球を作ろうとして失敗するたびに、何がうまくいかなかったのか、次は何を試すべきなのか、新たな知識を学んでいたのです。
うまくいかないことを理解し、新しい何かに挑戦することは、プロセスを反復し、改善する上で重要です。そしてそれがまさに、プロジェクトプレモーテムの役割でもあります。プロジェクトのキックオフ前にチームでプレモーテムを行い、どんな問題が起こりうるか想像することで、実際にプロジェクトを実行する際に、何がうまくいき、何がうまくいかないのかという知識をもとに進めることができます。
(プロジェクトそのものを始める前の) プレモーテムでは、プロジェクトチームはプロジェクトの終わりを見据え、失敗した場合を想定します。失敗から逆算して考えることで、チームはプロジェクトのリスク、またプロジェクトが進む中でそういったリスクを回避する方法について理解を深めることができます。
プレモーテムは、プロジェクトマネージャーやスクラムマスターの主導で行われますが、そのプロセスにはプロジェクトチーム全員が参加します。プレモーテムでは視点が多様であるほど将来起こりうるリスクを特定しやすくなり、回避できる可能性も高まります。
プレモーテムという言葉を聞いたことがなくても心配要りません。プロジェクトチームではよく、プロジェクトの最後に「ポストモーテム」(振り返り) が行われますが、終わった後では遅すぎるという場合もあります。そこで「プレモーテム」を行えば、プロジェクトのリスクを前もって特定し、問題が発生する前に対処できるというものです。
「プレ」「ポスト」といった名前からも想像できるように、プレモーテムとポストモーテムはそれぞれプロジェクトの異なる時点で行われるものです。プレモーテムはプロジェクトの開始前に行われ、プロジェクトが失敗するリスクを事前に分析評価する機会として機能します。
一方ポストモーテムは、プロジェクトが終わった後に行われる分析です。特にスクラムを実行しているチームでは、「レトロスペクティブ」と呼ばれることもあります。プレモーテムとは違い、ポストモーテムは必ずしもプロジェクトの失敗について分析するものではありません。何らかの形でプロジェクトがうまくいかなかった場合に行われることが多いですが、プロジェクトチームのメンバーがプロジェクトから得た学びを共有する機会としてポストモーテムを行うこともできます。
スプリントの振り返り用無料テンプレートプレモーテムの目的は、プロジェクトのリスク管理プロセスの目的と似ています。どちらのプロセスもプロジェクトのリスクを前もって特定し、回避するのに役立つものですが、この 2 つのプロセスでは主にリスクの特定方法が大きく異なります。
プロジェクトのリスク管理プロセスでは、チームは「リスク登録簿」というものを使ってプロジェクトの潜在的なリスクを特定し、監視します。そうすることで特定したリスクが実際に問題として発生してしまっても、効率的かつ効果的に対処するための計画がすでに用意されている状態を作ることができます。
一方プレモーテムでは、プロジェクトが失敗してしまった場合を想定します。プレモーテムはリスクを特定・管理するというよりは、問題が実際に発生した場合を想定するプロセスです。後からあれこれ心配する必要もなくなるので、プレモーテムを行うことで精神的に安心できるメンバーもいるでしょう。さらにプロジェクトリーダーはプレモーテムで出てきた情報をもとにリスクを軽減したり、プロジェクトのリスク管理計画を立てることができます。
記事: リスクマネジメントの基本と 6 つのステップを徹底解説プレモーテムは他のリスク管理計画と同様、プロジェクトの失敗防止に役立つものです。プレモーテムの特徴は、すでに失敗が起こってしまったものとして想定し、その地点から逆算して分析するという点にあり、これにはいくつか明確なメリットがあります。
プレモーテムのメリットには、たとえばこんなものがあります。
「将来の後知恵」が得られる: 将来の後知恵とはつまり、「すでに起こってしまった状態」を想像することで得られる知恵です。調査によると、この方法で分析を行うことで起こりうる結果の原因を正しく特定できる能力が 30% もアップすると言われています。
自信過剰な状態を防げる: プロジェクトを成功させたいあまり、無意識のうちに偏見に支配され、リスクを無視してしまっていることがあります。たとえプロジェクトのリスク分析を行っていたとしても、これは誰にでも起こりうることです。プレモーテムではプロジェクトがすでに失敗した状態を想定するため、自信過剰にならずにブレインストーミングを行うことができます。
部門の異なるメンバーを集められる: プレモーテムには中心となるプロジェクトチームだけでなくさまざまな関係者が参加するため、新たな視点によって他の方法では特定できないような潜在的リスクに関する貴重な意見が得られます。
プロジェクトのリスクに関して共通認識が持てる: 一般的なリスク管理計画と同様、プレモーテムはプロジェクトの潜在的リスクを警告する役割を果たします。プレモーテムを行っておくことで、プロジェクトの進行中も障害となるものを認識しやすくなり、万が一リスクが現実となってもすばやく対応することができます。
プレモーテムを実践する際は、失敗した時点から逆算して考え、プロジェクト計画に潜むリスクを特定しましょう。リスクを特定できたら、それぞれのリスクが実際に起こる可能性や深刻度についてブレインストーミングを行います。そして最後のステップで、可能性や深刻度の高いリスクを防ぎます。
失敗した状況を想像する前に、まずはプロジェクトがどのように進むのか大まかに把握する必要があります。ここで役立つのがプロジェクト計画です。プロジェクト計画とは、チームがプロジェクトの中で達成すべき重要な要素をまとめた詳細な計画です。
プロジェクト計画は次の 7 つの要素で構成されています。
プレモーテムを行う前にプロジェクト計画を作成、チームと共有しましょう。起こりうる問題について考えるためには、具体的なプロジェクト計画を知る必要があります。プロジェクトの複雑さに応じて、プロジェクトロードマップやプロジェクト憲章、ビジネスケースを共有してもいいでしょう。
たとえば、これが Asana のマーケティングキャンペーンのプロジェクト計画です。
プレモーテルを計画する際は、プロジェクトが失敗しうる原因について意見のあるメンバーをすべて招待しましょう。これには中心となるプロジェクトチームだけではなく、他の部門のパートナーも含まれます。プロジェクトのスポンサーや経営陣は日々の仕事にはそれほど関心がないので、招待しなくても構いません。誰を招待すべきか考える際は RACI チャートを作成してみましょう。
先ほどのマーケティングキャンペーン計画の例では、関係者は以下のようになります。
マーケティングキャンペーンリーダー兼メールマーケティングマネージャーの Daniela
キャンペーンでコピーライターを担当する Kabir
キャンペーンでデザインリーダーを担当する Avery
キャンペーンで SNS マネージャーを担当する Blake
動画マネージャーの Kat
プロジェクト計画を共有し、関係者を特定したら、いよいよプレモーテムの実行に移ります。プレモーテム会議の最初のステップはブレインストーミングセッションで、大きく 2 つのパートに分けられます。
まず最初に、チームメンバーはそれぞれプロジェクトの潜在的なリスクについてブレインストーミングを行います。同じ部屋に集まって行っても、会議前の数日間で各自がそれぞれのタイミングで行う形でも構いません。他のチームメンバーの意見に引っ張られないように、必ずそれぞれのメンバーが別々にブレインストーミングを行うようにしましょう。出てきたアイデアの共有や比較は後で行います。
プロジェクトリーダーは、チームメンバーが安心して自分の意見をすべて共有できるような環境を作りましょう。リスクの中には個人的なものもありますが、そういったリスクを無視してしまうとプロジェクトの成功に悪影響を及ぼします。誰もが安心して意見を述べられるよう、意見共有の前にグループ規範を確立するのもおすすめです。
記事: 29 個のブレーンストーミングテクニック: 創造力を引き出す方法マーケティングキャンペーンチームの例では、こんなキャンペーン失敗原因が特定できます。
プロジェクト成果物が予定通りに完成しなかった。
プロジェクト成果物は予定通りに完成したが、誤植やグラフィックのミスがあった。
プロジェクトの予算を超えてしまった。
お客様からキャンペーンメッセージに関するネガティブなフィードバックがあり、それが悪い評判につながってしまった。
キャンペーン関連のランディングページがクラッシュしてリリースの週に利用できなくなってしまった。
ブランドキャンペーンのデザインスタイルが競合他社に真似されてしまった。
マーケティング予算の削減により、ブランドキャンペーンの成果物やスケジュールに影響が出てしまった。
クリエイティブ戦略がお客様の心に響かず、市場を逃し、ブランドの認知度や価値の低下につながってしまった。
成果物に関する関係者の認識にズレがあり、プロジェクトの過程でストレスがたまってしまった。
チームメンバーがそれぞれアイデアを書き出したら、次はグループで共有します。プロジェクトリーダーかチームの進行役が、唯一の情報源にアイデアをすべてまとめるようにしましょう。このプロセスでは、チームメンバーが失敗の可能性について議論し、そこから意見をまとめられるように、視覚的であるのが理想的です。ホワイトボードや複数人で使えるブレインストーミングツールを使って全員のアイデアを記録しましょう。
意見共有の準備が整ったら、各メンバー順番に意見を 1 つずつ共有してもらいましょう。一人のメンバーにすべてのプロジェクト失敗例を読ませるのではなく、1 つ共有したら次の人へ移るようにすることで、全員が発言の機会を得られます。チームメンバーには、何か重要なことを付け加えるのでない限り、同じ失敗例は挙げないように促しましょう。
無料のチームブレーンストーミング用テンプレートプレモーテムのブレインストーミングで出たプロジェクト失敗例がどれも実際に起こる可能性が高いものとは限りません。また、実際に起こってしまったとしても、プロジェクトの目標に影響するほど深刻な問題ではないかもしれません。プロジェクト失敗例の中には、起こる可能性がかなり低そうなものもあれば、プロジェクトが失敗するほど深刻でないものもあるでしょう。失敗例のリストを確認し、チームで協力して実際に起こる可能性の高いリスクや深刻度の高いリスクを特定しましょう。
最終的なリスクの数は、プロジェクトの規模やプロジェクトが与えるインパクトの大きさによって異なります。一般的には 10 個程度がよいとされていますが、状況に応じてもっと少なくしても、多くしても構いません。
マーケティングキャンペーンのプレモーテムでは、このように 5 つのリスクを特定できます。
可能性高: プロジェクト成果物が予定通りに完成しなかった。
可能性高: プロジェクトの予算を超えてしまった。
深刻度高: キャンペーン関連のランディングページがクラッシュしてリリースの週に利用できなくなってしまった。
深刻度高: クリエイティブ戦略がお客様の心に響かず、市場を逃し、ブランドの認知度や価値の低下につながってしまった。
解決しやすい問題: 成果物に関して関係者の認識にズレがあり、プロジェクトの過程でストレスがたまってしまった。
プレモーテム会議が終わったら、チームがブレインストーミングした内容をプロジェクト計画に反映させましょう。チームメンバーから挙がった失敗例を防ぐために、計画を補強できる点がないか探しましょう。この作業により、プロジェクトが始まる前からリスクを減らし、最終的な結果をよりよいものにすることができます。
大規模なプロジェクトに取り組んでいる場合は、可能性や深刻度の高い失敗例の一部をリスク登録簿へと移しましょう。そして、リスク軽減のために大きな変更や新しいツールの導入を行った場合は、プロジェクト計画の変更点を自分のチームや他部門のチーム、経営陣の関係者、プロジェクトスポンサーなどに伝えましょう。
マーケティングキャンペーンの例では、以下のようなリスク対処法が考えられます。
プロジェクト成果物が予定通りに完成しない可能性が大いに考えられます。このリスクを防ぐために、ガントチャートのようなツールを使ってタスクをタイムライン形式で可視化し、具体的な成果物やタスクの前後関係を明確にしましょう。また、プロジェクトの進捗状況を経営陣と共有するため、週に一度プロジェクトステータスレポートを送信しましょう。
プロジェクトの予算を超えてしまう可能性が大いに考えられます。このリスクを防ぐために、月に一度プロジェクトステータスレポートに予算の更新情報を記載し、プロジェクトスポンサーが更新情報を把握できるようにしましょう。プロジェクト開始前に予算を再設定して、万が一の事態に備えて予算に余裕を持たせておきましょう。
キャンペーンのランディングページがクラッシュした場合、ブランドキャンペーンの成功に深刻な影響を与えます。このリスクを防ぐために、リリースの前週にステージング環境でページを立ち上げ、正しく機能することを確認しましょう。
クリエイティブ戦略がお客様の心に響かなかった場合、市場の喪失やブランド認知度、ブランド価値の低下につながるため、ブランドキャンペーンの成功に深刻な影響を与えます。このリスクを防ぐために、製品マーケティングチームはプロジェクト計画やプロジェクトの要旨にペルソナ調査を盛り込み、全員が認識を共有できるようにしましょう。
成果物に関する認識にズレがあると、プロジェクトの過程でストレスがたまってしまう可能性があります。このリスクは、コミュニケーション計画とワークマネジメントツールのようなプロジェクトに関するすべての情報が一か所にまとまった唯一の情報源によって簡単に解決できます。
プレモーテムはプロジェクトが失敗する可能性の把握や、起こりうる問題の防止に役立ちます。プレモーテムが終わったら、後はプロジェクトを実行するのみです。プロジェクトを始めるにあたってのヒントや、プロジェクト管理のベストプラクティスについては、プロジェクト管理のリソースハブをご覧ください。