見積は、構築する業務システムの規模と難易度で決まります。
しかしユーザは、ひとつの機能を作るのにどの程度の手間がかかるのか、なかなか検討がつかないものです。
一見簡単そうに見えるものも、画面の裏側では、プログラム、サーバ、ネットワークといった様々な技術が複雑に組み合わさり、 それらが正しく連携しあって、ひとつの機能を実現しています。
ユーザが画面を通して見ているものは、ある意味「結果」のみであり、システム全体からすれば、文字通り氷山の一角に過ぎないのです。

正しく必要な作業を積み上げ、作業の量と難易度を予測することができれば、それほど大きな見込み違いを起こしてしまうものではありません。
予算オーバーを起こしてしまうのは、作業の積み上げ段階において、必要な作業が抜けてしまったり、難易度を見誤ったりしていることが大きな原因なのです。

当然ですが、業務システムは作って終わりではありません。
システムを使って業務で成果を出さなくては、作った意味がありませんし、成果を出さなくてはシステム構築の費用を回収することができません。 しかも、予算をオーバーしているということは、それを回収するために、より多くの成果を出さなくてはならないということになります。 これはつまり、ユーザに本来必要のない仕事を課していることと同じなのです。
また、業務システムの運用開始後も、新しい業務、既存の業務の改善のためには、それに合わせてシステムを変更していくことが不可欠です。
しかし、初期構築で予算オーバーを起こした業務システムは、機能追加の段階でも、また想定を上回る費用が発生する可能性が高くなります。
業務システムが会社の利益を圧迫し、従業員の仕事を増やし、将来の利益まで食いつぶしてしまうことになるのです。

業務システムは一般的に、多部門、多ユーザで利用するものなので、さまざまな立場の人の意見を取り入れながら仕様を決めていく必要があります。 しかし、各部門がどのように業務を行っているのか、なにが必要なのかを、一人の担当者がすべて把握することは、そう簡単にできることではありません。 部門間の調整がつかず、結局どうすれば良いのかが決まらないということがよくあります。しかしそれでも、決めないことには前に進みません。 このような場合、大抵は「とりあえず」で進めることになります。
そして、概ね仕様を決定したところで、設計、実装と工程が進んでいくわけですが、徐々に全体像が見えてくるころから、 「ここが違う」「そこは変だ」という点が次々と出てきます。
課題が発見され、問題が特定されていくこと自体はよいことではあります。しかし、システムは部分が全体に影響を及ぼし、 全体が部分に影響するという特性があります。そのため、ある部分に修正を加えるためには、全体を修正しなければならないということがよく起こります。

積み上げられた石を崩さずに、下から石を抜き取ることが難しいように、出来上がってしまってからの変更は非常に困難な場合があります。
このように、大きな仕様変更が発生してしまうと、期日通りに構築を終えることができなくなってしまうのです。

では、作る前にどのような機能にするかを確実に決めることができれば、期日オーバーを起こさずに済むはずですが、仕様決定を「完璧に」実施することはまずできません。
様々な立場、役割の人々が利用する業務システムで、ひとりひとりに必要なものを事前に完壁に把握し、特定することはそもそも現実的ではないのです。 担当者本人ですら、自身の業務を全て洗い出せることは稀で、実際にシステムを利用してみて初めて、必要な機能が無いことに気づくといったこともよくある話です。

また、会社の業務自体も日々変わっていくものです。構築初期では存在すらしなかったものが、 業務システムが稼働する頃には必要不可欠な機能になっていることさえあります。
仕様は変わってしまうものなのです。

事前に仕様を確定することができないとしたとき、期日オーバーをなるべく起こさないシステムとはなんでしょうか？
それは「変化に強いシステム」です。
仕様の変更を比較的迅速に行えるシステム、一部の変更がなるべく全体に影響しないように配慮したシステムが変化に強いシステムです。
変化に強いシステムは、システムが完成した後の運用段階でも威力を発揮します。
会社は常に業務改善を行い、新しいサービスを模索しながら、継続的な収益を確保していかなければなりません。 変化に強い業務システムは、サービスの改善や新サービスの展開を容易にし、収益向上に貢献できるシステムなのです。

業務システムは基本的に注文生産であり、完成前には実物は存在しないので、出来上がったものはフタを開けてみないと分かりません。
さて、ようやく画面が動くようになり、ユーザが触ることができるようになったとき、ここでも、「思っていたものと違う」、「思っていた機能と違う」といった事態が起こります。 開発作業の終盤、多くの作り込みを行ってしまった後に、初めてユーザが確認を行うことは、失敗リスクを大幅に上昇させてしまいます。

「分かりやすさ」、「見やすさ」、「動き」などの感覚的な良し悪しは、それこそ現物を見て初めて判断できることで、 企画書、設計書ではどうにも分からないものです。
そして、業務システムが使いやすいかどうかは、これら感覚要素を含めて総合的に決まるものです。
大きさや配置の僅かな違いが使いやすさに影響を及ぼすので、確認を適切に行うためには、事前に、現物により近い状態を作り出す必要があります。

「間違いに気づく」、「より良い方法を発見する」のは、早い段階であるほどリスクを減らすことができます。 終盤で大きな問題を起こさないためには、早期に現物に近い環境を作成し、課題を抽出をすることです。
業務システム全体のうち、ユーザから見える部分は、「ユーザインターフェイス」すなわち「画面」です。画面イメージを早期に作成し、 画面イメージを通して課題抽出、問題発見をするしかないのです。