依頼者側の問題 #2:

根幹に関わる仕様変更

ある依頼主が10階建てのビルを発注したとします。業者から提出された図面に一応目を通すものの、当然ながら依頼主も専門外でよく分からず、業者に丸投げで工事を開始させたのですが、工事も順調に進み5階まで出来上がったところで、 依頼主がやっぱり15階建てにしたいと言い出したとします。この場合、ビルの土台や骨格が15階建ての重さに耐ええられない為、すべてを取り壊し、土台から工事をやり直すことになります。 その結果膨大な時間とお金をロスするのです。正にシステムも同じで、１度構築したシステムの根幹を修正しなければならないとしたら、それはシステムの作り直しと同義語であると考えなければなりません。

依頼者側の問題 #3:

責任のとれるキーマンの存在

組織が大きいほど、社内のシステムに対する要望やニーズは多様化します。その中で、会社にとって必要・意味のある要件と、あくまでも担当者の個人的な要件とをまず整理しなければなりません。会社のトップが自らシステム導入のキーマンとして関わってくれるのであれば、ある意味会社のためのシステムは出来上がるかもしれません。（経営者の意向だけを取り入れて、現場の声を無視してしまうと、理想と現実のギャップが大きくなり過ぎて、運用に乗らないということはありえますが。）担当者がトップではない場合、責任をとれる立場で、本当に会社の利益を優先して考えられるキーマンの存在が必要不可欠になります。

依頼者側の問題 #3:

慣れと固定概念

依頼主が「今までこうやってきたから」とか、「自分の会社のことは自分が一番よく分かっている」という姿勢では、今まで使っていたシステムより良いシステムはできません。少なくともシステムの限界を知っているのは、開発者であるということを依頼主によく理解してもらい、開発者が依頼者の業務をできる限り正しく把握できるよう、協力を得られるような体制になっていなければ、良いシステムを開発することは難しいといえます。