writing by OSAMU *このコラムはiPM naviで配信しています プロジェクト計画で、スコープを雑に決めると設計フェーズ以降はマネジメントが窮屈になっていきます。 ・スケジュール遅延 ・予算超過 ・クライアントとのコミュニケーション悪化 これらが原因でプロジェクトが破綻することも！ あなたが、これらを回避するには計画段階で、RFPやSOWを元にしてスコープ対象を調査することです。 PMであれば、事前調査の方法を理解していなければなりません。 意外にも、このことを知らないPMが多いってご存知でしょうか？
監修：えのきのキャリア 2003年に大手コンサルファームにジョイン。 数年間のオープン系システムのインフラエンジニアを経験したのち、プロジェクトマネジメント関連業務へキャリアチェンジ。 以降中小から大規模までさまざまなプロジェクトにおいてPM/PMO業務に従事。 製造業、メディア、金融、官公庁など、業界を問わず経験しており、クライアントの様々な文化に柔軟に対応している。近年ではシステム関連の知識を生かし業務コンサルテイング領域でも活動中
こんにちは、プロコンサルのOSAMUです。 私が参加しているiPMでは、PM初心者のスキルアップやDX時代に適応したいPMのリスキリングのサポートとして、iPM TRAININGを運営しています。 その中のオプションサービスとして、『トラブルプロジェクトの実例から学ぶ失敗しないマネジメント』をお伝えしています。 このコラムでは、読者のあなたへ、実際に私が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%超過することになった。
教訓（リスク管理表へ整理）
今回の原因は、テストの難易度の設定が間違っていた（または、行なっていない）ということであった。 このような事態を、事前に回避することはできる。 それは、プロジェクト計画の段階でこれらを実施することで防止できるのである。 ・クライアント要件を実現する難易度を設定しスコープ対象の判断を行う。 今回のトラブルプロジェクトをリスク管理表に整理したので、あなたのマネジメント業務で活用して頂ければ幸いである。
最後まで、読んでいただき有難う御座いました。
プロコンサル OSAMUさんのコラムを、もっと読むにはiPM naviメンバーサイトへログインして下さい。 アカウントをお持ちでない方は、画像をタッチして無料メンバーに登録して下さい