PMIイズム#2 「プロジェクト推進時に、スコープの範囲に目を光らせる」

スコープマネジメント

プロジェクトマネジメントにおけるスコープとは、「プロジェクトの作業範囲(やること、やらないこと)」のことです。
つまり、スコープ範囲内ならやる、範囲外ならやらないが正となります。
何らかの依頼が発生した際、PM/PMOはまずその依頼がスコープの範囲内であるか?を確認します。つまり、依頼を受ける/断る前にスコープ範囲を確認し、正しい判断を下す必要があります。この様な問題はPMP対策のeラーニングにも多く登場します。
また、結論としてスコープマネジメントではスコープについて以下のような取り組みが求められると考えます。

・ぱっと引き出せるようにする。

・変更が発生したらすぐに関係者に共有し、かつ履歴を残す。

・変更により影響を受ける人に納得いただき、今後のプロジェクト推進を考える。

スコープについて私自身が最も重要と考えていることは、
「スコープの変更が発生した時、そこに目を光らせ、プロジェクト全体に共有し、特にスコープの変更により影響を受ける人と認識を合わせ、合意を形成すること」であると考えます。
特に、アジャイル開発では要件が頻繁に変わる前提となり、ウォーターフォールにおいても予定や見通しは頻繁に変わり、場合によっては毎日のようにWBSに更新が発生します。ここで、誰かが認識を誤ったまま作業を進めてしまうことが最も危険と考えます。
私はJPS入社前にはSIer企業でエンジニアとして活動していましたが、
スコープの範囲が曖昧なまま進んでいくプロジェクトを多く経験しました。
具体的には、スコープに変更が生じた際、


・変更の根拠に関するエビデンスが残らず口頭だけで話が進んでしまう。

・上位から下位への伝言ゲームが一方的に進み情報の質がどんどん劣化する。

・スコープの変更について説明が無いまま作業を強引に依頼される。

といった事象が頻繁に発生しました。
こうなってしまうとプロジェクトは悪い方向に向かうだけ、ということは言うまでもありません。
最後に、スコープの変更をどのように管理・共有するか?になりますが、こちらは朝会等、関係者が多く集まる場で共有するのが効果的と考えます。そして、スコープの変更による影響についてその場でまとめて吸収できれば最も確実かつ効率的であると考えます。さらに、変更の履歴や理由等について文書に残す取り組みも必要になります。
私が現在所属しているプロジェクトでは、こちらを打ち合わせの議事に記載することで関係者に共有して履歴を残す、そして、スコープの変更により影響を受けるメンバーには詳細を個別に説明する取り組みを行っていますが、これらのアクションを進めることでプロジェクトが良い方向に向かった、と確かな感触を得られています。

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です