「技術仕様と範囲」と曖昧な提案

なんとかは風邪ひかないと言うので風邪ではないと思うのですが、喉が痛い。
睡眠時間少ない＋ちょっと突発の深夜仕事になったので体力に隙が出来たのかしらん。

ところで、プラント建設では提案リーダが「技術仕様と範囲」できっちり書いて、プロジェクト開始後に仕様が膨らむことを防御するために、コントラクタの受注量と供給能力のバランスが取りやすいが、ITの場合は、「技術仕様と範囲」を曖昧に書くのでプロジェクト開始後に仕様の膨張を制御できずにITコントラクタの受注量と供給能力のバランスがとりにくい。

ここでの話のテーマは、プラントやITのコントラクタ内部での「受注量と供給能力のバランス」です。

「受注量と供給能力のバランス」が取れないとどうなるか。例えば、十分受注している状況で、さらに提案するとなると提案リーダのスキルが足らないために見積もり精度が落ち、安値受注となり、赤字プロジェクトを抱えることになり結果的に受注しない方がよかった、となるわけです。

でも、経営サイドは取りに行け、と言いますよね。

提案リーダのスキル不足が精度の低い見積もりを作るとなんで赤字になるのか。簡単です。精度が低く高値を付ければ案件をロスするだけで、提案費用のコストだけでコトが済みます。一方、提案の精度が低くて落札出来てしまうと価格は安く見積もっちゃうわ、「技術仕様と範囲」が曖昧だわで、発注者に「それは仕様だ」と言われて仕様が膨らんでしまう、というコトになるわけです。

ワタシは提案書には、定量的な提案とバウンダリをしっかり書いているかを見るのでちょっとギャップを感じるなー。アプリケーションシステムだと、定量的な提案とバウンダリをしっかり書くことで仕様の膨張は防御出来ないものなんですかねー。