情報化プロジェクトにおいては，参加メンバーの間で情報を共有することが重要である。システムの設計や構築はとかく分業になりがちなので，同じ部屋にいながら，お互いの間で情報の交換や意思疎通が円滑でないケースが出てくるからだ。情報を共有できないまま作業を進めると，個々のメンバーの仕事は適切だったにもかかわらず，全体としては使い物にならないシステムが出来上がってしまう危険がある。
同じ会社の社員といっても，所属部門や担当する事業が異なる場合，あるいは同じ部門に所属していてしかも大部屋に一緒にいたとしても，他人が担当している業務をお互い意外に知らないものである。
情報化プロジェクトにおいても，新システムを検討する際の業務の見直し過程や設計・開発段階で，この事実を認識しておかないと，せっかくの討議が無駄に終わることが多い。したがって，他部署の実態をプロジェクト・メンバーがお互いに知りあえる場を設定し，プロジェクトの情報を共有しておくことが検討や設計作業を有意義に進め，プロジェクトの失敗を防止する大きなポイントとなる。
少なくとも，情報化の基本構想に関してプロジェクト参加者の認識が統一できていれば，局所的には最適であるが全体システムとしては最悪というような事態の発生を未然に防止できる。
情報共有の有無（1）
現場の利害が対立
販売業のA社は西暦2000年問題対策を考えるうちに，現行システムを全面刷新する方針を固めた。2000年問題へ対処するだけでも，マシンの入れ替えやプログラムの全面的な見直しが必要だったからだ。A社はシステム刷新のパートナとして従来から同社のシステム化を支援してきたソフト会社を選定した。
このソフト会社のSEは早速，A社の関連部門長へヒヤリングを開始し，課題の洗い出しに入った。ヒアリングで把握された解決すべき課題を踏まえ，ソフト会社のSEはA社の販売，物流，経理など各部門の現場担当者とそれぞれ課題の解決策を詰めていった。
ところが解決策の検討が進むにつれて，部門間の調整が大きな問題となってきた。ソフト会社のSEがある課題の解決のために販売部門と相談したところ，「それは物流部門でこうしてもらったら解決できる」という案が出される。そこで物流部門との打ち合わせの席で，「販売部門はこれこれの課題解決のために物流部門でこうして欲しいと要望しています」と伝えると，「それは無理だ，それよりも販売部門がこう対応してくれればよい」と対案が示される。
しかし物流部門の案は到底，販売部門が受け入れられるものではない。両者が同席して話し合う場を設けても，利害が対立する問題なのでなかなか結論が出ない。こういった問題が，販売部門と物流部門，販売部門と経理部門といったさまざまな組み合わせで多数発生した。二つの部門を担当する共通の上司が存在して，調整を図ってくれればよいが，A社の場合は販売，物流，経理の各部門ごとに担当役員がおり，なかなか調整が図れない。
こうしているうちに検討作業のデッドラインが近づいてきた。ソフト会社のSEは「調整ができない課題は先送りにして，とにかくシステムの開発を進めたい」と進言してきた。これを認めれば，2000年問題の対処だけをしたシステムとあまり変わらなくなってしまう。といって各部門の利害を調整する妙案はすぐには浮かばない。A社の情報システム課長は思案にくれている。
