【失敗プロジェクト】顧客体制にITプロジェクトの経験者がいない..3つの原因を分析!!
私が所属するiPM naviは数多くの失敗プロジェクトを分析してきました。
失敗プロジェクトには必ず原因があります。
今回はこの３つの原因を分析しました。
あなたのプロジェクト活動のリスク管理表に書き込んでください。
・クライアント体制に社内の調整役が不在である
・クライアントが実施すべき作業が不明確である
・クライアントがITプロジェクトの経験者をアサインできない
なぜ、プロジェクトが失敗に終わったのか？
原因を分析していきます。
1.失敗プロジェクトの実例を紹介
最初に原因を分析する失敗プロジェクトの実例を紹介します。
▪️プロジェクトのスコープと体制▪️
・クライアントは大手繊維メーカー
・クライアントの情報システム部で基幹業務の新規構開発を実施
・原料管理、物流管理、受注管理がシステム化対象
・中堅SierのA社が開発全般を請け負う
・開発体制は業務チーム、基盤チーム、テストチーム、管理チームで構成
・プロジェクトマネージャーはA社の佐藤（PM初心者）
▪️進捗状況▪️
プロジェクトは、要件定義工程で問題が起こりました。
開発チームは、当該工程をスムーズに実行するために万全な計画を立てていました。
しかし、クライアントの内部でプロジェクトの目的の齟齬の解消や要求仕様の確定ができません。
プロジェクトマネージャーは、クライアント内部の問題であることから、要求仕様の確定を強く催促しました。
▪️クレーム▪️
すると、クライアントから、社内でプロジェクトの目的を理解してもらえないことや、要求仕様の取りまとめに苦戦するのは、開発チームがリードしてくれないからとのクレームがあり、プロジェクトマネージャーは回避できませんでした。
▪️結果▪️
・不十分な要求仕様による品質の悪いシステムの完成。
・プロジェクトの目的を達成できないことによるビジネス損失。
このようにプロジェクトが破綻して失敗に終わりました。
プロジェクトマネージャーは、クライアントの体制にITプロジェクトに参加した経験者がいないという問題に気付かずプロジェクトを進めたからです。
**守秘義務により企業名・団体名・個人名等は架空名称となります。
2.失敗の原因の分析
原因１：クライアント体制に社内の調整役が不在
プロジェクトを健全に推進するなら、クライアントの体制も含めて計画を立てることが大事です。
開発チーム、クライアントチームが一体となることでプロジェクトは成功します。
プロジェクトマネージャーは、クライアント内部の問題であることから、要求仕様の確定を強く催促しました。
▪️クレーム▪️
すると、クライアントから、社内でプロジェクトの目的を理解してもらえないことや、要求仕様の取りまとめに苦戦するのは、開発チームがリードしてくれないからとのクレームがあり、プロジェクトマネージャーは回避できませんでした。
▪️結果▪️
・不十分な要求仕様による品質の悪いシステムの完成。
・プロジェクトの目的を達成できないことによるビジネス損失。
このようにプロジェクトが破綻して失敗に終わりました。
プロジェクトマネージャーは、クライアントの体制にITプロジェクトに参加した経験者がいないという問題に気付かずプロジェクトを進めたからです。
**守秘義務により企業名・団体名・個人名等は架空名称となります。
2.失敗の原因の分析
原因１：クライアント体制に社内の調整役が不在
プロジェクトを健全に推進するなら、クライアントの体制も含めて計画を立てることが大事です。
開発チーム、クライアントチームが一体となることでプロジェクトは成功します。
この問題プロジェクトでは、クライアント側で社内の各部署と関係を良好に構築できるリーダーがいませんでした。
また、プロジェクトマネージャーならクライアントチームの社内のパワーバランスを確認しておくのが良いでしょう。
そのためには、計画の段階で組織図を入手して、クライアント体制が十分に機能するかを確認しておかなければなりません。
原因２：クライアントが実施すべき作業が不明確である
クライアントの作業は、スコープマネージメントに当たります。
この問題プロジェクトでは、クライアントの作業がWBSに盛り込まれていませんでした。
本来であれば、クライアントの作業もWBSに表記して、作業の責任範囲を決めておくべきです。
しかし、クライアントの体制が脆弱なのであれば、開発チームが過去の経験を生かして、クライアントのやるべき作業を提言しなくてはなりません。
原因３：クライアントがITプロジェクトの経験をアサインできない
品質を担保するにはクライアントの体制も大きな影響を与えます。
このプロジェクトでは、クライアント体制にITプロジェクトの経験者をアサインできませんでした。
このような体制では、社内調整や要求仕様の取りまとめが難しいものです。
やはり、プロジェクト計画の段階で、プロジェクトマネージャーがクライアントの体制の弱点を見つけ出し、開発チームがサポートする範囲を相談することが望ましいです
3.失敗の回避策
この問題プロジェクトは、どのように対処するべきだったでしょうか？
また、プロジェクトマネージャーならクライアントチームの社内のパワーバランスを確認しておくのが良いでしょう。
そのためには、計画の段階で組織図を入手して、クライアント体制が十分に機能するかを確認しておかなければなりません。
原因２：クライアントが実施すべき作業が不明確である
クライアントの作業は、スコープマネージメントに当たります。
この問題プロジェクトでは、クライアントの作業がWBSに盛り込まれていませんでした。
本来であれば、クライアントの作業もWBSに表記して、作業の責任範囲を決めておくべきです。
しかし、クライアントの体制が脆弱なのであれば、開発チームが過去の経験を生かして、クライアントのやるべき作業を提言しなくてはなりません。
原因３：クライアントがITプロジェクトの経験をアサインできない
品質を担保するにはクライアントの体制も大きな影響を与えます。
このプロジェクトでは、クライアント体制にITプロジェクトの経験者をアサインできませんでした。
このような体制では、社内調整や要求仕様の取りまとめが難しいものです。
やはり、プロジェクト計画の段階で、プロジェクトマネージャーがクライアントの体制の弱点を見つけ出し、開発チームがサポートする範囲を相談することが望ましいです
3.失敗の回避策
この問題プロジェクトは、どのように対処するべきだったでしょうか？
対処策は３つあります。
Ⅰ.開発チームがクライアントの脆弱な体制を考慮したスケジュールを立てる。
Ⅱ.要.件定義の取りまとめを開発チームが全面的にサポートする。
Ⅲ現状のクライアント体制でプロジェクトが推進できるようにスコープを縮小する。
4.まとめ
（１）失敗の原因の分析
プロジェクトを健全に推進するなら、クライアントの体制も含めて計画を立てることが大事です。
そのためには、計画の段階で組織図を入手して、クライアント体制が十分に機能するかを確認しておかなければなりません。
クライアントの作業は、スコープマネージメントに当たります。
クライアントの体制が脆弱なのであれば、開発チームが過去の経験を生かして、クライアントのやるべき作業を提言しなくてはなりません。
品質を担保するにはクライアントの体制も大きな影響を与えます。
クライアントチームにITプロジェクトの経験者がいなければ品質劣化の原因になります。
（２）失敗の回避策 回避策は３つありました。
①開発チームがクライアントの脆弱な体制を考慮したスケジュールを立てる。
②要件定義の取とりまとめを開発チームが全面的にサポートする。
③現状のクライアント体制でプロジェクトが推進できるようにスコープを縮小する。
（３）教訓
この問題プロジェクトから得られた教訓は!!
プロジェクト計画の段階で、クライアントが実施するべき作業と必要なスキルを説明して、体制を構築してもらいましょう。
この教訓を皆さんのプロジェクト活動の参考にしてください。
5.Q&Aセッション
失敗プロジェクトの原因に関する質問に答えるQ&Aセッションを設けています。
皆さんの疑問や質問に対応することができます。
失敗プロジェクトに対する理解を深め、同じような失敗を回避するためのアドバイスをします。
iPM naviのサイトにアクセスしてコミュニティーに登録してください。
大手コンサルファームの社員や出身者が無料でアドバイスします。
ファームの人材とコミュニケーションが取れるイイ機会です。
是非、ご利用ください。
またコミュニティでは今回の失敗プロジェクトをプロジェクトの教訓としてリスク管理表にまとめました。
こちらも併せてチェックしてください!!
Ⅰ.開発チームがクライアントの脆弱な体制を考慮したスケジュールを立てる。
Ⅱ.要.件定義の取りまとめを開発チームが全面的にサポートする。
Ⅲ現状のクライアント体制でプロジェクトが推進できるようにスコープを縮小する。
4.まとめ
（１）失敗の原因の分析
プロジェクトを健全に推進するなら、クライアントの体制も含めて計画を立てることが大事です。
そのためには、計画の段階で組織図を入手して、クライアント体制が十分に機能するかを確認しておかなければなりません。
クライアントの作業は、スコープマネージメントに当たります。
クライアントの体制が脆弱なのであれば、開発チームが過去の経験を生かして、クライアントのやるべき作業を提言しなくてはなりません。
品質を担保するにはクライアントの体制も大きな影響を与えます。
クライアントチームにITプロジェクトの経験者がいなければ品質劣化の原因になります。
（２）失敗の回避策 回避策は３つありました。
①開発チームがクライアントの脆弱な体制を考慮したスケジュールを立てる。
②要件定義の取とりまとめを開発チームが全面的にサポートする。
③現状のクライアント体制でプロジェクトが推進できるようにスコープを縮小する。
（３）教訓
この問題プロジェクトから得られた教訓は!!
プロジェクト計画の段階で、クライアントが実施するべき作業と必要なスキルを説明して、体制を構築してもらいましょう。
この教訓を皆さんのプロジェクト活動の参考にしてください。
5.Q&Aセッション
失敗プロジェクトの原因に関する質問に答えるQ&Aセッションを設けています。
皆さんの疑問や質問に対応することができます。
失敗プロジェクトに対する理解を深め、同じような失敗を回避するためのアドバイスをします。
iPM naviのサイトにアクセスしてコミュニティーに登録してください。
大手コンサルファームの社員や出身者が無料でアドバイスします。
ファームの人材とコミュニケーションが取れるイイ機会です。
是非、ご利用ください。
またコミュニティでは今回の失敗プロジェクトをプロジェクトの教訓としてリスク管理表にまとめました。
こちらも併せてチェックしてください!!
