システムやパッケージ開発の環境は平成になってから格段に進化し、プロジェクトを成功させるための知見の共有も進んだはずなのに、残念なから「失敗プロジェクト」はまだ存在します。

ITプロジェクトが失敗するのは、なぜなのか。この深遠なテーマについて、ありがちなパターンを検証し、今後の改善に活かせればと考える次第であります。

失敗パターンのなかで最もタチが悪いのが、「ゴール＝成功が定義されていない」プロジェクトの存在です。

「〇〇を開発する」「×月×日までに納品する」だけでは、ゴールといえません。「いつまでに何を、どのくらいの費用でどこまで開発・製造し、どんな成果を得る」といったレベルまで具体化する必要があります。

とりわけ重要なのは、「成果の明確化」です。プロジェクトを推進した結果、何が実現するのかを数値で評価できるレベルに落とし込まなければ、予算や開発方法が妥当かどうかを判断できなくなります。

判断できなければ、失敗したプロジェクトのなかには、「そもそも失敗かどうかもよくわからない」ものが多々あるということになります。

一方、わかりやすい2大失敗パターンは、「予算オーバー」「納期遅れ」でしょう。

一般論でいえば、いずれもプロジェクト計画書の精度が高ければ起こらないはずです。「最初にきちんとプランを立てて明文化し、その通りやりましょう」と言って終わらせることもできるのですが、それでは不十分です。

失敗しないためのポイントを具体的にいうと、「計画書に必要な要素が網羅されているか」「計画のどこかに“顧客頼み”“顧客のせい”で入れている要素はないか」をチェックすべし、となります。

計画書に盛り込むべき項目は、「プロジェクトの目的」「ゴールヴィジョン」「スケジュール（全体、フェーズ単位）」「コスト（全体、明細）」「タスク」「体制と進め方」「リスクと対策方法」です。失敗するプロジェクトでありがちなのが、各チームの役割と責任の所在が曖昧になっているケースや、リスクマネジメントがなされていないプランです。

フェーズとタスクを切り分けた際に、それぞれについて誰が管理・判断するのかが明確でなければ、「指示がなかったからやらなかった」「このままで問題ないと思っていた」などといった言い訳が多発するプロジェクトになるでしょう。

想定されるリスクと解決策が明示されていないプロジェクトは、トラブルの発生が予算や納期の見直しに直結してしまう可能性が高くなります。

「ITプロジェクトの失敗・ありがちパターンと処方箋」後編では顧客とのリレーションやコミュニケーションが原因となる失敗パターンについて解説します。

【関連書籍PR】
グループ会社「株式会社インフィニットコンサルティング」の社員が書いた、開発プロジェクトを成功に導くノウハウ本：『システム発注から導入までを成功させる90の鉄則』に関する詳細情報はこちらのページ でご確認いただけます。

「システム企画」や「提案依頼書の作成」「ベンダー選定」「プロジェクト推進」の方法を、実際の現場レベルで使える形で説明している本です。