スコープのマネジメントって何するの？

以前にスコープというのは「何を作るか」という範囲のことだという書き方をしました。
PMBOKガイドには、スコープのマネジメントでは、プロジェクトに何が含まれ何が含まれないかを定義しコントロールすることに主眼を置いており、必要なすべての作業かつ必要な作業のみを含むことを確認するというニュアンスで表現されています。
実際には、プロジェクトのスコープとプロダクトのスコープという考え方が示されており、「何を作るか」の部分がプロダクト・スコープであり、プロダクトを生み出すために実行する作業がプロジェクト・スコープになります。

従来型（PMBOKガイドでは予測型）というか計画時点で何を作るか・どんなやり方で作るかをガチガチに決めてしまうようなプロジェクトでは、一旦決めたスコープをスコープ・ベースラインとして正式な変更手続きなしには変更できなくなります。そういったプロジェクトでは柔軟な変更に対応しにくいため、その部分を短所とみなされて嫌われつつあるように思います。（個人の感想です）
そうでないタイプのプロジェクトについては別の機会に書いていきたいと思います。

具体的にスコープ・マネジメントでどういうことをするのかというとPMBOK第6版やPMIの実務ガイドでは次の6つのプロセスが書かれています。
・スコープ・マネジメントの計画
・要求事項の収集
・スコープの定義
・WBSの作成
・スコープの妥当性確認
・スコープのコントロール

このうち上4つは計画プロセス群の範疇になります。最初に決めたら最後まで同じということではありません。実際には計画プロセスは1回きりではなく、各種の変更要求によって計画は変更される可能性があり、統合変更管理によって何度も計画プロセスは実施されます。
ただ、安易に変更するものではないため、しっかりと何を作るか・どうやって作るかを見極めなくてはいけません。

プロダクト・スコープにしろ、プロジェクト・スコープにしろどこまでがスコープの範疇なのかをできるだけ詳細化して文書で合意しておかないと後で揉める原因となります。
難しいのは、ユーザなりお客様が何を求めているか、プロジェクトの実施結果によってどんな価値を提供できるかということから、具体的なプロダクト・スコープを定義していくことではないでしょうか。

また、スコープありきの考え方になりますが、スコープを決めてからスケジュール、コスト（場合によっては品質に関しても）を見積もるのが従来型プロジェクトの特徴です。