プロジェクトマネジャーに贈るプロセス改善事例 第2回「完ぺきな」プロジェクト計画書に潜む失敗の落とし穴

プロジェクトの開始直前、予定していたエンジニアがアサインできない事態に遭遇した経験はないだろうか。今回は、実態に合わないプロジェクト計画が原因でプロジェクトの失敗を招いたY社の改善事例を紹介する。

[堀江弘志，豆蔵]

　プロジェクトを開始するとき、多くのプロジェクトマネジャーはプロジェクトを計画し、その成果物として「プロジェクト計画書」を作成する。しかし会社や対象部門、プロジェクトなどによって、計画の進め方、計画書の形式や内容はさまざまであり、実態に合わない計画を立てたことが原因でプロジェクトが失敗してしまうこともある。

プロジェクト計画書は「絵に描いたもち」？

　Y社は官公庁など公共機関のシステム構築を得意とするシステム開発会社である。大規模プロジェクトを扱うことが多いため、プロジェクトマネジメントを重要視しており、社内でマネジメントプロセスの標準化がなされている。

　2007年、Y社はある地方自治体の工事管理システムを受注し、同様のシステム開発経験を持つA氏をプロジェクトマネジャーに任命した。A氏は顧客が作成した提案依頼書などを基にプロジェクト計画書を作成し、社内と顧客の承認を得て無事プロジェクトをスタートさせた。

　ところが、1カ月もたたないうちにプロジェクトは迷走を始めた。

• 計画していた主要メンバーが社内の別プロジェクトに引き抜かれ、アサインできなかった
• 計画段階では見えていなかったステークホルダーが存在し、仕様の決定に時間を要した

など、プロジェクトの実行に影響を及ぼす問題が立て続けに発生したのだ。

　さらに、この後も計画段階では予期しなかったさまざまな問題に直面。結局、このプロジェクトは当初の計画よりも3カ月の稼働遅延、50％のコスト超過となり、社内では“失敗プロジェクト”と評価されてしまった。

　プロジェクトはなぜ失敗したのか。A氏が実施した計画プロセスは社内のマネジメントプロセスに従って進められており、プロジェクト計画書もひな型を利用して作成した。また、100ページに及ぶプロジェクト計画書は社内上層部や顧客の承認も得ており、手続き上でも何ら問題はないように思われた。

　しかし、発生した問題の中には計画段階で把握していれば回避できたものも含まれていた。A氏が作成したプロジェクト計画書の内容は、書式などの体裁には問題がなかったが中身を伴ったものではなく、実効性の低いものであったことが分かった。

関連ホワイトペーパー

運用管理 | プロジェクトマネジメント | リスクマネジメント | 工事進行基準 | システム構築