技術プロジェクトが失敗する7つの理由7 Real Reasons Why Tech Projects Fail

by Al Lee-Bourke

失敗とは何を意味するでしょうか。目標の未達成、中断、不実行など、様々な状況が考えられますが、一般には目標に対する成果との関連性に着目されます。しかしながら、目標は常に変動します。目標は事前に設定されたり、途中で変更されたり、成果に基づいて修正されたり、あるいは、目標を構成する要素の重要度が変化することがあります。この目標の持つ柔軟性は、技術プロジェクトの目標を適宜調整し、多くの技術プロジェクトにおける成功を保証します。

技術プロジェクトの失敗と成功


失敗を「目標と主な結果」(Objectives from Key Results)という観点から見てみましょう。別名をOKRアプローチと呼びます。古くからよく知られているOKRの例として、10年以内に人を月に送るというものがあります。

このプロジェクトはいくつかの失敗を経験し、途中で3人の宇宙飛行士が亡くなるなど6つの事故も発生しました。プロジェクトの目標は一般的に達成されたと言えますが、その過程で失敗もありました。成功への途上で起きた大きな6つの失敗を考えると、プロジェクト全体を成功と見なすべきかどうか疑問が生じます。しかし、失敗よりもプロジェクトの目標が優先されました。冷戦や当時の国際情勢の中で、人命よりも全体的な目標が優先されたのです。このケースは、予め決められた優先順位が調整された典型的な例です。優先順位によって、どんな技術プロジェクトもほぼ成功すると言えます。

この状況は、ルイス・キャロルの名言を思い起こさせます。

目的地が決まっていないのであれば、どんな道でもあなたを目的地に導くだろう

成功を定義しようと模索して進んだ道は大抵、成功への道となり、その他多くの道は成功への道ではなかったと言えます。私たちは、技術プロジェクトの失敗をより深く掘り下げる必要があります。

技術プロジェクトが失敗する7つの主な理由と、チェンジマネジメントの観点でどのように対処したらよいのかについて見てみましょう。

1. 定義が不十分なプロジェクト


当たり前すぎて驚くかもしれませんが、一般的には「なぜ」が欠如していることが非常に多いです。OKRを設定したら、Prosci®の4Pエクササイズを使って、「なぜこれをやるのか?」「なぜ今やるのか?」「やらなかったらどうなるのか?」を考えましょう。時間はかかりますが、これらに焦点を合わせることは重要であり、その価値は十分にあります。

2. リーダーシップの欠如


技術プロジェクトはしばしば「ITプロジェクト」と見なされIT部門の管轄下に置かれますが、それは誤った判断です。ITプロジェクトはビジネスプロジェクトです。技術プロジェクトが成功するには、積極的で目に見える強いスポンサーシップが必要であり、スポンサーからの積極的なコミュニケーションや、スポンサー同士の連携が不可欠です。そして、スポンサーを支援するために、組織内の各ビジネス部門のリーダーも積極的で目に見える活動をする必要があります。技術プロジェクトは単なるITプロジェクトではありません。

3. 説明責任の欠如


これは2番目の理由と関連しています。技術プロジェクトがITプロジェクトと見なされると、IT部門以外での説明責任が軽視されがちです。しかし繰り返しますが、人々に影響を与えるITプロジェクトは会社にとってのビジネスプロジェクトです。従って、成功にはしっかりとしたチェンジマネジメントが不可欠です。投資利益率(ROI)は主に3つの領域で見ることを思い出しましょう。導入のスピード、最終的な使用度合い、習熟度です。これらは人々に影響を与えるプロジェクト全てに当てはまります。従って、プロジェクトを成功させるには、人々を導き、ADKAR Modelの行程を進めるようにしなければならないのです。

4. 効果のないコミュニケーション


