情報システム部門・IT部門が強くなるためのプラットフォーム

攻めの情シス研究所

情シスにノウハウを。
情シスが会社を強くします。

要件定義後、大幅に予算オーバーしてきた場合、情シス責任者はどう動くか?

2023

3/17

要件定義後、大幅に予算オーバーしてきた場合、情シス責任者はどう動くか?

パッケージ要件定義あるある話

「ちょっと一緒に見てもらえませんか?」

ある情シス部長から相談がありました。

パッケージの基幹システム導入プロジェクトをプロジェクトマネージャー(以降、PM)に任せていたところ、要件定義が大幅に遅れたあげく、ベンダーからの再見積もりで大幅に予算オーバーの提示があったとのこと。

カスタマイズ費用は、当初の2倍です。

PMからは、これ以上は下げられないとの説明があったようです。

しかし、そんなはずはないと思うものの、どこがどう悪いのか具体的に指摘ができず、田村のところに相談がありました。

一般的に、要件定義後の再見積もりで予算オーバーするのはよくある話。

ですが、そのまま何もせずに承認するわけにはいきません。

情シス責任者として、どうチェックしていけば良いのでしょうか?

パッケージのメリットを意識しながら掘り下げていく

まず前提として、情シスの責任者は、すべてのプロジェクトに深く関わることは不可能です。

いろいろなプロジェクト関係の打ち合わせに加えて、経営層との調整や対外的なミーティング等で、日中の会議枠はほとんど埋まってしまいます。

隙間時間で、多くの決裁や承認、メールやチャット対応に忙殺されます。

そのため、プロジェクトは信頼できるプロジェクトマネージャーに任せて、要所で承認する運用にせざるを得ません。

今回のパッケージ導入においては、要件定義フェーズで「Fit&Gap」が行われ、ギャップの部分がカスタマイズとして再見積もりが行われました。

このギャップについて、細かく掘り下げて確認していくしかありません。

(ギャップのたな卸し)
・本当にこのカスタマイズは必要なのか?
・現行踏襲にこだわりすぎていないか?
・パッケージに合わせる努力をしたか?
・帳票はパッケージ標準機能で本当に運用できないのか?
・代替手段や運用カバーは考えたか?
・当初の目的通りBPRできたのか?

(全体的な見直し)
・優先順位と今回のスコープは妥当か?
・自社からみて削減や取り下げの余地はないか?
・フェージング(二次開発に回す)してスコープを縮められないか?
・提案時からの見積もり増額理由をベンダーから説明を受けたか?
・ベンダーから見積もり根拠の具体的な説明を受けたか?
・ベンダーと工数削減調整をしたか?(特に工数大のところ)

逆に、カスタマイズを変にケチらず、お金をかけるべきところもあります。

・他システム連携の自動化(手動運用排除)
・難易度の高い帳票やレポート
・プログラミングが伴うカスタマイズ

ここはベンダーのプロフェッショナルな技術に頼り、品質を十分に確保してもらうために、ある程度のコストは仕方ないと考えます。

他方、ノーコードで設定のみで対応できる部分は、社内で巻き取って「内製」していくのは有力な選択肢となります。

内製は自社側が大変になりますが、この段階から内製人材を育成できることは大きなメリットです。

何か疑問が生じても、開発体制を組んでいるベンダーからすぐに教えてもらうことができます。

スキルアップすることで、この先の保守フェーズで費用削減や現場ニーズへの柔軟な対応に繋げることもできるでしょう。

プロジェクトにきちんと踏み込む

ここで重要なのは、面倒臭がらずに、具体的な仕様まで踏み込んで確認することです。

細かいところまで踏み込むからこそ、プロジェクトメンバーと同じ目線で状況を捉えることができます。

プロジェクトに寄り添う姿勢を見せることで、PMやプロジェクトメンバーも信頼して、素直に打ち明けてくれます(ここで真実が判明することが多い)。

これらを丁寧にヒアリングしていくと、情シスのトップとして、今後のアクションが見えてきます。

・カスタマイズに頼りすぎているなら、経営トップから再び「パッケージに業務を合わせる」と熱量の高い号令を依頼する
・ベンダーの動きが悪いなら、ベンダートップと交渉して体制立て直しを迫る
・いつも問題が大きくなってから相談がくるなら、プロジェクトへの関与を強める

情シス責任者は、時間制限の中でプロジェクトをうまく軌道に乗せないといけません。

ここで求められるのは、情シストップならではの動きです。

担当者と同じレベルで思考しても解決しません。

トップ視点での俯瞰した思考で、影響力を行使し、トップマネジメントにより早急な解決を図ることが求められます。

また、自身の行動を振り返り、プロジェクトがうまくいっていないのなら、これをきっかけに関与の仕方を見直すべきでしょう。

上が関わり方を変えると大きく変わる

冒頭の情シス部長は、プロジェクトへの関わり方を変えました。

関わる時間を大幅に増やすことはできませんが、主体的に関わる姿勢に変えました。

・ステコミで報告してほしいことの提示
・ステコミの月次固定化
・ベンダー責任者との個別調整
・PMと顔を合わせるたびに状況確認

それから3か月が過ぎました。

ベンダーの体制は刷新され、動きが良くなりました。

PMから自発的に相談がくるようになりました。

今では、プロジェクトへの不信感はなく、信頼に変わっています。

貴社のIT部門・情報システム部門の責任者は、多くのプロジェクトに効果的な関与ができておりますでしょうか?

関連コラム

御社のシステム発注は、なぜ「ベンダー選び」で失敗するのか

情シスコンサルタント
田村 昇平

情シス(IT部門、情報システム部門)を支援するコンサルタント。

支援した情シスは20社以上、プロジェクト数は60以上に及ぶ。ITベンダー側で10年、ユーザー企業側で13年のITプロジェクト経験を経て、情シスコンサルティング株式会社を設立。

多くの現場経験をもとに、プロジェクトの全工程を網羅した業界初のユーザー企業側ノウハウ集『システム発注から導入までを成功させる90の鉄則』を上梓、好評を得る。同書は多くの情シスで研修教材にもなっている。

また、プロジェクトの膨大な課題を悶絶しながらさばいていくうちに、失敗する原因は「上流工程」にあるとの結論にたどり着く。そのため、ベンダー選定までの上流工程のノウハウを編み出し『御社のシステム発注は、なぜ「ベンダー選び」で失敗するのか』を上梓し、情シスにインストールするようになる。

「情シスが会社を強くする」という信念のもと、情シスの現場を日々奔走している。

著書の詳細は、こちらをご覧ください。