RFPの作成に取り掛かる前段階の作業として，RFP作成からベンダー選定までを一つのプロジェクトとして位置付け，そのプロジェクトに参加するメンバーを集め，プロジェクトチームを編成する必要がある。ここでは仮にそのチームをRFPチームと呼ぶことにする。
RFP作成やベンダー選定といった調達作業は基本的に複数のメンバーが携わるチームとして行うことが望ましい。どんなに小さな案件であっても，1人の担当者だけで行うと，以下のようなさまざまな弊害が発生する。
・要求に漏れがでやすい。
・ある要求は非常に詳しく，逆にある要求は薄いといったムラが生じやすい。
・ベンダー選定に個人の好みが出てしまい，客観性，公平性に欠ける可能性がある。
実際にRFP作成の作業を1人でやることになっても，少なくともレビューにはエンドユーザーや上司を参加させてチームとして機能させるように図るべきである。またRFP作成チームだけでなく，そのチームが協力を得られるような体制（ここでは便宜的に「サポーター」と呼ぶ）を作っておくとよい。サポーターの体制は緩やかなボランティア的なものではなく，できれば後述するステアリングコミッティーのように社内体制として確立した方がよい。
RFPチームの編成と会議体の設定における重要なポイントを解説する。
（1）RFPチームとサポーターのメンバー
RFPチームを組む上で，最初に決めなければならないのは「プロジェクトマネジャーを誰にするか」ということである。これを決めるに当たっての最大の判断基準は，調達活動を主導するのはエンドユーザー部門，情報システム部門どちらなのか，ということである。
以前であれば，システム案件は基本的にすべて情報システム部門が統括する，というケースがほとんどであったが，最近では，実際にシステムを利用するエンドユーザー部門が調達を主導するケースが増えている。この場合，プロジェクトのオーナーシップはエンドユーザー部門であり，その部門の担当役員がプロジェクトオーナーに就任する。その役員のライン下にいる適任者がプロジェクトマネジャーにアサインされることになる。もちろん，情報システム部門がオーナーとなり，そこからプロジェクトマネジャーが任命される場合もある。
どの部門がプロジェクトを主導するのかは会社の都合で決めればよいことで，大切なのはプロジェクトオーナーとプロジェクトマネジャーが明確に責任と権限を持ってアサインされることである。
プロジェクトマネジャーが決まったら，メンバー集めや協力体制の構築はプロジェクトオーナーの支援の下で，プロジェクトマネジャーが中心となって行う。
RFPチームのメンバーは以下の観点で召集できるとよい。プロジェクトに専任でアサインされることが理想ではあるが，現実的には本業と兼任というケースの方が多いだろう。そこは割り切って，まずはチームを編成することを優先しよう。
・エンドユーザー部門：実際にシステムを使う部署が複数ならば，各部署から参加者が出ることが望ましい。 ・情報システム部門：企画や開発の担当者だけでなく，運用の担当者も参加させる。 ・外部リソース：社内だけでRFPチームを編成する人的リソースやスキルが明らかに不足している場合は，外部のコンサルタントやITコーディネーターなどを採用することも検討する。
（2）プロジェクトチームおよび協力体制を回す会議体
RFPチームとサポーターを運営していくための会議体は基本的に次の3点を中心に考えればよい（図3）。
・ステアリングコミッティー
ステアリングコミッティーは，プロジェクトの上位意思決定機関（最上位機関は役員会を想定）のことを指す。プロジェクトマネジャーを中心とするRFPメンバーだけでなく，プロジェクトオーナーが参加して，RFPチームだけでは判断できないプロジェクト上の問題（スケジュール遅延やコスト超過など）を協議する。RFPの最終承認もステアリングコミッティーが行う。
ステアリングコミッティーには，エンドユーザー部門や情報システム部門など，新システムにかかわる部門の部長や課長などのマネジャークラスに参加してもらうようにしよう。それによって当事者意識を持たせ，サポーター体制が効力を発揮（ヒアリングやブレーンストーミングなどにRFPチーム以外のメンバーが協力的に参加してくれるように取り計らってもらう，など）するようにしたい。
ステアリングコミッティーのメンバー構成の工夫は非常に重要なことである。調達プロジェクト，ひいては開発プロジェクトの成否に大きく影響するので，プロジェクトマネジャーは留意すべきである。
・定例進捗会議
どのようなプロジェクトにおいても共通で行う会議である。プロジェクトマネジャーがRFPチームメンバーに対して行う，進捗会議を指す。
・タスクごとの個別会議
ヒアリングやブレーンストーミングを行う会議や，要件の優先順位を決める会議など，プロジェクトの作業を行って行く上で発生するタスクごとの会議を指す。この会議は定期的ではなく，イベント的に発生するものが多いので，定例進捗会議での管理対象となる。