チェンジマネジメントにおいてもコミュニケーションは重要です。通常の技術プロジェクトのコミュニケーションとチェンジマネジメントのコミュニケーションの最大の違いは、チェンジマネジメントの場合、まず聞き手を特定してからメッセージの内容を考えることです。これは、Prosciのチェンジマネジメントの5つの教義に合致します。組織の変革は、それを構成する一人ひとりが変革に関与し、受け入れ、活用していく決断をした延長線上に起きるのです。

また、ジョン・コッタ―氏の発言も心に留めておくと良いでしょう。

もし将来の見通しを5分以内に説明しても、相手が理解した様子や興味を示さなければ、あなたのメッセージは伝わっていないということです

Prosciの調査結果から導き出されたコミュニケーションのポイントについて以下に示します。

  • さまざまな方法を試すこと。バーチャルを含め、面と向かったコミュニケーションも必ず行うことが重要です。
  • 一人の社員にとって変革がどのような意味を持つのかを説明するのは、その社員の直属の上司や監督者が適任です。
  • シニアビジネスリーダーは、常に変革のビジネス上の理由を発信するべきです。信頼できる送り手からの発信が望ましいです。メッセージはオープンで透明性があり、5回から7回繰り返すことが重要です。

5. 計画やスケジュールの不備


チェンジマネジメントにおける重要なポイントはここにあります。プロジェクトが人々の行動に依存する場合、ビジネス上のベネフィットを実感できる時期はいつになるでしょうか。通常、稼働時にベネフィットを実感できることを目標としますので、人々はその段階でADKAR Modelの「Ability(能力)」段階に到達している必要があります。この時点で人々は、「早くこの新しいものを試してみたい。稼働日が楽しみだ。私にとって役に立つはずだ。私は変革の必要性を認知し、参加したい欲求がある。知識も備えたし、その能力もある」と感じるでしょう。つまり、Ability(能力)の段階に到達することで初めてビジネス上のベネフィットを実感できるようになります。

6. ユーザーテストやフィードバックの不足


チェンジマネジメントの観点から言えば、ADKAR Modelの要素のうち、エンドユーザーのDesire(欲求)に焦点を当てるべきです。例えば、どんなに最先端のテクノロジーを備えた格好いいクルマでも、工場から出てきた時点で誰もそれを受け入れて運転したいと思わなければ、クルマよりも自転車をみんなに与えた方がよほど意味があるということです。

7. 対処すべき問題が見当違い


時に企業は問題に対処してるつもりでも、実際には見当違いな問題に対処している場合があります。そのため、最初の段階で「何のためにこれを行うのか」という問いかけや、ADKARに集中することが重要です。特にDesire(欲求)の要素が重要です。あなたの組織の現場では何が問題とされていますか。あなたが解決すべき問題は何ですか。

進歩するとは変化すること


技術プロジェクトの25%は開始と同時に失敗し、20%から50%はROIを得られず、50%は終了後に大幅な修正を求められると言われています。しかし、目標に柔軟性を持たせ、優先順位を修正したりし、上記の要素を正しく備えさせれば、どのような技術プロジェクトも成功に導くことができます。最後に、サミュエル・ベケット氏の名言を紹介します。

挑戦し続けよう。失敗し続けよう。そして次はもっとうまく失敗しよう


著者:アル・リーバーク (Al Lee-Bourke)
アル・リーバークは、マイクロソフト社のAdoption and Change Management Global Practiceの元プリンシパル・コンサルタントです。スコットランドのグラスゴー近くに本拠地を構え、Prosciの方法論を駆使してITの生産性向上や重要なテクノロジーの受入れと使用を促進し、リーダーやチームのコーチングなど多岐にわたる支援実績を持っています。アルは、Prosciの認定上級インストラクターであり、チェンジマネジメント専門家のスコットランド支部長も務めています。さらに、彼は積極的なユーチューバーであり、著書も2冊あります。「Change Management Field Guide: How it works & tips for doing it」「What They Don’t Teach You at Change Management School: From Theory to Practice and Everything in Between.」