選択した手段が，今回上がった候補の中では，一番ベターな選択だったと仮定しよう。では，なぜ障害を引き起こしてしまったのだろうか？

　一般的に大規模なプロジェクトの場合，コミュニケーションラインの問題から，適切な単位に分割することが常套手段であるが，超巨大規模プロジェクトの場合ともなると，単純分割では，なお管理不能の状態が続く場合が多い。

　分割したプロジェクト間がお互いに何らかの依存関係がある場合に多く見られ，金融システムのように，決済系のシステムを軸にその他のシステムとの密な連携が発生するようなシステムでは，その特性から各プロジェクトの依存関係がより強く出るといえる。

　このように，複雑な依存関係で複数のプロジェクトが存在するようなケースでは，一箇所に火の手が上がると，それが別のプロジェクトにも飛び火し，これを鎮火しようとする動きから，プロジェクト毎に個別に局地戦が始まってしまう。これは，それぞれのプロジェクトリーダが己のプロジェクト内部問題の沈静化に躍起になってしまい，その結果，局地戦状況になってしまったと考えられる。

　プロジェクトを遂行すると言うことは，難題をいかに乗り越えることが出来るかが問われるといわれるように，計画どおり何も起こらず完了できるプロジェクトは無い。何らかの問題や不具合が日常のように発生し，これらをいかにマネジメントして無事目的を遂げられるかが真のプロジェクトマネジメントである。まさに，統合プロジェクト渦中の各プロジェクトリーダたちは，夜も昼も無く血のにじむような努力をしたに違いない。

　ドラッカーのマネジメントの原則によると，マネージャたるもの，よく周りを見て手を打つべしといったところではあるが，なんせ，マネージャもリーダも巨大システム統合の渦の中では，１プレーヤに過ぎず，往々にしてプレーヤは沈着冷静な正しい判断が出来ない状況に陥る。これはスポーツの世界でも，ビジネスの世界でも，人間が関わって行う全ての作業に共通的な事象であろう。

　“管理可能な単位にチームを分割せよ！”　を大所帯のプロジェクトで実施するとどうなるだろうか。単純に実施すると，プロジェクトが無数の小さなチームの単位に分割されてしまい，管理不可能な状態に陥る。この場合，いくつかのチームをグループ化してプロジェクトを管理することになり，それでもまだ全体で管理できないような数であれば，さらにその上に管理グループをかぶせて管理することになる。いわゆる統合が重要なキーワードとなる。

　よく考えて見ると，プロジェクトに参加する人数が同じであれば，管理組織を極小化した幅広の体制を敷こうが，幾重もの管理組織を持った幅は狭いが，縦に深い組織体制を敷こうが，常に変化する状況に対する指示や伝達を，正確かつ迅速に到達させることは，どちらも同じように難しいといえる。

　しかし，一般的に大規模開発の場合，多階層型のプロジェクト体制を敷くケースが多く，このこと自体は，軍隊組織がそうであるように，大規模なプロジェクトの運営といった観点から見ると，フラットな組織体制よりも成功する可能性は高くなるはずである。