提案書はプレゼン資料ではない。契約書の内容を補完する役割も果たすので、正確に書かれていることが重要だ。そのため発表者には、細かく正確に書かれた資料を、決められた時間内に要領よく説明することが求められる。提案書作成は、あまり口が達者ではないITエンジニアにとって力を発揮しやすい作業である。いえ、やはり説明は重要だ。今回は失敗事例から、提案書の発表時に覚えておいてほしいことを伝えたい。あるシステム開発の発注側のプロジェクトマネジメントを支援するコンサルティング案件の話だ。そのときの提案書は、部門長である筆者とコンサルティング部のマネジャーが準備した。自社にとって得意分野でもあり、そこそこ説得力のあるものに仕上がっていた。提案の場には、筆者、マネジャー、担当予定のPM、営業の4人で臨んだ。提案書の説明はPMが行った。提案書はそのプロジェクトにアサイン予定のPMが準備するのがベストだ。提案時点でそのPMは、既存案件のマネジメントを担っていた。プロジェクトの終盤なので、多忙を極めている。そんな中で、次の案件の提案準備まではしてもらえない。その提案では、PMに筆者らが作成した提案書を予習してもらい、説明に臨んだ。そのPMは、提案書をしっかり読み込んでくれており、内容の説明は申し分なかった。説明が一通り終わってから、ひと波乱起きた。顧客の責任者から、提案書には書かれていないプロジェクトの詳細な進め方を質問されたのだ。ここで、PMは、答えに詰まってしまった。質問されたポイントは、提案書からでは方針が読み取れず曖昧だったため、回答に迷いが生じたのだ。それを察知したマネジャーは、すかさずフォローを入れた。その後続いた質問にも丁寧に答えて、提案の説明は終了した。提案の帰り道、マネジャーは筆者に「ちょっと私がしゃべりすぎましたかね」と言ってきた。そこは筆者も気になっていた。PMの第一印象が悪くなったかもしれない、という気がしたのだ。数日後、営業から失注したとの報告が入った。マネジャーと筆者の予感は的中した。「提案内容は良かったが、そのPMに頼れるかどうか確信が持てなかった」ということだった。提案は一発勝負ではないでは、どうすればよかったのか。本来、アサイン候補のPMが提案の方針を策定すべきだ。どんなことにも答えられるだけ読み込むべきである。それができるなら苦労はしない。いつもベストな状態で提案に臨めるほどの余裕はないのだ。この局面だけ捉えると、内容の正確さを取るか、第一印象としての信頼感を取るか、究極の選択である。不正確な内容を適当に答えれば、顧客にとっても自分たちにとっても大きなリスクになる。いって、答えなければPMとしての信頼を失ってしまう。この先は会員の登録が必要です。xTECHには有料記事(有料会員向けまたは定期購読者向け)、無料記事(登録会員向け)、フリー記事(誰でも閲覧可能)があります。有料記事でも、登録会員向け配信期間は登録会員への登録が必要な場合があります。有料会員と登録会員に関するFAQはこちら次ページしかし、これは錯覚だ。農家が実感した自動飛行ドローンのすごさクラウド現場の負担軽減を!医療界でのAWS活用法SaaSを加速するソリューションとは?クラウドの新形態「aPaaS」のメリットDXを阻むコミュニケーションの壁とは?AWSとSAPの連携強化がもたらす利点は500万社が導入。価値創造型の社内コミュニケーションとは発想を豊かにする有機的な会議ツールとは働き方が変わる。Reserved.このページに掲載されている記事・写真・図表などの無断転載を禁じます。掲載している情報は、記事執筆時点のものです。