当初計画のコスト、スケジュール、スコープをほぼ予定通りに満たしたシステム開発プロジェクトは30％程度といわれる。これを成功とすれば、約70％のプロジェクトが失敗していることになる。読者の多くも何らかの形で失敗プロジェクトを経験されたのではないだろうか。
まれにプロジェクトの中止というドラスティックな決断がなされる場合もあるが、たいていの場合、コスト、スケジュール、スコープのいずれかを調整、あるいは複数の調整を組み合わせてリカバリーをしようとする。立て直しを図るタイミングやその時の状況によって打ち手は異なるが、どのような方法を採るにしても簡単にはいかないものである。
一般にユーザー側が最も嫌がるリカバリー方法は、別途予算を確保して追加でコストを支払うことである。仮にユーザー側のPM（プロジェクトマネジャー）が「コスト追加やむなし」と考えたとしても、経営層や上長が首を縦に振ってくれることはほとんどない。「コストだけは守れ」と厳しく叱責されるのがオチである。
従ってユーザー側のリカバリー案は、スケジュールとスコープで調整したものになる。具体的には、「コストの追加は無理だから、システムの本番稼働を3カ月延期し、一部の機能は2次フェーズに回す」といった内容になる。
しかし、開発者側であるベンダーの立場からすると、スケジュールの延期はコストの持ち出しを意味する。3カ月の延長となればその間のエンジニアの人件費を負担しなければならず、売り上げは増えないので赤字プロジェクトへの道をまっしぐらとなる。計画通りにプロジェクトが終了することを見込んで他のプロジェクトにエンジニアをアサインする予定を組んでいる場合、そのプロジェクトにも悪影響を及ぼしてしまう。
ベンダーとしてはスコープを大幅に削って何とか当初スケジュール内に収めるか、あるいは何としても追加予算を出してほしいと粘ることになる。
-
ベンダー「追加予算を何とか」
ユーザー「これ以上は出せない」
ベンダー「そこを何とか」
ユーザー「稼働は遅れていいから」
ベンダー「そもそも原因は…」
ユーザー「今さらそれを言うか！」
ただでさえプロジェクトの失敗で重苦しい雰囲気が漂っている中で、こんな議論を繰り返しても不毛である。
この議論に決着をつけるのは、結局コストしかない。予算に関する最終権限を持っている人同士が話し合わないと解決しない。だからプロジェクトオーナーやステアリングコミッティーをプロジェクトに巻き込んでおくことが重要なのだ。賢明なコスト決裁者同士が話し合えば、双方痛み分けとなるかもしれないが、妥協点を見つけることができるはずだ。
ユーザーが一方的に請負契約書などを盾にベンダーに負担を押し付ければ、品質や稼働後の運用でしっぺ返しを食らうかもしれない。逆にベンダーが「ここまで作ったのだから今さら中止にできないだろう」と脅したならば、仮にそこで追加予算を獲得したとしても、中長期的には顧客を失うことになるだろう。
