その提案でどんな結果になることを望んているの

on


プロジェクトの提案資料のレビューなんて手を抜こうと思えばいくらでも抜けるんです。形式的なチェックをしておけば「形だけ」はレビューしたことになるし、その指摘を修正さえしておけば提案リーダはお墨付きを得たことになりますから。


さて、それでいいのかどうか、と問うて仕舞えばそれはダメだとしか言えないし、そんなレビューでよければITに詳しくない人でもできる。どっちかというと校正慣れしている人の方が提案の本質と関係ないところで鬼のような量の指摘をしてくれる。


とある提案のレビューで提案内容を見ていると提案内容の１つに現行システムの調査・分析とある。普段からboundary、システムの界面を明示的にするように言っているのできちんと調査対象の範囲を示している。


それはいいんだけれど、じゃあその提案の調査・分析でいったいどのようなアプローチで、どのシステム環境に対して調査・分析して、どういったアウトプットをどんなレベルで書くつもりなのかは書かれてない。


提案レビューは、提案する方から提案を依頼している方に対して提示する契約条件と提供する役務を事前にチェックするために行う。なぜそんなことをわざわざ時間をかけて行うかといえば、その契約で得たい収益とそれの足枷となるかもしれないリスクを識別したいから。


提案レビューの目的から言えば、調査・分析で提案する方が書かないことは先方には伝わらない。書かれていないことは後からいくらでも提案を受けた方はリクエストを出すことができる。だって、そう思っていたんだから、と言われては提案する方は取りつく島がない。


調査・分析を提案するにあたってそのアプローチやアウトプットを書く場合に将来起きることは、提案したとおりに役務を履行するだけである。提案する際にアプローチやアウトプットを示しているということはそのアプローチでアウトプットを作るためのコストを積算しているのだから、履行できないわけがない。あとは集めていくる要員のパフォーマンスの出来不出来だ。どちらにしても提案する方の内部の事情だけである。


一方、アプローチやアウトプットを書かない場合に将来起きることは、提案を依頼した方、つまりお客さまからアプローチについてアレコレと横槍が入る隙を作ったり、出来上がったアウトプットに対して批評を受けてしまう恐れがあることだ。つまり、後出しジャンケンをされる隙を提案する方が自ら作っているということになる。


提案レビューではぶっちゃけどっちでもいい。それは提案する方に都合があるからだ。でも、どっちを選ぶにしても望む結果を意識して書かなければ望む結果は得られない。


提案レビューをする側としてはリスクを識別しているか、意図する＝望む結果は何かを確かめだけである。


ところで、その提案でどんな結末になることを望んでいるの。