writing by MIRIO
システム開発で顧客のニーズを実現するのは、大変難しいものです。 緻密な計画を立てても、予想外のトラブルが起こったり、開発途中で顧客の仕様変更を受け入れタスクの組み替えをしたりと、プロジェクトマネージャは気を抜く暇がないポジションですよね。 しかし、プロジェクトの推進を”場当たり”的に行なっていくPMがいたら、一体どうなるのでしょうか？ このようなPMに、メンバーが信頼を寄せることはありませんよ。 言わずともプロジェクトは大炎上ですよね❗️ あなたの周りにこのようなことで困っているプロジェクトチームはありませんか？ あなたが、このような炎上プロジェクトの主役にならないように『PMは顧客・開発メンバから信頼されていない』をリスクと捉えPJ計画の段階でリスク管理表に書き込んでおいてくださいね。
監修：プロコンサル Yuichiro Hayashi 2000年に大手コンサルファームBにジョイン。 同社の創業時からパートナーとして、セールス・コンサルティングとあらゆる組織で活躍しビジネスの拡大に貢献。 2005年にコンサルファームを設立。総数2,000以上のプロジェクトに携わり、経験したプロジェクトの検証と分析から『現場で使えるノウハウやリスク情報』を法人顧客やフリーランスPMOに提供。 2020年に大手クラウドソーシング 取締役としてジョイン。大手コンサルファームBでのセールススキルを活かして同社スタートアップサービスの拡大に貢献。
最初に見てもらったのが、プロジェクトマネージャであれば、押さえておきたいリスク事象の一つなんですね。 このようなリスクが起こりやすいプロジェクトには特徴があるんです。 特徴1： PMがプロジェクトのスコープを曖昧に理解して進めている。 特徴2： 開発メンバがWBSに従わず独自の判断で進めている。 特徴3： 顧客と合意したスコープに対して、不要な要件を排除しないで進めている。 特徴4： 開発メンバ・顧客とのコミュニケーションルールに不備がある。 特徴5： PMが顧客と合意したスコープに対して正しくWBSに落とし込めていない。 あなたが、参加しているプロジェクトが特徴1〜特徴5に当てはまっていたら、炎上プロジェクトの予感がしますので、細心の注意を払ってマネジメントしてくださいね。
このコラムでは、炎上プロジェクトの実例をあなたに紹介することで、プロジェクトのリスクをINPUTしてもらいマネジメントに役立ててもらえればと思ってます。 また、炎上プロジェクトの火消しまでのアプローチをたどれるように、このような順番で解説していきます。 approach1：根本的な問題 approach2：根本的な原因 approach3：解決策 今回は、『PMが”場当たり”的に基本設計工程でWBSを変更するため顧客や開発メンバからの信頼を失った』というテーマで、話しをスタートしますね！ **守秘義務により企業名・団体名・個人名等は架空名称となります。
時短したい人は30秒動画でこのコラムのポイントをお伝えしてます!!
*メンバー登録（無料）する前にiPM naviでどんなことができるのか？を確認する。
炎上プロジェクトの概要
PMが”場当たり”的に、基本設計工程でWBSを変更するため顧客や開発メンバからの信頼を失ったことによる炎上プロジェクト 1.プロジェクトのスコープと体制 ・顧客は大手製造メーカーである。
・顧客の情報システム部で基幹業務の新規構開発を実施。
・システム化スコープは商品管理、受注管理、課金管理が対象である。
・中堅SierのA社が開発ベンダーとして参画。
・A社は全開発工程の成果物の納品とシステムリリースの責任を請け負う。
・A社の開発体制は業務チーム、基盤チーム、テストチーム、管理チームで構成。
2.プロジェクトの状況 ・現在、プロジェクトは基本設計工程を行なっている。
・A社の開発メンバは、PMの作成したWBSで作業を進めていた。 ・WBSは『計画に無かったタスクが突然現れる』、『タスク順序が間違っている』、『スコープ変更に伴って不要となった要件を盛り込んだタスク…etc』と精度が低い。 ・これは、今に始まったことではなく要件定義工程でも頻繁に起こり、顧客からA社へクレームも多かった。
・開発メンバは、PMを信頼できなことから各自の経験でタスクを考え作業を進めていた。 ・このことから、マネジメント不能になり進捗の遅れや品質の悪さが目立ち始めた。
・プロジェクトを正常化するには、PMとメンバの協力関係の再構築が必要でありリリース日を延期せざる得ない状況になった。 *今回の実例は『特徴5：PMが顧客と合意したスコープに対して正しくWBSに落とし込めていないケース』である。
炎上プロジェクトの火消しまでのアプローチ
approach1：根本的な問題の定義
顧客、PM、開発メンバのヒアリングから今回の根本的な問題を『PMは顧客・開発メンバから信頼されていない』と定義しました。 approach2：根本的な原因の追求 このようなケースでは、『開発メンバのスコープの理解』、『コミュニケーションルールの周知と認識』、『WBSの品質精度』に焦点を当てて根本的な原因を探ることが重要です。そのため、以下のように原因の仮説を立てました。 (1)原因の仮説 ①開発メンバは必要・不要の要件を理解していない。 ②作業を進めていく上での懸念等をエスカレーションする仕組みがない。 ③WBSが顧客要件をシステム化設計できるようにタスク割されていない。 (2)仮説の検証仮説の検証として、関係者へレビューをしました。
(3)根本的な原因
レビューを通じて根本的な原因を探った結果、『WBSが顧客要件をシステム化設計できるようにタスク割されていない』ということが判明しました。
approach3：解決策 (1)解決策の案 根本的な原因から3つの解決策（案）を準備しました。 【解決策A】 プロジェクトマネジャーを交代する。 【解決策B】 プロジェクトマネジャーの弱点を補えるようにフォローアップ出来るメンバーをアサインする。 【解決策C】 チームの中のPM経験者をプロジェクトマネジャーに昇格させる。 (2)実行した解決策 プロジェクトに問題が起こった場合は、問題の大きさは関係ありません。 プロジェクトの管理要素である『品質』、『コスト』、『スケジュール』、『スコープ』のいずれかを調整することになります。 *プロジェクトの成功のためのトレードオフを仕掛ける。結末は以下の通りとなりました。 【解決策】 解決策B：プロジェクトマネジャーの弱点を補えるようにフォローアップ出来るメンバーをアサインする。 【解決策を選んだ理由】 ・開発会社からPMのスキルアップのため交代は避けたいとの意向があった。 ・PM育成のために開発会社で支援メンバを参画さ得るのであれば現在のPMが継続することに異論はない。
教訓の整理
このような炎上プロジェクトは、リスク対策として、あなたのプロジェクトマネジメントに活かしてくださいね。 プロジェクトが失敗する大きな要因の一つとして『WBSの精度』が挙げられます。 WBSの精度が低いと、その場の状況に合わせてWBSを変更する、または作り直すといった無駄な作業が発生します。 これは、今までの成果を台無しにするどころか、作業の手戻りというコストの増加や顧客・開発メンバのモチベーションを下げる結果となりプロジェクトチームの崩壊を招く可能性が高いものです。 このように安易に考えでマネジメントした結果、プロジェクトが炎上しデスマーチになるケースも多いものです。PMは、リスク事象として頭の中にインプットしておき、プロジェクト工程の中で何かしらの工夫が必要となります。
QAセッション
失敗プロジェクトの原因に関する質問に答えるQ&Aセッションを設けています。 皆さんの疑問や質問に対応することができます。 失敗プロジェクトに対する理解を深め、同じような失敗を回避するためのアドバイスをします。 iPM naviのサイトにアクセスしてコミュニティーに登録してください。 大手コンサルファームの社員や出身者が無料でアドバイスします。 ファームの人材とコミュニケーションが取れるイイ機会です。 是非、ご利用ください。 またコミュニティでは今回の失敗プロジェクトをプロジェクトの教訓としてリスク管理表にまとめました。 こちらも併せてチェックしてください!!
*メンバー登録（無料）する前にiPM naviでどんなことができるのか？を確認する。
最後まで読んでくれて有難う御座いました。
プロジェクトマネージャーを目指すなら必見！計画書の作り方を解説
プロジェクトマネージャーになるために欠かせないスキルの一つが、プロジェクト計画書の作成です。 しかし、初めて計画書を作成する人にとっては、何から手を付けていいか分からず苦戦することもあります。 そこで、プロジェクト計画書の作成手順を分かりやすく解説します。
