プロマネチェックリスト4 変更管理は開始タイミングと基準成果物を明確に

本日は変更管理導入の失敗事例についてのご紹介です。

過去、私が携わったプロジェクトでのお話しですが、一番大炎上させてしまったプロジェクトの事例となります。
もちろん変更管理運用以外にも数多くの問題がありましたが、変更管理がうまく機能できていなかったというのが
重要なポイントだったと思います。

前回の記事はこちら「プロマネチェックリスト3 課題管理は即時起票がポイント! 」です。

スポンサーリンク
レクタングル広告(大)

プロジェクト背景

中堅金融機関のBPRをともなう基幹系システム再構築プロジェクトでした。
当時私はIT系のコンサルティング会社のメンバーとして、こちらのプロジェクトを請け負う側にいました。

当時いたコンサルティング会社的にも数10億規模の案件はそこまでなく、難易度的にもかなり高めでしたが、売り上げを立てたいという社内事情などもあり、上流フェーズだけでの撤退や、開発フェーズはマネジメントのみでの参画などはなかなか、決断できなかったようです。

また、クライアントと開発側の関係は完全にクライアントが強い状態でした。

失敗の背景と結果

要件定義フェーズ時点で要件のつまり具合が完全にあまい状態で開発の見積りを出す必要がありました。

要件がつまりきっていないので、仕様変更のラインやスコープが曖昧で、クライアントからの要求は基本受けなければならない状態でしたし、
そもそも要件定義の結果、要件定義前に見積もった概算見積りを大きく超過しており、本来であればスコープ縮小やコスト調整をする必要があったのですが、
クライアントとの関係上、スコープは全てのみ、金額も要件定義前のものがキャップとプロジェクト前半から非常に苦しい局面に立ちました。

また、仕変の基準ラインが定められなかったので、詳細設計以降も要件の変更は基本的に受け入れる(コスト請求や納期調整もなし)という状態になってしまいました。

これで規模が小さいプロジェクトだったらまだ乗り越えられたかもしれないのですが、数十億規模のプロジェクトだと乗り切れるわけもなく
今振り返っても最初から炎上する要素はたくさんありました。

結果としてC/Oを長期に延伸し、請負側も多大な金銭的損失をこうむりました。

ポイント

仮に要件のつまり具合が不十分な状態で請負フェーズに突入したり、見積りを出したりしない

どうしてもスケジュールを守りたくなって、仕様の整理が曖昧なまま開発に進みたくなりますが、大規模プロジェクトでは本当に危険です。
一度立ち止まる勇気も必要です。

変更管理は厳格に実施

クライアントとの関係が悪かったとしても、クライアントに強く言えない状況でも変更管理を導入せずに
100%受けいる事は、お互いを不幸にします。

間違いなく。

必ず、要件定義(基本設計)で静止点をおき、それ以降はしかるべき判断フローをもって実施要否を判断する
コストや納期、優先順位判断をきっちり行っていくことが重要になります。

さいごに

本日は変更管理運用の重要性をあらためてご説明しました。

受注側でいると、クライアントに強く言えないことも多々ありますが、
結果的にお互い不幸になる事もあるので、変更管理運用は確実に実施する事が大切だと思っています。

最後までお読みいただき、ありがとうございました。

スポンサーリンク
レクタングル広告(大)
レクタングル広告(大)

シェアする

  • このエントリーをはてなブックマークに追加

フォローする