さて、それではプロジェクトを失敗させないために、このユーザー企業側のプロジェクトマネージャは、どのような対処をすべきだったろうか? 以下が想定できる。

  1. 今回の仕様変更が開発工程に与える影響を速やかに分析するために、開発会社へ提供できるような資料を、何とか経理システム担当者をつかまえて入手し、開発会社へ提供し、仕様変更の影響分析内容を聴取する
  2. 開発会社から報告を受けたリスケジュール案を自社内で協議し、システムの納期の延長や、仕様変更部分の段階的リリースなど対策案を検討する。また、リスケジュールが難しい場合は予算増額による開発会社の増員要請を行うなどの代替案を提示する
  3. 上記ユーザー企業側からの要望/協議の経緯を開発会社に伝え、対応を依頼する

このケースの場合、納期(D)と予算(C)を変更せずに開発受託会社側に仕様変更を呑ませることに執着するばかりに、本来の目的であるプロジェクトを成功させるという点が疎かになってしまっているのである。もちろん、このようなケースのしわ寄せは、仮に開発会社に白旗が揚がらなくても、品質(Q)の悪化という形で、マイナスの影響を及ぼす確率が高くなることは言うまでもない。

開発ベンダに無理な納期や予算を押し付ける前に、まずはシステムに関係するステークホルダーに対して予算やシステムリリース時期の交渉をして安全なプロジェクト管理を志向するほうがプロジェクトを成功させる…これが本来の目的を達成するために必要な行為だという認識が、残念ながら、このユーザー企業のプロジェクトマネージャに足りなかったのである。

何よりもこの開発受託会社は、プロジェクト成功のためには、対等のパートナーであり、相互に利益を享受可能な関係(WIN-WINの関係)を築くことが、重要であるということに気付くべきだった。

ただ、このような失敗も、前掲の当社フレームワークで言えば、スコープ管理、進捗・スケジュール管理、予算・実績管理、リスク・課題管理、コミュニケーション管理といったところに深く関連しており、体系立てた管理手法と、ツールがあれば、経験の浅いプロジェクト管理者であっても、回避可能と考えている。以降では、その一端を、ご説明したい。