業務を見直して優先順位を考える
もう一つ、併せて考えるべき点は優先順位です。
見積もった結果、予定されたコストや期間では対応できないと分かったとき、「そんなに払えない！ だったら辞める」としてしまうのも一手ではありますが、可能であるなら提示した要件のうち、優先度の低いもの、今やらなくても良いものを、実際にシステムを使う業務部門などと、よく相談してスコープから外すことを検討してみましょう。
大切なのは、本当に使う人と業務の流れを真剣に考えてみることです。必要と思っていた機能が、手作業や古いシステム等で代替できるとか、実はある特定の人物がこだわっていただけで、全体から見ればなくてもなんとかなる機能というのは、意外に多いものです。
そうした話し合いを通じて、機能の優先順位を決め、下位のものから順番に落としていくというのは、よく見られる方法です。
優先順位付けの方法としては、例えばMSCW分析であったり、スコアリングマトリクス、決定木分析、All-in/All-out方式など様々ありますが、こうした方式に則って、論理的にやれることと、やれないこと、延期することをを分けていくことです。今回、挙げた事件のプロジェクトでは、この辺りが本当にできていたのか、疑問が残ります。
このような論理的な優先順位付けは、もちろんSIベンダとの価格交渉に役立ちます。またユーザ側の担当者からすると、上層部に対して、実現できない要件や、追加コストの必要性について納得感のある説明を行うためにも役立つ方法です。
いずれにせよ、使いもしないパッケージソフトのために多額の費用だけが発生する状況は、ユーザにとって大きな痛手です。パッケージソフトのカスタマイズにあたっては、SIベンダとの商談中の情報収集やRFI(Request for information)、自己学習等も含めて、発注前にできるだけの情報を収集し分析することが必要です（了）。
