プロジェクトコストは、なぜ見積から乖離して大きくなるのか
itpjstudy
プロジェクトの遂行にあたっては、皆、オンスケジュール・オンバジェットを目指すと思います。しかし、スケジュールは守れても、予算通りに進むのはなかなか難しいことが多いです。そのため、どのプロジェクトでも、予備・バッファの予算を持っていることがほとんどです。
完璧な計画なんてありませんから、追加費用をゼロにすることは難しいかもしれませんが、最小化するための動きはするべきです。今回は、そんなお話です。
主な原因は、前フェーズにある
プロジェクト費用が、当初見積から乖離していく原因の多くは「やるべきことを、やるべきフェーズでしなかった」ことに起因します。
前フェーズからの持ち越し
例えば、設計課題がたくさんあり、設計作業が完全には終わっていないが、開発フェーズを見切り発車で始めてしまうことがあります。
その場合、そういった状態は、見積時には想定していませんでしたので、必ず、想定外の作業追加や手戻りが発生します。
数が少なければ、色々なやり繰りで、工数増加を吸収できることもあります。しかし、数が多くなると、吸収しきれず、後続の作業に影響を出すことになります。
プロジェクト期間を守るために、全量の設計が終わっていないうちに、開発に入るケースはよくあります。しかし、その場合は、たいてい費用は増加すると考えておいた方がよいです。
前フェーズの詰めが甘い
これもよくある例です。対向先システムとやり取りして、インタフェース仕様を確認したが、確認の仕方が甘く、仕様齟齬や漏れが残ったまま、テストに入ってしまうケースです。
この場合も、仕様齟齬・漏れの対応のため、設計書やプログラムの修正、テストのやり直しといった追加工数が掛ります。
こちらは、想定していない問題の発生ですので、事前にやり繰りをして、工数増を吸収することはできません。もちろん、テストフェーズは、そういった見落としを検知するためのフェーズですので、一定量の問題は、事前に工数として積まれています。
しかし、こちらも、その数が多くなれば、吸収することができず、費用増加は避けられなくなります。
そもそも見積前提に誤り・認識齟齬がある
上記でお話したのは、見積は正しかったが、プロジェクトでの作業遂行に問題があったケースです。
しかし、そもそも見積前提に誤りや認識齟齬があるケースも、少なからずあります。
見積前提に誤りがある
例えば、システム導入対象拠点を4法人としていたが、うち1法人は、2つの大きく異なる事業部に分かれていた。そのため、見積前提としては、実質5法人と考えるべきであった、というようなケースです。
そもそも見積が間違っていたということなので、プロジェクトが始まってしまってからでは、打ち手が限られます。
プロジェクト予算について、役員会で承認を取る前までに気付いておきたいです。以前、「プロ路ジェクト見積」について取り上げた6回シリーズがありますので、見積金額に大きく影響しそうな要素をきちんと押さえて、見積・見積精査を行ってください。
タスク内容や役割分担の想定が異なっていた
他に多いものとしては、タスクの内容や役割分担について、認識齟齬があるケースです。
ユーザ企業とITパートナで折半して、追加費用を緩和する方法もありますが、費用が追加になることには変わりません。こちらも、ユーザ企業とITパートナが契約締結する前に、見つけておきたいです。
このように、見積と実費用の乖離を防いでいくためには、
- やるべきことを、やるべきタイミングで、適切にやり切ること
- そもそも見積時に、漏れや齟齬が無いように、関係者で確認すること
が重要です。
しかし、プロジェクトを進めるのは、人間ですから、完璧ということはありません。そのため、乖離が生じることを前提とした動きが必要になってきます。
節目節目で見積を確認する
それには、見積との乖離が発生しているだろうという前提で、節目節目に見積を取り直して確認することが有効です。
その時点で判明している限りの情報をもとに、見積し直すことによって、どれくらいの費用追加があるのかが分かります。それだけでなく、前フェーズで何が漏れていたのかや、何の見積前提に齟齬があったのかを確認する契機にもなります。
見積しなおしのタイミングで、契約交渉もできるようにしておく
実は、この漏れや齟齬を確認する行為が非常に重要で、その後のプロジェクト運営を改善する大切なインプットになります。そういう意味では、見積しなおすタイミングで、契約期間も切っておくことがお勧めです。
契約交渉のタイミングは、色々なことを見直し、申し入れる良い機会です。そのため、契約交渉のタイミングを、あえて設けておくことが有効です。
問題は早めに解消しておくに限る
なお、よく言われていることですが、問題対応は、遅れれば遅れるほど、対応が大変になります。
上記は、倉庫システムとのインタフェース仕様に漏れがあって、ERP側のインタフェースを修正するケースです。
設計フェーズで対応すれば、ERP側のインタフェースだけの修正で済みます。しかし、開発フェーズでの対応となると、倉庫システム側の複数のインタフェースも修正しなくてはならなくなります。さらに、テストフェーズでの対応では、インタフェースの修正に加えて、テストシナリオの流し直しも必要になってくることがあります。
後続フェーズは、前方系のフェーズの成果を前提に、作業が進んでいきます。そのため、フェーズが進めば進むほど、対応の手間も大きくなってしまいます。
そういう意味でも、節目節目で、その時点で判明している問題にきちんと向き合って、対処していくことが重要です。
本当に突発的な出来事もある
ここまで、プロジェクトとして、問題をなるべく早期に発見して、見積と実費用の乖離を小さくしていくお話をしてきました。しかし、なかには、本当に予期せぬ、突発的な出来事も起こります。
例えば、急にM&Aで傘下に入った子会社も、色々な事情で、新システムの導入対象にしなければいけなくなるケースなどです。
プロジェクトの範疇外で起きる出来事ですので、どうしようもありません。もちろん、ユーザ企業とITパートナのマネジメント同士のコミュニケーションで、多少の情報共有は可能かもしれません。ただ、守秘義務の関係もあり、現場レベルを巻き込んだ動きにするのは非常に難しいです。
そのような場合は、すみやかに緊急対策会議を持ち、粛々と対応するしかありません。
もちろん、当初スケジュールや当初予算が膨らまないように、なるべく努力することは必要です。しかし、無理は禁物です。サラリーマンの心情として、なんとかしようと思う人も多いのですが、当初スコープの作業が台無しになっては意味がありません。
突発的な、予期せぬ出来事ですので、きちんとマネジメントに報告をして、適切な追加予算と期間を確保することが大切です。
その都度その都度、しっかりタスクを遂行してきたつもりでも、漏れやミスがあるのが、人間です。見積と実費用の乖離についても同じです。見積自体に問題があることもありますし、その後のタスクの進め方が良くなくて、費用が増加することもあります。
どういった原因で、費用が増えがちなのかを理解するとともに、節目節目で乖離を点検する仕掛けを事前に設けておくことが肝要です。
最後まで読んで頂き、ありがとうございました。ご意見・ご感想を頂けますと幸いです。
ITプロジェクト研究会
