その変更管理って正しいですか？品質の劣化が起きてませんか？
・PMを目指している。
・PM初心者でも失敗しないプロジェクト管理をやりたい。
・破綻プロジェクトからマネジメントを学びたい。
・プロジェクトの実例からリスク情報を集めたい。
そこで本コラムでは、iPM naviに参加している大手コンサルファームの社員・出身者が、実際にPMアドバイザーで参画した破綻プロジェクトを立て直した実例を紹介します。
お疲れ様です、ゆーろー@常駐しないPMOです。
わたしがプロコンサルとして参加しているiPM naviの”えのき”さんが、実際にPMアドバイザーで参画したプロジェクトとなります。
それではご覧ください♪
from えのき's column
プロジェクトは計画段階で、変更管理ルールを策定していますか？
多くのPM の答えは「YES」です！
しかし、変更管理ルールを守っているプロジェクトは少ないものです…
それはなぜか？
PMが顧客から継続受注したいがあまり、ルールを無視して無理やり仕様追加・変更を受け入れているからです。
その結果、プロジェクトが破綻することもあります。
ルールを破らざる得ないときはあるでしょう…
PMなら、プロジェクト計画で前提条件・制約条件で、このようなことをリスクヘッジできるようにプラニングしなくてはなりません。
このmanagement lessonは、多くのプロジェクトマネージャが身に覚えがあると思います。
プロジェクトが破綻する根本的な原因は計画のミスです。
このコラムで紹介する破綻プロジェクトは計画段階で、PMが必要なスキルを持っていなかったことで起こった実例です。
こんにちは、プロコンサルのえのきです。
今回は、『その変更管理って正しいですか？品質の劣化が起きてませんか？』というテーマです。
あなたのマネジメント業務で活用できるように、解決までのアプロローチを以下の順番でお伝えします。
・プロジェクトの状況
・問題の設定
・原因追求
・解決策
・教訓（リスク管理表へ整理）
👍 今回のコラム
むずかしさ ：
★★☆☆☆（PM初級者向け）
気付き学び ：
★★★★★(前提条件・制約条件のミスによるリスク)
お役立ち ：
★★★★★(スコープ管理)
プロジェクトの状況
1.プロジェクトのスコープと体制
・顧客はネット通販会社。
・顧客の情報システム部で新規構開発を実施。
・情報システム部の窓口は木村。
・プロジェクトオーナーは情報システム部の山田。
・システム化スコープは商品管理、仕分管理、配送管理。
・中堅SierのA社が開発ベンダーとして参画。
・A社は全開発工程の成果物の納品、システムリリースの責任を請け負う。
・A社の開発体制は業務チーム、基盤チーム、テストチーム、管理チームで構成。
・A社のPMは佐藤（初心者PM）
2.プロジェクト目標
品質目標：100%の不具合修正
スケジュール目標：予定通りのリリース
コスト目標：予算内でのシステム完成
3.プロジェクトの進捗状況
現在、プロジェクトは基本設計工程であり、所要期間の50%が経過した。
仕様変更が多発したことから当初の要件の品質を担保できず設計の品質劣化が起こっている。
そのため、顧客の情報システム部 木村に再度要件を整理して要件定義をやり直しを依頼した。
しかし、木村から
「様々な部署から改めて要望が出てきている。」
「変更に関するルールはお互いに決めていない。」
「当初の計画通り進めてほしい。」
と一蹴された。
佐藤は状況を把握しているが、具体的な問題や解決策が分からない状態である。
**守秘義務により企業名・団体名・個人名等は架空名称となります。
問題の設定
*私がアドバイザーとして、プロジェクトに参画して解決させた経緯のスタートです。
問題を考える場合は、どのマネジメント領域で発生したかを分類することで、後続のアプローチがスムーズに行え、得られた結果の根拠も説得力を持つ。
そこで、今回の問題は、プロジェクトで起きた事象を、様々なプロジェクト情報から考えをもとに考たところ『品質マネジメント領域』で発生した問題として取り扱った。
また、今回のプロジェクトの問題をこのように設定した。
”変更管理ルールが無いことから品質劣化”
この問題を放置することで、品質目標である要望達成率100%を逸脱する恐れがあった。
様々なプロジェクト情報
プロジェクト計画書、レービュー結果報告書、要求変更書、レビュー対象物、作業実績情報、作業範囲記述書、要件定義書、成果物一覧、課題問題整理表、役割分担表、要員の選定根拠、勤務表、成果物、関係者からのヒアリング結果
原因の追求
原因を特定するためには関係者へのヒアリングが重要である。
しかし、闇雲に関係者から聞き取りを行っても時間の無駄であることから原因の仮説を3つ立てた。
1.原因の仮説と検証
仮説1
リスクバッファー工数が間違っていた。
仮説の検証
有識者が算出したリスクバッファーは計画段階と同じだったか？
【 検証結果 】
ほぼ同じリスクバッファー工数であった。
仮説2
リスクを吸収する所要期間が間違っていた。
仮説の検証
有識者が算出したリスク対応期間は計画段階と同じだったか？
【 検証結果 】
ほぼ同じリスク対応期間であった。
仮説3
変更管理ルールが無かった。
仮説の検証
プロジェクト計画書に仕様追加や変更に関する変更管理ルールの記載があったか？
【 検証結果 】
変更管理ルールの記載が無く、仕様追加や変更に伴う顧客との協議形成が構築されていなかった。
2.今回の問題の原因
変更管理ルールが無かった。
と判明した。
また、PMは要件定義工程で顧客から品質合格を受理していたことから、後続工程での仕様追加や変更は起こらないと判断していたことが分かった。
解決策
わたしは3つの解決策を準備した。
解決策A
全ての仕様変更を等がプロジェクトで達成できるように、プロジェクト計画を見直す。
解決策B
変更管理ルールを策定し、ビジネスインパクの強い仕様変更のみを当該プロジェクトで吸収し実現する。
解決策C
変更管理ルールを策定し、ビジネスインパクの強い仕様変更のみを当該プロジェクトで吸収し実現する。
その上でスケジュールを延期する。
現在のプロジェクトの状況とこの解決策の案をPO山田へ提言した。
PO山田は、このような意向があった。
⚫︎ スコープについて ビジネスインパクトの強い仕様を変更のみを対象にすることに問題はなし。
⚫︎ スケジュールについて スケジュールの延期はできない。
このことから、解決策Bを採用した。
また、この解決策を施行することで、開発ベンダーA社は変更管理ルールの策定による工数が必要となり、計画工数を30%超過することになった。
教訓（リスク管理表へ整理）
今回の原因は、変更管理ルールが無かったということであった。
このような事態を、事前に回避することはできる。
それは、プロジェクト計画の段階でこれらを実施することで防止できるのである。
・スコープ計画の検討を行うときに変更管理ルールを策定し合意する。
・仕様追加や変更が発生した場合は品質、コスト、スケジュール、スコープへのリスクを調査してクライアントと協議することをプロジェクトの前提条件や制約条件として設定する。
今回のトラブルプロジェクトをリスク管理表に整理したので、あなたのマネジメント業務で活用して頂ければ幸いである。
最後まで、読んでいただき有難う御座いました。
アンケートのお願い
いいなと思ったら応援しよう！
