要件が固まらない開発外注で多い失敗は、発注前にすべてを決めようとすることと、何も決めずに作り始めることです。
両方とも極端です。
前者は相談が遅れ、後者は本開発で揉めます。

仕様書を完璧にしようとする

社内だけで完璧な仕様書を作ろうとすると、現場の要望を集めるだけで数か月かかることがあります。
その間に業務が変わり、最初に集めた要望が古くなる。
しかも、技術的な制約や既存システムの都合を見ないまま仕様化すると、ベンダーに渡した後で作り直しになります。

発注側が作るべきなのは、完成仕様ではなく、判断材料です。
業務課題、利用者、現行業務、制約、決裁者が分かれば、ベンダーは要件定義の進め方を提案できます。
完璧な仕様書を待つより、未確定事項を整理した上で相談する方が早いことが多いです。

とりあえず作る

反対に、とりあえず動くものを作れば分かる、という進め方も危険です。
小さな社内ツールなら成立することがありますが、複数部門、外部連携、権限、個人情報、会計処理が絡む案件では、後戻りが大きくなります。
動く画面があると、関係者は進んでいるように感じます。
しかし、業務ルールが未確定なら、画面はあとで大きく変わります。

プロトタイプを作るなら、検証したい問いを先に決めてください。
承認フローを確認するのか。
入力項目を確認するのか。
既存システム連携の可否を見るのか。
問いがないプロトタイプは、ただの早い実装になりがちです。

決裁者がレビューしない

現場担当者だけで要件定義やプロトタイプを進め、最後に決裁者へ見せる進め方も失敗しやすいです。
決裁者が見た瞬間に、予算、リスク、運用負荷の観点で差し戻すことがあります。
これはベンダーの問題ではなく、発注側のレビュー設計の問題です。

要件が固まらない案件ほど、最初から決裁者を巻き込みます。
毎回の打ち合わせに出てもらう必要はありません。
ただし、どの時点で何を承認するかを決めておかないと、開発が進んだ後で前提が変わります。