No.124: 見積りのベースラインを定めているか
prjmc staff
プロジェクトが失敗、混乱する原因の大きなものの一つとして見積り誤りがあります。このプロジェクトに必要な人数はどれくらいか、必要となる作業は何か、そしてそれらに要する期間はどれくらい必要か。これらの見通しに誤りがあれば、プロジェクトが成功する確率は明らかに低いものとなるでしょう。
一方、プロジェクト開始前の見積りにおいて、見通しの正しさの他に忘れてはならないことがあります。それは、プロジェクトが始まった後に起こり得ることに備えることです。
プロジェクトには変更がつきものです。最初に決めた要件や仕様が、一切ブレることなく最後まで維持されるということは滅多にありません。過去の案件のリピートであれば、あり得るかも知れないでしょう。しかし、プロジェクトというものがそれまでになかった独自の所産を生み出す活動であるという性格に基づけば、活動の過程で軌道修正が行われやすいのは容易に想像できます。
ましてや要件が曖昧なまま始めることになった、詳細は進めながら固めていくというようなよくあるプロジェクトでは、頻繁に変更が発生します。プロジェクトのマネジメントにおいて、CCB(Change Control Board; 変更管理委員会)という仕組みの確立が推奨されるのも、変更の発生が前提にあるからです。
問題は、発生する変更をどう識別するか、そしてどう対処するか準備を整えておくということです。そもそもCCBが機能するのは、”変更”を認識するからであって、それが”変更”と認識されない、”変更”と扱われなければCCBが役割を果たすことをないのです。
どういうことでしょう。システム開発で、ユーザが入力する画面を製作する要件があったとします。見積り段階において、だいたいこういった画面になるだろうと見通していたとしても、いざ製作の段階になって、顧客から入力項目の大幅な追加が示されたらどうなるでしょうか。顧客に対し、「入力項目の大幅な追加により費用が増加しますので、追加見積りをさせていただきます」と伝えて「了解しました」と言ってもらえるでしょうか。
「入力項目が増えても、この画面に必要な情報だから、当然当初の見積り金額の範囲でやってもらえると思っていましたよ」と言われた時に、反論できるでしょうか。
反論できないのは、見積りの中で”ベースライン”を定めていないからです。ベースラインとは、見積りの前提条件の一つであり、このラインを超えたら追加見積りになるという基準を示すものです。先ほどの例で言えば、この画面の入力項目数は○○件以内とする、ということを見積り時点で明確にしておくということです。
それでも実際に入力項目数の追加が発生したときに、見積りに基づいて顧客が追加費用を認めてくれるかは別問題です。顧客との関係を考えて、コストオーバーを受け入れるという判断もあり得るでしょう。しかし、少なくとも交渉は可能になります。交渉した結果、恩をうるということもできるでしょう。
非常にシンプルな例で説明しましたが、様々なところでこういったベースラインを検討し、定めておくことは、プロジェクトの成功に欠かせません。プロジェクトを受託する側がコストオーバー、工程遅延を防ぐだけではありません。委託側も見積りの段階でベースラインを意識し、決定事項を先送りせず事前の熟慮を促すことになるのです。
あなたの組織では、見積りのベースラインを定めさせているでしょうか。その見積りは、変更に耐性を持ったものになっているでしょうか。
