失敗する理由はだいたい同じ。プロジェクトが失敗しやすい5つのパターン

2019年11月7日 14:25

世の中にはたくさんのプロジェクトが存在します。それらのプロジェクトを成功に導くために私たちプロジェクトマネージャー（PM）がいますが、残念なことに、そのすべてが成功するわけではありません。

私はこれまで15年以上プロジェクトマネジメントに携わってきました。最近では、「プロジェクトの立て直し依頼」の相談を受けて、途中からプロジェクトに関わることも増えています。その中で、プロジェクトが傾きかけている原因を探っていくと、だいたいが同じ理由で失敗に向かってしまっています。

今回は、プロジェクトが失敗しがちなパターンをまとめてみました。

①作業工数に対する見積もりが甘い（きちんと要件定義をしないまま受注する）

本来は、きちんと要件定義をして正確な見積もりを出してから受注すべきです。しかし、中には要件定義をする前に「◯億円で大丈夫だろう」「このくらいもらっておけば十分だろう」と、まるっと受けてしまっているケースがあります。
この場合は制作に入る前に要件定義をするわけですが、「要件定義をしてみたら、想定の数倍の工数がかかることが判明した」「それによってスケジュールが大幅に遅れることがわかった」なんてことが起こります。

クライアントは当然ながら、その金額でスケジュール通りに完成するものだと思って発注しているわけですから、間違いなくクライアントとの間に問題が発生します。きちんと要件定義をしないまま受注するのは危険です。

②技術的リスクに対する見積もりが甘い

最近では、「◯◯の導入を支援します」など、ソリューションベンダーとしてツールやパッケージ製品を導入するサービスを提供している企業が多いですが、技術に対するリスクを甘く考えているケースが多くみられます。
本当に得意な領域の製品だけを扱えればいいのですが、クライアントの要望によっては扱ったことのない製品を扱う必要が出てきたり、日本の製品だけではなく海外製品も扱うことになったりします。

その場合、「製品を入れてみたら動かなかった」「サポートに問い合わせているものの、なかなか返事がもらえない」という問題が発生します。安易な受注は、自らのクビを締めることになります。

③PMが網羅的な計画を立てられていない

PMの仕事の中で最も大事なことは、段取りをつけることです。つまり、作業計画を立てるとういことです。誰がいつまでに何をすべきかを、ハイレベルに、その後、詳細なＷＢＳとして落とし込むことが重要です。
ここで、アプリケーション部分だけでなく、インフラや業務、場合によっては移行など網羅的なカテゴリで作業を立てること、またそれぞれの論理的な依存関係をきちんと整理することが重要になります。
これがないプロジェクトは、プロジェクトが進むたびにどんどん想定しないタスクが増えて、メンバーが疲弊して失敗することになります。

④PMがやるべき管理をしていない

ＰＭがすべきことをしておらず失敗するプロジェクトによくありがちなのが、「内部の定例会議がない」「定例会議があっても何を確認して何を管理するのか決まっていない」というケース。
まずは、コミュニケーションの場として定例会議は必ず設ける。そして、アジェンダを決めて会議を進め、進捗報告をしてもらって、その進捗を報告書にまとめる。そこで、課題が見つかれば課題管理表に、新たにTODOが発生したらTODO管理表に反映する。このような基本的なことをおろそかにしていくと、プロジェクトは失敗へと向かいます。

⑤クライアント（発注側）の意思決定体制が整っていない

実は、プロジェクトが失敗するのにはクライアント側に要因があることもあります。

古い体質の残る日本企業にありがちなのが、意思決定体制が整っていないために何も決まらず一向に進まないプロジェクトです。これには、自分ひとりで責任を取りたくないがために意思決定がなされないというパターンもあれば、会議でおおよそ決まったのに最終の決議は「上の者に確認します」となってしまう本当の責任者がいつも不在というパターンもあります。
いくらベンダーやPMが素晴らしくても、最終決定するクライアントがこのような体制では、うまく進むはずがありません。

もう一つクライアント側に要因があるパターンとして、そもそも確固たる意志やビジョンがないことがあります。
「どのような目的で」「誰のために」「何を」というプロジェクトの軸となるべき内容が固まっていなかったり、そもそもなかったりする場合、何を基準に決定していけば良いかわからず、常に決定軸がブレてしまいます。また、軸がなければ決まるものも決まらず、延々と会議を繰り返すことになります。
どうにかしてプロジェクトが進んでいって完了したとしても、軸が定まっていないプロジェクトですから使われないサービスになることが多く、最終的には失敗プロジェクトになるでしょう。

いかがでしたでしょうか。
今回紹介した5つは、高確率で失敗するパターンです。
多くの人、時間、お金を使ってプロジェクトを進めていくのですから、失敗は出来るだけ避けたいもの。失敗パターンを知って、それを回避するプロジェクト推進をしていきましょう。