無茶なスコープを縮小させる方法


writing by MASA *このコラムはiPM naviで配信しています ITプロジェクトは、『クライアントのやりたいこと』を要件定義工程で決めていきます。

やりたいこと(=要件)がプロジェクトで定められたリソース(スケジュール、予算、工数等)で対応できるのであれば良いのですが... 一般的にはリソースを逸脱することが多いものです。 そのとき、限られたリソースで要件を可能な限り実現しなければなりません。 しかし、限界があり要件を縮小しなければ...そんな時もあります。 闇雲に縮小することでクライアントとの関係が悪くなることもあります。 PMであれば、クライアントを上手にリードしながら『やりたいことの優先度』を付けなければなりません。

 

監修:えのきのキャリア 2003年に大手コンサルファームにジョイン。 数年間のオープン系システムのインフラエンジニアを経験したのち、プロジェクトマネジメント関連業務へキャリアチェンジ。 以降中小から大規模までさまざまなプロジェクトにおいてPM/PMO業務に従事。 製造業、メディア、金融、官公庁など、業界を問わず経験しており、クライアントの様々な文化に柔軟に対応している。近年ではシステム関連の知識を生かし業務コンサルテイング領域でも活動中。

 

こんにちは、プロコンサルのMASAです。

iPM PREMIUMで運営しているオンラインサロンでは、プロコンサルが企業さまのPMへ個別のレクチャーやプロジェクトの後方支援を行なっています。 その活動を通じて、プロジェクトを成功に導くために活用した大手コンサルファームならではの特別なノウハウやメソッドをコラムにしています。


今回のコラムは、SIerに勤務する25歳のPMの方からのご相談となります。


iPM navi無料メンバーに登録するとMASAさんの他のコラムが読み放題です。 無料メンバー登録はこちら(今すぐ無料メンバー登録する




目次

PMからのご相談

こんな時は、こうしてみれば良いですよ!

まとめ


PMからのご相談

■相談者 SIerに勤務する25歳のPM ■相談内容 わたしは、社会人3年目のIT企業に勤める25歳です。 今回のプロジェクトで初めてPMを担当しています(PM未経験者)。 ①現在、プロジェクトは基本設計の終盤です。 ②今回のプロジェクトは、クライアントの要件が多いことから優先度を付けて必要な要件に絞りました。 ③しかし、優先度合いを『絶対やりたい』、『やりたい』、『できるならやりたい』と設定したため、 ④全ての要件が『絶対やりたい』という結果になりました。 *優先度合いを間違った。 ⑤そのため、計画段階で組んでいたスケジュールと工数が大幅に超過する予定であり失敗プロジェクトの危機です。 ⑥どうにかして要件を縮小しスケジュールと工数の範囲内に抑えたいのですがアイデアが浮かびません。 相談のポイント ①当該プロジェクトは、要件ボリュームが多いためプロジェクトリソース(スケジュール・工数)の上限を超える可能性が高い。 ②相談者は、要件に対して優先度(度合い)を間違えた。 ③相談者は、要件ボリュームを縮小る方法を模索している。 あなたが、PMであればどのように対処しますか?


こんな時は、こうしてみれば良いですよ!

このように前提条件を整理しました。 ・プロジェクトのリリース日の延長は認められない。 ・クライアントが、納得いく方法であれば、要件ボリュームの縮小を検討する。 ・プロジェクトに必要とされるスキルを有したメンバーでチームは構成されている。 ITプロジェクトは、クライアントの『やりたいこと』を全て聞き出し整理することは間違えではありません。 しかし、リソースの範囲内で『やりたいこと』を実現できないのであれは、リソースを増やす、もしくは、やりたいこと(=要求)を縮小するのいずれかの選択となります。 特に、プロジェクト実行中に要件を縮小するには、難易度の高いクライアントへの説得方法が必要です。 そのため、全て出揃った要件に対して、優先度を付ける方法をとりますが、ITパートナーの都合による優先付けになってはいけません。 あくまでも、クライアント目線になって『将来的にビジネスとして効果を発揮できる要求』に対して、優先度を付けていきます。 まずは、このことを認識して、この問題をアプローチしていきましょう! *このアプローチはDX時代に適応したリスキリングしているPMの方にも実用的に使えます。


 

アプローチ1 要件が、将来的にビジネスとして効果を発揮できるか調査する。

アプローチ2 プロジェクトの前提条件・前提条件を逸脱しないように、要件に対して優先度を付ける。 アプローチ3 必要に応じて縮小したスコープに対してWBS・タスクネットワークを見直す。 アプローチ4 必要に応じてプロジェクトに必要なスキルを見直す。 アプローチ5 必要に応じてITパートナーのプロジェクト体制を見直す。

 
まとめ

要件定義工程では、クライアントが「何をしたいのか?」 これを具体的に「どのようなシステムにしたいのか?」を決めていく作業と認識している方も多いものです。 これは正しいことですが、実は落とし穴があります。 クライアントの要求仕様は、優先度を付けないと品質・コスト・スケジュールに大きなインパクトを与えて、プロジェクトは破綻します。 例えば、 ・要件が明確になるのは詳細設計を行わないと決められない。 ・クライアントも要件を提示しているが理解できていない。 このようなことは、頻繁にプロジェクトでは起こるものです。 それであれば、プロジェクト計画の段階で、バッファー工数(予備コスト)を積んでおくのも、一つの手です。 しかし、現実は難しいことではないでしょうか? そのため、要件には優先度を付けるという対処を行う場合もあります。 ポイント❗️ ・要件がクライアントのビジネスの有効であるかを調査する。 ・優先度を付ける。 ・必要に応じてスケジュール、工数、体制…etcを見直す。 これらを、しっかり実施することで、プロジェクトを円滑に実行することができるでしょう。 最後まで、読んでいただき有難う御座いました。

 

PM naviは、PM初心者・PMスキルをアップしたい方、DX時代に適応するためリスキリングしているPMの方。

そのような方々へ、プロジェクト計画・管理・問題解決…etcのお悩みを解決するために、無料メンバーになると便利なサービスがご利用頂けます。