writing by MASA
プロジェクト進行中に顧客の都合で作業が停滞することは日常茶飯事です。 特に、厄介なのが顧客サイドにITプロジェクトの経験者がいない時... このようなとき、PMはプロジェクトを遂行するのに耐えうる体制を構築してもらえるように、プロジェクトオーナーへ直談判するのも一つの手です。 しかし、顧客の人材リソースにも制約（有識者は本来の業務で忙しい、たのプロジェクトに参加中...etc）があり、難しい場合が多いものです。 これは、プロジェクトのリスクです❗️ 顧客体制がプロジェクトに耐えられない貧弱な状況であれば、PMはどうすれば良いのでしょうか？ みなさんと一緒に考えていきましょう。
監修：プロコンサル Osamu Hirayama 2001年に大手コンサルファームBにジョイン。 ITコンサルタントとして複数のシステム開発プロジェクトのPM・PMOに従事。 2016年よりSIerの取締役として、BtoC向けスマートフォンアプリ開発サービスのビジネススケールに貢献。 2019年にITコンサルファームを設立。大手金融会社の新規事業のIT担当として、脳機能を定期的に測定することにより、認知機能の変化を把握するシステムの開発を担当し自社ビジネスを拡大。
こんにちは、プロコンサルのMASAです。 最初に見てもらったのが、プロジェクトマネージャであれば、押さえておきたいリスク事象の一つです。 このようなリスクが起こりやすいプロジェクトには特徴があります。 特徴1： 顧客の仕様に関する不明点がQA管理されていない。 特徴2： 顧客が業務で利用するデータ項目の定義を理解していない。 特徴3： 顧客が業務改善範囲の優先度は理解しているがシステム機能としてのイメージがない 特徴4： 顧客がプロジェクトで『自分たちがやるべきタスクと実現体制』を洗い出されていない 特徴5： 顧客がプロジェクトのリスクが発生した場合に品質・コスト・スケジュール・要望のどれに影響が出るかを理解していない。 あなたが、参加しているプロジェクトが特徴1〜特徴5に当て放っていたら、炎上プロジェクトの予感がしますので、細心の注意を払ってマネジメントしてください。
このコラムでは、炎上プロジェクトの実例をあなたに紹介することで、プロジェクトのリスクをINPUTしてもらいマネジメントに役立ててもらえればと思ってます。
また、炎上プロジェクトの火消しまでのアプローチをたどれるように、このような順番で解説していきます。
approach1：根本的な問題
approach2：根本的な原因
approach3：解決策
今回は、『要件定義工程で顧客の体制にITプロジェクトの経験者が居ない』というテーマで、話しをスタートします！
**守秘義務により企業名・団体名・個人名等は架空名称となります。
炎上プロジェクトの概要
PMが、要件定義工程で顧客の体制にITプロジェクトの経験者が居ないことによる炎上プロジェクト
1.プロジェクトのスコープと体制
・顧客は大手出版会社である。
・顧客の情報システム部で財務会計の新規構開発を実施。
・システム化スコープは財務会計管理、管理会計管理、社員管理が対象である。
・中堅SierのA社が開発ベンダーとして参画。
・A社は全開発工程の成果物の納品とシステムリリースの責任を請け負う。
・A社の開発体制は業務チーム、基盤チーム、テストチーム、管理チームで構成。
2.プロジェクトの状況
・現在、プロジェクトは要件定義工程を行なっている。
・A社の開発メンバは、PMの作成したWBSで作業を進めていた。
・しかし、要件の確認や確定が一向に進まなかった。
・これはITチームの要件定義の進め方、業務やシステムの理解が不足している訳ではなく、顧客が業務関連部署へのシステム化の説明と要件確定の調整が難航していた。
・そのため、要件定義工程の実施期間を延長しなければならない状態になっている。
*今回の実例は、炎上プロジェクトの特徴として『特徴4：顧客がプロジェクトで"自分たちがやるべきタスク"を洗い出されていないケース』である。
炎上プロジェクトの火消しまでのアプローチ
approach1：根本的な問題の定義
顧客、PM、開発メンバーのヒアリングから今回の根本的な問題を『顧客側でITプロジェクトの経験者を体制に組み込むことが出来ていない』と定義しました。
approach2：根本的な原因の追求
このようなケースでは、『顧客社内でのITプロジェクトの実績有無』、『顧客としてのITプロジェクトの推進知識』、『顧客社内でのITプロジェクト経験者の招集可否』に焦点を当てて根本的な原因を探ることが重要です。
そのため、以下のように原因の仮説を立てました。
(1)原因の仮説
①顧客自体がITプロジェクトの経験がない（会社として初めてのITプロジェクトである）。
②顧客がITプロジェクトでの役割・やるべきことを知らない。
③顧客の社内からITプロジェクト経験者を探して当該プロジェクトに参画させるのが困難である。
(2)仮説の検証
仮説の検証として、関係者へレビューをしました。
(3)根本的な原因
レビューを通じて根本的な原因を探った結果、『顧客の社内からITプロジェクト経験者を探して当該プロジェクトに参画させるのが困難である』ということが判明しました。
approach3：解決策 (1)解決策の案 根本的な原因から3つの解決策（案）を準備しました。 【解決策A】 リリーススケジュールを変更しないように必要最低限のシステム機能をリリース範囲とする。 【解決策B】 要件定義の取り纏めをITチームが支援し、100%の要件を盛り込みリリーススケジュールを変更しないようにタスクを組み替える。 【解決策C】 プロジェクトを中断して、体制を含め計画を見直しをする。 (2)実行した解決策 プロジェクトに問題が起こった場合は、問題の大きさは関係ありません。 プロジェクトの管理要素である『品質』、『コスト』、『スケジュール』、『スコープ』のいずれかを調整することになります。 *プロジェクトの成功のためのトレードオフを仕掛ける。結末は以下の通りとなりました。 (2)実行した解決策 解決策B：要件定義の取り纏めをITチームが支援し、100%の要件を盛り込みリリーススケジュールを変更しないようにタスクを組み替える。 (3)解決策を選んだ理由 ・顧客はスケジュールの遅延をリカバリー出来るのであれば、コスト増加もやむを得ないとの判断があった。 ・顧客がITチームへ要件定義の取り纏めの支援を要請し社内での予算を確保できた。 ・顧客からプロジェクトの中断と要件の絞り込みは避けて欲しいとの要望があった。
教訓の整理（リスク管理表に入れてください）
このような炎上プロジェクトは、リスク対策として、あなたのプロジェクトマネジメントに活かしてください。 プロジェクトは予期せぬトラブルに見舞われるものです。 ITチームが完璧な体制を組んでいたとしても、顧客側の都合で作業が停滞することもあります。 顧客の体制に問題があるからといって、PMがこの問題を放置していけません。 特に、『顧客の体制にITプロジェクトの経験者がいない』となればプロジェクトは進みません。 そのため今回の教訓からリスク対策を以下のように整理しました。 【リスク対策1】 プロジェクト計画工程で顧客がプロジェクトでやるべきことを5W1Hで具体的に説明し合意する。 【リスク対策2】 プロジェクト計画工程で顧客がプロジェクトで『やるべきこと』に対する必要なスキルと経験を説明し合意する。 【リスク対策3】 顧客が各開発工程で必要とされる人材と人数を招集できるように調整する。
教訓をリスク管理表に入れる
今回の教訓をリスク管理表に入れておくと、あなたのプロジェクトマネジメントに深みと厚みが増します。リスク管理表の作り方の参考コラムはこちらです↓
わたしのコラムで、あなたのお役に立てれば幸いです。 品質管理・スコープ管理、今回のようなトラブルプロジェクトの事例、これらをコラムとして配信していこうと思ってます。 ぜひ、今後とも応援を宜しくお願いします。
Comentários