プロジェクトの目標が明確だったとしても，計画/体制が不適切ではプロジェクトが火を噴くことは確実だ。計画/体制の不備が原因で危機に陥ったケースでは，稼働予定日までに決められた作業を遂行できるよう計画/体制を思い切って変更するしかない。
一例を挙げよう。日本自動車工業会（JAMA）と日本自動車輸入組合（JAIA）が共同で2005年1月，自動車リサイクル法の施行に合わせて稼働させた「自動車リサイクルシステム」の開発プロジェクトは，要件定義や設計作業が大幅に遅れていたが，計画/体制を大幅に見直すことで，予定通りシステムを稼働することができた。
このプロジェクトは，2005年1月に自動車のリサイクル促進を目的に施行された「使用済自動車の再資源化等に関する法律（自動車リサイクル法）」に従って，自動車のリサイクル状況や費用などを管理するシステムを構築するものだった。2003年10月から要件定義を始め，2005年1月の稼働を目指して，1億台以上の自動車情報を管理できるシステムの開発に着手した。
ところが2003年10月～12月の要件定義フェーズで，業務要件の詳細がなかなか決まらない危機が発生した。これまでに前例がない業務だったため，業務要件がなかなか決まらなかったのだ。明らかな「火事」である。
2004年1月～3月には，2005年1月の稼働日に間に合わせるため，業務要件が完全に固まらないまま一部のプログラム開発を始めた。しかし「要件が確定したあとで開発作業の手戻りも発生していた」と，このプロジェクト全体を統括したPMO（Project Management Office，JAMAやJAIAに加盟する自動車メーカーのシステム担当者などで構成）のメンバーの1人だったJAMAの笹野敏久氏は振り返る。なお，このプロジェクトでは1人のプロジェクト・マネージャではなく，PMOが指揮する体制をとっていた。
要件定義の遅延という火事に気付いたPMOのメンバーは2004年4月，全ステークホルダーに向けて「非常事態宣言」を発令。JAMAに加入する自動車メーカーに対しては情報システム部門の要員を，概要設計/開発/運用を担うベンダー（それぞれアクセンチュア/日立製作所/日本IBM）にはプロジェクトマネジメント要員の追加派遣を依頼。それと同時に，プロジェクトの計画/体制を大幅に見直した（図4）。
計画に関しては，2005年1月の稼働予定日までに必要なプログラムと，予定日以降でも間に合うプログラムに分けて，それぞれのリリース時期をずらすことで開発作業の負荷を平準化した（Part1で説明したレベル1サービス復旧/レベル2サービス復旧に相当，図4上）。
また体制については，概要設計/開発/運用をそれぞれ異なるベンダーが担当していたため，各ベンダーが抱える問題を管理/調整する「開発支援チーム」を新設した（Part1で説明した「サービス開始委員会」に相当）。
このチームには自動車メーカーとベンダーの要員約10人が参加。このチームで，各ベンダーが抱える問題を吸い上げ，問題解決の方針を決めていった。例えば開発担当ベンダーが，要件が固まらないと解決できない問題を抱えていた場合，概要設計担当ベンダーに「業務面から解決してほしい」と指示した。
開発支援チームを設置する前は，各ベンダーで問題が発生しても，自分たちだけで解決しようとし，無駄に時間がかかっていた。「開発支援チームを設置することでプロジェクト内の風通しが格段に良くなった」と笹野氏は語る。
組織の壁を越えて要件をチェック
体制を変更して消火に成功したケースをもう一例挙げよう。
システム・インテグレータ，セントラル・コンピュータ・サービス（CCS）の梅澤浩二氏（経営企画部アシスタントマネージャ）がコンサルタントとして，ある製造業のERP導入プロジェクトを支援したときのことだ。このプロジェクトは営業/生産部門の業務改革をしたうえで，営業/生産/経理部門にERPパッケージを導入することが目的だった。だが，営業/生産部門の担当者がそれぞれチームを作って業務要件を固めたときに，経理部門から「その要件では経理業務ができない」とストップがかかった。出火である（図5）。
原因は，営業/生産担当者が業務要件を決める際，経理担当者のチェックがなかったことだ。「本来は営業/生産部門が入力するデータを経理部門でどう使うか，経理担当者が確認する必要があった。このプロジェクトではそれが全くなかった」（梅澤氏）。
そこで，梅澤氏はプロジェクト体制そのものを変更することにした。経理部門の担当者に営業/生産チームに入ってもらい，営業/生産担当者が決定した業務要件の内容を確認してもらうことにしたのである。「このデータは財務諸表の作成に使われるのかどうか，使われるとしたらどの勘定科目として扱えるのか」といったことをチェックし直すことで，結果的に経理担当者が納得する業務要件に修正することができた。このように，業務要件の確定に適さない体制でスタートしたプロジェクトでは，組織の隔たりを解消して要件を確定しやすくすることが「火消しの対策」となる。
インタフェース分科会で役割確認
体制の変更では，システムを開発するベンダーの役割分担を明確にする必要があるケースもある。
ソニー生命保険は2005年4月，保険の事務処理をWebで可能にする1000人月規模のシステム開発プロジェクトを始めた際，ベンダー1社では要員を確保できないため，ベンダー3社に開発を依頼した。開発を依頼したベンダーは同社としては初めて依頼したベンダーばかりだった。そして，「ベンダー同士の役割分担の大枠は決まっていたが，細かい役割分担までは決まっていなかった」（プロジェクト・マネージャを務めた業務プロセス改革本部情報システム2部 IS企画1課 統括課長 後藤聖央氏）。このままでは設計/開発フェーズでベンダー間で作業の重複や漏れが発生し，大火事になるのは必至だった。
そこで後藤氏は，各ベンダーの役割の境目を明確にする「インタフェース分科会」を設置した（図6）。この分科会でシステム間のインタフェースを決めると同時に，各ベンダーの細かい作業分担も決めた。その結果「仕様が固まったあとの設計作業も，今は順調に進んでいる」と後藤氏は成果を語る。
