PMプロの知恵コーナー
先号　　　次号

ゼネラルなプロ (14)

向後　忠明　[プロフィール]　：12月号
　今月号からは請負業者が事業主 (オウナー)側から提出された引合書(RFP)をベースに提案書を作成するステップに入ります。
　そのステップとは提案書(プロポーザル)の作成、提出、評価・交渉、契約に至るまでの作業プロセスとそこでのプロジェクトマネジャの取るべきアクションに関するものです。
　このプロセスはプログラムにせよプロジェクトにせよ、事業主(オウナー)そして請負業者双方にとって非常に重要なステップです。リスク認識力と全治全能を使って対応していく時であります。
　したがって、必然的にプロジェクト責任者であるプロジェクトマネジャにとっても重要なステップでもあり、これまでの治験を持って対応していく必要があります。
　このステップではプロジェクト全体のリスクマネジメント計画の一環でもあると言う認識を持って当たらなければなりません。
　しかし、このようにプロジェクトマネジャにとって重要なステップであるのにもかかわらず、ここでの活動の詳細についてはP2MやPMBOKでもその具体的内容は示されていません。
　以下に筆者の著書からの抜粋とその後の経験を入れて、このステップでの具体的に取るべきアクションやその内容に関する記述は余りないです。
＜ステップ1：準備/提案書作成/提出＞
　最初のステップは事業主(オウナー)側から出された引合書(RFP)に従い、請負業者側が提案書を準備することになります。
　その準備とは、対象となるプロジェクトの規模や複雑性により異なるが提案書(プロポーザル)作成のための責任者を早くから決定し、万全の体制を決めておく必要があります。
　場合によっては、他の会社と一緒になってこの提案書の作成をする必要になることもあります。この場合には関係各社と具体的な提案書作成に関する合意文書や役割分担を規定し、入札作業に入る体制を整えておく必要があります。
　一般的にここで示される責任者はプロポーザルマネジャと称されます。
　IT事業においてはこのステップでは営業の責任者または担当者がその責を負いますが、この辺がエンジニアリング企業のものと違うところです。
　どちらの場合が良いかは企業の方針もあることでもあります。しかし、筆者の考えは、このステップでの各作業の内容や契約までのいきさつを良く知った人すなわちプロポーザルマネジャがプロジェクトマネジャとして実行も行うことがベターと考えています。

　その理由はリスクマネジメントにあります。

　プロジェクトマネジャの視点から見た場合、事業主(オウナー)からの引合書(RFP)を入手したら、その読み込みを行いプロジェクト全般のありようの把握、求めているプロジェクトの範囲そしてそれに見合った人材(プロジェクト要員)の選択を行います。
　そして、引合書(RFP)に示される要求条件およびプロジェクトを取り巻く内外の環境を考慮しながら提案書の作成をすることになります。
　この時点で自分の治験および識者からのアドバイス等からプロジェクトに潜むリスクを察知し、プロジェクトを実行に当たってのリスク回避または低減の対策をとっておく必要があります。
　この時点でのリスク回避・低減検討がリスクマネジメントのクライマックスであり、ここでの活動がプロポーザルマネジャまたはプロジェクトマネジャの重要な仕事になります。
　すなわち、プロジェクトの開始時の提案や契約そして計画段階は一般的にリスク事象が図14-1に示すように多い時期であり、これを逃すとプロジェクトの失敗原因となる場合が多いです。
図14-1　リスク事象の頻度＜P2Mより＞
図14-1　リスク事象の頻度＜P2Mより＞

　上記に示したような理由で、筆者はプロジェクトの責任者になる人すなわちプロジェクトマネジャが提案および契約に関する活動まで関与していくことが望ましいと考えています。
　さてこのように準備が整って引合書(RFP)の検討が終わり、リスク検討を含め、提案書の提出方法や記述方法を良く吟味した上で提案書の作成に入ります。
　なお、提案書の作成の手順についてはすでにゼネラルなプロ(12)の図12-1「営業活動から提案書作成まで」に示しているのでそちらを参照してください。

　また、引合書(RFP)にはゼネラルなプロ(12)の表12-1「引合書の項目例」に示すように提案書の書き方や様式を示しているケースもあります。この場合はこれに沿って行います。
　そうでない場合はそれぞれの企業の標準に従って作成すれば良いでしょう。

　さて、それでは提案書作成までどのような活動が行われ、準備されるかを図14-2に示します。
図14-2　提案書作成までの活動
図14-2　提案書作成までの活動

　以上が提案書作成までの一般的なプロセスですが、自社のみでの提案活動であれば合意書の作成はいりません。
　そして、提案書の作成を行い、事業主(オーナ)に提出する。
　提出に際しても事業主(オーナ)よりの指示があればそれに従い提出することになりますが、その具体的項目例の一部を下記の表14-1および14-2に示します。

表14-1　商業的プロポーザル
表14-1　商業的プロポーザル


表14-2　技術的プロポーザル
表14-2　技術的プロポーザル

　提案書(プロポーザル)は一般的に表14-1および14-2に示すように商業的プロポーザルと技術的プロポーザルに分けると良いです。

今月号は少し詳細な説明になってしまっているので、読者諸君も食傷気味になっていると思いますのでこの辺でやめておきます。よって今月号はこの辺で終わりとします。
　来月号は今月号の続きで提案書(プロポーザル)の構成と「何故、商業用と技術用」に分けて作成するかについての話から入ります。

＜筆者からの提言＞
　なお、読者諸君に再度言っておきますが、引合いから契約までの手順や活動はプログラム & プロジェクトマネジャにとって非常に重要な局面です。
　特に、IT系の事業において、この局面の多くは営業の所掌範囲にあることが多いようです。そのため、この重要な局面に関与せず、契約が成ってからプロジェクトマネジャが指名されるケースが多いです。そのため、営業との確執も多く、「プロジェクトが上手くいかない場合の責任ばかりがプロジェクトマネジャに来る」と、プロジェクトマネジャの不満が多く、またプロジェクトマネジャになりたいと言う希望者も少なくなっています。
　この辺は企業トップの判断によりますが、ここまで任せられる人材がまだ育っていないと言われればそれまでです。
　責任を持って最後までこのプロジェクトを実行する覚悟で、「この仕事は私がすべてやるので任せてください」と宣言し、ここで説明されたステップに従って読者諸君も挑戦してみてはどうでしょうか？それがハイクラスPMすなわち「ゼネラルなプロ」になる第一歩です。
　筆者もそのような気概のある人がいれば微力ながら協力します。
ページトップに戻る