事例からベンダーコントロールの成功と失敗を学ぶ

全体を見ながら要件を調整したことがよい結果に

ベンダーコントロールの成功事例として、複数のベンダーが参加するモバイルアプリケーション開発プロジェクトを紹介します。
プロジェクトを進めていく中で、ベンダーの1社であるA社から「現状の要件ではプロジェクトの目的が達成できず、当初のスケジュールから遅れる可能性がある」との問題提起があり、要件を調整する必要がありました。
ベンダーコントロールが行うアクションは、プロジェクトのスケジュールと全体のコストに収まる範囲でA社と要件を調整することです。しかし、その前に要件調整がA社以外のベンダーに影響を与えないか、A社が実施した部分をA社以外のベンダーのサポートで回収できないかをベンダーコントロールは検討しました。
その結果、要件調整はA社だけでなく、B社やC社にも影響を与えることが判明し、ベンダーコントロールは代替要件を提案するだけでなく、その代替要件を採用した場合の品質、コスト、納期への影響を提示するようベンダーに求めました。そして、A社、B社、C社から提案された代替要件を取りまとめ、品質、コスト、納期への影響が最も少ない案を仮採用しました。この結果、各社への影響は最小限に抑えられ、プロジェクトの進捗も正常に戻すことができたのです。

この事例で得られたこと

この事例にはベンダーコントロール担当者として留意すべき点があります。それは「要件調整」と「スケジュール調整」です。複数のベンダーが関わるプロジェクトではよくあります。
要件調整や仕様変更の依頼、スケジュール遅延の報告を受けた場合、他のベンダーにも影響がないかどうかをまず確認しなければなりません。A社との要件調整だけを行っていたら「要件調整の結果、実はB社も影響を受けていた」ということが後で判明することになるので、作業を大幅にやり直していたかもしれません。影響範囲を適切に判断するためには、プロジェクトに関わるベンダーを全体的に巻き込む重要性を理解しておく必要があります。

予想以上の費用を請求されることも

ベンダーコントロールは、慣れていないとトラブルが発生しやすいので注意が必要です。基本的に、複数のベンダーが必要な場合は、依頼をする企業がベンダーコントロールを行うことになります。企業が中心となって、スケジュールやその他の作業をコントロールしていきますが、IT分野は専門知識や経験が必要になる場合もあります。
もしITの知識に詳しくない人が担当になった場合、専門知識を必要とする場面で的確に判断することができないでしょう。調整や評価が上手くいかずトラブルになってしまい、予算を超えるような費用を請求される可能性があります。
ITに詳しくなくてもベンダーコントロールを適切に進められる人もいますが、上記のようなトラブルが発生する可能性の方が高いです。